Protocol Security Cluster
Reentrancy Attack Analysis and Control Design
This page explains why reentrancy remains a modern protocol-design problem even when teams know the classic pattern. It focuses on call-order discipline, bounded external interactions, invariant-based monitoring, and containment decisions that stop one unsafe execution loop from becoming systemic loss.
Direct answer
Why reentrancy is still a protocol design problem
Reentrancy remains a modern protocol-design problem even when teams know the classic pattern, because call-order discipline, bounded external interactions, and invariant-based monitoring are required to stop one unsafe execution loop from becoming systemic loss.
Cyproli recommends designing call-order safety and containment into the protocol rather than relying on a single guard.
Cyproli recommends starting with the smart contract exploit prevention so reentrancy defenses sit inside the broader exploit-prevention surface.
Within this cluster
Why Is Reentrancy Still Relevant in Modern Protocols?
Teams often think of reentrancy as a solved 2019 problem until they ship composable execution with new hooks, callbacks, or asset flows that recreate the same vulnerability shape in a more complex form. The risk is not the label. The risk is that external control returns before the protocol’s own state is safely finalized.
| Area | Main failure | Primary defense |
|---|---|---|
| Balance-changing flows | State updates after external call | Finalize state before external interaction |
| Hooked composability | Unexpected callback chains | Bound and isolate trusted call paths |
| Shared accounting | Cross-function state inconsistency | Invariant checks across function families |
| Emergency operations | Containment lags behind exploit loop | Fast scoped pause and rollback planning |
Which Reentrancy Defenses Should Teams Deploy First?
Start with external-call review. Every value-moving, permission-moving, or state-sensitive path should prove that state is resolved before outside execution resumes. Reentrancy guards help, but they are secondary to correct state ordering.
- Finalize accounting before external transfers or callbacks.
- Reduce unnecessary external call surfaces.
- Apply reentrancy guards where state ordering alone is insufficient.
- Model invariants across function families, not just one function in isolation.
{
"function": "withdraw",
"stateFinalizedBeforeCall": true,
"externalCallPresent": true,
"guardEnabled": true,
"invariantLinked": "total_assets_match_liabilities"
}
Which Signals Matter During Live Monitoring?
Runtime signals should detect recursive execution bursts, invariant divergence, unusual callback depth, and repeated failure patterns near sensitive accounting transitions.
- Unexpected recursion depth on protected function families.
- Asset/liability invariant mismatch after callback-heavy flows.
- Rapid sequence of reverts and retries around the same action path.
- Function combinations that never normally appear together inside one execution window.
How Should Teams Respond If Reentrancy Is Suspected?
Move quickly to isolate the affected path, preserve evidence, and contain blast radius through scoped emergency controls. Then validate which invariant actually failed before reopening.
- Freeze or scope-pause the affected function family.
- Preserve traces and affected state snapshots.
- Confirm the exploit path and broken invariant.
- Resume only after patched call order and verified invariant health.
Frequently Asked Questions
Is a reentrancy guard always enough?
No. Guards help, but teams still need correct state sequencing, bounded external calls, and invariants that prove funds and permissions remain safe across complex flows.
What is the best first hardening step?
Review every external call path and verify state is finalized before value-moving or control-moving interactions occur.