Aave V3.3 contest details

• Join Sherlock Discord
• Submit findings using the issue page in your private contest repo (label issues as med or high)
• Read for more details

Q&A

Q: On what chains are the smart contracts going to be deployed?

Ethereum, Base, Arbitrum, Avalanche, Optimism, Polygon, Metis, Gnosis, BNB Chain, Scroll, Zksync Era

---

Q: If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?

Aave only allows whitelisted tokens, that by design should not have “weird” traits, like ERC777, or activated fee-on-transfer, amongst others. This “whitelisting” is applied before the listing happens via on-chain governance, with a technical pre-analysis performed by development teams contributing to the Aave protocol. Exceptions are managed ad-hoc like it can be the case of USDT (with theoretically potential fee-on-transfer).

---

Q: Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?

All permissioned entities are trusted (Owner, Admin, Umbrella).

---

Q: Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?

We assume protocols the codebase has as dependencies (e.g. Chainlink, assets listed themselves) behave non-maliciously, and its fundamentals don’t change, for example, by upgrading proxies to any breaking implementation.

---

Q: Is the codebase expected to comply with any specific EIPs?

No.

---

Q: Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.

Nothing within the context of Aave v3.3, aside from external entities like the Chainlink price feeds, which are assumed to function and not miss-behave.

---

Q: What properties/invariants do you want to hold even if breaking them has a low/unknown impact?

Apart from all the extra information in this document, a list of properties of the system can be found in the Aave-v3.3-properties file in the repository.

---

Q: Please discuss any design choices you made.

As Aave v3.3 is an upgrade on top of Aave v3.2, special care was taken to not break any existing integrations.

Some debatable compromises are being made in the upgrade:

1. Deficit is handled differently for GHO than for any other asset. The reason for this inconsistent behavior is discussed in the audit performed by StErMi. The alternatives would have required different compromises and/or an upgrade of vGHO/aGHO which we did not want to include in an upgrade.
2. An edge case is being introduced in which liquidating uint256.max would revert instead of liquidating max, as described in the Certora audit. The decision was taken to accept this minor UX issue as it can only appear in edge case scenarios, and the solution would have required extensive changes on liquidationLogic.
3. Clearing the bad debt as a result of a liquidation increases the gas cost ~linearly with every additional debt asset. To keep gas costs under control, the bad debt cleanup will not clear the borrower’s collateral positions. Note: the bad debt cleanup will only be performed when the borrower’s collateral positions are nonexistent or worth less than 1 base unit.

A full description of the design on v3.3 can be found in the Aave-v3.3-features file on the repository.

---

Q: Please provide links to previous audits (if any).

• Stermi
• Certora

Audits of the previous protocol versions can be found here.

---

Q: Please list any relevant protocol resources.

• Proposed changes
• Summary of changes
• Upgrade proposal

---

Q: Additional audit information.

• The exact project scope is reflected on the sherlock scope page. The v3.3 pr on the aave-v3-origin repository includes additional helpers and tests, which are not included in the scope

• The Aave protocol has a working system of liquidations, the goal of this contest is to detect any problem that could:

  1. Create any type of loss of funds for the protocol itself caused by the new logic.
  2. Create a situation in which a position that should be liquidated can no longer be liquidated
  3. Allow a user position to reach an inconsistent state (e.g. having borrowing enabled, but no more borrow position, disabling collateral while not respecting Health Factor validations, …). Anything that creates a meaningful danger to the system.

• Some extra assumptions and limitations:

  • Liquidators would potentially need to adapt their infrastructure, a consequence we think is legitimate given their “user” profile of the protocol, seeking profit and optimization.
  • This contest is about v3.3 new logic. Any type of issue existing on any part of the Aave protocol with no influence from the new contest will not be considered valid here and should be reported on the running Aave Immunefi bug bounty program.

---

Audit scope

aave-v3-origin @ ad00e17d3f733f22bd006fd3b4adcfa91467811d

• aave-v3-origin/src/contracts/helpers/AaveProtocolDataProvider.sol
• aave-v3-origin/src/contracts/helpers/WrappedTokenGatewayV3.sol
• aave-v3-origin/src/contracts/protocol/libraries/configuration/ReserveConfiguration.sol
• aave-v3-origin/src/contracts/protocol/libraries/logic/BorrowLogic.sol
• aave-v3-origin/src/contracts/protocol/libraries/logic/BridgeLogic.sol
• aave-v3-origin/src/contracts/protocol/libraries/logic/ConfiguratorLogic.sol
• aave-v3-origin/src/contracts/protocol/libraries/logic/LiquidationLogic.sol
• aave-v3-origin/src/contracts/protocol/libraries/logic/ReserveLogic.sol
• aave-v3-origin/src/contracts/protocol/libraries/logic/ValidationLogic.sol
• aave-v3-origin/src/contracts/protocol/libraries/types/DataTypes.sol
• aave-v3-origin/src/contracts/protocol/pool/Pool.sol