The Raft Protocol exploit of November 10, 2023, which resulted in a $6.7 million loss, exposed a sobering reality in DeFi security: the vulnerability that enabled the attack was not detected by multiple professional audits. With Ethereum trading at $2,078 at the time, the 1,577 ETH lost represented a significant blow to the stablecoin protocol and its users. For developers and security researchers working in the DeFi space, the Raft exploit provides a valuable case study in the limitations of conventional auditing approaches and the advanced techniques needed to identify deeply embedded smart contract vulnerabilities.
The Objective
This tutorial aims to equip experienced smart contract developers and auditors with advanced techniques for identifying the class of vulnerabilities that the Raft exploit fell into: flaws in the interaction between multiple contracts that individually appear correct but produce dangerous behavior when combined. The Raft vulnerability involved the minting logic for the R stablecoin, where the attacker was able to mint tokens without providing adequate collateral by exploiting a gap in how the protocol validated collateralization across its contract system. Understanding how to detect these interaction-based vulnerabilities requires going beyond standard static analysis and formal verification into the realm of invariant testing, fuzzing, and cross-contract state modeling.
Prerequisites
To follow this tutorial effectively, you should have a solid understanding of Solidity development, familiarity with common smart contract vulnerability patterns such as reentrancy, integer overflow, and access control issues, and experience with at least one auditing framework. You will need Foundry or Hardhat installed for testing and fuzzing, Slither for static analysis, and Echidna or Medusa for property-based fuzzing. An understanding of DeFi primitives—particularly stablecoin mechanics, collateralization ratios, and liquidation systems—is essential, as the Raft exploit was deeply intertwined with the protocol’s stablecoin minting logic. All examples will use Solidity 0.8.x syntax and assume familiarity with the Ethereum Virtual Machine.
Step-by-Step Walkthrough
Step one: Map the complete contract interaction graph. Before auditing any DeFi protocol, create a visual map of every contract and the functions they call on each other. The Raft exploit exploited an interaction between the collateral management contract and the stablecoin minting contract. Use tools like slither with the --print call-graph option to generate this map automatically. Pay special attention to cross-contract function calls that modify state in multiple contracts within a single transaction.
Step two: Define and test invariants. Invariants are conditions that must always hold true regardless of the state of the system. For a stablecoin protocol like Raft, critical invariants include: the total supply of the stablecoin must always be less than or equal to the total value of collateral deposited, the collateralization ratio for any position must never fall below the minimum threshold after any valid operation, and the sum of all individual collateral values must equal the protocol’s total collateral value. Write these invariants as assertions using Echidna or Foundry’s invariant testing framework. The Raft vulnerability would have been caught by an invariant test asserting that the total supply of R never exceeds the total collateral value.
Step three: Implement guided fuzzing. Standard fuzzing generates random inputs, but guided fuzzing targets specific interaction patterns. Configure Echidna or Medusa to specifically test sequences involving deposit, mint, and withdraw operations in rapid succession, as these are the operations most likely to reveal state inconsistencies. Set the fuzzer to run for at least 100,000 iterations with a maximum sequence length of 10 operations. The key is to focus on edge cases where collateral values change between the validation check and the actual minting of tokens.
Step four: Perform cross-contract reentrancy analysis. While the Raft exploit was not a classic reentrancy attack, it involved a similar pattern where state was read and acted upon before being fully updated across all relevant contracts. Use Slither’s reentrancy detector with the cross-contract flag enabled, and manually review any function that makes external calls before completing state updates. Pay particular attention to functions that interact with ERC-20 token contracts, as these external calls can trigger unexpected callbacks.
Step five: Conduct a formal specification review. Beyond automated tools, manually verify that the protocol’s actual implementation matches its specification. The Raft Protocol’s specification likely stated that R tokens can only be minted against verified collateral, but the implementation allowed a path that bypassed this requirement. Create a formal or semi-formal specification of the protocol’s intended behavior and systematically verify each code path against it.
Troubleshooting
If your invariant tests pass but you suspect vulnerabilities still exist, consider whether your invariants are comprehensive enough. A common mistake is testing only the happy path invariants while neglecting edge cases like zero-amount operations, maximum-value deposits, or operations performed during liquidation events. If fuzzing does not find issues, increase the sequence length and iteration count, or use guided fuzzing with specific target sequences. If Slither reports no vulnerabilities, remember that static analysis tools cannot detect all interaction-based flaws—they are limited to patterns they are programmed to recognize. Always complement automated tools with manual review of cross-contract interactions. When reviewing code, focus on the assumptions each contract makes about the state of other contracts. The Raft exploit existed because one contract assumed that collateral had been validated when it had not.
Mastering the Skill
Advanced smart contract auditing is an ongoing discipline that evolves with every new exploit. The Raft Protocol vulnerability of November 10, 2023, joins a long list of DeFi exploits that were missed by conventional auditing approaches. To master this field, commit to studying every major exploit and understanding not just what happened but why existing tools failed to detect it. Build a personal library of invariant templates for common DeFi patterns—stablecoins, lending protocols, DEXs, and bridges. Contribute to open-source security tools and participate in bug bounty programs to sharpen your skills against real-world targets. As DeFi protocols grow more complex, the demand for auditors who can identify these deeply embedded vulnerabilities will only increase, making this expertise both valuable and essential for the ecosystem’s security.
Disclaimer: This article is for educational purposes only. The techniques described should be used ethically and responsibly for improving smart contract security.
1577 ETH lost because the minting path was never tested end to end with real value. protocol raised 6.7M but wouldnt pay for formal verification on the critical path
the Raft bug passed multiple professional audits because each contract looked correct in isolation. interaction bugs are invisible to standard review
6.7m loss because nobody tested what happens when minting logic interacts with the collateral check across two separate contracts. composability is a double edged sword
1,577 ETH gone because nobody tested cross-contract state changes with real value. composability gives you DeFi magic and also gives you 6.7M exploits. same coin
interaction bugs between individually correct contracts are the hardest class to find. formal verification helps but its expensive and rarely covers the full system
formal verification at 50k is cheap insurance for a protocol holding millions. teams spend more on marketing than security. priorities are backwards
Rina Patel protocols raising 6.7M but wont spend 50k on Certora. the ROI math is obvious but founders optimize for fundraising narratives not user safety
rina you get it. protocols raising 6.7M in a round wont spend 50k on formal verification because it shows up as a line item on a spreadsheet and investors dont ask for it. incentives are misaligned top to bottom
formal verification is getting cheaper with tools like certora and halmos. the problem is teams dont want to spend 50k on verification for a protocol holding 6.7m
the Raft exploit is the textbook case for integration testing. minting worked fine in isolation, it was the interaction with the price feed that created the vulnerability
integration_kep_ every audit firm charges 3x for integration tests vs unit tests. protocols just pick the cheaper option and hope
1577 ETH gone because formal verification was deemed too expensive. the protocol raised 6.7M but wouldnt spend 50K on Certora specs
professional audits missed this for months should humble every auditor in the space. complacency is the real vulnerability
complacency plus audit scope that doesnt cover cross-contract interactions. the audit says contract A is fine and B is fine but never tests them together
audit scope exclusions are the real vulnerability. teams pay for contract level audits but the interaction layer is always out of scope because its harder to test
zkbear audit firms arent complacent, theyre structurally constrained. the scope doc is written by the protocol team and they explicitly exclude cross-contract interactions to save money. auditors flag it in the report and nobody reads page 47
audit scope docs written by the protocol team to save money. they exclude cross-contract interactions because testing them is expensive. then this happens
fuzzing the collateral check in isolation passes every time. its only when you fuzz the minting path AND the collateralization check together that the edge case shows up. differential fuzzing should be standard for every defi protocol
lint_check_ differential fuzzing the minting path and collateral check together would have caught this instantly. its insane that protocols still test contracts in isolation
the collateralization gap between contracts is exactly why single-scope audits miss everything. each contract passes in isolation
rekt_forensics_ this is why composability is a double edged sword. each piece looks safe until they touch
1577 ETH lost because nobody tested the minting path end to end. individual function review is not an audit
1577 eth gone because the audit covered contract A and contract B separately but never tested them talking to each other. composability kills
individual contract audits are like testing brakes and steering separately but never driving the car. Raft proved composability bugs only show up in integration
fuzz_kep_void_ fuzzing catches reentrancy and overflow but not cross-contract state assumptions. you need formal verification for that and almost nobody does it
4 professional audits and nobody caught the minting logic gap. this is why audit reports are fancy PDFs not insurance policies
tomasz_r audits check for known patterns. the raft bug was an interaction between contracts that looked fine individually. different problem entirely