Aave Labs’ proposed V3.8 upgrade adds a single reentrancy guard on Pool operations and nothing else, by the proposal’s own description The guard uses EIP-1153 transient storage, a relatively
Aave Labs’ proposal for what it calls Aave V3.8 stands out for what it deliberately does not include. The proposal describes the release as non-invasive and very measured, adding essentially one meaningful change, a reentrancy guard on the protocol’s core Pool operations, rather than bundling in new features, expanded asset support, or other enhancements that might typically accompany a version upgrade.
That narrow focus reflects just how seriously decentralized finance protocols now treat reentrancy as a category of risk. A reentrancy attack occurs when a malicious contract exploits a flaw that lets it call back into a protocol’s own functions before an initial transaction has fully finished executing, potentially letting the attacker drain funds or manipulate a protocol’s internal accounting in ways the original code never intended to allow. This category of exploit has a long and costly history across decentralized finance, going back to some of the earliest and most prominent hacks in the space’s development.
The specific mechanism Aave’s proposal relies on, EIP-1153, introduces what Ethereum calls transient storage, a type of data storage that exists only for the duration of a single transaction and is automatically cleared once that transaction completes. Using transient storage for a reentrancy guard offers a notable advantage over older approaches to the same problem: because the data clears itself automatically and only persists for the life of one transaction, it can provide the same protective function at a lower gas cost than storage mechanisms that persist data more permanently on-chain.
If approved, the proposal calls for deploying this hardened guard across an unusually long list of Aave V3 instances spanning more than a dozen different blockchain networks, including Ethereum’s Core and Lido markets, Base, Arbitrum, Polygon, Optimism, and several others, excluding only instances that have already been fully frozen. That breadth underscores just how widely Aave’s codebase has been deployed across the broader multi-chain decentralized finance landscape, and how much surface area a single security hardening change like this one can cover in one coordinated release.
Choosing to isolate a security improvement into its own standalone release, rather than bundling it alongside unrelated feature work, can also make the resulting code easier for independent auditors to review thoroughly, since reviewers can focus specifically on the security-relevant change without needing to simultaneously evaluate unrelated new functionality introduced in the same release. Aave’s proposal explicitly plans further audits, including a review from Certora, before any final on-chain vote. The proposal, posted on Aave’s own governance forum, states plainly that securing Aave V3 remains a top priority for the protocol’s developers.
This post first appeared in Why Aave Is Spending an Entire Protocol Upgrade on Security Alone
