{"id":"8c599c58-f3eb-42f1-bc2d-6c562138e677","arxiv_id":"2501.04841","paper_version":3,"verdict":"REJECT","confidence":"MODERATE","novelty_score":2.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"A student prototype applies Ethereum smart contracts to used-car auctions, claiming security and privacy gains, but ships no code and offers no comparison to existing systems.","lead":"This paper describes a prototype used-car auction system built on Ethereum smart contracts, allowing sellers to list vehicles and buyers to bid on them. It is a course-project write-up with no released code, no comparison to existing systems, and an admitted list of unaddressed bugs.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"§V.D describes auction end as 'transfer money from the previous owner to the buyer', reversing the payment direction stated in §V.B ('send its money to the car owner'); the central auction settlement logic is internally inconsistent.","rationale":"The reader's weakest assumption is that the Solidity code correctly implements the auction and payment rules. My concern is a concrete instance where the paper contradicts itself on exactly that point: the use-case description and the algorithm description specify opposite payment directions at auction settlement. If the code follows §V.D, the system is economically broken; if it follows §V.B, then the paper's central algorithm section is wrong. Either way, the central claim of a working, secure vehicle auction is not supported. Because no source code or executable artifact is provided, the contradiction cannot be resolved from the manuscript alone. The paper's own Limitations section admits unresolved conditional-judgment issues and unfamiliarity with smart-contract internals, further undermining the assumption of correct implementation. This is not a disagreement with the research community's consensus; it is an internal inconsistency in the paper's own description of the core mechanism. The reader's REJECT verdict remains appropriate, so no change to the verdict is needed.","tokens_in":8474,"tokens_out":4708,"duration_ms":43578,"concrete_test":"Ask the authors to release the Solidity source (promised in §VI Limitations as a future GitHub upload), locate the auction-end/withdraw functions, and run a test on the Ropsten transaction shown in Figure 11 that logs the ETH balance changes of the winning bidder and the previous owner. If the previous owner's balance decreases and the buyer's balance increases, the implemented payment direction is reversed and the central auction claim fails; if the buyer pays, then §V.D is wrong and the paper still needs a corrected, verifiable description.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central claim is a functioning smart-contract vehicle auction in which bidding and payment rules are executed on-chain. For that claim to hold, the auction-end settlement must move funds from the winning buyer to the car's current owner, and transfer ownership from that owner to the buyer. The paper's own use-case description states this: 'When he wins the bid, the system will send its money to the car owner' (§V.B). However, the Algorithm Design section for ending the auction says the opposite: 'the system will transfer money from the previous owner to the buyer, and change the owner of this car' (§V.D, Figure 11). This is not a minor wording issue. If the deployed contract follows the §V.D description, the winning bidder receives money while the seller pays and loses the car, making the auction economically nonsensical; if the description is a typo and the code follows §V.B, the paper misdescribes the core mechanism. No source code is released to resolve the ambiguity, and the Limitations section explicitly says 'our code may have ignored these issues' and 'we are not familiar enough with the underlying architecture of the smart contract code.' Thus the load-bearing assumption that the smart contract correctly implements auction and payment rules is unsupported and internally contradicted.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes a blockchain-based used-car auction system built on Ethereum smart contracts. It describes two contracts (Car Repo and Car Bid), a price estimation routine, a bidding procedure, and an auction-end settlement, and reports a small set of Remix/Ropsten screenshots as evaluation. The abstract claims that the smart-contract design enhances the security and privacy of vehicle trading, and the conclusion repeats that the use of smart contracts improves security and privacy.","tokens_in":8691,"tokens_out":4621,"duration_ms":43803,"significance":"If the implementation were correct and publicly verifiable, the system would be a straightforward application of standard smart-contract auction patterns; the contribution over existing blockchain auction designs is incremental. The paper's honest Limitations section is a strength, but it also concedes a missing frontend, unreleased code, and possible conditional-judgment bugs. No formal analysis, security evaluation, or reproducibility artifacts are provided, so the claimed security and privacy benefits are not established.","major_comments":[{"comment":"The auction settlement direction is described inconsistently. Section V.B states that when a buyer wins, \"the system will send its money to the car owner.\" Section V.D and Figure 11 state that at auction end, \"the system will transfer money from the previous owner to the buyer, and change the owner of this car.\" These are opposite cash flows. If the deployed contract follows Section V.D, the winner receives money while the seller pays and loses the car; if it follows Section V.B, the paper misdescribes the core mechanism. Because no source code is provided, the reader cannot determine which behavior is implemented. This contradiction directly affects the central claim that smart contracts enforce the auction and payment rules.","section":"V.D / V.B"},{"comment":"The privacy claim in the abstract (\"enhances the security and privacy of the system\") is contradicted by the paper's own analysis in Section III.B, which states that blockchain confidentiality is weak and that all transaction data, smart contract code, and state values are public. The design does not include encryption, off-chain storage, or any other privacy mechanism, so the claimed privacy enhancement is unsupported.","section":"III.B / Abstract"},{"comment":"The evaluation consists only of screenshots of a car being added, a price of 8898 being computed, an owner being changed, and bids being recorded. There is no source code, no transaction hash, no test of the auction-end settlement, no gas-cost analysis, and no adversarial or edge-case testing. The Limitations section concedes that the code is not uploaded and that the authors are \"not familiar enough with the underlying architecture of the smart contract code.\" Consequently, the central claim that the system functions as a secure auction is not substantiated.","section":"VI"}],"minor_comments":[{"comment":"There is a typo in the first paragraph of Section I.A: \"Managers cannutilize the data\" should read \"Managers can utilize the data.\"","section":"I.A"},{"comment":"The event names \"autionNotYetEnded\" and \"AuctionEndAlreadyEnd\" appear to be misspelled (likely \"auctionNotYetEnded\" and \"AuctionEndAlreadyEnded\").","section":"V.D"},{"comment":"The price estimation procedure is described only qualitatively (\"several standards are applied\" based on age, mileage, accident history, and trade times) with no formula or calibration, so the single output value 8898 in Section VI cannot be reproduced or validated.","section":"V.C"},{"comment":"Several references are either self-citations to unrelated preprints (e.g., [7], [12], [17], [25]) or citations to non-blockchain works (e.g., [2], [20], [24]); these do not ground the technical claims and should be replaced with relevant literature.","section":"References"}],"recommendation":"reject","confidential_remarks":"The paper reads like a course project report rather than a research article. The citation pattern raises concerns: several references are the author's own preprints or unrelated TechRxiv papers, which does not inspire confidence. The internal contradiction in the auction settlement direction and the conceded lack of code make the central claim unverifiable; the privacy claim is further contradicted by the paper's own analysis. This manuscript likely falls below the bar for a serious venue."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You asked for a candid read of arXiv:2501.04841. The short version: this is a course-project write-up, not a research paper. The central claim—a working, secure, privacy-enhancing vehicle auction on Ethereum—is unsupported. No code is released, the evaluation is four screenshots, and the authors' own Limitations section admits to unresolved conditional-judgment bugs, a missing frontend, and unfamiliarity with the smart contract architecture.\n\nWhat the paper does reasonably well: it describes a clean two-contract design (car registry plus auction house), gives clear use-case and class diagrams, and the price estimator is simple but at least explicitly stated as a heuristic. The authors are also refreshingly candid about what they did not finish. That honesty earns some credit.\n\nThe soft spots are load-bearing, though. The stress-test note is right: §V.B says the winning bidder's money goes to the car owner, but §V.D and Figure 11 say the system transfers money from the previous owner to the buyer. Those cannot both be true. Either the deployed contract does something economically nonsensical, or the paper misdescribes its own mechanism. With no source code, you cannot tell which. This is not a minor wording slip; it is the core settlement logic.\n\nBeyond that, the paper never compares against prior blockchain auction or vehicle-trading systems, despite the related-work section citing car-sharing contracts. The citation pattern is also odd—several references are self-citations to unrelated preprints on community detection, housing prices, and GNNs. The security analysis is textbook-level and never substantiates the abstract's privacy claim; in fact, the paper correctly notes that blockchain data is public, which undercuts that claim.\n\nThe evaluation is screenshots only: a car added, a price of 8898 computed, an owner changed, bids recorded. No gas costs, no adversarial testing, no coverage of failure cases. The admitted missing code and unresolved bugs are exactly the evidence needed to evaluate a smart contract system.\n\nWho is this for? Maybe a student wanting a record of a class project. A research reader gets nothing new: the pattern is standard, the evaluation is anecdotal, and the core logic is internally inconsistent. I would desk-reject this. If the author wants a real paper, they need to release and verify the code, fix the payment-direction contradiction, and benchmark against existing systems. Not worth referee time as-is.","headline":"A candid course-project write-up: honest about its own limits, but the core auction logic is internally contradictory and no code or data backs the central claim.","tokens_in":9202,"tokens_out":1589,"would_cite":false,"duration_ms":17205,"reading_group":"no","serious_thinker":"no","would_accept_peer_review":false},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper claims a decentralized used-car auction can be enforced by two Ethereum smart contracts that handle bidding, payment, and ownership transfer.","keywords":["blockchain","smart contracts","Ethereum","Solidity","vehicle auction","decentralized application","ownership transfer","security analysis"],"falsifier":"Deploy the two contracts on a public testnet and run an adversarial transaction sequence: a bid placed after the auction end time, a bid below the computed floor price, a bid below the current highest bid, and a second withdrawal after an earlier withdrawal. If any of these transactions succeeds when it should be reverted, or if an auction-end call can be reentered to drain funds, the claim that the contracts enforce the auction rules is false.","tokens_in":8251,"feed_emoji":"🚗","tokens_out":8745,"duration_ms":82121,"temperature":0.7,"pith_summary":"This paper tries to show that a used-car auction can be moved onto the Ethereum blockchain, replacing a central server with two smart contracts that store vehicle information, run the bidding, and transfer ownership. The motivation is that centralized marketplaces have a single point of failure and can tamper with records, while blockchain transactions are replicated and tamper-resistant. The paper builds a Solidity prototype in which a car registry contract maintains cars and computes estimated prices, and an auction contract accepts only valid bids, ends the auction at a set time, pays the owner, and lets losing bidders withdraw. The paper also argues that blockchain provides integrity and availability, though it concedes that confidentiality is weak and that the prototype code has not been fully checked for conditional-judgment and security pitfalls. If the prototype works as described, it would be a small demonstration that vehicle ownership records and auction rules can be enforced by code rather than by a trusted operator.","feed_headline":"Smart contracts enforce a used-car auction on Ethereum","feed_subtitle":"A prototype swaps the central server for code that checks bids, holds funds, and transfers car ownership.","key_machinery":"The load-bearing objects are the two contracts and the data they share. The car registry contract acts as a repository: its car mapping holds vehicle records, and its price-calculation function turns mileage, age, accident history, and trade count into a floor price. The auction contract acts as the auctioneer: a trade-car structure carries the car's identity and the computed floor price, and the bid function enforces three conditions (auction still open, bid above current highest, bid above floor price) before updating the leader. The withdraw function returns money to losing bidders, and the auction-end routine transfers the winning amount to the owner and reassigns the car. The whole design assumes that whatever the contracts enforce is what happens, because each transaction is executed by the Ethereum network and cannot be silently changed.","core_discovery":"The central claim is that a decentralized vehicle auction can be implemented as a pair of Ethereum smart contracts. The car registry contract stores a mapping of car records, lets an agent add cars, upload accident-history costs, fetch current owners, and compute a sale price from age, mileage, accident history, and trade count. The auction contract wraps the selected car in a trade-car structure holding that estimated price, accepts bids only while the auction is open and above both the current highest bid and the estimated price, records the highest bidder, and at auction end transfers the bid amount to the owner and updates the car's owner. The same contract lets unsuccessful bidders withdraw their funds. The paper reports test-transaction results on a public test network showing car creation, price calculation, owner change, and bid recording. On this evidence the author concludes that smart contracts provide security and privacy for the bidding process compared with centralized used-car platforms.","pith_inferences":["The paper leaves physical delivery and vehicle condition outside the contract; a natural extension is an oracle or inspection provider that anchors off-chain facts to on-chain records, otherwise ownership transfer is only a ledger entry.","A testable extension would measure gas costs per bid and per withdrawal, since the paper notes resource use is unoptimized; contracts that cost more to call than the car's margin would not be used.","The same two-contract pattern could be adapted to other registrable assets such as property titles or IoT device ownership, with the agent role replaced by a verified authority."],"forward_implications":["Vehicle records such as current owner and accident history would live on-chain and become auditable, with no central operator able to rewrite them.","Auction settlement would be automated: the winning bid is transferred to the owner and ownership is updated in the same contract call, removing trust in the platform operator.","The pricing and bidding logic could be reused for other item auctions, not just cars, because the registry and auction responsibilities are separated.","Because all bids and contract states are public, the system offers transparency at the cost of bidder privacy, and losing bidders must remember to withdraw."],"supporting_citations":[{"why":"It supplies the Ethereum platform with Turing-complete smart contracts and the 15-second block time the system selects for adaptability.","marker":"[3]"},{"why":"It defines smart contracts as self-verifying, self-executing, and tamper-resistant code, which is the premise for handing auction rules to a contract.","marker":"[10]"},{"why":"It establishes blockchain as a decentralized ledger with proof-of-work and a longest-chain rule, the integrity basis the paper relies on.","marker":"[11]"},{"why":"It is cited in the limitations as identifying conditional-judgment vulnerabilities in smart contracts, the risk the author admits the code may contain.","marker":"[9]"},{"why":"It provides the overview of smart-contract architecture and the Solidity execution environment used for the implementation.","marker":"[23]"},{"why":"It introduces a trusted-execution-environment-based approach to confidentiality, which the paper uses to show how blockchain transparency might be mitigated.","marker":"[4]"}],"fun_headline_variants":["Ethereum smart contract auction for vehicles","Car auction on blockchain, no central server needed","Smart contracts handle bid, funds, and ownership transfer","Decentralized used-car auction via Ethereum smart contracts","Secure vehicle auction powered by smart contracts"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The prototype's guarantees stand or fall on the correctness of its Solidity code, which the paper itself says may contain mistaken conditional judgments and unexplored smart-contract pitfalls.","fun_headline_variants_meta":{"raw":{"variants":["Ethereum smart contract auction for vehicles","Car auction on blockchain, no central server needed","Smart contracts handle bid, funds, and ownership transfer","Decentralized used-car auction via Ethereum smart contracts","Secure vehicle auction powered by smart contracts"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000267,"raw_usage":{"total_tokens":1596,"prompt_tokens":906,"completion_tokens":690,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":522,"completion_tokens_details":{"reasoning_tokens":620}},"tokens_in":522,"tokens_out":690,"duration_ms":6529,"temperature":1.0,"reasoning_tokens":620,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T21:23:22.317237+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Deploy the two contracts on a public testnet and run an adversarial transaction sequence: a bid placed after the auction end time, a bid below the computed floor price, a bid below the current highest bid, and a second withdrawal after an earlier withdrawal. If any of these transactions succeeds when it should be reverted, or if an auction-end call can be reentered to drain funds, the claim that the contracts enforce the auction rules is false.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It supplies the Ethereum platform with Turing-complete smart contracts and the 15-second block time the system selects for adaptability."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It defines smart contracts as self-verifying, self-executing, and tamper-resistant code, which is the premise for handing auction rules to a contract."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It is cited in the limitations as identifying conditional-judgment vulnerabilities in smart contracts, the risk the author admits the code may contain."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It provides the overview of smart-contract architecture and the Solidity execution environment used for the implementation."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"It introduces a trusted-execution-environment-based approach to confidentiality, which the paper uses to show how blockchain transparency might be mitigated."}],"review_version":1}