Add Aave Lending Deposit and Withdrawal With Delegation

[MoMannn]

What?

• Test on how to best use delegations to deposit / withdraw funds for Aave v3 protocol.

Why?

• Requested feature.

How?

• By leveraging existing caveat enforcers

Notes

• This PR includes a POC of the adapter that will be used for interacting with the Aave protocol. This adapter helps skip the ERC20 approval step and directly transfer ERC20 tokens using a delegation.

---

Note

High Risk
Introduces a new contract that moves/approves ERC-20s and executes Aave pool calls via delegation redemption, so mistakes could impact fund flow and authorization boundaries. While heavily tested, it’s still new onchain logic interacting with external protocol contracts.

Overview
Adds a new AaveAdapter contract to enable Aave v3 supply/withdraw via the delegation framework by redeeming a 2-step delegation chain (token/aToken transfer to adapter, then self-call into Aave), with strict execution-mode gating and an owner-only emergency token recovery path.

Introduces a full mainnet-fork Foundry test suite (AaveLending.t.sol) covering direct vs delegation flows, adapter-based deposit/withdraw across multiple tokens, and extensive event/error/edge-case coverage. Also adds IAavePool interface, a DeployAaveAdapter deployment script, documentation for “Delegation Adapters” (incl. Aave), and updates script/coverage.sh to run/merge coverage across EVM versions (London + Shanghai/Cancun-specific test selection).

^{Written by Cursor Bugbot for commit 4e28e7f. This will update automatically on new commits. Configure here.}

[hanzel98]

It is pending to validate if we prefer the simple withdrawByDelegation or withdrawByDelegationOpenEnded

If we decide that we want both options, then we need to unify the code to avoid code duplication and also apply the same approach to the other adapters.

[cursor]

Bug: Withdrawal Events Emit Incorrect Amount

The withdrawByDelegation and withdrawByDelegationOpenEnded functions incorrectly emit the WithdrawExecuted event with the requested _amount parameter. The aavePool.withdraw() function returns the actual amount withdrawn, which can differ from the requested amount (e.g., when type(uint256).max is used for full withdrawal). This leads to inaccurate event data.

src/helpers/AaveAdapter.sol#L186-L189

delegation-framework/src/helpers/AaveAdapter.sol

Lines 186 to 189 in 67a37fb

	// Withdraw from Aave directly to the delegator
	aavePool.withdraw(_token, _amount, msg.sender);
	emit WithdrawExecuted(msg.sender, msg.sender, _token, _amount);

src/helpers/AaveAdapter.sol#L217-L220

delegation-framework/src/helpers/AaveAdapter.sol

Lines 217 to 220 in 67a37fb

	// Withdraw from Aave directly to the delegator
	aavePool.withdraw(_token, _amount, _delegations[0].delegator);
	emit WithdrawExecuted(_delegations[0].delegator, msg.sender, _token, _amount);

Fix in Cursor

---

Bug: Allowance Overflow in SafeIncreaseAllowance

The _ensureAllowance function can cause an arithmetic overflow. If the current allowance is non-zero but insufficient, calling safeIncreaseAllowance with type(uint256).max will attempt currentAllowance + type(uint256).max, which overflows uint256 and reverts the transaction (due to Solidity 0.8+ overflow checks). This logical flaw, while unlikely in practice, can be resolved by using safeApprove to set the allowance directly to type(uint256).max or by calculating the precise increase amount.

src/helpers/AaveAdapter.sol#L93-L99

delegation-framework/src/helpers/AaveAdapter.sol

Lines 93 to 99 in 67a37fb

	/// @param _amount Amount needed for the operation
	function _ensureAllowance(IERC20 _token, uint256 _amount) private {
	uint256 allowance_ = _token.allowance(address(this), address(aavePool));
	if (allowance_ < _amount) {
	_token.safeIncreaseAllowance(address(aavePool), type(uint256).max);
	}
	}

Fix in Cursor

---

Was this report helpful? Give feedback by reacting with 👍 or 👎

[hanzel98]

This PR needs an RPC URL secret on github to work