The Starknet-based lending protocol zkLend suffered a devastating security breach in February 2025, losing approximately $9.57 million in digital assets after an attacker exploited a subtle decimal precision vulnerability in the platform’s smart contract code. The incident, which sent shockwaves through the Layer 2 DeFi ecosystem, highlights the persistent risks that even audited protocols face when handling complex mathematical operations across different token decimal configurations.
The Exploit Mechanics
The attacker targeted a critical flaw in how zkLend’s accumulator system handled decimal precision across different token types. Starknet, unlike Ethereum’s EVM, uses a Cairo programming model with its own arithmetic rules, and the vulnerability emerged from the interaction between token decimals and the protocol’s interest rate accumulator calculations. The exploit allowed the attacker to manipulate the accumulator to artificially inflate their collateral value while deflating their debt, creating a massive arbitrage opportunity that drained the protocol’s liquidity pools.
Specifically, the attacker used a flash loan to amplify their position, then triggered the decimal precision mismatch to withdraw significantly more value than they had deposited. The attack was executed in a single transaction, making it impossible for the protocol’s monitoring systems to intervene before the damage was done. With Bitcoin trading around $95,500 and Ethereum near $2,670 at the time, the stolen assets represented a substantial loss for the protocol’s users.
Affected Systems
The exploit directly impacted zkLend’s lending pools on Starknet, with multiple token markets affected including major stablecoins and wrapped assets. The protocol was forced to pause all operations immediately after detecting the breach. zkLend’s native ZEND token also experienced significant downward pressure as news of the exploit spread across social media and crypto news outlets.
The broader Starknet DeFi ecosystem felt the impact as well, with total value locked across the network dropping as users rushed to withdraw funds from other protocols out of caution. The incident raised uncomfortable questions about the maturity of Cairo-based smart contract development and whether existing audit practices adequately cover the unique risks of Starknet’s execution environment.
The Mitigation Strategy
zkLend’s response team acted swiftly to contain the damage. The protocol offered a 10% white hat bounty to the attacker, urging them to return the stolen funds. The team also engaged multiple blockchain security firms, including SlowMist and BlockSec, to conduct a thorough post-mortem analysis. Their findings confirmed that the decimal precision vulnerability was the root cause, with the exploit bearing similarities to the earlier EraLend hack on the same network.
For the broader ecosystem, the incident underscored the need for specialized audit tools that can detect decimal precision issues in Cairo smart contracts. Standard EVM-focused audit methodologies may not catch these types of vulnerabilities, creating a dangerous blind spot for protocols building on Starknet and similar non-EVM chains.
Lessons Learned
The zkLend exploit serves as a stark reminder that decimal handling remains one of the most treacherous areas of smart contract development. Even small discrepancies in how tokens with different decimal places interact within lending protocols can create exploitable conditions. Development teams must implement rigorous testing specifically for decimal edge cases, including fuzzing with extreme values and formal verification of mathematical operations.
The incident also highlights the importance of layered security approaches. While audits are essential, protocols should complement them with real-time monitoring systems that can detect anomalous accumulator behavior, circuit breakers that pause operations when unusual withdrawal patterns emerge, and insurance mechanisms that can compensate users in the event of a successful exploit.
User Action Required
Users who had funds deposited in zkLend should monitor the protocol’s official communication channels for updates on the recovery process and any potential compensation plans. For users of other Starknet DeFi protocols, this incident serves as a reminder to evaluate the security measures in place, particularly around decimal handling and accumulator mechanisms. Diversifying across multiple protocols and chains remains one of the most effective strategies for minimizing the impact of any single exploit.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before engaging with any DeFi protocol.
decimal precision bugs are the new reentrancy. seen 3 lending protocols get hit the same way in 2025 alone, all because cairo handles integers differently than solidity devs expect
9.57M gone because someone didnt account for token decimal mismatch. this is a 2 line fix if you catch it in review. heartbreaking stuff
decimal precision bugs keep happening because auditors know Solidity inside out but barely understand Cairo. L2 security is only as strong as the audit quality
starknet_defi_fan flash loans amplifying a decimal bug is nightmare fuel for any lending protocol. one tx and 9.57M just gone
9.57M gone in minutes. That’s not just bug money, that’s entire startup funding vaporized.
startup funding vaporized in one transaction. and Starknet audits somehow missed basic decimal math. Cairo is a different beast from Solidity
cairo audits are still in their infancy compared to solidity. the tooling just isnt there yet for catching these edge cases
Mira Novak the tooling gap between Cairo and Solidity is massive. Echidna and Slither dont even have proper Cairo equivalents yet
decimal precision bugs are gonna keep happening on Cairo until the tooling catches up to Solidity. Echidna and Slither barely work on Cairo contracts
decimal_drift_ Echidna doesnt even support Cairo. you literally cannot property test Starknet contracts the way you can with Solidity. the tooling gap is the vulnerability
Exactly. The missing validation on the Starknet sequencer timestamp is what made the replay possible in the first place. In Cairo 1.0 the Syscall.get_block_timestamp doesn’t guarantee uniqueness across reorged blocks the way Ethereum’s does. zkLend should have been comparing against the previous oracle update slot, not just the raw timestamp.
decimal precision bug on starknet let them drain 9.57M. cairo_dev_101 spotted the sequencer timestamp miss.
cairo_dev_101 comparing Starknet timestamp to Ethereum is fair but the real issue is zkLend assumed the sequencer would never reorg. that assumption cost 9.57M
decimal precision on starknet lol. nobody ever learns these basic math errors cost millions
Been through worse exploits. The real question is: how long until they patch this and do people come back?
sarah K people came back after bigger exploits on ethereum mainnet. question is whether starknet defi TVL ever recovers to levels where this matters
This also highlights why every lending protocol on Starknet should implement a circuit breaker on large liquidations. A $9.57M exploit through a single precision bug means there was zero rate limiting on the withdrawal side. Even a basic time-weighted check like MakerDAO’s debt ceiling would have throttled this significantly.
every starknet lending protocol needs that circuit breaker now. layer2_watch got it spot on.
layer2_watch MakerDAO style debt ceilings should be mandatory on every lending protocol. zkLend had zero throttle on withdrawals, 9.57M gone in one tx
flash loan to amplify a decimal precision exploit is clean execution. one transaction, 9.57M gone. the accumulator design was the weak link
flash loan amplifying the decimal exploit was too clean. flash_defi_ called the execution perfectly.
The decimal precision vulnerability here is almost identical to the one that hit another Starknet DeFi protocol last quarter. The root cause is always the same — mixing 18-decimal ERC-20 assumptions with Cairo’s native uint256 behavior. Until Starknet standardizes a token decimal registry, these bugs will keep appearing.
starknet_security this is the third decimal bug on Cairo this year alone. the language handles uint256 differently and devs keep importing EVM assumptions
flash loan amplifying a decimal bug in one transaction is technically elegant. the attacker understood the accumulator better than the devs who built it