
Aave Labs proposed a V3.8 security update aimed at preserving liquidations using flash loans. On October 23, the company clarified how reentrancy protection will interact with existing integrations. The proposal, posted on October 21, adds protection to pool operations. This protection limits the ability of an external callback to re-enter protected contract functions until the previous call is completed. However, it excludes the functions flashLoan() and flashLoanSimple() from its scope so that their callbacks can continue to invoke pool actions, including liquidations.
This is important because liquidation integrations may rely on the ability to borrow an asset, repay an unhealthy position, and complete the rest of the operation within a single transaction before settlement checks. Blocking any subsequent interaction with the pool indiscriminately would hinder this sequence. The key design question is which return routes to the protocol are intentional: a useful security boundary should account for transaction patterns that integrations rely on, including calls after assets exit the pool but before repayment verification.
The proposed implementation uses temporary storage introduced through the EIP-1153 standard in Ethereum. This storage is available during the transaction and discarded upon its completion, allowing it to carry temporary lock state and track whether a protected operation is already in progress. The specification cites reentrancy locks as one use case and explains why temporary storage might be cheaper than writing temporary state to permanent storage. For a heavily used decentralized finance protocol, the design question includes both the cost for regular transactions and the protection the mechanism adds.
This material is prepared solely for informational purposes and does not constitute financial advice or a recommendation.




