{"id":"d350b417-594e-4a9f-9ed9-188166629e4c","arxiv_id":"2508.07190","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"A corpus-level study of 191 NFT-related EIPs finds a Draft/Final-bifurcated ecosystem centered on ERC-721/ERC-1155 inheritance, heavy reuse of core functions, skewed contributor participation, and security risk growing with functional complexity.","lead":"This paper maps the technical foundations of NFTs by studying 191 Ethereum standards proposals (EIPs), their interfaces, inheritance links, and community discussions. It gives builders and researchers the first structured view of which NFT standards are foundational, how they fragment, and why added functionality adds security risk.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Corpus and parser fidelity are unvalidated, so the 213/191-EIP selection and the 1,572-function mapping cannot yet be independently audited.","rationale":"The reader's conditional verdict already centers on corpus and parse fidelity; my read agrees. The concern is not that the authors are wrong but that the central artifact is not yet auditable: no data release, no validation of the regex parser, and no inter-tool agreement. Releasing the data and comparing against a grammar-aware parser is a concrete, low-cost check that would either validate the 1,572-function corpus or show where it breaks. I do not see a reason to move the verdict: the paper's novelty and internal coherence support conditional acceptance contingent on this check, not rejection. I also note that the security discussion (RQ7) rests on secondary sources and contains at least one apparent internal mismatch (ERC-4675 described as fractional-ownership in §VI.B vs. 'Token URI JSON Schema' in Table VI/ref [70]), but that is secondary to the corpus claim; if anything, it strengthens the need for data release and parser validation before relying on the paper's map.","tokens_in":21679,"tokens_out":4617,"duration_ms":45105,"concrete_test":"Ask the authors to release the 213-EIP inclusion list and the 1,572-row function table, then independently reproduce the pipeline on the same July-2025 eips.ethereum.org snapshot: (1) recompute the keyword+manual selection and check whether the 213/191 sets match; (2) re-parse the 191 EIPs with a grammar-aware Solidity parser (e.g., tree-sitter-solidity or slither) and compare extracted function signatures, parameter-type frequencies, and inheritance edges with the regex output. If the 213/191 sets or the function/inheritance aggregates differ by more than ~5%, RQ2–RQ4 distributions and the core-centric inheritance conclusion must be re-estimated; if they match within tolerance, the concern is resolved.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's central empirical contribution (RQ1–RQ4) is a corpus-level map built on two unverified steps: the keyword+manual filter that selects 213 NFT-related EIPs (191 with interfaces) and the regex-based extraction of 1,572 functions, parameter types, and inheritance edges from embedded Solidity (§IV.B). Every headline statistic — stage percentages (30.0% Draft/Final, 27.7% Stagnant), category counts (584/153/129/114/84), function-reuse frequencies, and the ERC-165/ERC-721 core-centric inheritance graph — is a downstream aggregate of these choices. The manuscript states the datasets 'will be released once this work is finalized' (Table III), and no validation set, annotation protocol, or parser test is reported; manual confirmation of the 213-EIP pool is described but not operationalized. Regex parsing of Solidity is fragile: multi-line signatures, comments/string literals containing 'function', inherited declarations, and interface-vs-implementation blocks are all plausible sources of systematic error. If even a small fraction of the 191 EIPs is mis-parsed, the function counts and inheritance topology shift, and the central map is not trustworthy. This is exactly the load-bearing unverified step.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper claims to present the first study of NFTs through the lens of Ethereum Improvement Proposals (EIPs). The authors construct a corpus of 213 NFT-related EIPs (191 with Solidity interfaces), parse 1,572 interface functions, build an inheritance graph centered on ERC-165/ERC-721, profile 445 contributors, and mine Ethereum Magicians discussions. They describe a bifurcated stage distribution, a core-centric inheritance topology, skewed contributor and engagement patterns, and a qualitative security assessment of ERC-721, ERC-1155, ERC-6551 and emerging proposals. The stated contributions are: the structural landscape of NFT standards, a socio-technical perspective on standardization, and a synthesis of academic coverage and security challenges.","tokens_in":21838,"tokens_out":4100,"duration_ms":43232,"significance":"If the dataset construction and parsing are sound, this would be a useful structured map of the NFT standardization ecosystem, and the RQ decomposition is a sensible organizing device. The paper usefully distinguishes foundational from emerging standards and quantifies function reuse and inheritance concentration. However, the magnitude of the contribution is currently bounded by two unverified pillars: the corpus/parser fidelity and the qualitative security claim. The paper would be substantially strengthened by releasing the dataset and validation artifacts, and by either sharply scaling back or rigorously supporting the 'growing functional complexity heightens security risks' assertion.","major_comments":[{"comment":"The counts that anchor the paper—213/191 EIPs, 1,572 functions, stage percentages, and the inheritance graph—depend entirely on the keyword+manual selection and regex-based parsing described in §IV.B. No validation set, annotation protocol, parser error rate, or inter-annotator agreement is reported; Table III states the datasets 'will be released once this work is finalized.' Regex parsing of Solidity is fragile with respect to multi-line signatures, comments/strings containing 'function', inherited declarations, and interface-vs-implementation blocks. Because every RQ1–RQ4 statistic inherits these choices, I ask for release of the datasets and a validation/error analysis, or at least a conservative sensitivity analysis.","section":"§IV.B / Table III"},{"comment":"The abstract's claim that the paper 'show[s] that growing functional complexity heightens security risks' is not supported by the presented evidence. §VI.B and Table V are qualitative, and many vulnerability attributions rely on blog posts or industry articles ([61]–[69], [71]–[74]) rather than systematic measurements. No complexity metric or risk metric is operationalized, and no correlation is computed. The internal inconsistency between §VI.B's description of ERC-4675 as supporting fractional ownership and Table VI's listing of EIP-4675 as 'Token URI JSON Schema' further indicates that this review needs reworking. Please reframe as a scoped qualitative review or provide rigorous empirical support.","section":"§VI.B / Abstract"},{"comment":"The abstract says the paper 'expose[s] poor cross-version interoperability,' but no operational definition of interoperability is given and no compatibility metric is measured. Fig. 5 and the RQ3 discussion show inheritance/extension edges, which are not equivalent to interoperability. The paper should either define and measure cross-version interoperability explicitly or soften this claim to 'limited interface reuse among standards.'","section":"Abstract / RQ3 / Fig. 5"},{"comment":"The real-name/pseudonym heuristic and the geolocation classification are not validated. The distinction between 'Real Name' and 'Pseudonym' is based on 'plausibly corresponds' with no operational criteria, and the geographic distribution rests on self-reported GitHub locations with 24.2% of contributors excluded. The specific numbers (78.2%/21.8%, 22.6% US, etc.) should be presented as heuristics, and the classification rules should be released so the robustness of RQ5 can be assessed.","section":"§V.E"}],"minor_comments":[{"comment":"The manuscript contains many corrupted placeholder symbols (e.g., 'balanceOf', 'approve', 'tokenURI' appear as ���������) and incomplete references, notably [42] 'Author of the forum post', [68] 'Author(s) listed on the EIP page', and [70] 'Year of creation'. These must be fixed before any publication.","section":"Throughout"},{"comment":"The relationship between the 'over 10,000 discussion entries' from 39 EIP + 11 ERC pages and the 121 NFT EIP topics in Table III is unclear. Please explain the filtering steps and counts.","section":"§IV.B / Table III"},{"comment":"Figure 5 is difficult to read: node labels are too small and many edges are indistinguishable. A zoomable or summarized version would help the reader verify the core-centric inheritance claim.","section":"Fig. 5"},{"comment":"Table V includes a 'Color legend' but the table is rendered as text; if colors are not visible in the final format, replace the legend with explicit textual labels.","section":"Table V"},{"comment":"The security discussion cites several blog posts as primary evidence (e.g., [62], [63], [65], [66]). Prefer peer-reviewed or official references for claims about standard-level vulnerabilities, or explicitly label the evidence base as community sources.","section":"§VI.B"}],"recommendation":"major_revision","confidential_remarks":"The manuscript appears to be a rushed submission: corrupted symbols, placeholder citations, and unvalidated datasets undermine confidence in the headline claims. I see the core dataset as potentially valuable, but it must be released and validated. Also, the heavy reliance on the authors' own prior work in the related-work section is noticeable; this should be kept proportionate in revision."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The genuinely new thing here is the corpus: 213 NFT-related EIPs, 191 with explicit interfaces, 1,572 parsed functions, an inheritance graph, and contributor statistics. Nobody has measured the standards layer at this scale before, and the descriptive results—stage distribution, function categories, parameter co-occurrence, authorship skew—are useful and internally coherent. The inheritance graph centering on ERC-165 and ERC-721 is plausible, and the paper is honest about prior work being market- or incident-focused.\n\nThat said, the load-bearing steps are unverified. The keyword-plus-manual filter and the regex parsing of Solidity interfaces are described but not validated. No dataset is released, no parser test is reported, and no annotation protocol is given. The stress-test critique is fair: every headline statistic inherits those choices, and a small parsing error rate shifts the function counts and topology. This is a reproducibility gap, not a fatal flaw.\n\nTwo abstract claims also outrun the evidence. \"Poor cross-version interoperability\" is never operationalized—the inheritance graph shows limited reuse but no metric of interoperability. \"Growing functional complexity heightens security risks\" rests on a qualitative review of blog sources, and at least one attribution (ERC-4675 as a fractional-vault standard) looks wrong on its face. The reference list has placeholder entries, which is sloppy but fixable.\n\nOverall: this is a legitimate measurement contribution with a fixable robustness problem. The authors should release the corpus and parser, add a validation set or inter-annotation agreement, and either measure complexity-vs-incident rates or temper the security claim. I would send it to peer review, because the topic matters and the empirical core deserves scrutiny, but I would condition acceptance on releasing the data and cleaning up the overclaims.","headline":"First real map of the NFT standards layer, but the corpus and parser are not yet auditable and two abstract claims outrun the evidence.","tokens_in":22431,"tokens_out":2196,"would_cite":false,"duration_ms":23281,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that NFTs are best understood through their EIP standards, and that a corpus-level analysis of 191 proposals reveals a few foundational interfaces dominating reuse while newer, more complex standards widen the security ris","keywords":["NFT standards","Ethereum Improvement Proposals","ERC interfaces","Solidity interface parsing","token standardization","NFT security","contributor analysis","blockchain empirical study"],"falsifier":"Take the same EIP corpus, have independent annotators hand-label NFT relevance and hand-parse a random sample of the 191 interfaces, then compare precision and recall of the keyword filter and the extracted 1,572 function signatures against that gold standard. A material disagreement rate would overturn the RQ1–RQ4 statistics; so would finding an NFT-related EIP absent from the 213/191 set or a parsed inheritance edge that contradicts the official EIP text.","tokens_in":21480,"feed_emoji":"🔷","tokens_out":11173,"duration_ms":98166,"temperature":0.7,"pith_summary":"This paper argues that the technical backbone of NFTs—the Ethereum Improvement Proposals that define them—can and should be studied as a corpus, and that doing so reveals the ecosystem's structure. It filters 213 NFT-related EIPs, parses 1,572 Solidity interface functions from 191 of them, and builds an inheritance graph that shows a core-centric landscape: ERC-165 and ERC-721 are the dominant hubs, a small set of functions such as balanceOf and safeTransferFrom is reused across standards, and later proposals mostly add specialized extensions on top. The data also shows a bifurcated and selective pipeline (30% Draft, 30% Final, 27.7% Stagnant), a contributor base dominated by single-author proposals and a small recurring core, and limited interface reuse across versions—the paper's evidence for poor cross-version interoperability. Finally, it argues that security risk grows with functional complexity: ERC-721 and ERC-1155 have bounded, known vulnerabilities, while ERC-6551 and newer extensions introduce enforcement gaps that contract-level checks alone cannot close. A reader should care because this is the first systematic map of the layer that defines what an NFT actually is, and it locates where interoperability and risk are concentrated.","feed_headline":"191 NFT EIPs parsed; ERC-721 and ERC-165 dominate","feed_subtitle":"Parsing 1,572 Solidity interfaces shows standardization concentrates on ERC-721/ERC-165 and complexity raises risk.","key_machinery":"The carrying object is the EIP corpus treated as a structural dataset. The pipeline has three parts: a keyword filter using terms such as 'nft' and 'non-fungible' plus a manual confirmation round that selects 213 NFT-related proposals; automated parsing of embedded Solidity interfaces with HTML parsing and regular expressions, extracting 1,572 functions with parameter types, return types, and declared inheritance edges; and a time-anchored inheritance graph in which nodes are standards, edges are declared inheritance or extension relations, and node size encodes in-degree centrality. That graph is what turns a list of documents into a map: it is the mechanism by which foundational standards","core_discovery":"The paper claims the NFT ecosystem has a measurable standardization substrate: 213 NFT-related EIPs, 191 with Solidity interfaces, yielding 1,572 parsed functions. The stage distribution is bifurcated (30% Draft, 30% Final, 27.7% Stagnant), the inheritance graph is core-centric—ERC-165 and ERC-721 are hubs—and reuse concentrates on a few primitives like balanceOf, safeTransferFrom, and ownerOf. Contributor data shows 76 single-author proposals and 379 of 445 authors contributing once. The paper also argues security risk scales with complexity, with ERC-6551 and extensions like ERC-4907, ERC-4675, and ERC-2981 introducing enforcement gaps beyond the contract itself.","pith_inferences":["The same corpus-level lens could be turned on fungible-token standards (the ERC-20 family) or on Bitcoin-native token proposals to test whether the core-centric, high-stagnation, single-author-heavy pattern is a general property of token standardization or specific to NFTs.","The paper's risk analysis is built on secondary sources; a direct test would be to scan deployed ERC-6551 and ERC-4907 contracts for the named vulnerability patterns—asset draining before sale, shared-implementation flaws, missing royalty enforcement—to see whether the complexity-risk correlation holds outside the standards text.","Because the parameter-level data is machine-readable, a practical extension is an automated compatibility checker that flags new NFT EIPs whose signatures conflict with, or fail to inherit from, the 1,572-function corpus.","The pseudonymity and geolocation classifications are heuristic; validating them against GitHub profiles or on-chain attribution would make the 20.4% pseudonymous figure robust enough to use in policy discussions."],"forward_implications":["If the map is correct, new NFT standards that do not inherit from ERC-165 or ERC-721 or reuse the dominant primitives will face interoperability friction, because wallets, marketplaces, and indexers are built around those hubs.","The 30% Final and 27.7% Stagnant split implies that most proposed NFT functionality never reaches adoption; standards that clear Draft are the exception, and community attention is the binding constraint.","Because 76 of 213 EIPs are single-author and 379 of 445 authors contribute once, standardization depends on a small recurring core; over 65% of proposals come from unaffiliated individuals.","Security risk is not uniform across standards: ERC-6551's token-bound account model and extensions such as ERC-4907, ERC-4675, and ERC-2981 shift the attack surface from the NFT contract to interactions, shared implementations, and off-chain enforcement.","Academic NFT research is misaligned with the standard landscape: studies concentrate on ERC-721 market data, while ERC-1155 and post-2021 standards remain empirically underexamined."],"supporting_citations":[{"why":"Supplies the NFT definition and the black-box framing that motivates looking at the standard layer.","marker":"[1]"},{"why":"Defines ERC-721, the foundational interface whose functions and hub position anchor the inheritance graph and reuse analysis.","marker":"[8]"},{"why":"Defines ERC-1155, the multi-token standard used as the second foundational hub and the benchmark in the security review.","marker":"[9]"},{"why":"Example thread used to illustrate concentrated, long-lived community engagement around a technically novel proposal.","marker":"[41]"},{"why":"Secondary source for the ERC-6551 asset-draining-before-sale attack vector in the security analysis.","marker":"[65]"},{"why":"Defines ERC-2981, one of the emerging standards whose royalty mechanism is analyzed for enforcement gaps.","marker":"[72]"},{"why":"Supports the claim that ERC-2981 lacks on-chain enforcement, underpinning the emerging-standard risk discussion.","marker":"[73]"}],"fun_headline_variants":["1,572 NFT functions parsed: ERC-721/165 stay central","NFT EIP stage split: 30% Draft, 30% Final, 27.7% Stagnant","76 single-author NFT EIPs: sparse collaboration mapped","Complex NFT EIPs like ERC-6551 open security gaps","NFT standardization: core-centric inheritance, rising risks"],"cache_read_input_tokens":2816,"weakest_assumption_plain":"Everything rests on the dataset being complete and correctly parsed: if some NFT-related proposals were missed or interface functions were misread, the stage percentages, function-reuse counts, centrality rankings, and risk conclusions would all shift.","fun_headline_variants_meta":{"raw":{"variants":["1,572 NFT functions parsed: ERC-721/165 stay central","NFT EIP stage split: 30% Draft, 30% Final, 27.7% Stagnant","76 single-author NFT EIPs: sparse collaboration mapped","Complex NFT EIPs like ERC-6551 open security gaps","NFT standardization: core-centric inheritance, rising risks"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000823,"raw_usage":{"total_tokens":3404,"prompt_tokens":682,"completion_tokens":2722,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":426,"completion_tokens_details":{"reasoning_tokens":2623}},"tokens_in":426,"tokens_out":2722,"duration_ms":18239,"temperature":1.0,"reasoning_tokens":2623,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-05T22:16:57.005495+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Take the same EIP corpus, have independent annotators hand-label NFT relevance and hand-parse a random sample of the 191 interfaces, then compare precision and recall of the keyword filter and the extracted 1,572 function signatures against that gold standard. A material disagreement rate would overturn the RQ1–RQ4 statistics; so would finding an NFT-related EIP absent from the 213/191 set or a parsed inheritance edge that contradicts the official EIP text.","supporting_citations":[{"cited_title":"Eip- 721: Non-fungible token standard","cited_arxiv_id":null,"evidence_quote":"Defines ERC-721, the foundational interface whose functions and hub position anchor the inheritance graph and reuse analysis."},{"cited_title":"and Ronan Sandford","cited_arxiv_id":null,"evidence_quote":"Defines ERC-1155, the multi-token standard used as the second foundational hub and the benchmark in the security review."},{"cited_title":"Eip-4973 - account-bound tokens","cited_arxiv_id":null,"evidence_quote":"Example thread used to illustrate concentrated, long-lived community engagement around a technically novel proposal."},{"cited_title":"ERC-6551 standard: Token bound accounts (tba)","cited_arxiv_id":null,"evidence_quote":"Secondary source for the ERC-6551 asset-draining-before-sale attack vector in the security analysis."},{"cited_title":"EIP- 2981: NFT royalty standard","cited_arxiv_id":null,"evidence_quote":"Defines ERC-2981, one of the emerging standards whose royalty mechanism is analyzed for enforcement gaps."},{"cited_title":"‘ERC-2981‘ (NFT royalty standard) implementation","cited_arxiv_id":null,"evidence_quote":"Supports the claim that ERC-2981 lacks on-chain enforcement, underpinning the emerging-standard risk discussion."}],"review_version":1}