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

Medium Risk
Adds new adapter contracts that redeem delegation chains to move and approve tokens before calling external DeFi protocols (Aave/Morpho), so mistakes could impact funds flow despite comprehensive fork-based tests.

Overview
Adds Delegation Adapters for DeFi protocols that don’t natively support delegations, including a new AaveAdapter (supply/withdraw) and MorphoAdapter (ERC-4626 deposit/redeem) that redeem a delegation chain to atomically transfer tokens into the adapter, perform the protocol call, and direct outputs back to the root delegator.

Introduces supporting protocol interfaces (IAavePool, IMorphoVault), a DeployAaveAdapter Foundry script, and extensive mainnet-fork tests (AaveLending.t.sol, MorphoLending.t.sol) covering direct flows, adapter flows, events, and revert cases. Updates docs (README.md, new documents/Adapters.md) and enhances script/coverage.sh to run/merge coverage across EVM versions (London + Shanghai/Cancun-specific test subsets).

^{Written by Cursor Bugbot for commit 1ed69ec. 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

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

[cursor]

_ensureAllowance over-approves by adding instead of setting allowance

Medium Severity

_ensureAllowance calls safeIncreaseAllowance(spender, _amount) which adds _amount to the current allowance, resulting in allowance_ + _amount. The intent is to ensure the allowance is at least _amount, so the increase should be _amount - allowance_, or forceApprove could set it directly to _amount. While this works when the starting allowance is zero (normal flow), any residual allowance causes over-approval and risks arithmetic overflow with large _amount values. The same issue exists in MorphoAdapter._ensureAllowance.

Additional Locations (1)

• src/helpers/MorphoAdapter.sol#L172-L178

 

[cursor]

Duplicated adapter infrastructure across AaveAdapter and MorphoAdapter

Low Severity

MorphoAdapter and AaveAdapter share identical implementations of executeFromExecutor, withdrawEmergency, all error definitions, both modifiers (onlyDelegationManager, onlySelf), and the _ensureAllowance pattern. A shared base adapter contract would eliminate this duplication, reducing maintenance burden and the risk of inconsistent bug fixes across adapters.

Additional Locations (1)

• src/helpers/AaveAdapter.sol#L45-L332