Pith. sign in

REVIEW 5 major objections 5 minor 56 references

Exposing Hidden Backdoors in NFT Smart Contracts: A Static Security Analysis of Rug Pull Patterns

T0 review · 5 major / 5 minor · reviewed 2026-08-07 · deepseek-v4-flash

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

Pith's one-line read Analyzing 49,940 verified NFT smart contracts with the Slither static analyzer, this paper claims that over 22% carry high-risk rug-pull indicators such as selfdestruct, suggesting hidden backdoors are systematically pre-engineered rather…

desk verdict Real dataset, real pipeline, but the 22.6% 'hidden backdoor' figure is an unvalidated heuristic dressed as a finding. read the letter →

arxiv 2506.07974 v1 pith:TNRMUFZD submitted 2025-06-09 cs.CR

Chetan Pathade , Shweta Hooli This is my paper
classification cs.CR
keywords NFTsmartcontractsrugpullstaticanalysisselfdestructdelegatecallriskscoringEthereumhiddenbackdoors
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

This paper claims that hidden backdoors in NFT smart contracts are common enough to be a systemic pattern, not rare accidents. Running the Slither static analyzer over 49,940 verified NFT contracts on Ethereum and applying a weighted risk score, it finds that about 22.6% of contracts reach high-risk status through combinations of selfdestruct, delegatecall, owner-only mint/withdraw, tx.origin checks, and deprecated compiler versions. The intended upshot is that rug pulls can be detected and triaged at scale before deployment by flagging these code patterns. A sympathetic reader would take the paper's central claim to be that roughly one in four verified NFT contracts contains logic that can drain funds or seize control, and that this is frequently pre-engineered rather than accidental.

What carries the argument

The machinery is a two-stage pipeline. First, Slither constructs a contract's control-flow graph, abstract syntax tree, and inheritance hierarchy to detect over 100 vulnerability patterns, with emphasis on selfdestruct, delegatecall, external calls in loops, owner-only or unrestricted mint/withdraw, and tx.origin-based access control. Second, a hand-assigned heuristic scoring model weights each finding (selfdestruct and delegatecall +3; external call in loop, unrestricted/owner-only withdraw/mint, and tx.origin checks +2; deprecated Solidity version +1) and classifies contracts with cumulative score ≥5 as high risk, 3–4 as medium, and 1–2 as low. The scoring model is what turns raw Slither findings into the paper's headline risk distribution.

What would settle it

Trace the on-chain history of a random sample of the 11,309 high-risk contracts: if they execute selfdestruct, drain funds, or freeze user assets at the same rate as unflagged contracts, the pattern score does not predict rug pulls. Alternatively, remove contracts that are near-direct copies of standard library templates and re-run the scoring; if the high-risk share collapses below the paper's 22.6%, the signal is template reuse rather than deliberate backdoor engineering.

Watch

Extended reading notes

Core claim

The central discovery is a measured prevalence: across 49,940 standalone, verified NFT contracts derived from the DISL dataset, 11,309 (22.6%) score at least 5 on the authors' heuristic risk scale and are labelled high-risk, 17,478 (35.0%) are medium, and 21,153 (42.4%) are low. Individual pattern counts reinforce the picture: 18,925 contracts use owner-only withdrawal, 14,478 have unrestricted mint access, 6,881 use selfdestruct, and 4,724 use delegatecall. The paper interprets the co-occurrence of these patterns—8,217 contracts with two or more high-severity indicators, 3,456 with three or more, and 62 with four or more—as evidence that many contracts are deliberately designed to retain deployer control after launch, supporting the hypothesis that rug pulls are pre-engineered through contract logic rather than opportunistic exits.

Load-bearing premise

The central interpretation rests on the assumption that co-occurrence of these weighted code patterns is a valid proxy for deliberate backdoor design; if selfdestruct, delegatecall, and owner-only controls are mostly accidental, inherited from standard templates, or common in benign NFT contracts, the 22.6% figure no longer measures rug-pull intent.

Editorial extensions

If this is right

  • If the 22.6% high-risk figure holds, NFT marketplaces can pre-screen collections by running static pattern scoring before listing, and label contracts with risk badges.
  • Security auditors gain a reproducible first-line filter that points human review to the small set of contracts with overlapping backdoor indicators.
  • Developers are given a concrete checklist: avoid selfdestruct and delegatecall, renounce ownership, restrict mint/withdraw conditions, and avoid tx.origin.
  • The co-occurrence data implies that exploitability escalates with pattern combinations, so a contract with selfdestruct plus delegatecall should be treated as more dangerous than one with either alone.
  • The near-38% rate of owner-only withdrawal suggests centralized post-deployment control, not decentralization, is the default for many NFT projects.

Reading between the lines

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

  • The paper does not link its flagged contracts to actual on-chain rug pull events; correlating the 11,309 high-risk contracts with transaction histories of fund drains or selfdestruct executions would test whether the score predicts real harm.
  • A substantial share of the high-risk signal may come from template reuse: many NFT collections start from OpenZeppelin base contracts with onlyOwner and mint logic, so a natural extension is to subtract template-derived patterns and re-measure the deliberate-backdoor rate.
  • Extending the same weighted scoring to other chains (Polygon, BNB Chain, Avalanche) would reveal whether the 22.6% prevalence is Ethereum-specific or a cross-ecosystem norm.
  • The paper's own admission that static analysis 'cannot differentiate between intentional malicious logic and negligibly insecure logic' suggests the strongest version of the claim—pre-engineering—will need dynamic confirmation, such as fuzzing or symbolic execution, to hold up.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

5 major / 5 minor

Summary. The paper presents a static analysis pipeline that filters verified Ethereum contracts from the DISL dataset to NFT-related contracts, runs Slither, assigns a weighted risk score based on six hand-picked vulnerability patterns, and classifies contracts into low/medium/high risk tiers. The headline result is that 22.6% of 49,940 analyzed contracts are high-risk, and the authors interpret this as evidence that rug-pull backdoors are deliberately pre-engineered rather than accidental. The paper also reports prevalence of individual patterns, co-occurrence statistics, example contracts, and mitigation recommendations.

Significance. If the central claim were established, a measurement showing that more than 20% of verified NFT contracts contain deliberate backdoor logic would be important for the smart-contract security community. The paper's pipeline design is straightforward, its use of a large public dataset (DISL) is appropriate, and the authors make a good-faith effort to describe preprocessing, static analysis, and scoring. However, the paper's own limitation statement in Section VII-C concedes that static scoring cannot distinguish intentional from negligent logic, which directly undercuts the headline interpretation. The heuristic weights in Table I are not validated against any ground-truth set of known rug pulls, and no baseline, sensitivity analysis, or uncertainty intervals are provided. The contribution is therefore best viewed as a descriptive prevalence study of certain code patterns, not as a detection study of hidden backdoors. With substantial reframing and additional validation, the dataset could be useful, but as written the load-bearing inference is unsupported.

major comments (5)
  1. [VII-C, VII-A, VIII] Section VII-C states that the risk scoring 'cannot differentiate between intentional malicious logic and negligibly insecure logic,' yet Section VII-A (and the conclusion in Section VIII) asserts that contracts with these patterns are 'unlikely to occur by accident' and that the results 'strongly suggest' a recurring design model of deliberately retained control. This is the central inference of the paper, and it is contradicted by the paper's own limitation. Since Slither findings are syntactic pattern matches—for example, 'external call in a loop' fires on routine batch-transfer loops in OpenZeppelin-based contracts, and 'onlyOwner withdrawal' is standard in Ownable templates—the leap from pattern co-occurrence to malicious intent is unsupported. The authors must either add a validated ground-truth comparison (e.g., known rug-pull contracts versus known benign collections) or substantially weaken the claims to pattern prevalence.
  2. [Table I, Section III-C] Table I assigns weights of +3, +2, or +1 to six vulnerability patterns and sets a high-risk threshold of score ≥ 5, but no justification, validation, or sensitivity analysis is given. The weights and thresholds are free parameters; different choices would change the headline 22.6% figure. The paper does not compare the scoring against any labeled dataset of confirmed rug pulls, nor does it report precision, recall, or confidence intervals. Because the weights are arbitrary, the risk tiers are a definitional output of the authors' heuristic rather than a measured property. A concrete test would be to score a set of confirmed rug-pull contracts (e.g., from Huang et al. [42]) and a set of known benign collections and report separation; until then, the 22.6% figure is unvalidated.
  3. [Section IV, Table II] Table II states that the DISL dataset contains 98,879 contracts, while Section III-A says DISL contains more than 514,000 contracts. Section IV-B says the NFT filter reduces 98,879 contracts to 'approximately 98,000 candidates,' which implies the NFT filter removed fewer than 1% of contracts, and then sanitization removes roughly half. These numbers do not reconcile: if DISL has 514k contracts, what is the 98,879? How can nearly all of 98,879 be NFT-relevant while the broader dataset is 514k? The manuscript should report the exact counts at each stage and explain the relationship between the DISL subset and the claimed 514k total.
  4. [Section V-E, Table III] Section V-E states that 'over 22% of NFT contracts show high-risk patterns such as selfdestruct,' but selfdestruct appears in only 6,881 contracts (13.8% of the 49,940), and the high-risk tier (score ≥ 5) is a composite that can be reached without selfdestruct. Also, 'nearly 38% of contracts use onlyOwner in a way that grants unilateral financial control' is inferred from 18,925 contracts with an onlyOwner withdrawal/mint finding, but Slither's finding is a pattern match that does not establish unilateral control, since the function may be restricted by other conditions. The results section should report patterns as detected by the tool, not as confirmed privileges.
  5. [Section III and IV (reproducibility)] The paper describes a 'repeatable process' and a 'reproducible foundation,' but neither the filtering/sanitization scripts, the Slither wrapper, the risk-scoring implementation, nor the list of analyzed contract addresses is released. For a measurement study whose headline is a prevalence percentage, this makes independent verification impossible. At minimum, the authors should release the contract identifiers and the per-contract detection output.
minor comments (5)
  1. [Section II] The Background section contains a duplicated paragraph: the second paragraph ('The NFT ecosystem is based on blockchain technologies...') repeats the content of the first paragraph nearly verbatim.
  2. [Abstract/Index Terms] The index terms line has a typo: 'Index T erms' should be 'Index Terms.'
  3. [Figure 2] Figure 2 is captioned 'MSmart analysis flow chart [55],' but the methodology uses Slither, and the caption/reference do not match the paper's pipeline.
  4. [References] References [54] and [56] are unrelated to NFT or smart-contract security (they concern LLM injection and genomic privacy); they appear to be padding and should be removed or replaced.
  5. [Table V] Table V lists anonymized contract IDs but no source addresses or verification links, so the 'representative examples' cannot be checked; the authors should provide real addresses or release the underlying data.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the 22.6% high-risk figure is an explicitly heuristic, definitional classification, not a prediction that reduces to its own inputs; the paper's stated inability to distinguish intentional from negligent logic is a validity limitation, not a circular derivation.

full rationale

The paper's derivation chain is an empirical measurement pipeline: select NFT contracts, run Slither, apply the Table I heuristic weights, bin contracts into tiers by score (Section III-C, Table III), and report prevalence. No output quantity is a prediction fitted to the same data, and no parameter is estimated from the dependent variable. The risk tier is literally defined by the weighted sum, so the statement that 22.6% of contracts are 'high risk' is a transparent restatement of the scoring rule rather than an independent test; this is operationalization, not circularity. The main interpretive step is Section VII-A, where co-occurrence is read as evidence that backdoors were 'pre-engineered.' That inference is not a formal derivation, and the paper itself at Section VII-C concedes that the scoring 'cannot differentiate between intentional malicious logic and negligibly insecure logic.' That concession weakens the conclusion's validity, but it does not make any equation reduce to itself. There are no load-bearing self-citations: the authors are independent researchers, and no relevant prior work by the same authors is invoked as evidence; the 'uniqueness imported from authors' and 'ansatz smuggled in via citation' patterns do not occur. Section VII-C's limitation is flagged and weighed: it limits the strength of the Section VII-A claim but does not constitute circular reasoning. Accordingly, no specific circular steps are identified.

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

The central claim depends on hand-assigned heuristic weights and risk thresholds, plus domain assumptions that static patterns map to malicious intent and that the filtered contract set is representative. No new entities are introduced.

free parameters (7)
  • risk_weight_selfdestruct = 3
    Hand-assigned in Table I; no calibration against confirmed rug pulls.
  • risk_weight_delegatecall = 3
    Hand-assigned in Table I; no empirical justification.
  • risk_weight_external_call_in_loop = 2
    Hand-assigned in Table I; no empirical justification.
  • risk_weight_unrestricted_or_owner_only_withdraw_mint = 2
    Hand-assigned in Table I; no empirical justification.
  • risk_weight_tx_origin_access_control = 2
    Hand-assigned in Table I; no empirical justification.
  • risk_weight_deprecated_solidity_version = 1
    Hand-assigned in Table I; outdated compiler does not imply malicious intent.
  • risk_tier_thresholds = high >= 5, medium 3-4, low 1-2; score 0 unclassified
    Chosen thresholds define the headline percentages; no theoretical or empirical calibration, and score-0 contracts are not assigned a tier.
assumptions (4)
  • domain assumption Slither's static findings are a reliable proxy for rug-pull-relevant backdoor risk.
    Used throughout Section V; the paper never validates flags against confirmed malicious contracts.
  • domain assumption Contracts implementing NFT interface functions or referencing NFT keywords are representative NFT contracts.
    Section IV-B's interface, inheritance, and keyword filters may include false positives and exclude proxy or multi-file contracts.
  • domain assumption High co-occurrence of static patterns indicates deliberate design rather than accidental insecure coding.
    Stated in Section VII-A as a supported hypothesis, but no ground truth is provided.
  • domain assumption Deprecated Solidity version usage is a rug-pull indicator.
    Assigned +1 in Table I; an outdated compiler version is a code-quality issue, not a backdoor indicator.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Exposing Hidden Backdoors in NFT Smart Contracts: A Static Security Analysis of Rug Pull Patterns." pith.science (2026). https://pith.science/paper/TNRMUFZD

@misc{pith2026250607974,
  author       = {Pith},
  title        = {Pith review of: Exposing Hidden Backdoors in NFT Smart Contracts: A Static Security Analysis of Rug Pull Patterns},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TNRMUFZD}},
  note         = {Machine review of arXiv:2506.07974}
}
read the original abstract

The explosive growth of Non-Fungible Tokens (NFTs) has revolutionized digital ownership by enabling the creation, exchange, and monetization of unique assets on blockchain networks. However, this surge in popularity has also given rise to a disturbing trend: the emergence of rug pulls - fraudulent schemes where developers exploit trust and smart contract privileges to drain user funds or invalidate asset ownership. Central to many of these scams are hidden backdoors embedded within NFT smart contracts. Unlike unintentional bugs, these backdoors are deliberately coded and often obfuscated to bypass traditional audits and exploit investor confidence. In this paper, we present a large-scale static analysis of 49,940 verified NFT smart contracts using Slither, a static analysis framework, to uncover latent vulnerabilities commonly linked to rug pulls. We introduce a custom risk scoring model that classifies contracts into high, medium, or low risk tiers based on the presence and severity of rug pull indicators. Our dataset was derived from verified contracts on the Ethereum mainnet, and we generate multiple visualizations to highlight red flag clusters, issue prevalence, and co-occurrence of critical vulnerabilities. While we do not perform live exploits, our results reveal how malicious patterns often missed by simple reviews can be surfaced through static analysis at scale. We conclude by offering mitigation strategies for developers, marketplaces, and auditors to enhance smart contract security. By exposing how hidden backdoors manifest in real-world smart contracts, this work contributes a practical foundation for detecting and mitigating NFT rug pulls through scalable automated analysis.

Figures

Figures reproduced from arXiv: 2506.07974 by the authors.

Figure 1
Figure 1. Slither Overview [8] This process yields a rich vulnerability profile for each con￾tract, which we then classify based on exploitability. C. Heuristic-Based Risk Scoring Static analysis tools provide a wealth of raw issue data, but not all findings are equally dangerous or relevant to rug pulls. To quantify contract risk in a meaningful and interpretable way, we introduce a heuristic scoring system based on security… view at source ↗
Figure 2
Figure 2. MSmart analysis flow chart [55] D. Result Aggregation and Visualisation To facilitate interpretation and enable future audits, we compile all results into a structured dataset. For each contract, we store: • Detected issues and descriptions • Address and filename • Total score and risk tier • Affected functions and line numbers We then generate a series of visualizations, including: • Bar charts showing the frequenc… view at source ↗
Figure 3
Figure 3. NFT Contracts by Risk Tier TABLE III: Risk Tier Classification Risk Tier Criteria Number of Contracts Percentage (%) High Score ≥ 5 11,309 22.6% Medium Score 3–4 17,478 35.0% Low Score 1–2 21,153 42.4% Insight: Nearly 1 in 4 NFT contracts in our dataset exhibit multiple high-risk patterns, suggesting a systemic threat posed by contract-level control logic abuse. A. Prevalence of Individual Vulnerability Patterns We … view at source ↗
Figures from the paper (1 more)
Figure 4
Figure 4. Figure 4: Smart Contract Vulnerability Patterns • Use of onlyOwner withdrawal • Unrestricted mint() access • Use of selfdestruct() • Use of delegatecall • External calls in loops • tx.origin authorization logic TABLE IV: Vulnerability Patterns and Contracts Affected Vulnerabilit…

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

56 extracted references · 48 canonical work pages

  1. [42]

    Jintao Huang, Ningyu He, Kai Ma, Jiang Xiao, and Haoyu Wang. 2023. Miracle or Mirage? A Measurement Study of NFT Rug Pulls. Proc. ACM Meas. Anal. Comput. Syst. 7, 3, Article 51 (December 2023), 25 pages. https://doi.org/10.1145/3626782

    work page doi:10.1145/3626782 2023

  2. [1]

    ERC-721: Non- Fungible Token Standard

    William Entriken and Dieter Shirley, et al. ERC-721: Non- Fungible Token Standard. Ethereum Improvement Proposals. https://eips.ethereum.org/EIPS/eip-721

    work page

  3. [2]

    Ethereum Improvement Proposals

    ERC-1155: Multi Token Standard. Ethereum Improvement Proposals. https://github.com/ethereum/eips/issues/1155

    work page

  4. [3]

    Understanding Rug Pulls: An In-depth Behavioral Analysis of Fraudulent NFT Creators

    Sharma Trishie and Agarwal Rachit, et al. "Understanding Rug Pulls: An In-depth Behavioral Analysis of Fraudulent NFT Creators" Association for Computing Machinery (2023)

    work page 2023

  5. [4]

    TurboPack: Honest Majority MPC with Constant Online Communication

    Escudero Daniel and Goyal Vipul, et al. "TurboPack: Honest Majority MPC with Constant Online Communication" Association for Computing Machinery (2022)

    work page 2022

  6. [5]

    Pied-Piper: Revealing the Backdoor Threats in Ethereum ERC Token Contracts

    Ma Fuchen and Ren Meng, et al. "Pied-Piper: Revealing the Backdoor Threats in Ethereum ERC Token Contracts" Association for Computing Machinery (2023)

    work page 2023

  7. [6]

    Smart Contract Vulnera- bilities: Vulnerable Does Not Imply Exploited

    Daniel Perez and Benjamin Livshits, et al. "Smart Contract Vulnera- bilities: Vulnerable Does Not Imply Exploited" USENIX Association (2021)

    work page 2021

  8. [7]

    The State of Ethereum Smart Contracts Security: Vulnerabilities, Countermeasures, and Tool Support

    Haozhe Zhou and Amin Milani Fard, et al. "The State of Ethereum Smart Contracts Security: Vulnerabilities, Countermeasures, and Tool Support" Journal of Cybersecurity and Privacy (2022)

    work page 2022

Show all 56 references
  1. [8]

    Slither: A Static Analysis Framework for Smart Contracts

    Feist Josselin and Grieco Gustavo, et al. "Slither: A Static Analysis Framework for Smart Contracts" 2019 IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB)

    2019

  2. [9]

    Journal of Systems and Software

    Ye Jiaming and Ma Mingliang, et al. "Journal of Systems and Software" Elsevier BV (2022). https://arxiv.org/abs/1912.04466

    2022 arXiv

  3. [10]

    ERC-721 Non-Fungible Token Standard - Devel- oper Documentation. Ethereum.org Developer Docs

    "ERC-721 Non-Fungible Token Standard - Devel- oper Documentation. Ethereum.org Developer Docs." https://ethereum.org/en/developers/docs/standards/tokens/erc-721/

  4. [11]

    Enjin Platform

    ERC-1155 Token Standard - Official Enjin Ecosystem Documentation. Enjin Platform. https://enjin.io/ecosystem/ethereum-foundation

  5. [12]

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

    Hanting Chu and Pengcheng Zhang, et al. "A survey on smart contract vulnerabilities: Data sources, detection and repair" Information and Software Technology

  6. [13]

    Smart Contract Vulnerabilities, Tools, and Benchmarks: An Updated Systematic Literature Review

    Gerardo Iuliano and Dario Di Nucci. "Smart Contract Vulnerabilities, Tools, and Benchmarks: An Updated Systematic Literature Review" arXiv:2412.01719 (2025)

    2025

  7. [14]

    Serial Scammers and Attack of the Clones: How Scammers Coordinate Multiple Rug Pulls on Decentralized Exchanges

    Huynh, Phuong Duy and Dau, Son Hoang, et al. "Serial Scammers and Attack of the Clones: How Scammers Coordinate Multiple Rug Pulls on Decentralized Exchanges." Association for Computing Machinery (2025)

    2025

  8. [15]

    DeGatchi Technical Research

    Smart Contract Obfuscation Techniques. DeGatchi Technical Research. https://degatchi.com/articles/smart-contract-obfuscation/

  9. [16]

    NFT Smart Contract Audit: Guide For Founders & Man- agers

    Malanii Oleh. "NFT Smart Contract Audit: Guide For Founders & Man- agers." Hacken Security Research. https://hacken.io/discover/security- audit-for-nft-guide-for-founders-and-managers/

  10. [17]

    Vulnerability detection techniques for smart contracts: A systematic literature review

    Fernando Richter Vidal and Naghmeh Ivaki, et al. "Vulnerability detection techniques for smart contracts: A systematic literature review." Information and Software Technology. https://www.sciencedirect.com/science/article/pii/S016412122400205X

  11. [18]

    Proxion: Uncovering Hid- den Proxy Smart Contracts for Finding Collision Vulnerabilities in Ethereum

    Cheng-Kang Chen and Wen-Yi Chu, et al. "Proxion: Uncovering Hid- den Proxy Smart Contracts for Finding Collision Vulnerabilities in Ethereum." arXiv:2409.13563. https://arxiv.org/abs/2409.13563

    arXiv

  12. [19]

    Blockchain Security Analysis

    Top NFT Smart Contract Audit Tools in 2025: Ultimate Security Guide. Blockchain Security Analysis. https://blockchainpress.media/nft-smart- contract-audit-tools/

    2025

  13. [20]

    How effective are smart con- tract analysis tools? evaluating smart contract static analysis tools using bug injection

    Ghaleb, Asem and Pattabiraman, Karthik. "How effective are smart con- tract analysis tools? evaluating smart contract static analysis tools using bug injection." Proceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis

  14. [21]

    ASSERT-KTH. (2024). DISL Dataset - 514,506 Unique Solidity Files. HuggingFace Datasets. https://huggingface.co/datasets/ASSERT- KTH/DISL

    2024

  15. [22]

    Ethereum Foundation. (2024). Contracts - Solidity Documentation. Official Solidity Language Reference. https://docs.soliditylang.org/en/latest/contracts.html

    2024

  16. [23]

    OpenZeppelin. (2024). OpenZeppelin Contracts - Library for Secure Smart Contract Development. GitHub Repository. https://github.com/OpenZeppelin/openzeppelin-contracts

    2024

  17. [24]

    O’Reilly Media. (2024). Pragma, import, and comments - Ethereum Smart Contract Development. O’Reilly Learning Platform. https://www.oreilly.com/library/view/ethereum- smart-contract/9781788473040/1fe7a466-21a5-4726-8618- 08de49730254.xhtml

    2024

  18. [25]

    Solidity Documentation. (2024). Introduction to Smart Contracts. https://docs.soliditylang.org/en/v0.8.0/introduction-to-smart- contracts.html

    2024

  19. [26]

    HuggingFace Datasets

    Slither Audited Smart Contracts Dataset. HuggingFace Datasets. https://huggingface.co/datasets/mwritescode/slither-audited-smart- contracts

  20. [27]

    Lashkari, B., & Musilek, P. (2023). Evaluation of Smart Contract Vul- nerability Analysis Tools: A Domain-Specific Perspective. Information, 14(10), 533. https://doi.org/10.3390/info14100533

    2023 doi

  21. [28]

    Heuristic approach for risk assessment modeling: EPCCM application (Engineer Procure Construct Contract Management)

    Ali F. Bakr and Khaled El Hagla, et al. "Heuristic approach for risk assessment modeling: EPCCM application (Engineer Procure Construct Contract Management)." https://doi.org/10.1016/j.aej.2012.09.001

    2012 doi

  22. [29]

    and Sheng, V

    Kiani, R. and Sheng, V. S. (2024). Ethereum Smart Con- tract Vulnerability Detection and Machine Learning-Driven Solu- tions: A Systematic Literature Review. Electronics, 13(12), 2295. https://doi.org/10.3390/electronics13122295

    2024 doi

  23. [30]

    Jiachi Chen, Xin Xia, David Lo, and John Grundy. 2021. Why Do Smart Contracts Self-Destruct? Investigating the Selfdestruct Function onEthereum.ACMTrans.Softw.Eng.Methodol.31,2,Article30(April 2022), 37 pages. https://doi.org/10.1145/3488245

    2021 doi

  24. [31]

    Halborn Security. (2023). Delegatecall Vulnerabil- ities In Solidity. Halborn Blog. Retrieved from https://www.halborn.com/blog/post/delegatecall-vulnerabilities-in- solidity

    2023

  25. [32]

    OpenZeppelin. (2023). Admin Accounts and Multisigs. OpenZeppelin Blog. Retrieved from https://blog.openzeppelin.com/admin-accounts- and-multisigs

    2023

  26. [33]

    Safe Global. (2024). Ethereum Smart Accounts. Retrieved from https://safe.global/

    2024

  27. [34]

    Nicola Atzei, Massimo Bartoletti, and Tiziana Cimoli. 2017. A Survey of Attacks on Ethereum Smart Contracts SoK. In Proceedings of the 6th International Conference on Principles of Security and Trust - Volume 10204

    2017

  28. [35]

    OpenZeppelin. (2024). The Parity Wallet Hack Explained. OpenZep- pelin Blog. Retrieved from https://blog.openzeppelin.com/on-the-parity- wallet-multisig-hack-405a8c12e8f7

    2024

  29. [36]

    OpenSea Cre- ator Documentation

    Smart Contract Security Best Practices for NFT Creators. OpenSea Cre- ator Documentation. Retrieved from https://docs.opensea.io/docs/smart- contract-security

  30. [37]

    Petar Tsankov, Andrei Dan, Dana Drachsler-Cohen, Arthur Gervais, Florian Bünzli, and Martin Vechev. 2018. Securify: Practical Security Analysis of Smart Contracts. In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security (CCS ’18). Association f...

    2018

  31. [38]

    Retrieved from https://www.certik.com/resources/blog/1Kl3XHKDdzIZvW0dyJLuSu- how-to-secure-nfts-part-two-nft-smart-contract-security

    How to Secure NFTs: Part Two - NFT Smart Contract Security. Retrieved from https://www.certik.com/resources/blog/1Kl3XHKDdzIZvW0dyJLuSu- how-to-secure-nfts-part-two-nft-smart-contract-security

  32. [39]

    A Comprehensive Survey of Smart Contracts Vulnerability Detection Tools: Techniques and Method- ologies

    Niosha Hejazi and Arash Habibi Lashkari. "A Comprehensive Survey of Smart Contracts Vulnerability Detection Tools: Techniques and Method- ologies." https://doi.org/10.1016/j.jnca.2025.104142

    2025

  33. [40]

    Sci Rep 14, 23433 (2024)

    Ortu,M.,Ibba,G.,Destefanis,G.etal.Taxonomicinsightsintoethereum smart contracts by linking application categories to security vulnera- bilities. Sci Rep 14, 23433 (2024). https://doi.org/10.1038/s41598-024- 73454-0

    2024 doi

  34. [41]

    Gustavo Grieco, Will Song, Artur Cygan, Josselin Feist, and Alex Groce. 2020. Echidna: effective, usable, and fast fuzzing for smart contracts. In Proceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis (ISSTA 2020). Asso- ciation for Compu...

    2020

  35. [43]

    Cyberscope. (2024). NFT Smart Contract Audit. Retrieved from https://www.cyberscope.io/nft-smart-contract-audit

    2024

  36. [44]

    Automated Repair of Smart Contract Vulnera- bilities: A Systematic Literature Review

    Kiani, R.; Sheng, V.S. Automated Repair of Smart Contract Vulnera- bilities: A Systematic Literature Review. Electronics 2024, 13, 3942. https://doi.org/10.3390/electronics13193942

    2024 doi

  37. [45]

    Trail of Bits. (2023). Fuzzing on-chain contracts with Echidna. Trail of Bits Blog. Retrieved from https://blog.trailofbits.com/2023/07/21/fuzzing-on-chain-contracts- with-echidna/

    2023

  38. [46]

    Asem Ghaleb and Karthik Pattabiraman. 2020. How effective are smart contract analysis tools? evaluating smart contract static analysis tools using bug injection. In Proceedings of the 29th ACM SIGSOFT Inter- national Symposium on Software Testing and Analysis (ISSTA 2020). Ass...

    2020

  39. [47]

    Loi Luu, Duc-Hiep Chu, Hrishi Olickel, Prateek Saxena, and Aquinas Hobor. 2016. Making Smart Contracts Smarter. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS ’16). Association for Computing Machinery, New York, NY, USA, 254–269. ...

    2016

  40. [48]

    Kaspersky. (2023). What Are NFT Rug Pulls? How To Protect Yourself From NFT Fraud? Retrieved from https://www.kaspersky.com/resource- center/preemptive-safety/nft-rug-pulls

    2023

  41. [49]

    Smart Contract Security: A Software Lifecycle Perspective,

    Y. Huang, Y. Bian, R. Li, J. L. Zhao and P. Shi, "Smart Contract Security: A Software Lifecycle Perspective," in IEEE Access, vol. 7, pp. 150184-150202, 2019, doi: 10.1109/ACCESS.2019.2946988

    2019

  42. [50]

    Trusting a Smart Contract Means Trusting its Owners: Understanding Centralization Risk

    Lamby, Metin and Zieglmeier, et al. "Trusting a Smart Contract Means Trusting its Owners: Understanding Centralization Risk." https://arxiv.org/abs/2312.06510v1

    arXiv

  43. [51]

    Christof Ferreira Torres, Julian Schütte, and Radu State. 2018. Osiris: Hunting for Integer Bugs in Ethereum Smart Contracts. In Proceedings ofthe34thAnnualComputerSecurityApplicationsConference(ACSAC ’18). Association for Computing Machinery, New York, NY, USA, 664–676. https...

    2018

  44. [52]

    Consensys Diligence. (2024). Smart Contract Audits. Retrieved from https://diligence.consensys.io/

    2024

  45. [53]

    Sidechain technologies in blockchain networks: An examination and state-of-the-art review

    Amritraj Singh and Kelly Click, et al. "Sidechain technologies in blockchain networks: An examination and state-of-the-art review" https://doi.org/10.1016/j.jnca.2019.102471

    2019

  46. [54]

    Red Teaming the Mind of the Machine: A Systematic Evalua- tion of Prompt Injection and Jailbreak Vulnerabilities in LLMs

    "Red Teaming the Mind of the Machine: A Systematic Evalua- tion of Prompt Injection and Jailbreak Vulnerabilities in LLMs" arXiv:2505.04806. https://arxiv.org/abs/2505.04806

    arXiv

  47. [55]

    and Zhao, X

    Fei, J., Chen, X. and Zhao, X. (2023). MSmart: Smart Contract Vulnerability Analysis and Improved Strategies Based on Smartcheck. Applied Sciences, 13(3), 1733. https://doi.org/10.3390/app13031733

    2023 doi

  48. [56]

    Securing Genomic Data Against Inference Attacks in Federated Learn- ing Environments

    "Securing Genomic Data Against Inference Attacks in Federated Learn- ing Environments" arXiv:2505.07188. https://arxiv.org/abs/2505.07188

    arXiv

Pith tools

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