The check-effects-interact pattern is a smart contract coding style that orders logic as validation first, state changes second, and external calls last. It is used to reduce re-entrancy risk by updating contract state before handing control to another contract or address.
How the Check-Effects-Interact Pattern Works
The check-effects-interact pattern is a defensive smart contract style that separates decision-making from state mutation and from external interaction. By validating conditions first, then updating storage, and only then calling out, it reduces the chance that control returns to a contract that can exploit stale state.
The sequence matters because external calls can re-enter execution before the original function has finished. If state has already been updated, the second entry sees the new reality rather than the old one, which closes a common path to repeated withdrawals, double-spends, or other logic abuse.
Why It Is Used in Smart Contract Security
This pattern exists because smart contracts often execute in adversarial environments where external code cannot be assumed safe. A contract that sends value, invokes a callback, or hands control to another address must treat that boundary as a potential attack surface, not a routine programming step.
Its main security value is not that it prevents every bug, but that it reduces dependency on execution order. That makes the contract's behaviour easier to reason about during audits, testing, and review of business logic that depends on balances, ownership, limits, or one-time actions.
Used well, the pattern also supports clearer invariants. Once the effect has been recorded, any later interaction is less likely to observe a state that can be manipulated for repeated benefit.
Common Failure Modes and Limitations
The pattern is strongest when it is applied consistently. It can be weakened when a function performs an external call before all state updates are complete, when multiple functions share mutable assumptions, or when a callback path can reach logic that was not written to be re-entry safe.
It also does not replace access control, correct accounting, or safe external integration design. A contract can still fail if validation is wrong, if state transitions are incomplete, or if an external dependency behaves unexpectedly even after the core ordering is correct.
For that reason, the pattern should be treated as one part of a broader contract-security discipline, not as a universal guarantee against all re-entrancy or call-chain abuse.
Where It Fits in Secure Contract Design
Check-effects-interact is most useful in functions that transfer assets, settle balances, update permissions, or trigger third-party logic. In those cases, the contract should make its own state internally consistent before it gives up control to something outside its trust boundary.
The pattern also pairs naturally with careful review of any function that depends on contract balance, user entitlements, or counters that must not be reused. A clear ordering discipline helps auditors spot where trust is handed over and whether that handoff could expose the contract to unexpected callback behaviour.
For teams building or reviewing contracts, OWASP Smart Contract Top 10 Guide is a useful companion because it places re-entrancy alongside other high-impact smart contract weaknesses and shows how the pattern fits into broader review practice.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V15 — Secure Coding and Architecture | Check-effects-interact is a secure coding pattern that hardens execution flow in contract logic. |
| Recommendation — Apply secure coding discipline that updates state before any external interaction. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The pattern is a code-level safeguard for reducing exploitable application logic flaws. |
| Recommendation — Review application logic for unsafe external-call ordering and re-entry exposure. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Re-entrancy abuse is an application exploitation path that targets exposed contract logic. |
| Recommendation — Map exploitable contract entry points and hunt for repeated-call abuse paths. | ||
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org