Pith. sign in

REVIEW 3 major objections 2 minor 49 references

The Dark Side of Upgrades: Uncovering Security Risks in Smart Contract Upgrades

T0 review · 3 major / 2 minor · reviewed 2026-08-06 · deepseek-v4-flash

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

Pith's one-line read Smart contract upgrades carry eight security risk types, four of them overlooked by the public and lacking mitigation measures, with 31,407 related issues detected in a preliminary scan.

desk verdict The abstract is a promising empirical study of smart contract upgrade risks, but the supplied full text is an unrelated fuzzing paper, so none of the headline numbers can be audited from what I have. read the letter →

arxiv 2508.02145 v1 pith:TIFH2GCV submitted 2025-08-04 cs.CR

Dingding Wang , Jianting He , Siwei Wu , Yajin Zhou , Lei Wu , Cong Wang This is my paper · ORCID
classification cs.CR
keywords smartcontractupgradesupgraderisksblockchainsecuritytaxonomyincidentschainspublicawarenessvulnerabilitydetection
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

Upgrading a smart contract lets developers fix bugs and add features, but it breaks the immutability that many users rely on. This paper argues that upgrade behaviors create security risks that are more varied and less understood than previous work suggests. The authors build what they describe as the first large-scale dataset of upgrade behavior, covering 83,085 upgraded contracts and 20,902 upgrade chains, and from 37 real-world incidents they derive a taxonomy of eight upgrade-risk types. Their survey of public disclosures and mitigation options finds that four of those eight types are overlooked: they appear nowhere in public guidance and have no mitigation measures. A preliminary scan for just those four types identifies 31,407 issues, which the paper takes as evidence that the overlooked risks are common in practice.

What carries the argument

The argument is carried by a dataset of 83,085 upgraded contracts and 20,902 upgrade chains, the first large-scale collection of upgrade behaviors according to the paper, and by an eight-type taxonomy of upgrade risks built from 37 security incidents. The dataset supplies the scale that lets the authors find upgrade behaviors earlier work missed, while the taxonomy converts those behaviors into named risk categories that drive the public-awareness survey. The 31,407 figure comes from a preliminary automated detection scan targeting the four overlooked risk types, so that scan is the empirical step that connects the taxonomy to the claim of widespread risk.

What would settle it

An independent reproduction of the detection scan on the same or a comparable set of upgraded contracts would refute the prevalence claim if it found far fewer than 31,407 valid issues; a systematic review of public documentation, audit reports, and existing security tools that shows the four supposedly overlooked risk types already have published mitigations would refute the 'overlooked' claim.

Watch

Extended reading notes

Core claim

The central claim is that a smart contract upgrade is not a single event but a chain of behaviors, and that these behaviors carry at least eight distinguishable security risk types. The paper develops an eight-type taxonomy from 37 real-world incidents and asserts that it is the first complete view of upgrade-related insecurities. It then finds, through a survey of public awareness, that four of the eight types are absent from public discussion and lack mitigation. The paper ties the taxonomy to prevalence by running a preliminary detection of those four types across its dataset and reporting 31,407 related issues. In the authors' telling, this shows that the 'dark side' of upgrades is not hypothetical: overlooked upgrade risks are present at scale on deployed contracts.

Load-bearing premise

The central claim rests on the dataset correctly identifying which contracts were upgraded and how their upgrade chains connect, and on the eight-type taxonomy being complete enough that the four 'overlooked' types are genuinely missing from public knowledge rather than missing from the authors' search.

Editorial extensions

If this is right

  • Security audits of smart contracts would need to treat upgrade mechanics as an independent risk category, checking not just the current code but the whole upgrade history and chain.
  • If the taxonomy is adopted, platforms and regulators would have a shared vocabulary for requiring disclosure of upgrade behavior, since current public channels miss four risk types entirely.
  • Developers of upgrade frameworks would need to add built-in safeguards for the four unmitigated risk types, which today have no mitigation measure.
  • The 31,407 detected issues imply that remediation efforts should extend to already-deployed contracts, not only newly written ones.
  • The dataset of upgrade chains could serve as a baseline for future tools that scan for upgrade-chain-level vulnerabilities instead of single-contract snapshots.

Reading between the lines

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

  • Because the abstract reports a preliminary scan without validation details, the 31,407 count is best read as an upper bound; a random-sample audit of flagged contracts would test how many are genuine vulnerabilities rather than false positives.
  • If the four overlooked risk types truly lack mitigations, existing smart contract security standards were designed around single immutable contracts; updating those standards might close the gap faster than patching individual contracts.
  • The upgrade-chain dataset could support other studies, such as measuring how quickly contracts patch known bugs after an incident, or correlating upgrade frequency with exploit likelihood.
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

3 major / 2 minor

Summary. The abstract announces a large-scale empirical study of security risks in smart contract upgrades, reporting a dataset of 83,085 upgraded contracts and 20,902 upgrade chains, a taxonomy of eight risk types derived from 37 real-world incidents, a survey of public awareness and mitigations, and a preliminary detection that identifies 31,407 issues. The submitted full text, however, is an unrelated paper titled 'BiFuzz: A Two-Stage Fuzzing Tool for Open-World Video Games' by Kato et al., containing no methodology, data, or results about smart contracts or upgrades. The manuscript therefore does not contain the study its title and abstract describe.

Significance. If the abstract's claims were fully substantiated by a matching manuscript, the work would be significant for smart contract security: a large upgrade-behavior dataset, an incident-derived taxonomy, and a public-awareness gap analysis could inform tooling and policy. However, in the submitted form the full text is a different paper, and the abstract alone provides no methodological detail, validation, or error bounds for any of the reported quantities. The contribution cannot be evaluated or credited on the available evidence.

major comments (3)
  1. [Full text, Sections I–V] The manuscript body is not the paper announced by the title and abstract. The full text is 'BiFuzz: A Two-Stage Fuzzing Tool for Open-World Video Games', with no mention of smart contracts, upgrades, security incidents, or the reported dataset. Consequently, the abstract's central empirical claims (83,085 upgraded contracts, 20,902 upgrade chains, 37 incidents, eight risk types, 31,407 issues) are entirely unsubstantiated in the submitted text. This is a load-bearing defect that cannot be repaired by local revision of the present document.
  2. [Abstract, 'we detect these upgrade risks'] Even taking the abstract on its own, the 31,407-issue count is not interpretable without a definition of an 'issue', the detection rule used, whether the count is unique contracts or issue instances, and any precision or false-positive analysis. The abstract states only that the detection is preliminary; without these details, the headline number cannot be audited or compared with other studies.
  3. [Abstract, 'four types of security risks are overlooked'] The claim that four of the eight risk types are 'overlooked by the public and lack mitigation measures' depends on the completeness of both the incident-derived taxonomy and the public-awareness survey. The abstract gives no inclusion criteria for the 37 incidents, no description of how the taxonomy was validated as complete, and no methodology for the survey. The claim could be an artifact of an incomplete taxonomy or an unrepresentative survey, so it is not supportable from the information provided.
minor comments (2)
  1. [Title and Abstract] The title and abstract describe a smart contract upgrade security study, but the full text is an unrelated video-game fuzzing paper; the submission must be corrected to contain the work described.
  2. [Abstract, 'first large-scale dataset' and 'first complete view'] The novelty claims would benefit from explicit comparison with prior works on upgrade-behavior datasets and upgrade-risk taxonomies; the abstract currently asserts novelty without positioning against existing literature.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity found; the abstract's empirical pipeline (dataset, taxonomy, survey, detection) is self-contained and does not define its conclusions into its inputs.

full rationale

The abstract of arXiv:2508.02145 reports an empirical study: it constructs a dataset of 83,085 upgraded contracts and 20,902 upgrade chains, builds an eight-type taxonomy from 37 real-world incidents, surveys public awareness and mitigations, and then applies a detector that finds 31,407 issues. None of these steps reduces to its own inputs by construction. The taxonomy is derived from incidents and then used in detection, which is a normal application of a classification scheme rather than a circular derivation. The 'overlooked by the public' claim depends on the survey's completeness and the '31,407 issues' figure depends on the detector's precision and definition of an issue; these are unverified empirical concerns, but unverified empirical claims are not circularity. There is no cited uniqueness theorem, no fitted parameter renamed as a prediction, no equation equating an output to an input, and no self-citation chain visible in the abstract. The supplied full text is a different paper (BiFuzz, a video-game fuzzing tool), so the analysis must rest on the abstract alone; that mismatch is an auditability or provenance problem, not a circular-reasoning defect. Under the hard rules, without a quotable reduction of a claimed result to its own inputs, the correct finding is no significant circularity with score 0.

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

The central claims rest on two unverified domain assumptions: that on-chain data can be parsed into upgrade chains with acceptable accuracy, and that a taxonomy from 37 incidents covers the risk space. No free parameters or invented entities are specified in the abstract.

assumptions (2)
  • domain assumption On-chain data can be reliably parsed to identify upgrade behavior (e.g., proxy contracts and upgrade transactions).
    The abstract does not describe validation of upgrade detection; correctness of all downstream claims depends on this.
  • domain assumption A taxonomy built from 37 incidents covers the space of upgrade-related insecurities.
    The claim that four risk types are overlooked assumes the taxonomy is complete and representative.

how reviews work

0 comments
Cite this review

Pith. "Pith review of The Dark Side of Upgrades: Uncovering Security Risks in Smart Contract Upgrades." pith.science (2026). https://pith.science/paper/TIFH2GCV

@misc{pith2026250802145,
  author       = {Pith},
  title        = {Pith review of: The Dark Side of Upgrades: Uncovering Security Risks in Smart Contract Upgrades},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/TIFH2GCV}},
  note         = {Machine review of arXiv:2508.02145}
}
read the original abstract

Smart contract upgrades are increasingly common due to their flexibility in modifying deployed contracts, such as fixing bugs or adding new functionalities. Meanwhile, upgrades compromise the immutability of contracts, introducing significant security concerns. While existing research has explored the security impacts of contract upgrades, these studies are limited in collection of upgrade behaviors and identification of insecurities. To address these limitations, we conduct a comprehensive study on the insecurities of upgrade behaviors. First, we build a dataset containing 83,085 upgraded contracts and 20,902 upgrade chains. To our knowledge, this is the first large-scale dataset about upgrade behaviors, revealing their diversity and exposing gaps in public disclosure. Next, we develop a taxonomy of insecurities based on 37 real-world security incidents, categorizing eight types of upgrade risks and providing the first complete view of upgrade-related insecurities. Finally, we survey public awareness of these risks and existing mitigations. Our findings show that four types of security risks are overlooked by the public and lack mitigation measures. We detect these upgrade risks through a preliminary study, identifying 31,407 related issues - a finding that raises significant concerns.

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 47 canonical work pages

  1. [1]

    o wis and R. B \

    M. Fr \"o wis and R. B \"o hme, ``Not all code are create2 equal,'' in International Conference on Financial Cryptography and Data Security. 1em plus 0.5em minus 0.4em Springer, 2022, pp. 516--538

    work page 2022

  2. [2]

    J. Chen, ``Finding ethereum smart contracts security issues by comparing history versions,'' in Proceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering, 2020, pp. 1382--1384

    work page 2020

  3. [3]

    Huang, X

    Y. Huang, X. Wu, Q. Wang, Z. Qian, X. Chen, M. Tang, and Z. Zheng, ``The sword of damocles: Upgradeable smart contract in ethereum,'' in Proceedings of the 32nd IEEE/ACM International Conference on Program Comprehension, 2024, pp. 333--345

    work page 2024

  4. [4]

    X. Li, J. Yang, J. Chen, Y. Tang, and X. Gao, ``Characterizing ethereum upgradable smart contracts and their security implications,'' in Proceedings of the ACM on Web Conference 2024, 2024, pp. 1847--1858

    work page 2024

  5. [5]

    Salehi, J

    M. Salehi, J. Clark, and M. Mannan, ``Not so immutable: Upgradeability of smart contracts on ethereum,'' in International Conference on Financial Cryptography and Data Security. 1em plus 0.5em minus 0.4em Springer, 2022, pp. 539--554

    work page 2022

  6. [6]

    Chaliasos, M

    S. Chaliasos, M. A. Charalambous, L. Zhou, R. Galanopoulou, A. Gervais, D. Mitropoulos, and B. Livshits, ``Smart contract and defi security tools: Do they meet the needs of practitioners?'' in Proceedings of the 46th IEEE/ACM International Conference on Software Engineering, 2024, pp. 1--13

    work page 2024

  7. [7]

    W. E. Bodell III, S. Meisami, and Y. Duan, ``Proxy hunting: understanding and characterizing proxy-based upgradeable smart contracts in blockchains,'' in 32nd USENIX Security Symposium (USENIX Security 23), 2023, pp. 1829--1846

    work page 2023

  8. [8]

    ``Proxy dataset,'' 2025, https://github.com/USCHunt-Anon/USCHunt/tree/master/study/data

    work page 2025

Show all 49 references
  1. [9]

    Wood et al., ``Ethereum: A secure decentralised generalised transaction ledger,'' Ethereum project yellow paper, vol

    G. Wood et al., ``Ethereum: A secure decentralised generalised transaction ledger,'' Ethereum project yellow paper, vol. 151, no. 2014, pp. 1--32, 2014

    2014

  2. [10]

    ``Bscscan: Bnb smart chain explorer,'' 2024, https://bscscan.com/

    2024

  3. [11]

    ``Erc-20: Token standard,'' 2015, https://eips.ethereum.org/EIPS/eip-20

    2015

  4. [12]

    ``Erc-721: Non-fungible token standard,'' 2018, https://eips.ethereum.org/EIPS/eip-721

    2018

  5. [13]

    ``Etherscan: The ethereum blockchain explorer,'' 2024, https://etherscan.io/

    2024

  6. [14]

    ``Upgradehub,'' 2024, https://upgradehub.xyz/

    2024

  7. [15]

    ``Blocksec security incidents,'' 2024, https://app.blocksec.com/explorer/security-incidents

    2024

  8. [16]

    ``Defillama hacks,'' 2024, https://defillama.com/hacks

    2024

  9. [17]

    ``De.fi rekt-database,'' 2024, https://de.fi/rekt-database

    2024

  10. [18]

    ``Slowmist hacked,'' 2024, https://hacked.slowmist.io/

    2024

  11. [19]

    ``Beware of the proxy: learn how to exploit function clashing,'' 2019, https://forum.openzeppelin.com/t/beware-of-the-proxy-learn-how-to-exploit-function-clashing/1070

    2019

  12. [20]

    Ruaro, F

    N. Ruaro, F. Gritti, R. McLaughlin, I. Grishchenko, C. Kruegel, and G. Vigna, `` en Not your Type ! Detecting Storage Collision Vulnerabilities in Ethereum Smart Contracts ,'' in en Proceedings 2024 Network and Distributed System Security Symposium . 1em plus 0.5em minus 0.4em...

    2024

  13. [21]

    ``Erc-1967: Proxy storage slots,'' 2019, https://eips.ethereum.org/EIPS/eip-1967

    1967

  14. [22]

    ``Erc-7201: Namespaced storage layout,'' 2023, https://eips.ethereum.org/EIPS/eip-7201

    2023

  15. [23]

    ``Storage gaps,'' 2025, https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable#storage-gaps

    2025

  16. [24]

    ``Openzeppelin upgradesn,'' 2025, https://docs.openzeppelin.com/upgrades

    2025

  17. [25]

    F. Ma, M. Ren, L. Ouyang, Y. Chen, J. Zhu, T. Chen, Y. Zheng, X. Dai, Y. Jiang, and J. Sun, ``Pied-piper: Revealing the backdoor threats in ethereum erc token contracts,'' ACM Transactions on Software Engineering and Methodology, vol. 32, no. 3, pp. 1--24, 2023

    2023

  18. [26]

    Antonino, J

    P. Antonino, J. Ferreira, A. Sampaio, and A. Roscoe, ``Specification is law: Safe creation and upgrade of ethereum smart contracts,'' in International Conference on Software Engineering and Formal Methods. 1em plus 0.5em minus 0.4em Springer, 2022, pp. 227--243

    2022

  19. [27]

    ``Mythril,'' 2022, https://github.com/ConsenSys/mythril

    2022

  20. [28]

    Luu, D.-H

    L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, ``Making smart contracts smarter,'' in Proceedings of the 2016 ACM SIGSAC conference on computer and communications security, 2016, pp. 254--269

    2016

  21. [29]

    Mossberg, F

    M. Mossberg, F. Manzano, E. Hennenfent, A. Groce, G. Grieco, J. Feist, T. Brunson, and A. Dinaburg, ``Manticore: A user-friendly symbolic execution framework for binaries and smart contracts,'' in 2019 34th IEEE/ACM International Conference on Automated Software Engineering (A...

    2019

  22. [30]

    ``Rattle,'' 2022, https://github.com/crytic/rattle

    2022

  23. [31]

    Brent, A

    L. Brent, A. Jurisevic, M. Kong, E. Liu, F. Gauthier, V. Gramoli, R. Holz, and B. Scholz, ``Vandal: A scalable security analysis framework for smart contracts,'' arXiv preprint arXiv:1809.03981, 2018

    2018 arXiv

  24. [32]

    Contro, M

    F. Contro, M. Crosara, M. Ceccato, and M. Dalla Preda, ``Ethersolve: Computing an accurate control-flow graph from ethereum bytecode,'' in 2021 IEEE/ACM 29th International Conference on Program Comprehension (ICPC). 1em plus 0.5em minus 0.4em IEEE, 2021, pp. 127--137

    2021

  25. [33]

    Grech, L

    N. Grech, L. Brent, B. Scholz, and Y. Smaragdakis, ``Gigahorse: thorough, declarative decompilation of smart contracts,'' in 2019 IEEE/ACM 41st International Conference on Software Engineering (ICSE). 1em plus 0.5em minus 0.4em IEEE, 2019, pp. 1176--1186

    2019

  26. [34]

    Grech, S

    N. Grech, S. Lagouvardos, I. Tsatiris, and Y. Smaragdakis, ``Elipmoc: Advanced decompilation of ethereum smart contracts,'' Proceedings of the ACM on Programming Languages, vol. 6, no. OOPSLA1, pp. 1--27, 2022

    2022

  27. [35]

    Y. Zhou, D. Kumar, S. Bakshi, J. Mason, A. Miller, and M. Bailey, ``Erays: reverse engineering ethereum's opaque smart contracts,'' in 27th USENIX security symposium (USENIX Security 18), 2018, pp. 1371--1385

    2018

  28. [36]

    P. Bose, D. Das, Y. Chen, Y. Feng, C. Kruegel, and G. Vigna, ``Sailfish: Vetting smart contract state-inconsistency bugs in seconds,'' in 2022 IEEE Symposium on Security and Privacy (SP). 1em plus 0.5em minus 0.4em IEEE, 2022, pp. 161--178

    2022

  29. [37]

    C. F. Torres, J. Sch \"u tte, and R. State, ``Osiris: Hunting for integer bugs in ethereum smart contracts,'' in Proceedings of the 34th annual computer security applications conference, 2018, pp. 664--676

    2018

  30. [38]

    Grech, M

    N. Grech, M. Kong, A. Jurisevic, L. Brent, B. Scholz, and Y. Smaragdakis, ``Madmax: Surviving out-of-gas conditions in ethereum smart contracts,'' Proceedings of the ACM on Programming Languages, vol. 2, no. OOPSLA, pp. 1--27, 2018

    2018

  31. [39]

    P. Qian, J. He, L. Lu, S. Wu, Z. Lu, L. Wu, Y. Zhou, and Q. He, ``Demystifying random number in ethereum smart contract: taxonomy, vulnerability identification, and attack detection,'' IEEE Transactions on Software Engineering, vol. 49, no. 7, pp. 3793--3810, 2023

    2023

  32. [40]

    Z. Wang, J. Chen, Y. Wang, Y. Zhang, W. Zhang, and Z. Zheng, ``Efficiently detecting reentrancy vulnerabilities in complex smart contracts,'' arXiv preprint arXiv:2403.11254, 2024

    2024 arXiv

  33. [41]

    Z. Liao, Z. Zheng, X. Chen, and Y. Nan, ``Smartdagger: a bytecode-based static analysis approach for detecting cross-contract vulnerability,'' in Proceedings of the 31st ACM SIGSOFT International Symposium on Software Testing and Analysis, 2022, pp. 752--764

    2022

  34. [42]

    M. Ren, Z. Yin, F. Ma, Z. Xu, Y. Jiang, C. Sun, H. Li, and Y. Cai, ``Empirical evaluation of smart contract testing: What is the best choice?'' in Proceedings of the 30th ACM SIGSOFT international symposium on software testing and analysis, 2021, pp. 566--579

    2021

  35. [43]

    K. Li, Y. Xue, S. Chen, H. Liu, K. Sun, M. Hu, H. Wang, Y. Liu, and Y. Chen, ``Static application security testing (sast) tools for smart contracts: How far are we?'' Proceedings of the ACM on Software Engineering, vol. 1, no. FSE, pp. 1447--1470, 2024

    2024

  36. [44]

    Sendner, L

    C. Sendner, L. Petzi, J. Stang, and A. Dmitrienko, ``Large-scale study of vulnerability scanners for ethereum smart contracts,'' in 2024 IEEE Symposium on Security and Privacy (SP). 1em plus 0.5em minus 0.4em IEEE Computer Society, 2024, pp. 220--220

    2024

  37. [45]

    L. Su, X. Shen, X. Du, X. Liao, X. Wang, L. Xing, and B. Liu, ``Evil under the sun: Understanding and discovering attacks on ethereum decentralized applications,'' in 30th USENIX Security Symposium (USENIX Security 21), 2021, pp. 1307--1324

    2021

  38. [46]

    S. Zhou, M. M \"o ser, Z. Yang, B. Adida, T. Holz, J. Xiang, S. Goldfeder, Y. Cao, M. Plattner, X. Qin et al., ``An ever-evolving game: Evaluation of real-world attacks and defenses in ethereum ecosystem,'' in 29th USENIX Security Symposium (USENIX Security 20), 2020, pp. 2793--2810

    2020

  39. [47]

    Zhang, B

    Z. Zhang, B. Zhang, W. Xu, and Z. Lin, ``Demystifying exploitable bugs in smart contracts,'' in 2023 IEEE/ACM 45th International Conference on Software Engineering (ICSE). 1em plus 0.5em minus 0.4em IEEE, 2023, pp. 615--627

    2023

  40. [48]

    L. Zhou, X. Xiong, J. Ernstberger, S. Chaliasos, Z. Wang, Y. Wang, K. Qin, R. Wattenhofer, D. Song, and A. Gervais, ``Sok: Decentralized finance (defi) attacks,'' in 2023 IEEE Symposium on Security and Privacy (SP). 1em plus 0.5em minus 0.4em IEEE, 2023, pp. 2444--2461

    2023

  41. [49]

    ͺާh Δ|MWWR^HH7U -L

    11em plus .33em minus .07em 4000 4000 100 4000 4000 500 `\.=1000 = #1 \@IEEEnotcompsoconly \@IEEEcompsoconly #1 * [1] 0pt [0pt][0pt] #1 * [1] 0pt [0pt][0pt] #1 * \| ** #1 \@IEEEauthorblockNstyle \@IEEEcompsocnotconfonly \@IEEEauthorblockAstyle \@IEEEcompsocnotconfonly \@IEEEco...

Pith tools

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