The Radiant Capital exploit on January 2, 2024, which extracted approximately $4.5 million worth of ETH from the protocol’s Arbitrum deployment, represents a class of attack that every advanced DeFi user should understand. Precision rounding vulnerabilities are subtle, difficult to detect through standard auditing, and devastating in practice. This tutorial provides a deep technical walkthrough of how these exploits work and how to evaluate lending protocols for similar risks.
The Objective
This guide aims to equip experienced DeFi users with the knowledge to identify precision rounding vulnerabilities in lending and borrowing protocols. By understanding the mathematical mechanics behind the Radiant Capital exploit, you will be better positioned to assess the security of any protocol that handles token quantity calculations, interest rate accrual, or exchange rate conversions.
Prerequisites
Before proceeding, you should be comfortable with the following concepts:
- Solidity arithmetic — Understanding of fixed-point math, integer division, and the absence of floating-point numbers in the EVM
- RAY and WAD precision — Familiarity with common precision standards (RAY = 10^27, WAD = 10^18) used in DeFi protocols
- Flash loan mechanics — How uncollateralized instantaneous loans enable price manipulation attacks
- Lending protocol architecture — Understanding of deposit, withdrawal, and interest accrual functions in protocols like Aave or Compound
Step-by-Step Walkthrough
Step 1: Understanding the Vulnerable Formula
Radiant Capital used a precision expansion formula that can be expressed as: result = (a * RAY + b / 2) / b. This formula expands a value a by multiplying it with RAY (10^27), then divides by b. The b / 2 term provides rounding compensation. Under normal conditions, when a is much larger than b, the rounding error is negligible. The problem emerges when b approaches the magnitude of a.
Step 2: How the Attacker Manipulated Variables
The attacker recognized that by manipulating the relationship between a and b, they could create enormous rounding discrepancies. Consider this example: when a * RAY = 10,000 and b = 3, the result is 3,333 — a minor rounding error. But when b = 3,000, the result becomes just 3, which is off by a factor of 1,000. The attacker deliberately engineered conditions where b was close in magnitude to a, causing the protocol to drastically undervalue the attacker’s debt while overvaluing their collateral.
Step 3: The Flash Loan Attack Sequence
The attack proceeded as follows: First, the attacker obtained a 3 million USDC flash loan from Aave. They deposited this into Radiant Capital’s newly launched native USDC market on Arbitrum, receiving rUSDC tokens in return. By manipulating the deposit and withdrawal amounts to exploit the rounding vulnerability, they artificially inflated their profit margin on each transaction cycle. The attacker received approximately 2 million rUSDC for what should have been a proportionally smaller deposit, then converted the excess back to ETH. The entire exploit extracted roughly 1,902 ETH, valued at approximately $4.5 million at the time.
Step 4: Why This Bypassed Audits
Precision rounding bugs are notoriously difficult to catch because the vulnerable code functions correctly under normal operating conditions. Standard test suites use typical deposit amounts where the rounding error is negligible. The vulnerability only manifests at extreme parameter values that auditors may not test. This is why fuzzing tools and formal verification are essential for DeFi protocols handling mathematical calculations.
Troubleshooting
When evaluating a DeFi protocol for rounding vulnerabilities, watch for these warning signs:
- Division before multiplication — Operations that divide before multiplying lose precision. Always multiply first, then divide.
- Unbounded variable ratios — If user input can control the ratio between numerator and denominator in precision calculations, rounding errors can be weaponized.
- New market launches — Newly launched markets with low liquidity are especially vulnerable because the parameter space is narrow, making it easier for attackers to manipulate ratios.
- Missing bounds checks — Protocols should enforce minimum and maximum values for critical parameters to prevent the extreme ratios that enable rounding exploits.
Mastering the Skill
To build deep expertise in DeFi security analysis, practice with the following approaches. Set up a local fork of Ethereum mainnet using Foundry or Hardhat and reproduce known exploits like the Radiant Capital attack on your local environment. Use Echidna or Medusa for property-based fuzzing of smart contract math functions. Study the audit reports published by firms like Trail of Bits, OpenZeppelin, and Spearbit to learn how professionals identify these vulnerabilities.
The DeFi ecosystem lost billions to smart contract vulnerabilities in 2023, and early 2024 shows the trend continuing. Understanding the mathematical foundations of these exploits transforms you from a passive user into an informed participant who can evaluate protocol risk independently. As Bitcoin trades above $44,950 and the total crypto market cap approaches $1.7 trillion, the financial stakes demand nothing less than rigorous security awareness from every serious DeFi user.
Disclaimer: This article is for educational purposes only and does not constitute financial or investment advice. Engaging with DeFi protocols carries significant risk, including the potential loss of all deposited funds.
radiant got hit for 4.5m because nobody checked the rounding direction on their index calculation. basic stuff that auditors miss when the math looks complicated enough
the issue is that Solidity division always rounds down. so if you compute borrow shares or interest, an attacker can call the function millions of times and extract dust each time
346849 the million-call extraction pattern is why protocol-level rate limits matter. cap the calls per block and the dust extraction becomes economically unviable
Liang W. Solidity division rounds down so the attacker calls withdraw millions of times. the fix is literally always multiply before divide. day one solidity curriculum and Radiant missed it
mul_before_div_ multiply before divide is literally in the OpenZeppelin SafeMath docs. Radiant paid auditors to skip the README
the RAY formula breakdown should be required reading for anyone deploying on arbitrum. radiant lost 4.5m because of integer division order
automated tools catch reentrancy but rounding exploits require mathematical reasoning about the protocol itself. the audit gap between these two attack classes is massive
the detailed breakdown of the RAY formula edge case is exactly what DeFi security education needs more of
the RAY formula breakdown is exactly the kind of deep technical content this space needs. most explainer posts just say rounding error and move on
ray_check_ RAY formula breakdown should be mandatory reading for anyone deploying a lending protocol. 4.5M for a one bit rounding error is absurd
fixed point math in solidity is unforgiving. one division before multiplication and youre bleeding dust on every call
precision and rounding bugs in lending protocols are way more common than reentrancy at this point. auditors need to update their checklists
agree. the focus on reentrancy guards in most audits misses the entire class of math errors that are actually costing money
reentrancy guards are the low hanging fruit of audits. rounding errors require actual mathematical analysis which most auditors skip because its harder
Kyoko S. rounding bugs are the new reentrancy. same pattern every cycle, the attack surface shifts and audits take 2 years to catch up
79837 reentrancy gets all the audit attention because tools flag it automatically. rounding bugs need a human who understands fixed point math and auditors bill by the hour
the prerequisites section is honest about the skill level needed. too many “advanced” tutorials skip the math foundation entirely
auditors focusing on reentrancy while rounding bugs drain millions is a misallocation of attention. the attack surface shifted years ago
Ines V. auditors spending 80% of time on reentrancy checks while rounding bugs drain millions. the allocation is completely backwards
every audit report leads with reentrancy findings because theyre easy to detect automatically. math bugs need manual review and nobody wants to pay for that
Tobias K. automated reentrancy detection is cheap and easy to show in a report. math review requires someone who actually understands fixed point arithmetic and costs more
the RAY formula edge case breakdown is genuinely useful content. most security posts just say rounding error and never explain the actual math behind the exploit
4.5M drained from a one-bit rounding error on RAY. every lending protocol in defi should be running invariant tests on their index calculations tonight
dust_collector_ a one-bit rounding error draining 4.5M should be the default case study in every smart contract course. most devs dont think about integer division edge cases
auditors charging 50K to run Slither and miss 4.5M rounding bugs while spending 80 percent of the report on reentrancy guards is the real exploit
the million-call extraction pattern is why gas optimization and security are at odds. protocols batch operations to save gas which also caps attack iterations. Radiant had no rate limit on the vulnerable function