Reason to trust
How Our News is Made
Strict editorial policy that focuses on accuracy, relevance, and impartiality
Ad discliamer
Morbi pretium leo et nisl aliquam mollis. Quisque arcu lorem, ultricies quis pellentesque nec, ullamcorper eu odio.
Aave Labs has clarified that its proposed V3.8 security upgrade would preserve flash-loan liquidations. The October 23 response addresses how a reentrancy guard would interact with existing integrations.
TL;DR: Aave’s proposed V3.8 guard excludes flash-loan entry points. Governance approval and security audits remain pending.
The proposal, posted October 21, adds a guard to Pool operations. Such guards constrain the ability of an external callback to enter protected contract functions again before an earlier call finishes. Aave Labs says flashLoan() and flashLoanSimple() would be excluded, allowing their callbacks to keep invoking Pool actions, including liquidations.
Why The Callback Matters
A smart contract receiving a flash loan needs time within the transaction to do something with the borrowed assets. Aave’s developer guide describes a sequence in which the Pool transfers assets, calls the receiver contract and then checks settlement conditions.
For a simple flash loan, the receiver must make the amount borrowed plus the required fee available for repayment. If the transaction cannot meet its conditions, it reverts. The broader flash-loan interface can cover multiple assets and, under permitted conditions, open a collateral-backed debt position.
Those mechanics explain why the scope of a guard matters. A liquidation integration may need to borrow an asset, repay an unhealthy position and complete the rest of its transaction before settlement. Blocking every subsequent Pool interaction indiscriminately would interfere with that sequence.
The important design question is which routes back into the protocol are intentional. A useful security boundary must account for the transaction patterns that integrations depend on, including calls that occur after assets have left the Pool but before repayment is checked.
A Transaction-Length Lock
The proposed implementation uses transient storage introduced through Ethereum’s EIP-1153. That storage remains available during a transaction and is discarded when the transaction ends. It can therefore carry temporary lock state to track whether a protected operation is already running.
The specification identifies reentrancy locks as a use case and explains why transient storage can cost less than writing temporary state to permanent storage. For a heavily used DeFi protocol, the design question includes the cost imposed on ordinary transactions as well as the protection added by the guard.
Aave’s proposed path includes feedback, a Snapshot vote, security review and an on-chain improvement proposal. Certora and additional reviewers are expected to assess the changes before that final step.
For integrators on Ethereum and other affected networks, the clarification provides a concrete compatibility point to check against the eventual code. The reviewed implementation must preserve the intended transaction sequence while enforcing the new boundary. A statement of design intent is useful during that work; deployed behavior will depend on the implementation governance ultimately accepts.
Written by the News Desk and edited by Samuel Rae.
