The twin security incidents that struck the crypto ecosystem in late January 2026 — the $7 million SagaEVM bridge exploit on January 21 and the $4.13 million Makina Finance oracle manipulation attack on January 20 — share a common root cause that extends far beyond the individual protocols involved. Both incidents exploited vulnerabilities that existed in known attack surfaces but were inadequately addressed by the protocols’ security assessment processes. For developers and security professionals, these incidents provide a masterclass in the critical importance of comprehensive audit scoping.
The Objective
This guide walks through the process of designing and executing a smart contract audit scope that eliminates the kind of blind spots that led to the Saga and Makina exploits. The goal is not simply to pass an audit — it is to ensure that every meaningful attack vector is identified, assessed, and either mitigated or explicitly accepted as a known risk with appropriate safeguards.
By the end of this walkthrough, you will understand how to define audit boundaries, identify inherited risk from dependencies, evaluate oracle and bridge attack surfaces, and establish ongoing monitoring that catches vulnerabilities before attackers do.
Prerequisites
This guide assumes you have intermediate knowledge of smart contract development and basic familiarity with common attack vectors including reentrancy, integer overflow, access control failures, and flash loan attacks. You should understand how price oracles work and why they can be manipulated. Familiarity with the Cosmos SDK, IBC protocol, and EVM bridge architecture is helpful but not required.
You will need access to your protocol’s codebase, a list of all external dependencies and integrations, and ideally the reports from any previous security audits your project has undergone. If you are building on a framework like Ethermint, CosmWasm, or any other third-party execution environment, you will also need access to that framework’s known vulnerability database and change log.
Step-by-Step Walkthrough
Step 1: Map Your Attack Surface Comprehensively
Begin by creating a complete dependency graph of your protocol. This includes not just your own smart contracts, but every external library, framework, oracle, bridge, and integration point. The Saga exploit demonstrated that vulnerabilities in a dependency — Ethermint’s EVM module — can be just as devastating as vulnerabilities in your own code.
For each component in your dependency graph, document the trust assumptions. What happens if the oracle provides incorrect prices? What happens if the bridge accepts fraudulent messages? What happens if a dependency introduces an unexpected behavior? If you cannot answer these questions for any component, that component represents an unexamined risk.
Step 2: Define Audit Scope by Attack Vector, Not by Contract
Traditional audit scoping defines scope as a list of contracts or files to review. This approach misses cross-contract interactions and systemic risks. Instead, scope your audit by attack vector. For each category of attack — reentrancy, oracle manipulation, bridge exploitation, access control, front-running, integer overflow, and so on — specify how that vector will be tested across all relevant components.
The Makina Finance exploit is a perfect cautionary tale. The protocol had six audits, but oracle manipulation was listed as “out of scope.” By defining scope by contract rather than by attack vector, the audits missed the single most impactful vulnerability in the entire system.
Step 3: Evaluate Inherited Risk Explicitly
For every third-party component your protocol uses, conduct or commission a separate security assessment focused specifically on that component’s interaction with your protocol. Do not assume that because a framework is widely used, it is secure. Ethermint is used by multiple Cosmos-based chains, yet the vulnerability that Saga exploited was present in the module itself.
Document all inherited risks in a risk register that is maintained alongside your codebase. For each inherited risk, specify the mitigation in place, the residual risk level, and the monitoring strategy for detecting exploitation attempts.
Step 4: Implement Multi-Layered Oracle Protection
If your protocol uses price oracles — and most DeFi protocols do — implement multiple layers of protection. Use at least two independent oracle sources and implement deviation checks between them. Deploy time-weighted average price (TWAP) mechanisms that make manipulation economically impractical. Set conservative circuit breaker thresholds that pause operations during anomalous price movements.
Most importantly, include oracle manipulation scenarios explicitly in your test suite. Write tests that simulate flash loan attacks on DEX pools used as price sources, sudden price drops during market crashes, and stale price feeds during network congestion. These are not theoretical risks — they are the exact conditions that led to the Makina exploit.
Step 5: Establish Continuous Security Monitoring
Audit-time security is necessary but not sufficient. Deploy automated monitoring systems that track on-chain activity for suspicious patterns. Monitor for unusual contract deployments near your protocol, unexpected large token transfers, bridge activity anomalies, and oracle price deviations.
The Saga team’s decision to halt the chain at block 6,593,800 was effective because they had the monitoring in place to detect the exploit quickly. Without real-time monitoring, the attacker could have extracted significantly more than the $7 million ultimately stolen.
Troubleshooting
Problem: Audit firms resist expanding scope due to cost and timeline concerns.
Solution: Negotiate scope by priority. Identify the highest-impact attack vectors based on your protocol’s specific architecture and insist those are covered in the initial audit. Lower-priority vectors can be addressed in follow-up assessments. The key is ensuring that no high-impact vector is left unexamined.
Problem: Third-party dependencies have limited documentation or audit reports.
Solution: Conduct your own assessment of critical dependency code paths. Focus on the specific functions and interfaces your protocol uses, rather than attempting a full assessment of the entire framework. At minimum, verify that input validation, access control, and state management in the code paths you depend on meet your security requirements.
Problem: Budget constraints limit the number of audit engagements.
Solution: Prioritize coverage of the most impactful attack vectors over depth of analysis on lower-risk components. A broad but shallow assessment that covers oracle manipulation, bridge security, and access control is more valuable than a deep assessment that excludes these vectors. Consider engaging multiple firms for targeted reviews rather than a single firm for a comprehensive but scoped-out engagement.
Mastering the Skill
Advanced audit scoping is ultimately about understanding that security is not a checkbox — it is a continuous process of identifying, evaluating, and mitigating risk. The Saga and Makina exploits are not anomalies; they are the predictable result of security processes that prioritize appearances over actual protection.
To deepen your expertise, study the post-mortem reports from major exploits including Saga, Makina, Ronin Bridge, Wormhole, and Nomad. Each incident reveals a specific category of blind spot that comprehensive scoping would have caught. Build a personal checklist of attack vectors organized by protocol type — lending, DEX, bridge, yield aggregator — and ensure that every audit scope you define addresses each relevant vector.
The crypto industry lost over $370 million to hacks and exploits in January 2026 alone. As a security professional, your job is to ensure that the protocols you work on are not contributing to next month’s statistics. That starts with refusing to accept “out of scope” as an answer for high-impact attack vectors.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before making any investment decisions.
both saga and makina were attacked through vectors that were explicitly marked out of scope. the whole out of scope culture in audits needs to die
This should be required reading for every protocol founder shopping for audits. If your auditor lets you exclude oracle manipulation from scope, find a new auditor.
^ hard agree. inherited risk from dependencies is the silent killer too. your code can be perfect but if the oracle you rely on isnt, you still get rekt