Pith. sign in

REVIEW 3 major objections 6 minor 51 references

Mining Characteristics of Vulnerable Smart Contracts Across Lifecycle Stages

T0 review · 3 major / 6 minor · reviewed 2026-08-16 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The lifecycle stage of a vulnerable smart contract can be inferred from its transaction history and ego-network structure.

desk verdict 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. read the letter →

arxiv 2504.15063 v1 pith:J3ZEW6H3 submitted 2025-04-21 cs.CR cs.AI

Hongli Peng , Xiaoqi Li , Wenkai Li This is my paper · ORCID
classification cs.CRcs.AI
keywords smartcontractsEthereumlifecyclestagesvulnerabilitydetectiontransactionfeaturesegonetworkDELEGATECALLSELFDESTRUCT
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

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.

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 (3)
  1. [Section 3, Section 5.1.2, Table 5] 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.
  2. [Abstract, Section 1, Section 4.2] 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.
  3. [Section 6.1, Table 5] 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.
minor comments (6)
  1. [Section 3.1.5 and 3.1.6] 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.
  2. [Section 1 and Section 4.2] The number of identified vulnerable contracts is 840 in Section 1 but 800 in Section 4.2; this inconsistency should be reconciled.
  3. [Table 5] 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.
  4. [Figures 5, 6, and 14] 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.
  5. [Section 4.3, Equations (1)-(2)] 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.
  6. [Abstract and Section 5] 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.

Circularity Check

1 steps flagged · score 6.0 of 10

Lifecycle stages are defined from the same DELEGATECALL/SELFDESTRUCT vulnerability labels that the features and classifier are built to separate, so the main 'stage differentiation' result partly reduces to re-identifying the input opcode classes.

  1. self definitional [Section 3 (stage assignment), Section 5.1.2/5.1.3 (opcode-derived features), Section 6 Table 5 and Finding 14]
    "DELEGATECALL indicates the upgrade stage, signaling vulnerabilities in the old contract and the need for a new version with similar functionality. SELFDESTRUCT marks the destruction stage... Other vulnerabilities typically emerge during the deployment and operational stages. ... Contracts with delegatecall vulnerabilities involve transactions with zero values, a result of DELEGATECALL’s nature. ... Finding 14: Significant distinctions indeed exist among smart contracts that contain vulnerabilities at different lifespan stages."

    The three 'lifecycle stages' are not independently observed stages; they are the vulnerability classes Others/Delegatecall/Selfdestruct by construction. A contract is put in the upgrade class if it has a DELEGATECALL-related vulnerability, and in the destruction class if it has SELFDESTRUCT. The features then measure behaviors that follow from those very opcodes (zero-value transactions for DELEGATECALL, final outgoing transfers and short lifespans for SELFDESTRUCT), and the KNN model classifies contracts by those same labels.

full rationale

The paper is not wholly circular: it builds a large real transaction dataset, computes ego-network statistics, and the KNN separation (AUC 0.722) could have failed. However, the central 'lifecycle' framing is definitional. Section 3 equates upgrade stage with DELEGATECALL vulnerabilities and destruction stage with SELFDESTRUCT vulnerabilities, so the three classes used throughout the feature analysis and in the classifier are the vulnerability-opcode groups themselves. Several reported features are direct consequences of those opcodes, and the paper explicitly attributes zero-value transactions to DELEGATECALL's nature. Finding 14 therefore claims to distinguish lifecycle stages when it actually distinguishes the vulnerability groups that defined the stages. This is a partial, construction-level circularity rather than a fully forced equivalence, so the score is 6. No load-bearing self-citation or uniqueness-import pattern was found; self-citations in the paper are contextual.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

The central analysis rests on tool-based vulnerability labels, the opcode-to-stage mapping, the Etherscan crawl, and the five-period time partition. None of these are independently verified in the paper, and the classification experiment uses the same labels that define the groups.

free parameters (2)
  • five-period lifespan partition (P1-P5) = 5 periods
    The paper divides each contract's lifespan into five periods without justifying the number or boundary choices; all per-period statistics and Findings 1-13 depend on this partition.
  • vulnerability consensus threshold = 2 or more tools
    A vulnerability is accepted only if at least two of the four selected tools flag it; this arbitrary threshold determines which contracts enter the dataset and receive lifecycle labels.
assumptions (4)
  • domain assumption Etherscan transaction histories are complete and accurate.
    The dataset is built entirely by crawling Etherscan; if internal transactions or failed transactions are incompletely recorded, the ego networks and features are biased (Section 4.2).
  • domain assumption The four selected tools (Mythril, Confuzzius, Slither, Sfuzz) detect vulnerabilities accurately enough for consensus labeling.
    Tool selection was based on 500 contracts, and no validation against real exploits or a ground-truth corpus is reported (Section 4.2).
  • ad hoc to paper Presence of DELEGATECALL- or SELFDESTRUCT-related vulnerabilities marks the upgrade or destruction stage, respectively.
    This opcode-to-stage mapping is introduced in Section 3 and never validated against actual contract histories at scale; it is load-bearing for all stage-specific findings.
  • domain assumption First-order transaction neighbors form a meaningful ego network for characterizing contract behavior.
    The ego network includes only nodes directly connected to the contract (Section 2.3); higher-order interactions are ignored, which may omit important context.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Mining Characteristics of Vulnerable Smart Contracts Across Lifecycle Stages." pith.science (2026). https://pith.science/paper/J3ZEW6H3

@misc{pith2026250415063,
  author       = {Pith},
  title        = {Pith review of: Mining Characteristics of Vulnerable Smart Contracts Across Lifecycle Stages},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/J3ZEW6H3}},
  note         = {Machine review of arXiv:2504.15063}
}
read the original abstract

Smart contracts are the cornerstone of decentralized applications and financial protocols, which extend the application of digital currency transactions. The applications and financial protocols introduce significant security challenges, resulting in substantial economic losses. Existing solutions predominantly focus on code vulnerabilities within smart contracts, accounting for only 50% of security incidents. Therefore, a more comprehensive study of security issues related to smart contracts is imperative. The existing empirical research realizes the static analysis of smart contracts from the perspective of the lifecycle and gives the corresponding measures for each stage. However, they lack the characteristic analysis of vulnerabilities in each stage and the distinction between the vulnerabilities. In this paper, we present the first empirical study on the security of smart contracts throughout their lifecycle, including deployment and execution, upgrade, and destruction stages. It delves into the security issues at each stage and provides at least seven feature descriptions. Finally, utilizing these seven features, five machine-learning classification models are used to identify vulnerabilities at different stages. The classification results reveal that vulnerable contracts exhibit distinct transaction features and ego network properties at various stages.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

51 extracted references · 24 canonical work pages

  1. [1]

    Bitcoin: A peer-to-peer electronic cash system

    Nakamoto S. “Bitcoin: A peer-to-peer electronic cash system.” Decentralized business review, pp.1–9,2008

    work page 2008

  2. [2]

    Quorum-based model learning on a blockchain hierarchical clinical researchnetworkusingsmartcontracts

    Kuo T-T, Pham A. “Quorum-based model learning on a blockchain hierarchical clinical researchnetworkusingsmartcontracts.” International journal of medical informatics,vol.169, pp.104924–104933,2023.https://doi.org/10.1016/j.ijmedinf.2022.104924

    arXiv 2023

  3. [3]

    Improving diagnosis through digital pathology: Proof-of-concept implementation using smart contracts and decentralized file storage

    Subramanian H, Subramanian S. “Improving diagnosis through digital pathology: Proof-of-concept implementation using smart contracts and decentralized file storage.” Journal of medical Internet research, vol. 24, no. 3, pp. 34207–34224, 2022. https://doi.org/10.2196/34207 [4]QiP,ChiaroD,GiampaoloF,PiccialliF.“Ablockchain-basedsecureinternetofmedicalthings ...

    work page doi:10.2196/34207 2022

  4. [5]

    Optimal smart contract for autonomous greenhouse environment based on IoT blockchain network in agriculture

    Jamil F, Ibrahim M, Ullah I, Kim S, Kahng HK, Kim D-H. “Optimal smart contract for autonomous greenhouse environment based on IoT blockchain network in agriculture.” Computers and Electronics in Agriculture, vol. 192, pp. 106573–106591, 2022. https://doi.org/10.1016/j.compag.2021.106573https://doi.org/10.1016/j.compag.2021.106573 [6]SuH,GuoB,ShenY,Suo X.“...

    arXiv 2022

  5. [8]

    On discovering vulnerabilities in android applications

    Li X, Yu L, Luo X. “On discovering vulnerabilities in android applications.” Mobile security and privacy,pp.155–166,2017

    work page 2017

  6. [9]

    Blockchain smart contracts for supply chain finance: Mapping the innovation potential in australia-china beef supply chains

    Natanelov V, Cao S, Foth M, Dulleck U. “Blockchain smart contracts for supply chain finance: Mapping the innovation potential in australia-china beef supply chains.” Journal of Industrial Information Integration, vol. 30, pp. 100389–100403, 2022. https://doi.org/10.1016/j.jii.2022.100389

    arXiv 2022

  7. [10]

    The value of smart contract in trade finance

    Wang X, Xu F. “The value of smart contract in trade finance.” Manufacturing & Service Operations Management, vol. 25, no. 6, pp. 2056–2073, 2022. https://doi.org/10.1287/msom.2022.1126

    arXiv 2022

  8. [11]

    Blockchainforthemetaverse:Areview

    Huynh-The T, Gadekallu TR, Wang W, Yenduri G, Ranaweera P, Pham Q-V, Costa DB da, LiyanageM.“Blockchainforthemetaverse:Areview.” Future Generation Computer Systems, vol.143,pp.401–419,2023

    work page 2023

Show all 51 references
  1. [12]

    A survey of attacks on ethereum smart contracts (sok)

    Atzei N, Bartoletti M, Cimoli T. “A survey of attacks on ethereum smart contracts (sok).” Proceedings of the principles of security and trust (POST),pp.164–186,2017

    2017

  2. [13]

    Characterizing the solana NFT ecosystem

    Kong D, Li X, Li W. “Characterizing the solana NFT ecosystem.” Companion proceedings of the ACM web conference 2024,pp.766–769,2024

    2024

  3. [14]

    GasTrace: Detecting sandwich attack malicious accounts in ethereum

    Liu Z, Li X, Peng H, Li W. “GasTrace: Detecting sandwich attack malicious accounts in ethereum.” 2024 IEEE international conference on web services (ICWS), pp. 1409–1411, 2024

    2024

  4. [15]

    SCALM: Detecting bad practices in smart contracts through LLMs

    Li Z, Li X, Li W, Wang X. “SCALM: Detecting bad practices in smart contracts through LLMs.” arXiv preprint arXiv:2502.04347,2025

    2025

  5. [16]

    Enhancing smart contract vulnerability detection in DApps leveragingfine-tunedLLM

    Bu J,Li W, Li Z, Zhang Z, Li X. “Enhancing smart contract vulnerability detection in DApps leveragingfine-tunedLLM.” arXiv preprint arXiv:2504.05006,2025. [17]JeonS,LeeG,KimH,WooSS.“Designandevaluationofhighlyaccuratesmartcontractcode vulnerabilitydetectionframework.” Data Min...

    2025

  6. [18]

    Defectchecker: Automated smart contract defect detection by analyzing evm bytecode

    Chen J, Xia X, Lo D, Grundy J, Luo X, Chen T. “Defectchecker: Automated smart contract defect detection by analyzing evm bytecode.” IEEE Transactions on Software Engineering, vol.48,no.7,pp.2189–2207,2021.https://doi.org/10.1109/TSE.2021.3054928

    2021

  7. [21]

    SoK: Security analysis of blockchain-based cryptocurrency

    Liu Z, Li X. “SoK: Security analysis of blockchain-based cryptocurrency.” arXiv preprint arXiv:2503.22156,2025

    2025 arXiv

  8. [22]

    SmartBugBert: BERT-enhanced vulnerability detection for smartcontractbytecode

    Bu J, Li W,Li Z, Zhang Z, Li X. “SmartBugBert: BERT-enhanced vulnerability detection for smartcontractbytecode.” arXiv preprint arXiv:2504.05002,2025

    2025

  9. [23]

    StateGuard: Detecting state derailment defects in decentralized exchange smart contract

    Li Z, Li W, Li X, Zhang Y. “StateGuard: Detecting state derailment defects in decentralized exchange smart contract.” Companion proceedings of the ACM web conference 2024, pp. 810–813,2024

    2024

  10. [24]

    SCLA: Automated smart contract summarization via LLMs andcontrolflowprompt

    Li X, Mao Y, Lu Z, Li W, Li Z. “SCLA: Automated smart contract summarization via LLMs andcontrolflowprompt.” arXiv e-prints,pp.arXiv–2402,2024. [25]LiZ,Li W,LiX,Zhang Y.“Guardiansoftheledger:Protectingdecentralized exchangesfrom statederailmentdefects.” IEEE Transactions on Re...

    2024

  11. [26]

    A survey on smart contract vulnerabilities: Data sources, detection and repair

    Chu H, Zhang P, Dong H, Xiao Y, Ji S, Li W. “A survey on smart contract vulnerabilities: Data sources, detection and repair.” Information and Software Technology, vol. 159, pp. 107221–107238,2023.https://doi.org/10.1109/JIOT.2023.3241544

    2023

  12. [27]

    Smart contract life-cycle management: An engineering framework for the generation of robust and verifiable smart contracts

    Mustafa I, McGibney A, Rea S. “Smart contract life-cycle management: An engineering framework for the generation of robust and verifiable smart contracts.” Frontiers Blockchain, vol.6,pp.2624–7852,2023.https://doi.org/10.3389/fbloc.2023.1276233

    2023

  13. [28]

    Unveiling wash trading in popular NFT markets

    Niu Y, Li X, Peng H, Li W. “Unveiling wash trading in popular NFT markets.” Companion proceedings of the ACM web conference 2024,pp.730–733,2024

    2024

  14. [29]

    DeFiTail: DeFi protocol inspection through cross-contract execution analysis

    Li W, Li X, Zhang Y, Li Z. “DeFiTail: DeFi protocol inspection through cross-contract execution analysis.” Companion proceedings of the ACM web conference 2024, pp. 786–789, 2024

    2024

  15. [30]

    Smart contracts in the real world: A statistical explorationofexternaldatadependencies

    Wang Y, Li X, Ye S, Xie L, Xing J. “Smart contracts in the real world: A statistical explorationofexternaldatadependencies.” arXiv preprint arXiv:2406.13253,2024

    2024

  16. [31]

    Detecting malicious accounts in Web3 through transaction graph

    Li W, Liu Z, Li X, Nie S. “Detecting malicious accounts in Web3 through transaction graph.” Proceedings of the 39th IEEE/ACM international conference on automated software engineering,pp.2482–2483,2024

    2024

  17. [32]

    SmartBugs 2.0: An execution framework for weakness detection in Ethereum smart contracts

    Angelo M di, Durieux T, Ferreira JF, Salzer G. “SmartBugs 2.0: An execution framework for weakness detection in Ethereum smart contracts.” Proceedings of the 38th IEEE/ACM international conference on automated software engineering (ASE), pp. 2102–2105, 2023. https://doi.org/10...

    2023

  18. [35]

    Understanding the dynamic and microscopic traits of typical ethereum accounts

    Wu J, Huang B, Liu J, Li Q, Zheng Z. “Understanding the dynamic and microscopic traits of typical ethereum accounts.” Information Processing & Management, vol. 60, no. 4, pp. 103384–103400,2023.https://doi.org/10.1016/j.ipm.2023.103384

    2023

  19. [36]

    Network-based evidential three-way theoretic model for large-scale group decision analysis

    Liu Z, He X, Deng Y. “Network-based evidential three-way theoretic model for large-scale group decision analysis.” Information Sciences, vol. 547, pp. 689–709, 2021. https://doi.org/10.1016/j.ins.2020.08.042

    2021 doi

  20. [37]

    Dappscan: Building large-scale datasets for smartcontractweaknessesindappprojects

    Zheng Z, Su J, Chen J, Lo D, Zhong Z, Ye M. “Dappscan: Building large-scale datasets for smartcontractweaknessesindappprojects.” IEEE Transactions on Software Engineering,vol. 50,pp.1360–1373,2024.https://doi.org/10.1109/TSE.2024.3383422

    2024

  21. [38]

    Mutation testing for integer overflow in ethereum smartcontracts

    Sun J, Huang S, Zheng C, Wang T, Zong C, Hui Z. “Mutation testing for integer overflow in ethereum smartcontracts.” Tsinghua Science and Technology,vol. 27,no. 1,pp.27–40,2021. https://doi.org/10.26599/TST.2020.9010036

    2021

  22. [39]

    DeFi protocol DForce suffers reentrancy attack, $3.6 million lost

    Khatri A “DeFi protocol DForce suffers reentrancy attack, $3.6 million lost”. [Online] Available: https://zyberglobal.com/f/defi-protocol-dforce-suffers-reentrancy-attack-36-million-lost?blogc ategory=News

  23. [40]

    Smart contract vulnerability detection combined with multi-objective detection

    Zhang L, Wang J, Wang W, Jin Z, Su Y, Chen H. “Smart contract vulnerability detection combined with multi-objective detection.” Computer Networks, vol. 217, pp. 109289–109302, 2022.https://doi.org/10.1016/j.comnet.2022.109289

    2022

  24. [41]

    TXSPECTOR: Uncovering attacks in ethereum from transactions

    Zhang M, Zhang X, Zhang Y, Lin Z. “TXSPECTOR: Uncovering attacks in ethereum from transactions.” Proceedings of the 29th USENIX security symposium (USENIX security), pp. 2775–2792,2020. [42]Ivanov N,Yan Q, Kompalli A.“TxT : Real-time transaction encapsulation for ethereum smar...

    2020

  25. [44]

    A survey of mythril, a smart contract security analysis tool for EVM bytecode

    Sharma N, Sharma S. “A survey of mythril, a smart contract security analysis tool for EVM bytecode.” Indian J Natural Sci,vol.13,pp.75–83,2022

    2022

  26. [45]

    Confuzzius: A data dependency-aware hybrid fuzzer for smart contracts

    Torres CF, Iannillo AK, Gervais A, State R. “Confuzzius: A data dependency-aware hybrid fuzzer for smart contracts.” Proceedings of the IEEE european symposium on security and privacy,pp.103–119,2021.https://doi.org/10.1109/EuroSP51992.2021.00018

    2021

  27. [46]

    Slither: A static analysis framework for smart contracts

    Feist J, Grieco G, Groce A. “Slither: A static analysis framework for smart contracts.” Proceedings of the 2019 IEEE/ACM 2nd international workshop on emerging trends in software engineering for blockchain, pp. 8–15, 2019. https://doi.org/10.1109/WETSEB.2019.00008

    2019

  28. [47]

    Sfuzz: An efficient adaptive fuzzer for solidity smart contracts

    Nguyen TD, Pham LH, Sun J, Lin Y, Minh QT. “Sfuzz: An efficient adaptive fuzzer for solidity smart contracts.” Proceedings of the ACM/IEEE 42nd international conference on software engineering,pp.778–788,2020.https://doi.org/10.1145/3377811.3380334

    2020

  29. [48]

    Smart contract vulnerabilities: Vulnerable does not imply exploited

    Perez D, Livshits B. “Smart contract vulnerabilities: Vulnerable does not imply exploited.” Proceedings of the 30th USENIX security symposium (USENIX security), pp. 1325–1341, 2021

    2021

  30. [49]

    Temporal analysis of transaction ego networks with different labels on ethereum

    Huang B, Liu J, Wu J, Li Q, Lin H. “Temporal analysis of transaction ego networks with different labels on ethereum.” Proceedings of the IEEE international symposium on circuits and systems,pp.3517–3521,2022.https://doi.org/10.1109/ISCAS48785.2022.9937257 [50]Zhang Z, Lin Z, M...

    2022

  31. [51]

    Temporal analysis of the entire ethereum blockchain network

    Zhao L, Sen Gupta S, Khan A, Luo R. “Temporal analysis of the entire ethereum blockchain network.” Proceedings of the web conference, pp. 2258–2269, 2021. https://doi.org/10.1145/3442381.3449916 [52]Li X, et al. “Hybrid analysis of smart contracts and malicious behaviors in et...

    2021

  32. [54]

    Modeling and understanding ethereum transaction records via a complex network approach

    Lin D, Wu J, Yuan Q, Zheng Z. “Modeling and understanding ethereum transaction records via a complex network approach.” IEEE Transactions on Circuits and Systems II: Express Briefs,vol.67,no.11,pp.2737–2741,2020.https://doi.org/10.1109/TCSII.2020.2968376

    2020

  33. [55]

    Graph structure and statistical properties of ethereum transaction relationships

    Guo D, Dong J, Wang K. “Graph structure and statistical properties of ethereum transaction relationships.” Information Sciences, vol. 492, pp. 58–71, 2019. https://doi.org/10.1016/j.ins.2019.04.013

    2019 doi

  34. [56]

    TTAGN: Temporal transaction aggregation graph network for ethereum phishing scams detection

    Li S, Gou G, Liu C, al. et. “TTAGN: Temporal transaction aggregation graph network for ethereum phishing scams detection.” Proceedings of the ACM web conference, pp. 661–669, 2022.https://doi.org/10.1145/3485447.3512226

    2022

  35. [57]

    Evolution of ethereum transaction relationships: Toward understanding global driving factors from microscopic patterns

    Lin D, Chen J, Wu J, Zheng Z. “Evolution of ethereum transaction relationships: Toward understanding global driving factors from microscopic patterns.” IEEE Transactions on Computational Social Systems, vol. 9, no. 2, pp. 559–570, 2021. https://doi.org/10.1109/TCSS.2021.3093384

    2021

  36. [58]

    Uncle maker:(time) stamping out the competition in ethereum

    Yaish A, Stern G, Zohar A. “Uncle maker:(time) stamping out the competition in ethereum.” Proceedings of the ACM SIGSAC conference on computer and communications security, pp. 135–149,2023.https://doi.org/10.1145/3576915.3616674 [59]BaiQ,ZhangC,LiuN,ChenX,XuY,WangX.“Evolutiono...

    2023

  37. [60]

    Ethainter: A smart contract security analyzer for composite vulnerabilities

    Brent L, Grech N, Lagouvardos S, Scholz B, Smaragdakis Y. “Ethainter: A smart contract security analyzer for composite vulnerabilities.” Proceedings of the 41st ACM SIGPLAN conference on programming language design and implementation, pp. 454–469, 2020. https://doi.org/10.5281...

    2020 doi

  38. [61]

    Smarter contracts: Detecting vulnerabilities in smart contracts with deep transferlearning

    Sendner C, Chen H, Fereidooni H, Petzi L, König J, Stang J, Dmitrienko A, Sadeghi A-R, Koushanfar F. “Smarter contracts: Detecting vulnerabilities in smart contracts with deep transferlearning.” NDSS,pp.1–18,2023.https://dx.doi.org/10.14722/ndss.2023.23263

    2023

  39. [62]

    Peculiar: Smart contract vulnerability detection based on crucial data flow graph and pre-training techniques

    Wu H, Zhang Z, Wang S, Lei Y, Lin B, Qin Y, Zhang H, Mao X. “Peculiar: Smart contract vulnerability detection based on crucial data flow graph and pre-training techniques.” Proceeding of the IEEE 32nd international symposium on software reliability engineering (ISSRE),pp.378–3...

    2021

  40. [63]

    Gaschecker: Scalable analysis for discovering gas-inefficient smartcontracts

    Chen T, Feng Y, Li Z, Zhou H, al. et. “Gaschecker: Scalable analysis for discovering gas-inefficient smartcontracts.” IEEE Transactions on Emerging Topics in Computing,vol. 9, no.3,pp.1433–1448,2020

    2020

  41. [64]

    Gasol: Gas analysis and optimization for ethereum smart contracts

    Albert E, Correas J, Gordillo P, Román-Dı́ez G, Rubio A. “Gasol: Gas analysis and optimization for ethereum smart contracts.” Proceedings of the international conference on tools and algorithms for the construction and analysis of systems (TACAS), pp. 118–125, 2020

    2020

  42. [65]

    Scsguard: Deep scam detection for ethereum smart contracts

    Hu H, Bai Q, Xu Y. “Scsguard: Deep scam detection for ethereum smart contracts.” Proceedings of the IEEE INFOCOM-IEEE conference on computer communications workshops (INFOCOM WKSHPS), pp. 1–6, 2022. https://doi.org/10.1109/INFOCOMWKSHPS54753.2022.9798296

    2022

  43. [66]

    An exploratory study of smart contracts in the ethereum blockchain platform

    Oliva GA, Hassan AE, Jiang ZM. “An exploratory study of smart contracts in the ethereum blockchain platform.” Empirical Software Engineering, vol. 25, pp. 1864–1904, 2020. https://doi.org/10.1007/s10664-019-09796-5

    1904 doi

Pith tools

Reviewed August 16, 2026 · model on record in the stance chip above.