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

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).

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

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.

No.

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.

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.

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.

• Stermi
• Certora

Audits of the previous protocol versions can be found here.

• Proposed changes
• Summary of changes
• Upgrade proposal

• 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.