Low Findings
oracle_base::only_risk_or_pool_admin auth logic is wrong
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
By looking at the same function _onlyAssetListingOrPoolAdmins in the Solidity codebase, we can see that the users that should be able to call the function protected by this auth function are the ones with the role "asset listing admin" and "pool admin". On the Aptos implementation instead, we have that: • "Risk admin" are allowed. • "Asset listing admin" are not allowed.
price_cap_stable_adapter implementation is incompatible with the requirements
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
The price_cap_stable_adapter should mimic the implementation of the PriceCapAdapterStable contract. The scope of such a contract is to cap the price of the USD pegged assets, and it's currently used in the Aave ecosystem when Aave needs to fetch the prices of tokens like USDC (and other USD pegged assets). This is, for example, the asset price source used for USDC in the AaveOracle contract deployed on Ethereum Mainnet: 0x736bf902680e68989886e9807cd7db4b3e015d3c. The current implementation and usage of price_cap_stable_adapter is incompatible with the requirements and needs and requires a full refactor of the logic and data structure.
ISOLATED_COLLATERAL_SUPPLIER_ROLE validate_automatic_use_as_collateral logic does not
work
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
In Aave's Solidity implementation, the validation_logic::validate_automatic_use_as_collateral function checks whether the msg.sender has the ISOLATED_COLLATERAL_SUPPLIER_ROLE. (As the logic contracts are delegatecalled, the msg.sender is for example the Pool contract). The purpose of the role is for migration contracts to be able to set collateral flags on behalf of users when dealing with isolated assets.
set_reserve_interest_rate_strategy should perform additional sanity checks on the input parameters
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
The set_reserve_interest_rate_strategy logic is currently only performing a sanity check on the optimal_usage_ratio input parameter. Following the logic applied by DefaultReserveInterestRateStrategyV2, the set_reserve_interest_rate_- strategy should also implement the following required sanity checks: • optimal_usage_ratio <= MAX_OPTIMAL_POINT. • optimal_usage_ratio >= MIN_OPTIMAL_POINT. • variable_rate_slope1 <= variable_rate_slope2. • base_variable_borrow_rate + variable_rate_slope1 + variable_rate_slope2 <= MAX_BORROW_RATE. On solidity, the above constant values (used as lower/upper bounds) are defined as follows: • uint256 public constant MAX_BORROW_RATE = 1000_00;. • uint256 public constant MIN_OPTIMAL_POINT = 1_00;. • uint256 public constant MAX_OPTIMAL_POINT = 99_00;. Note that in Solidity, the above constant values are expressed in bps and must be converted into the format used by the Aptos implementation (RAY).
validate_flashloan_complex is not reverting when the list of assets have duplicates
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
The validate_flashloan_complex is missing a sanity check introduced Aave v3.1.0 (see ValidationLogic.sol#L338-L340) that requires the uniqueness of the asset requested to be flashloaned. This check should be added to the Aptos implementation.
pool_configurator module should expose a getter function for the pending_ltv value of a reserve
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
The pool_configurator module defines the pending_ltv in the Global Storage.
In the Solidity implementation, it's possible to fetch such information for a specific asset via the getPendingLtv(address asset) function. This feature is not available in the Aptos codebase and should be implemented.
finalize_transfer should use the scaled_amount and not amount
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
The current implementation of pool_token_logic::finalize_transfer performs the transfer validation and user config updates if the amount is greater than zero. This logic has been correctly changed in the Aave Solidity Implementation (see SupplyLogic.sol#L191-L193) to not rely on the non-scaled amount but on the scaled one. While amount could be greater than zero (the one specified by the user), the transfer operation transfers from an account to another the scaled version of that amount, that could be equal to zero because of rounding down. To avoid any possible errors and unexpected behaviors, the Aptos implementation should be aligned to the Solidity one.
Aave Reward System Management, documentation and concerns(further review)
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Periphery
Auditor: Spearbit
Report:
Report Date: Jun 2025
Description:
On Aave Protocol EVM, the Reward system is currently configured as follows: each reward has its own TransferStrategy which will transfer the rewards (depending on the strategy itself) from a specific REWARDS_- VAULT. From the research done by Spearbit for Aave Reward system on the Ethereum Mainnet, every configured reward uses the same deployed PullRewardsTransferStrategy that will pull from the same REWARDS_VAULT. The REWARDS_VAULT configured is the "ACI multisig address" 0xac140648435d03f784879cd789130F22Ef588Fcd, which in practice can be considered a Smart Wallet. We assume that, on Solidity, the ACI multisig will provide just the allowance needed by the PullRewardsTransferStrategy to correctly limit what an external source (like the strategy) can pull in case of a problem/hack. • Problem 1: lack of proper explanation and documentation relative to the rewards_vault: On the Aptos side, we only know what has been provided as a "dev comment" on top of the rewards_vault attribute itself.
Wrong bounds check in rewards_controller::update_reward_data
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Periphery
Auditor: Spearbit
Report:
Report Date: Jun 2025
Description:
The rewards_controller::update_reward_data function wants to assert that the new_index fits into 104 bits (to align with the Solidity implementation).
However, it performs a wrong bounds check, the MAX_U104 is 2 ** 104 - 1, not 2 ** 104.
default_reserve_interest_rate_strategy should be based on the logic from Solidity DefaultReserveInterestRateStrategyV2
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.1-3.3 Core
Auditor: Spearbit
Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Core V3.1-V3.3 Report.pdf
Report Date: Jun 2025
Description:
The current implementation of aave_rate::default_reserve_interest_rate_strategy is based on the deprecated DefaultReserveInterestRateStrategy from Aave V3.0.2. Given that most of the Aptos code has been moved to Aave V3.3, the same upgrade should also apply to upgrade the logic of the interest rate strategy to the new DefaultReserveInterestRateStrategyV2.
validate_flashloan_simple misses a sanity check introduced by Aave V3.3
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.1-3.3 Core
Auditor: Spearbit
Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Core V3.1-V3.3 Report.pdf
Report Date: Jun 2025
Description:
The validateFlashloanSimple function on Aave V3.3 reverts if the requested amount is greater than the aToken.totalSupply() (see ValidationLogic.sol#L357-L361).
This sanity check is not performed in the Aptos public fun validate_flashloan_simple.
validate_borrow misses a sanity check introduced by Aave V3.1
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.1-3.3 Core
Auditor: Spearbit
Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Core V3.1-V3.3 Report.pdf
Report Date: Jun 2025
Description:
The Aave V3.1 release has introduced an additional sanity check on the borrow amount requested by the caller (see ValidationLogic.sol#L154-L158)
This sanity check is not performed in the Aptos validate_borrow function.
set_reserve_freeze does not revert when the reserve is already in the desired state
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.1-3.3 Core
Auditor: Spearbit
Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Core V3.1-V3.3 Report.pdf
Report Date: Jun 2025
Description:
The current implementation of pool_configurator::set_reserve_freeze is not reverting when the state of the reserve is equal to the freeze input parameter. This issue has been already reported and addressed on the Aave Solidity Implementation codebase (see Cantinacontest-AaveV3.1 and should also be replicated on the Aptos codebase.
Full removal of the admin_controlled_ecosystem_reserve
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.1-3.3 Core
Auditor: Spearbit
Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Spearbit Aave Aptos Core V3.1-V3.3 Report.pdf
Report Date: Jun 2025
Description:
By looking at the Aave V3.3 codebase in GitHub relative to the Treasury management, we can see that the "old" AdminControlledEcosystemReserve contract has been fully removed. From our own research, such a contract is not used anymore within the Aave ecosystem, and the removal from the codebase is validating our hypothesis. On every EVM chain, the AToken treasury is deployed as a Collector contract, and the REWARDS_ VAULT of the PullRewardsTransferStrategy contract is configured as the "ACI multisig address" 0xac140648435d03f784879cd789130F22Ef588Fcd. Given all these facts, we think that the aave_pool::admin_controlled_ecosystem_reserve should be fully removed from the Aave Aptos Implementation codebase.