{"id":"a7c50326-6f2e-4838-b825-23ca1008d366","arxiv_id":"2504.15063","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Vulnerable smart contracts show distinct transaction and ego-network signatures across lifecycle stages, and a KNN classifier separates the three groups with about 72% accuracy.","lead":"This study examined Ethereum smart contracts with known weaknesses and found that transaction patterns differ depending on whether the weakness appears during deployment, upgrade, or destruction. A machine learning model can partly identify these lifecycle stages, which could help security tools look beyond source code.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Stage labels are assigned from DELEGATECALL/SELFDESTRUCT vulnerability presence, so KNN separation may reflect opcode families rather than lifecycle stages.","rationale":"The reader identified the same load-bearing assumption: lifecycle stage is inferred from vulnerability type rather than externally validated. I agree that this is the single point on which the central claim depends. If the mapping fails, the paper's contribution reduces to showing that contracts with different vulnerable opcodes have different transaction behavior, which is a weaker and less novel claim than distinguishing lifecycle stages. Finding 4 makes the concern concrete rather than hypothetical, since a notable fraction of selfdestruct-labeled contracts did not actually self-destruct. Other weaknesses, such as the missing normal-contract baseline, absent error bars, and inconsistent contract counts (840 vs. 700 vs. 800), are real but secondary; they would temper overclaims without invalidating the descriptive analysis. A conditional acceptance requiring on-chain validation of the stage assignment is therefore appropriate, and the reader's CONDITIONAL verdict should stand until that validation is performed.","tokens_in":15262,"tokens_out":5658,"duration_ms":53144,"concrete_test":"Use the released Figshare dataset to sample 50 contracts from each of the three classes. Query Etherscan internal transactions and event logs for each sample: record whether a DELEGATECALL to a new implementation (an upgrade event) or a SELFDESTRUCT occurs, and the block time of the first such event. Compare these event times to the assigned stage and to the P1-P5 windows. Then recompute the KNN accuracy on the subset of contracts whose assigned stage is confirmed by an actual on-chain lifecycle event. If the confirmed-subset accuracy is materially lower than 0.726, or if fewer than 80% of delegatecall-labeled and selfdestruct-labeled contracts have the corresponding event, the Finding 14 separation is an artifact of the label mapping rather than lifecycle stage.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section 3 assigns lifecycle stage from vulnerability type: 'DELEGATECALL indicates the upgrade stage' and 'SELFDESTRUCT marks the destruction stage,' with everything else assigned to deployment and execution. This makes the three classes in Table 5 codesigned with the features: the opcode itself produces zero-value transactions and short lifespans that the features then measure. A contract is labeled 'upgrade stage' if its code contains a delegatecall vulnerability, even if no delegatecall is ever executed and no upgrade occurs; a contract is labeled 'destruction stage' if it contains selfdestruct, even if it remains alive. The paper's own Finding 4 partially undermines the mapping: manual inspection found only 58.5% of selfdestruct-labeled contracts actually self-destructed. Thus the KNN result and every stage-specific finding may characterize contracts containing particular vulnerable opcodes, not contracts at particular lifecycle stages. The 'first lifecycle empirical study' claim and Finding 14 rest entirely on this unvalidated equivalence.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper presents an empirical study of vulnerable Ethereum smart contracts, organized by a proposed three-stage lifecycle: deployment/execution, upgrade, and destruction. Using SmartBugsV2 together with four detection tools, the authors identify roughly 800 vulnerable contracts from the SmartBugs wild dataset, retrieve over 1.54 million related transactions from Etherscan, and compute a set of transaction and ego-network features (lifespan, transaction counts and amounts, neighbor dynamics, network density, and clustering coefficient). They compare these features across three groups defined by vulnerability type (DELEGATECALL-related, SELFDESTRUCT-related, and 'other') and then train five classifiers; the KNN model yields accuracy 0.726 and AUC 0.7222, leading to Finding 14 that contracts with vulnerabilities at different lifecycle stages can be distinguished by the proposed features. The paper claims to be the first empirical lifecycle study of smart contract security and open-sources its code and data.","tokens_in":15396,"tokens_out":5026,"duration_ms":42262,"significance":"If the lifecycle interpretation were validated, the paper would be a useful empirical contribution: it assembles a large multi-tool-consensus dataset of vulnerable contracts, provides descriptive statistics of transaction behavior, and makes code and data openly available. The strongest descriptive content is the separation of transaction patterns among DELEGATECALL-, SELFDESTRUCT-, and other-vulnerability classes. However, the central claim that these groups correspond to lifecycle stages rests on an unvalidated mapping from opcode presence to lifecycle phase, and the classification result is circular with respect to that mapping. As a study of opcode-defined vulnerability classes, the findings are plausible but preliminary; as the 'first empirical study on the security of smart contracts throughout their lifecycle,' the evidence is currently insufficient. The absence of a normal-contract baseline also means the abstract's claim of distinguishing vulnerable from normal contracts is not supported.","major_comments":[{"comment":"The lifecycle stage labels are constructed directly from the presence of DELEGATECALL or SELFDESTRUCT vulnerabilities: Section 3 states that 'DELEGATECALL indicates the upgrade stage' and 'SELFDESTRUCT marks the destruction stage,' with all other vulnerabilities assigned to deployment and execution. The features that drive the KNN separation, such as zero-value transaction ratios (Section 5.1.2) and lifespan (Table 2), are direct consequences of these opcodes' semantics, not independent evidence about lifecycle behavior. Moreover, the authors' own manual inspection in Section 5.1.2 (Finding 4) found that only 58.5% of selfdestruct-tagged contracts actually self-destructed, which directly contradicts the assumption that SELFDESTRUCT presence equals the destruction stage. Because the class labels are codesigned with the features, the accuracy and AUC reported in Table 5 and Finding 14 cannot be interpreted as evidence that contracts at different lifecycle stages are distinguishable; they may only distinguish contracts containing different vulnerable opcodes. This is the load-bearing issue for the paper's central claim.","section":"Section 3, Section 5.1.2, Table 5"},{"comment":"The abstract and introduction claim that the proposed features are 'effectively distinguished from normal contracts,' but no normal (non-vulnerable) contracts appear anywhere in the dataset or analysis. Section 4.2 describes collecting only vulnerable contracts from the SmartBugs wild dataset, and all tables and figures in Sections 5 and 6 compare only the three vulnerability classes (Other, Delegatecall, Selfdestruct). Consequently, the paper cannot support any statement about distinguishing vulnerable contracts from normal ones. The authors should either add a baseline of randomly sampled non-vulnerable contracts and compare feature distributions or classifier performance against that baseline, or remove the 'normal contracts' claims from the abstract and introduction.","section":"Abstract, Section 1, Section 4.2"},{"comment":"The classification experiment reports no error bars, no statistical significance tests, and insufficient methodological detail. The decision-tree model (labeled 'DR' in Table 5) has accuracy 0.305, below the 0.333 random baseline for a three-class problem, which suggests either that the feature set is not informative for at least one class or that label noise is high. No per-class sample sizes are given, and the description 'validation utilizing cross-validation' is unspecified. Without confidence intervals, cross-validation details, or a permutation test against the null hypothesis of no class separability, the KNN result (accuracy 0.726, AUC 0.7222) cannot be distinguished from chance variation or from classification driven by the trivial opcode-derived features.","section":"Section 6.1, Table 5"}],"minor_comments":[{"comment":"Both Section 3.1.5 and Section 3.1.6 describe the 'unchecked return value' vulnerability in nearly identical wording; the second subsection appears intended for 'Unprotected Ether Withdrawal' but does not present a distinct description.","section":"Section 3.1.5 and 3.1.6"},{"comment":"The number of identified vulnerable contracts is 840 in Section 1 but 800 in Section 4.2; this inconsistency should be reconciled.","section":"Section 1 and Section 4.2"},{"comment":"The abbreviation 'DR' for the decision-tree model is nonstandard and should be 'DT' or spelled out; also, 'default parameters from the sklearn library' should be replaced with explicit hyperparameter values to ensure reproducibility.","section":"Table 5"},{"comment":"Figure numbering is inconsistent: Fig. 5 is referenced both for the lifespan distribution and for the top-eight long-lifespan vulnerabilities, and Fig. 14 is used both for the clustering-coefficient plot and for the KNN ROC curve; the figures should be renumbered and all references updated.","section":"Figures 5, 6, and 14"},{"comment":"The graph notation in Section 4.3 contains unrendered symbols (e.g., '? = ?, ?'), and Equations (1) and (2) are referenced in the text but never explicitly numbered; both should be fixed in the final manuscript.","section":"Section 4.3, Equations (1)-(2)"},{"comment":"The abstract mentions 'seven feature descriptions,' but Section 5 presents at least eight distinct metrics (lifespan, transaction volume, incoming/outgoing ratio, transaction amounts, neighbor counts, old/new neighbor ratios, network density, and clustering coefficient); the number of features and their definitions should be made consistent and explicit.","section":"Abstract and Section 5"}],"recommendation":"major_revision","confidential_remarks":"The central circularity between the lifecycle labels and the features is substantial, but the paper's descriptive findings about opcode-defined vulnerability classes are still potentially useful, and the weaknesses are addressable by reframing the contribution or adding validation. I therefore recommend major revision rather than rejection. I also note that the reference list contains a large number of self-citations from the same research group; while not inappropriate per se, the authors should ensure each one is genuinely necessary and relevant."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The punchline: this paper is not really about lifecycle stages. It labels contracts as upgrade/destruction based on whether they contain DELEGATECALL or SELFDESTRUCT vulnerabilities, so the three classes are defined by opcode families. The KNN separation (accuracy 0.726) mostly shows that contracts with delegatecall, selfdestruct, or other vulnerabilities have different transaction and ego-network statistics. That is a legitimate descriptive finding, but it is presented as evidence for distinct lifecycle stages, which the data do not establish.\n\nWhat the paper does well: it compiles a large transaction dataset (over 1.54 million records) from Etherscan for a set of vulnerable contracts identified with multiple tools, and it opens the data and code. The feature definitions (lifespan, transaction volume, ratio of incoming/outgoing, neighbor turnover, ego-network density, clustering coefficient) are clear, and the figures are informative. The finding that delegatecall-vulnerable contracts have predominantly zero-value transactions and low clustering, while selfdestruct ones have short lifespans and high clustering, is a useful characterization of these vulnerability families.\n\nThe soft spots are serious. The stage mapping is load-bearing and unvalidated. A contract with a delegatecall vulnerability is called \"upgrade stage\" even if no upgrade ever happens; a selfdestruct vulnerability is called \"destruction stage\" even if the contract remains alive. The paper's own Finding 4 says only 58.5% of selfdestruct-labeled contracts actually self-destructed. So the classification labels are not lifecycle stages. In addition, the introduction claims the features distinguish vulnerable from normal contracts, but no normal-contract baseline appears in the ML experiment. The sample size is inconsistent (840 in the abstract, 800 in Section 4, 700 in the contributions), and there are no error bars or significance tests. Several findings (e.g., delegatecall has zero-value transactions) are near-tautologies given how the groups are defined.\n\nThe stress-test note is on point: the KNN result may reflect opcode families, not lifecycle stages.\n\nWho is this for? Researchers working on transaction-level signals for smart contract risk could mine the dataset and feature descriptions. But the lifecycle framing should not be repeated without external validation. The paper deserves a serious referee, but it needs major revision: either obtain real lifecycle events (proxy upgrades, selfdestruct transactions) to label stages, or reframe the contribution as a comparative study of vulnerable contracts by opcode family, and add a normal-contract baseline.\n\nRecommendation: send to peer review with the expectation of heavy revision.","headline":"A useful descriptive study of vulnerable contracts by opcode family, but the 'lifecycle stage' framing is not supported by the label construction and needs major revision before it can be used.","tokens_in":15938,"tokens_out":3021,"would_cite":false,"duration_ms":27679,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The lifecycle stage of a vulnerable smart contract can be inferred from its transaction history and ego-network structure.","keywords":["smart contracts","Ethereum","lifecycle stages","vulnerability detection","transaction features","ego network","DELEGATECALL","SELFDESTRUCT"],"falsifier":"For the 800 flagged contracts, scrape on-chain events and check whether DELEGATECALL-labelled contracts actually have a proxy-upgrade or implementation-change transaction, and whether SELFDESTRUCT-labelled contracts actually execute a selfdestruct at the end of their recorded lifespan. If most DELEGATECALL contracts never upgrade and most SELFDESTRUCT contracts never self-destruct, the stage labels collapse and the KNN separation would be classifying vulnerability types, not lifecycle stages.","tokens_in":14999,"feed_emoji":"⛓️","tokens_out":5984,"duration_ms":48758,"temperature":0.7,"pith_summary":"Smart contracts fail in different ways at different phases of their lives, and this paper aims to show those phases leave measurable traces. It divides the contract lifecycle into deployment and execution, upgrade, and destruction; treats the presence of DELEGATECALL as the marker of upgrade-stage contracts, SELFDESTRUCT as the marker of destruction-stage contracts, and all other detected vulnerabilities as deployment-stage; then builds seven features from over 1.54 million transactions and ego networks of 800 flagged contracts. The paper's central result is that these features separate the three stage classes well enough for a K-nearest-neighbours classifier to reach 0.726 accuracy and 0.7222 AUC, and it reports a series of stage-specific patterns: destruction-stage contracts are short-lived, upgrade-stage contracts trade mostly zero-value transactions, and deployment-stage contracts dominate early transaction volume. If correct, the finding gives security analysts a dynamic, behaviour-based signal that complements static code analysis.","feed_headline":"Transaction history reveals a vulnerable contract's lifecycle stage","feed_subtitle":"A KNN classifier separates deployment, upgrade, and destruction contracts with 0.726 accuracy.","key_machinery":"The machinery is a stage-labelled transaction-feature vector built from on-chain history. Each vulnerable contract is treated as a node in an ego network, meaning the subgraph of the contract plus its first-order transaction neighbours, and seven features are computed over five equal time windows (P1 to P5): lifespan, transaction count, transaction amount, neighbour counts, old versus new neighbours, ego-network density, and local clustering coefficient. The stage label is assigned by opcode: the presence of DELEGATECALL marks the upgrade stage, the presence of SELFDESTRUCT marks the destruction stage, and all other vulnerabilities mark the deployment and execution stage. These seven features are fed to five machine-learning classifiers, with K-nearest neighbours performing best.","core_discovery":"On the paper's own terms, the discovery is that vulnerable smart contracts at different lifecycle stages are distinguishable populations, not just code-level accidents. Contracts flagged for DELEGATECALL-related vulnerabilities behave like upgrade-stage contracts: fluctuating transaction counts, mostly zero-value calls, and a high ratio of old neighbours. Contracts flagged for SELFDESTRUCT behave like destruction-stage contracts: lifespans under 100 days, balanced incoming and outgoing neighbours, the highest local clustering coefficient, and a final phase of outgoing transfers. Contracts with other vulnerabilities behave like deployment- and execution-stage contracts: long possible lifespans, early concentration of transaction volume, and about 90% of their transaction amounts occurring in the first period. The KNN model's performance, with accuracy 0.726, precision 0.715, recall 0.726, F1 score 0.713, and AUC 0.7222, is offered as evidence that these features genuinely differentiate the stages.","pith_inferences":["The opcode-to-stage mapping is the hinge of the whole pipeline; I would test it directly by matching DELEGATECALL-flagged contracts against on-chain proxy-upgrade events and SELFDESTRUCT-flagged contracts against actual selfdestruct transactions. If the match rate is low, the stage labels and the classifier results would need reinterpretation.","The same seven features could be applied to other blockchains or to non-vulnerable contracts; if stage signatures are universal, the approach could become a general contract-ageing monitor rather than a vulnerability detector.","The ego-network variables, especially density, clustering, and old-neighbour ratio, may be usable to spot proxy or upgradeable contracts before a vulnerability is known, since upgrade-stage contracts show a distinctive combination of few neighbours, many old neighbours, and zero-value calls."],"forward_implications":["If the paper is right, a contract's lifecycle stage can be estimated from on-chain transaction behaviour alone, without needing its source code.","Stage-specific patterns imply that security tooling should treat a contract as a changing object: deployment, upgrade, and destruction present different risk profiles.","The reported feature differences imply that a contract entering its destruction phase can be recognised by a short lifespan and a late burst of outgoing transfers.","The KNN results imply that a non-linear distance-based classifier is better suited to this feature space than linear or tree-based models.","A monitoring system could use the seven features to prioritise contracts by likely stage, focusing review effort on upgrade- and destruction-related risks."],"supporting_citations":[{"why":"Supplies the SmartBugs wild dataset of over 47,000 smart contracts from which the vulnerable sample is drawn.","marker":"[43]"},{"why":"Provides SmartBugsV2, the execution framework used for weakness detection in the contracts.","marker":"[32]"},{"why":"Mythril is one of the four tools selected for vulnerability detection at deployment and destruction stages.","marker":"[44]"},{"why":"Confuzzius adds hybrid fuzzing to the detection pipeline.","marker":"[45]"},{"why":"Slither is selected as a static-analysis detector in the pipeline.","marker":"[46]"},{"why":"Sfuzz is selected as an adaptive fuzzer in the pipeline.","marker":"[47]"},{"why":"Etherscan is the source of the complete transaction histories used to build the dataset and ego networks.","marker":"[33]"},{"why":"Supplies the dynamic ego-network analysis approach that the paper's feature design extends.","marker":"[35]"},{"why":"Supports the finding that vulnerable contracts are not necessarily exploited, used to interpret long-lived contracts.","marker":"[48]"},{"why":"Provides the temporal Ethereum network density baseline against which the ego-network density findings are compared.","marker":"[51]"}],"fun_headline_variants":["Vulnerable contracts have distinct transaction fingerprints by lifecycle stage","Ethereum contracts show stage-specific vulnerability signatures","KNN tells contract stage from transaction patterns of vulnerabilities","Lifecycle stage of vulnerable contracts inferred from on-chain behavior"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The paper assumes the lifecycle stage of a contract is determined by its vulnerability type: any contract with DELEGATECALL is an upgrade-stage contract, any with SELFDESTRUCT is a destruction-stage contract, and every other vulnerable contract belongs to deployment and execution; it does not independently validate this mapping against real upgrade or destruction events.","fun_headline_variants_meta":{"raw":{"variants":["Vulnerable contracts have distinct transaction fingerprints by lifecycle stage","Ethereum contracts show stage-specific vulnerability signatures","KNN tells contract stage from transaction patterns of vulnerabilities","Lifecycle stage of vulnerable contracts inferred from on-chain behavior"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000762,"raw_usage":{"total_tokens":3363,"prompt_tokens":909,"completion_tokens":2454,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":525,"completion_tokens_details":{"reasoning_tokens":2390}},"tokens_in":525,"tokens_out":2454,"duration_ms":15078,"temperature":1.0,"reasoning_tokens":2390,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-16T11:34:01.320985+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"For the 800 flagged contracts, scrape on-chain events and check whether DELEGATECALL-labelled contracts actually have a proxy-upgrade or implementation-change transaction, and whether SELFDESTRUCT-labelled contracts actually execute a selfdestruct at the end of their recorded lifespan. If most DELEGATECALL contracts never upgrade and most SELFDESTRUCT contracts never self-destruct, the stage labels collapse and the KNN separation would be classifying vulnerability types, not lifecycle stages.","supporting_citations":[{"cited_title":"A survey of mythril, a smart contract security analysis tool for EVM bytecode","cited_arxiv_id":null,"evidence_quote":"Mythril is one of the four tools selected for vulnerability detection at deployment and destruction stages."},{"cited_title":"Smart contract vulnerabilities: Vulnerable does not imply exploited","cited_arxiv_id":null,"evidence_quote":"Supports the finding that vulnerable contracts are not necessarily exploited, used to interpret long-lived contracts."}],"review_version":1}