Checks Effects Interactions is a smart contract coding pattern that performs validation before changing state and before making external calls. It reduces reentrancy risk by checking conditions first, updating balances or other state second, and only then interacting with another contract or system.
How Checks Effects Interactions Works
Checks Effects Interactions is a defensive smart contract pattern that sequences execution so the contract first validates inputs and conditions, then updates its own state, and only after that makes an external call. That order matters because it narrows the window in which another contract can re-enter before balances or permissions have been updated.
The pattern is best understood as a control against unsafe call ordering, not as a complete security guarantee. It reduces one of the most common classes of smart contract failure, but it still depends on correct validation logic, correct state transitions, and careful handling of any downstream contract that can execute arbitrary code during the interaction phase.
Why the Pattern Reduces Reentrancy Risk
Reentrancy becomes dangerous when external code is invoked before the contract has finished recording the effect of the current action. If the caller can re-enter through a fallback function, callback, or another externally controlled path, it may observe stale state and repeat the same operation before the contract has updated its own records.
Checks Effects Interactions breaks that attack path by ensuring the contract commits the effect before control leaves the contract. In practice, that means a withdrawal, transfer, or other balance-changing action should be reflected internally before the external interaction can trigger a second pass through the same logic. For a broader review of the surrounding vulnerability classes and defences, see the OWASP Smart Contract Top 10 Guide.
It is especially relevant in systems that rely on complex value flows, composable DeFi integrations, or token logic that calls into other contracts as part of normal execution. The pattern helps preserve invariants such as “balance cannot be spent twice” or “approval changes take effect before external control is yielded.”
Where the Pattern Sits in Smart Contract Design
This pattern is not a substitute for access control, input validation, or formal correctness of business logic. It is a sequencing discipline that works alongside those controls. A contract can still be vulnerable if the validation step is incomplete, if state is updated incorrectly, or if the external call itself creates a different class of exploit such as denial of service or unexpected callback behaviour.
Designers often pair this ordering with narrow external interfaces, minimized callback surfaces, and conservative assumptions about any contract they invoke. That is because the moment a contract calls out, it must assume the callee may be hostile, may consume all remaining gas, or may attempt to re-enter through any available path.
In review and audit work, the key question is whether the contract ever interacts externally before all critical checks and internal effects are complete. That question is often more important than the exact syntax used to make the call.
Limits, Trade-offs, and What It Does Not Solve
Checks Effects Interactions lowers reentrancy exposure, but it does not eliminate all reentrancy risks in every architecture. Cross-function reentrancy, delegated execution patterns, proxy-based designs, and complex token standards can still create unsafe execution paths if the contract’s invariants are not designed holistically.
The pattern also introduces a trade-off: it forces developers to be disciplined about when state becomes authoritative. If state is updated too early, a later failure may leave the contract in an inconsistent condition unless the entire transaction correctly reverts. If state is updated too late, the contract remains exposed to repeated execution during the external interaction. Good design therefore pairs the pattern with transactional reasoning, explicit invariant checks, and testing that simulates callback-driven control flow.
In short, the pattern is a sequencing rule that supports safer contract composition, but it only works when the contract’s overall logic is written to tolerate adversarial re-entry and nested execution.
Risk and Threat Considerations
The main risk is that an external call can hand control to untrusted code before the contract has finalized its own state, letting an attacker repeat the same sensitive action against stale balances, allowances, or bookkeeping. That can lead to repeated withdrawals, duplicated claims, or other state-desynchronization effects.
Failure mechanism: The contract invokes external code before recording the effect of the current action, so the callee re-enters while the original state still reflects the pre-transaction condition.
Impact: The attacker can drain value, violate invariants, or force the contract into an inconsistent or loss-making state, especially where funds movement or privilege checks depend on accurate internal state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Reentrancy-safe sequencing supports enforcing access and action boundaries in contract logic. |
| Recommendation — Design contract flows so authorization-dependent state changes happen before any external interaction. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Secure coding guidance applies to preventing unsafe call ordering and logic flaws in custom software. |
| Recommendation — Review application code for reentrancy-prone call sequences and enforce secure coding patterns. | ||
| NIST SP 800-53 Rev 5 | SC-39 — Process Isolation | External-call isolation and controlled execution boundaries help limit the blast radius of hostile callbacks. |
| Recommendation — Isolate untrusted execution paths so external calls cannot corrupt critical contract state. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Smart contracts exposed through public interaction can be targeted through application logic exploits. |
| Recommendation — Map externally reachable contract surfaces to exploitation pathways and test for logic abuse. | ||