Pith. sign in

REVIEW 2 major objections 1 minor 38 references

Decoupling Reentrancy Protection from Smart Contract Implementation Logic

T0 review · 2 major / 1 minor · reviewed 2026-06-29 · grok-4.3

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

Pith's one-line read Sentinel moves reentrancy protection into a proxy layer that intercepts every call to the implementation contract.

desk verdict Sentinel moves reentrancy protection into the proxy layer so contracts stay unchanged, but the 100% coverage claim rests on an unevaluated assumption that the proxy catches every call path. read the letter →

arxiv 2605.25207 v1 pith:3ADKVS3T submitted 2026-05-24 cs.CR cs.ET

Shashank Joshi , Wojciech Golab This is my paper · ORCID
classification cs.CRcs.ET
keywords reentrancyattackssmartcontractsproxylayerethereumsecuritydappprotectionblockchainvulnerabilitiesguardstaticcallhandling
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

The paper introduces Sentinel as a proxy-based system that adds reentrancy protection without modifying the underlying smart contract code. It intercepts all calls at the proxy level and applies either a gas-optimized internal guard or an external lock registry, while also handling static calls to block read-only reentrancy. Evaluation on 70 vulnerable contracts shows complete coverage of four major attack categories, exceeding prior tools by more than 40 percent. A sympathetic reader would care because this approach decouples security logic from business logic, potentially allowing existing contracts to gain protection through deployment changes alone.

What carries the argument

The proxy layer that intercepts every call to the underlying implementation contract and applies dual-mode reentrancy guards (internal gas-optimized or external lock registry) while handling static calls.

What would settle it

A working reentrancy exploit on any of the 70 evaluated contracts or on a new contract that successfully bypasses the Sentinel proxy while the implementation remains unchanged.

Watch

Extended reading notes

Core claim

By integrating reentrancy logic directly into the proxy layer that sits in front of the implementation contract, Sentinel provides type-agnostic mitigation that intercepts all relevant calls, including cross-contract and static calls, and uses a dual-mode system of internal guard or external lock registry to prevent reentrancy across attack variations.

Load-bearing premise

The proxy layer can intercept every relevant call, including cross-contract and static calls, without creating new attack surfaces or breaking legitimate contract behavior, and the 70-contract dataset with four categories represents real-world threats.

Editorial extensions

If this is right

  • Achieves 100 percent security coverage across the four major reentrancy attack categories on the 70-contract dataset.
  • Outperforms existing solutions by more than 40 percent in coverage.
  • Enables safe execution of view functions by correctly handling static calls and blocking read-only reentrancy.
  • Offers developers a choice between a low-gas internal mode and a higher-security external registry for cross-contract cases.

Reading between the lines

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

  • Developers could deploy Sentinel in front of existing contracts without rewriting their implementation logic.
  • The same proxy-interception pattern might extend to other call-based vulnerabilities if similar guards are added.
  • Adoption would shift security responsibility partly to infrastructure providers who manage the proxy layer.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

2 major / 1 minor

Summary. The paper proposes Sentinel, a proxy-based system that decouples reentrancy protection from smart contract logic by intercepting calls at the proxy layer. It includes a dual-mode guard (gas-optimized internal and high-security external lock) and handles static calls to prevent Read-Only Reentrancy. Evaluation on 70 vulnerable contracts claims 100% coverage across four reentrancy attack categories and over 40% improvement over existing solutions.

Significance. If the proxy interception is complete and the evaluation holds, this provides a deployable, type-agnostic solution to a major security issue causing substantial financial losses in DApps. The decoupling approach could allow easier adoption without modifying contract code.

major comments (2)
  1. [Evaluation] Evaluation section: The claim of 100% security coverage across four major reentrancy attack categories on a dataset of 70 contracts lacks supporting details on methodology, the definition of the four categories, baseline comparisons, and error analysis. This makes it impossible to assess whether the 40% outperformance claim is supported.
  2. [Proxy layer] Proxy layer description: The central assumption that the proxy intercepts every relevant call (including cross-contract, static calls, and without bypass via direct implementation calls, assembly CALLs, or delegatecall patterns) is load-bearing for the 100% coverage claim but is not shown to be complete against all EVM opcode sequences or multi-contract call graphs.
minor comments (1)
  1. Abstract states 'rigorous evaluation' without any specifics on the 70-contract dataset or attack categories; a summary table would improve clarity.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their constructive feedback, which identifies key areas for improving the clarity and rigor of our evaluation and system description. We address each major comment below and will revise the manuscript to incorporate additional details and analysis.

read point-by-point responses

  1. Referee: [Evaluation] Evaluation section: The claim of 100% security coverage across four major reentrancy attack categories on a dataset of 70 contracts lacks supporting details on methodology, the definition of the four categories, baseline comparisons, and error analysis. This makes it impossible to assess whether the 40% outperformance claim is supported.

    Authors: We agree that the current manuscript presents the evaluation results at a high level without sufficient supporting details. In the revised version, we will expand the Evaluation section to explicitly define the four reentrancy attack categories, describe the methodology for selecting and testing the 70 contracts (including data sources and testing harness), provide quantitative baseline comparisons with existing solutions to substantiate the over 40% improvement, and include an error analysis discussing any limitations or edge cases encountered. This will allow readers to fully evaluate the claims. revision: yes

  2. Referee: [Proxy layer] Proxy layer description: The central assumption that the proxy intercepts every relevant call (including cross-contract, static calls, and without bypass via direct implementation calls, assembly CALLs, or delegatecall patterns) is load-bearing for the 100% coverage claim but is not shown to be complete against all EVM opcode sequences or multi-contract call graphs.

    Authors: The design positions the Sentinel proxy as the sole public entry point, with the implementation contract not directly exposed, thereby intercepting external calls including static calls (via dedicated handling to prevent ROR) and cross-contract calls (via the external lock registry). We acknowledge that the manuscript does not exhaustively enumerate all possible EVM opcode sequences or complex multi-contract graphs. In the revision, we will add a new subsection in the Proxy Layer description that analyzes potential bypass vectors such as direct implementation calls (mitigated by standard proxy deployment where only the proxy address is publicized), low-level assembly CALLs, and delegatecall patterns, along with their handling under the dual-mode guard. We will also extend the discussion to multi-contract call graphs and clarify the assumptions in the threat model. revision: yes

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: system description and empirical evaluation contain no self-referential derivations or fitted predictions.

full rationale

The paper introduces a proxy-based Sentinel system for reentrancy protection and reports direct evaluation results (100% coverage on 70 contracts across 4 categories). No equations, parameters fitted to subsets then renamed as predictions, self-citations used as load-bearing uniqueness theorems, or ansatzes smuggled via prior work appear in the provided text. The central claims rest on the described implementation and test outcomes rather than reducing to inputs by construction; the interception assumption is an engineering claim subject to external verification, not a definitional loop.

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

Abstract-only review; no explicit free parameters, axioms, or invented entities are stated. The approach implicitly assumes standard EVM call semantics and proxy delegation mechanics from prior Ethereum literature.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Decoupling Reentrancy Protection from Smart Contract Implementation Logic." pith.science (2026). https://pith.science/paper/3ADKVS3T

@misc{pith2026260525207,
  author       = {Pith},
  title        = {Pith review of: Decoupling Reentrancy Protection from Smart Contract Implementation Logic},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3ADKVS3T}},
  note         = {Machine review of arXiv:2605.25207}
}
read the original abstract

Reentrancy attacks remain a persistent threat to decentralized applications (DApps), with malicious actors siphoning around 80M USD from the DApp ecosystem last year by exploiting EVM's inter-contract message-passing semantics. Existing research focuses primarily on detection, relying on known attack patterns, and fails to provide deployable solutions that eliminate the vulnerability. Traditional reentrancy guards are similarly limited, offering incomplete coverage across attack variations and lacking robustness against complex DApp interactions. In this paper, we introduce Sentinel, a novel proxy-based approach that mitigates reentrancy vulnerabilities in a type-agnostic way by integrating reentrancy logic directly into the proxy layer, intercepting all calls to the underlying implementation contract. Key features include a dual-mode operational system offering both a gas-optimized internal guard and a high-security external lock registry for cross-contract reentrancy prevention. The proxy also intelligently handles static calls, enabling safe view-function execution while protecting against Read-Only Reentrancy (ROR) attacks. Through rigorous evaluation on a dataset of 70 vulnerable smart contracts, Sentinel achieves 100% security coverage across four major reentrancy attack categories, outperforming existing solutions by over 40%

Figures

Figures reproduced from arXiv: 2605.25207 by the authors.

Figure 2
Figure 2. An Example for Cross Function Reentrancy Attack [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 1
Figure 1. An Example for Single Function Reentrancy Attack [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 3
Figure 3. An Example for Cross Contract Reentrancy Attack [PITH_FULL_IMAGE:figures/full_fig_p005_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: An Example for Read Only Reentrancy Attack [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
Figure 5
Figure 5. Figure 5: Architecture Diagram For Sentinel Optimized Mode [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Architecture Diagram For Sentinel HighSec Mode [PITH_FULL_IMAGE:figures/full_fig_p008_6.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

38 extracted references · 3 canonical work pages

  1. [1]

    Blockchain-enabled smart contracts: architecture, applications, and future trends,

    S. Wang, L. Ouyang, Y . Yuan, X. Ni, X. Han, and F.-Y . Wang, “Blockchain-enabled smart contracts: architecture, applications, and future trends,”IEEE Transactions on Systems, Man, and Cybernetics: Systems, vol. 49, no. 11, pp. 2266–2277, 2019

    2019

  2. [2]

    Blockchain: the state of the art and future trends,

    Y . Yuan, F.-Y . Wang,et al., “Blockchain: the state of the art and future trends,”Acta automatica sinica, vol. 42, no. 4, pp. 481–494, 2016

    2016

  3. [3]

    A new approach to prevent reentrant attack in solidity smart contracts,

    C. Dong, Y . Li, and L. Tan, “A new approach to prevent reentrant attack in solidity smart contracts,” inBlockchain Technology and Application: Second CCF China Blockchain Conference, CBCC 2019, Chengdu, China, October 11–13, 2019, Revised Selected Papers 2, pp. 83–103, Springer, 2020

    2019

  4. [4]

    A peer-to-peer electronic cash system,

    S. Nakamoto and A. Bitcoin, “A peer-to-peer electronic cash system,” Bitcoin.–URL: https://bitcoin. org/bitcoin. pdf, vol. 4, no. 2, p. 15, 2008

    2008

  5. [5]

    A next-generation smart contract and decentralized application platform,

    V . Buterinet al., “A next-generation smart contract and decentralized application platform,”white paper, vol. 3, no. 37, pp. 2–1, 2014

    2014

  6. [6]

    Security vulnerabilities in ethereum smart contracts,

    A. Mense and M. Flatscher, “Security vulnerabilities in ethereum smart contracts,” inProceedings of the 20th international conference on information integration and web-based applications & services, pp. 375– 380, 2018

    2018

  7. [7]

    Smart contracts based on blockchain for logistics management,

    N. ´Alvarez-D´ıaz, J. Herrera-Joancomart´ı, and P. Caballero-Gil, “Smart contracts based on blockchain for logistics management,” inProceedings of the 1st international conference on Internet of Things and machine learning, pp. 1–8, 2017

    2017

  8. [8]

    Smart contracts,

    M. Kolvart, M. Poola, and A. Rull, “Smart contracts,”The Future of Law and etechnologies, pp. 133–147, 2016

    2016

Show all 38 references
  1. [9]

    Smartsupply: Smart contract based validation for supply chain blockchain,

    S. Su, K. Wang, and H. S. Kim, “Smartsupply: Smart contract based validation for supply chain blockchain,” in2018 IEEE international conference on internet of things (iThings) and IEEE green computing and communications (GreenCom) and IEEE cyber, physical and social computing ...

    2018

  2. [10]

    Kevm: A complete formal semantics of the ethereum virtual machine,

    E. Hildenbrandt, M. Saxena, N. Rodrigues, X. Zhu, P. Daian, D. Guth, B. Moore, D. Park, Y . Zhang, A. Stefanescu,et al., “Kevm: A complete formal semantics of the ethereum virtual machine,” in2018 IEEE 31st Computer Security Foundations Symposium (CSF), pp. 204–217, IEEE, 2018

    2018

  3. [11]

    Zeus: analyzing safety of smart contracts.,

    S. Kalra, S. Goel, M. Dhawan, and S. Sharma, “Zeus: analyzing safety of smart contracts.,” inNdss, pp. 1–12, 2018

    2018

  4. [12]

    Finding the greedy, prodigal, and suicidal contracts at scale,

    I. Nikoli ´c, A. Kolluri, I. Sergey, P. Saxena, and A. Hobor, “Finding the greedy, prodigal, and suicidal contracts at scale,” inProceedings of the 34th annual computer security applications conference, pp. 653–663, 2018

    2018

  5. [13]

    Turn the rudder: A beacon of reentrancy detection for smart contracts on ethereum,

    Z. Zheng, N. Zhang, J. Su, Z. Zhong, M. Ye, and J. Chen, “Turn the rudder: A beacon of reentrancy detection for smart contracts on ethereum,”arXiv preprint arXiv:2303.13770, 2023

    2023

  6. [14]

    Towards verifying ethereum smart contract bytecode in isabelle/hol,

    S. Amani, M. B ´egel, M. Bortin, and M. Staples, “Towards verifying ethereum smart contract bytecode in isabelle/hol,” inProceedings of the 7th ACM SIGPLAN international conference on certified programs and proofs, pp. 66–77, 2018

    2018

  7. [15]

    Slither: a static analysis framework for smart contracts,

    J. Feist, G. Grieco, and A. Groce, “Slither: a static analysis framework for smart contracts,” in2019 IEEE/ACM 2nd International Workshop on Emerging Trends in Software Engineering for Blockchain (WETSEB), pp. 8–15, IEEE, 2019

    2019

  8. [16]

    Securify: Practical security analysis of smart contracts,

    P. Tsankov, A. Dan, D. Drachsler-Cohen, A. Gervais, F. Buenzli, and M. Vechev, “Securify: Practical security analysis of smart contracts,” inProceedings of the 2018 ACM SIGSAC conference on computer and communications security, pp. 67–82, 2018

    2018

  9. [17]

    Smartcheck: Static analysis of ethereum smart contracts,

    S. Tikhomirov, E. V oskresenskaya, I. Ivanitskiy, R. Takhaviev, E. Marchenko, and Y . Alexandrov, “Smartcheck: Static analysis of ethereum smart contracts,” inProceedings of the 1st international workshop on emerging trends in software engineering for blockchain, pp. 9–16, 2018

    2018

  10. [18]

    Openzeppelin reentrancyguard

    “Openzeppelin reentrancyguard.”

  11. [19]

    Blockchain technology: revolution from a centralized to distributed systems,

    A. S. Mane and B. S. Ainapure, “Blockchain technology: revolution from a centralized to distributed systems,” inData Intelligence and Cognitive Informatics: Proceedings of ICDICI 2021, pp. 577–591, Springer, 2022

    2021

  12. [20]

    Blockchain challenges and opportunities: A survey,

    Z. Zheng, S. Xie, H.-N. Dai, X. Chen, and H. Wang, “Blockchain challenges and opportunities: A survey,”International journal of web and grid services, vol. 14, no. 4, pp. 352–375, 2018

    2018

  13. [21]

    The idea of smart contracts,

    N. Szabo, “The idea of smart contracts,”Nick Szabo’s papers and concise tutorials, vol. 6, no. 1, p. 199, 1997

    1997

  14. [22]

    Sereum: Protecting existing smart contracts against re-entrancy attacks,

    M. Rodler, W. Li, G. O. Karame, and L. Davi, “Sereum: Protecting existing smart contracts against re-entrancy attacks,”arXiv preprint arXiv:1812.05934, 2018

    2018 arXiv

  15. [23]

    A mechanism to detect and prevent ethereum blockchain smart contract reentrancy attacks,

    A. Alkhalifah, A. Ng, P. A. Watters, and A. Kayes, “A mechanism to detect and prevent ethereum blockchain smart contract reentrancy attacks,”Frontiers in Computer Science, vol. 3, p. 598780, 2021

    2021

  16. [24]

    Ethereum (eth) blockchain explorer

    Etherscan.Io, “Ethereum (eth) blockchain explorer.”

  17. [25]

    How effective are smart contract analysis tools? evaluating smart contract static analysis tools using bug injection,

    A. Ghaleb and K. Pattabiraman, “How effective are smart contract analysis tools? evaluating smart contract static analysis tools using bug injection,” inProceedings of the 29th ACM SIGSOFT international symposium on software testing and analysis, pp. 415–427, 2020

    2020

  18. [26]

    Foundry - ethereum development framework

    “Foundry - ethereum development framework.”

  19. [27]

    Mythril

    ConsenSysDiligence, “Mythril.”

  20. [28]

    Making smart contracts smarter,

    L. Luu, D.-H. Chu, H. Olickel, P. Saxena, and A. Hobor, “Making smart contracts smarter,” inProceedings of the 2016 ACM SIGSAC conference on computer and communications security, pp. 254–269, 2016

    2016

  21. [29]

    Redefender: detecting reentrancy vulnerabili- ties in smart contracts automatically,

    B. Li, Z. Pan, and T. Hu, “Redefender: detecting reentrancy vulnerabili- ties in smart contracts automatically,”IEEE Transactions on Reliability, vol. 71, no. 2, pp. 984–999, 2022

    2022

  22. [30]

    Smartreco: Detecting read-only reentrancy via fine-grained cross-dapp analysis,

    J. Zhang, Z. Zheng, Y . Nan, M. Ye, K. Ning, Y . Zhang, and W. Zhang, “Smartreco: Detecting read-only reentrancy via fine-grained cross-dapp analysis,”arXiv preprint arXiv:2409.18468, 2024

    2024

  23. [31]

    Using coq to enforce the checks- effects-interactions pattern in deepsea smart contracts,

    D. Britten, V . Sj ¨oberg, and S. Reeves, “Using coq to enforce the checks- effects-interactions pattern in deepsea smart contracts,” inFMBC 2021, 2021

    2021

  24. [32]

    A new approach to prevent reentrant attack in solidity smart contracts,

    C. Dong, Y . Li, and L. Tan, “A new approach to prevent reentrant attack in solidity smart contracts,” inCCF China Blockchain Conference, pp. 83–103, Springer, 2019

    2019

  25. [33]

    Defi lender rari capital/fei loses $80m in hack,

    K. R. Kessler and Sam, “Defi lender rari capital/fei loses $80m in hack,” May 2023

    2023

  26. [34]

    Cream finance hacker stole $18.8m in a flash loan attack,

    T. Olajide, “Cream finance hacker stole $18.8m in a flash loan attack,” Aug 2021

    2021

  27. [35]

    Decentralized exchange orion protocol hacked for $3 million,

    V . Chawla, “Decentralized exchange orion protocol hacked for $3 million,” Feb 2023

    2023

  28. [36]

    Burgerswap explains $7.2 million flash loan attack in post- mortem,

    E. Genc ¸, “Burgerswap explains $7.2 million flash loan attack in post- mortem,” May 2021

    2021

  29. [37]

    Manticore

    Trailofbits, “Manticore.”

  30. [38]

    Reguard: finding reentrancy bugs in smart contracts,

    C. Liu, H. Liu, Z. Cao, Z. Chen, B. Chen, and B. Roscoe, “Reguard: finding reentrancy bugs in smart contracts,” inProceedings of the 40th international conference on software engineering: companion proceeed- ings, pp. 65–68, 2018

    2018

Pith tools

Reviewed June 29, 2026 · model on record in the stance chip above.