Aave V3.8 Proposal Adds A Reentrancy Guard To 15 Deployments

Aave Labs wants one change in the next Aave V3 release, and it is a lock. The Aave V3.8 proposal adds a reentrancy guard to Pool operations, built on transient storage, and it asks the community to approve the upgrade across 15 deployments. It was posted to the Aave governance forum at 17:06 UTC on October 21.

One guard, fifteen deployments

Aave Labs calls the release "non-invasive and very measured," focused on security. The summary lists a single change, a reentrancy guard on Pool operations during external callbacks. In its words the changes are "quite minor," though worth applying for resilience.

The Aave V3.8 guard uses transient storage, the feature defined in EIP-1153. Per the proposal, it protects Pool accounting consistency, including when one transaction's execution flow interacts with the Pool more than once. Aave Labs says it protects against "theoretical reentrancy exploits."

Summary, motivation and change list from the proposal. Source: Aave governance forum, ARFC Aave V3.8.

Why transient storage changes the cost argument

Gas was historically the objection to this kind of guard, the proposal says. Transient storage removes it. Per EIP-1153, transient state acts like storage but is thrown away after every transaction. Nothing touches disk, which makes it cheaper. Aave Labs argues the guard now adds little overhead.

By Ethereum standards the idea is old. EIP-1153 dates from June 2018 and is now marked Final. Alexey Akhunov and Moody Salem wrote it, and it adds the opcodes TLOAD and TSTORE.

Lock logic follows a simple idea. Before a Pool operation runs, a flag is set in transient storage. Any callback that tries to re-enter the Pool finds the flag raised and fails. When the transaction ends, the flag vanishes by itself. That is the general pattern, and the proposal gives no code in its summary.

Where the Aave V3.8 upgrade would land

Targets named in the rollout plan are the Aave V3 instances on Ethereum (Core and Lido), Plasma, Avalanche, BNB and Monad. Base, Arbitrum, Mantle and X Layer follow in the list. So do Polygon, Linea, Optimism, Gnosis, MegaETH and Celo. Only active instances count. Deployments where all assets are frozen and caps are set to zero are left out.

Aave V3.8 licence, audits and the road to a vote

V3.8 will be published as its own version of the Licensed Work under a Business Source License. A change date is set by Aave Governance and recorded in a text record at v38.aavelicense.eth. Until a date is set, the code stays under the licence. Intellectual property would move to the Aave Foundation through a separate governance proposal.

Audits come first. Certora and third parties will review V3.8 before any on-chain proposal. Aave Labs also states it has no undisclosed financial interest in the outcome.

Steps follow a familiar order. Community feedback comes in the ARFC stage. A positive response sends it to a Snapshot vote for off-chain confirmation. After audits finish, an Aave Improvement Proposal would ask governance to upgrade the in-scope instances. At posting time the thread had one post and about 216 views.