## Understanding Aave V3 Borrows: A Deep Dive into `onBehalfOf` and Credit Delegation Aave V3, a leading decentralized lending protocol, offers sophisticated features for borrowing assets. One of the key parameters enabling advanced functionalities like Credit Delegation is `onBehalfOf`. This lesson deconstructs an Aave V3 `borrow` transaction, specifically focusing on how `onBehalfOf` works, using insights from the Tenderly transaction debugger and Aave V3's source code. ## Transaction Deep Dive with Tenderly We begin by examining an example transaction where DAI was borrowed from Aave V3. The **Tenderly transaction debugger** is an invaluable tool for this, providing a comprehensive overview including a transaction summary, contracts interacted with, emitted events, state changes, and a gas profiler. In Tenderly's "Input and Output" section for the `borrow` function call, we find the following parameters: * `asset`: The contract address of the asset being borrowed. In our example, this is DAI (`0x6b175474e89094c44da98b954eedeac495271d0f`). * `amount`: The quantity of the asset to borrow. For instance, `100000000000000000000` represents 100 DAI, assuming 18 decimal places. * `interestRateMode`: Set to `2` in this transaction. * `referralCode`: Set to `0`. * `onBehalfOf`: In this specific transaction, this address is `0xd24cba...`, which is also the sender's address (`msg.sender`). This indicates the sender is borrowing for themselves. The `interestRateMode = 2` signifies a **Variable Debt** interest rate model. While previous Aave versions offered a stable debt model, Aave V3 primarily supports variable debt for new borrows. The `onBehalfOf` parameter is central to Aave's Credit Delegation feature. It allows a user (the `msg.sender` or "caller") to initiate a borrow transaction where the debt is attributed to another user (the `onBehalfOf` address). **Use Case: Credit Delegation** Imagine Alice wants to allow Bob to borrow against her collateral. 1. Alice (the delegator) first approves Bob (the delegatee) to take on debt on her behalf. 2. Bob then calls the `borrow` function. In this call: * `msg.sender` will be Bob's address. * `onBehalfOf` will be set to Alice's address. The outcome is that the debt obligation is assigned to Alice, while Bob, the `msg.sender`, receives the actual borrowed tokens. ## Tracing `onBehalfOf`: A Source Code Journey Let's trace the `onBehalfOf` parameter through the Aave V3 source code to understand its journey and impact. The initial `borrow` function is typically called on a proxy contract, often an `InitializableImmutableAdminUpgradeabilityProxy`, which then delegates the call to the underlying Aave `Pool` contract implementation. ### `Pool.sol` - The `borrow` Entry Point The `borrow` function within the `Pool.sol` contract serves as the primary entry point for borrowing operations. ```solidity // function borrow( // address asset, // uint256 amount, // uint256 interestRateMode, // uint16 referralCode, // address onBehalfOf // Address for whom the debt is being taken // ) public virtual override { // // ... // BorrowLogic.executeBorrow( // _reserves, // _reservesList, // _eModeCategories, // _usersConfig[onBehalfOf], // User configuration for the 'onBehalfOf' address // DataTypes.ExecuteBorrowParams({ // asset: asset, // user: msg.sender, // The actual caller of the function // onBehalfOf: onBehalfOf, // The address that will take on the debt // amount: amount, // interestRateMode: DataTypes.InterestRateMode(interestRateMode), // referralCode: referralCode, // releaseUnderlying: true, // Assumed true for typical borrows // // ... // }) // ); // } ``` Key observations: * The `onBehalfOf` parameter received from the initial transaction call is passed directly into the `DataTypes.ExecuteBorrowParams` struct. * Within this struct, `user` is explicitly set to `msg.sender` (the entity initiating the transaction, e.g., Bob in our credit delegation example). * The `onBehalfOf` field in the struct retains the value of the `onBehalfOf` parameter (the address that will accrue the debt, e.g., Alice). * The user configuration for the `onBehalfOf` address (`_usersConfig[onBehalfOf]`) is also passed to `BorrowLogic.executeBorrow`. ### `BorrowLogic.sol` - Core Borrowing Mechanics The `Pool` contract delegates the core borrowing logic to the `BorrowLogic.sol` library. This library's `executeBorrow` function orchestrates the necessary state updates and interactions. ```solidity // function executeBorrow( // // ... // DataTypes.UserConfigurationMap storage userConfig, // DataTypes.ExecuteBorrowParams memory params // ) external { // // ... (Updates state, validates borrow) // // (bool isFirstBorrowing, reserveCache.nextScaledVariableDebt) = IVariableDebtToken( // reserveCache.variableDebtTokenAddress // ).mint(params.user, params.onBehalfOf, params.amount, reserveCache.nextVariableBorrowIndex); // // // ... (Updates interest rates and virtual balances) // // if (params.releaseUnderlying) { // IAToken(reserveCache.aTokenAddress).transferUnderlyingTo(params.user, params.amount); // } // // ... // } ``` In `executeBorrow`: * The `IVariableDebtToken.mint` function is called on the relevant variable debt token contract. Notice the arguments: * The first argument is `params.user` (which is `msg.sender`, e.g., Bob). * The second argument is `params.onBehalfOf` (the address that will accrue the debt, e.g., Alice). * If `params.releaseUnderlying` is true (typical for standard borrows), the underlying borrowed tokens are transferred to `params.user` (`msg.sender`) via `IAToken(...).transferUnderlyingTo(params.user, params.amount)`. This means Bob receives the DAI. ### `VariableDebtToken.sol` - Minting Debt The `mint` function within `VariableDebtToken.sol` (which implements the `IVariableDebtToken` interface) handles the creation of debt tokens. ```solidity // function mint( // address user, // The msg.sender (e.g., Bob) // address onBehalfOf, // The address taking the debt (e.g., Alice) // uint256 amount, // uint256 index // ) external virtual override onlyPool returns (bool, uint256) { // if (user != onBehalfOf) { // // This is the credit delegation case // _decreaseBorrowAllowance(onBehalfOf, user, amount); // } // return _mintScaled(user, onBehalfOf, amount, index, scaledTotalSupply()); // } ``` Here: * The parameters `user` and `onBehalfOf` correspond to `params.user` and `params.onBehalfOf` from `BorrowLogic.executeBorrow`. * A critical check: `if (user != onBehalfOf)`. If true, it signifies a credit delegation scenario (e.g., Bob borrowing on Alice's behalf). In this case, the `_decreaseBorrowAllowance` function is called. * Subsequently, `_mintScaled` is called, passing along `user`, `onBehalfOf`, and `amount`. ### `DebtTokenBase.sol` - Managing Credit Delegation Allowances The `_decreaseBorrowAllowance` function, typically found in a base contract like `DebtTokenBase.sol`, is integral to the credit delegation mechanism. ```solidity // function _decreaseBorrowAllowance(address delegator, address delegatee, uint256 amount) internal { // // delegator is 'onBehalfOf' (e.g., Alice) // // delegatee is 'user' (e.g., Bob, the msg.sender) // uint256 newAllowance = _borrowAllowances[delegator][delegatee] - amount; // _borrowAllowances[delegator][delegatee] = newAllowance; // // ... // } ``` This function reduces the pre-approved borrowing allowance that the `delegator` (Alice, the `onBehalfOf` address) has granted to the `delegatee` (Bob, the `user`/`msg.sender`). ### `ScaledBalanceTokenBase.sol` - Attributing Debt The `_mintScaled` function, often part of `ScaledBalanceTokenBase.sol` (a base for token contracts that handle scaled balances, like debt tokens), is responsible for the actual minting of debt tokens. ```solidity // function _mintScaled( // address caller, // 'user' (e.g., Bob, the msg.sender) // address onBehalfOf, // 'onBehalfOf' (e.g., Alice) // uint256 amount, // uint256 index // ) internal returns (bool) { // // ... (calculates amountScaled) // // _mint(onBehalfOf, amountScaled.toUint128()); // Debt token is minted to 'onBehalfOf' (Alice) // // // ... (updates user state for 'onBehalfOf') // // ... (emits Mint event with 'caller', 'onBehalfOf', etc.) // return (scaledBalance == 0); // Returns if it was the first mint for this user // } ``` The most crucial line here is `_mint(onBehalfOf, amountScaled.toUint128())`. The internal `_mint` function, which performs the token creation, is called with `onBehalfOf` as the recipient. This means **the debt tokens are minted to the `onBehalfOf` address (Alice), making her responsible for the debt.** The `caller` argument (Bob, `msg.sender`) is used for event emission and potentially other logic, but the debt itself is associated with `onBehalfOf`. ## Connecting Code to the Tenderly Call Trace The Tenderly call trace visually represents this flow: 1. **`InitializableImmutableAdminUpgradeabilityProxy.borrow(...)`**: The transaction's initial call hits the proxy contract. 2. **`PoolInstance.borrow(...)`**: The proxy delegates the call to the `Pool` implementation contract. 3. **`BorrowLogic.executeBorrow(...)`**: The `Pool` contract invokes the `executeBorrow` function in the `BorrowLogic` library. * Internal calls within `executeBorrow` include: * `BorrowLogic.cache(reserve = ...)`: Caches reserve data in memory to optimize gas for subsequent reads. * `BorrowLogic.updateState(...)`: Updates liquidity and borrow indexes for the reserve. * `BorrowLogic.validateBorrow(...)`: Performs checks to ensure the borrow is permissible (e.g., sufficient collateral, not exceeding borrow caps). * **`InitializableImmutableAdminUpgradeabilityProxy.mint(user = 0xd24cba..., onBehalfOf = 0xd24cba..., amount = ...)`**: This reflects the call to the `VariableDebtToken`'s `mint` function. * The `user` parameter here is `params.user` from `BorrowLogic` (i.e., `msg.sender`). * The `onBehalfOf` parameter is `params.onBehalfOf` from `BorrowLogic`. * In the Tenderly example where the sender borrows for themselves, `user` and `onBehalfOf` are identical. In a credit delegation scenario, `user` would be the delegatee (Bob), and `onBehalfOf` would be the delegator (Alice). The debt token is minted to the `onBehalfOf` address. * **`InitializableImmutableAdminUpgradeabilityProxy.transferUnderlyingTo(target = 0xd24cba..., amount = ...)`**: This shows the call to the `AToken`'s `transferUnderlyingTo` function. * The `target` parameter is `params.user` from `BorrowLogic` (i.e., `msg.sender`). * This transfers the actual borrowed underlying asset (e.g., DAI) to the `msg.sender`. * `BorrowLogic.updateInterestRatesAndVirtualBalance(...)`: Final state updates post-borrow. ## Key Aave V3 Concepts in Action This transaction flow highlights several important Aave V3 architectural patterns and concepts: * **Proxy Pattern**: Aave V3's `Pool` contract utilizes an upgradeable proxy (`InitializableImmutableAdminUpgradeabilityProxy`) allowing for logic updates without changing the main contract address. The actual business logic resides in an implementation contract (e.g., `PoolInstance`). * **Library Contracts**: `BorrowLogic.sol` is a prime example of a library contract. It encapsulates reusable borrowing logic, promoting modularity, cleaner main contracts, and helping to manage contract size limits. * **Debt Tokens (VariableDebtToken)**: These are ERC20-compliant tokens representing a user's outstanding debt for a specific asset. Crucially, they are minted to the `onBehalfOf` address, signifying that this address is responsible for repaying the debt. * **ATokens**: These are interest-bearing ERC20 tokens representing a user's supplied liquidity or collateral in Aave. In the borrowing process, the `AToken` contract facilitates the transfer of the borrowed underlying asset to the `msg.sender` (the `user` who initiated the borrow). * **Credit Delegation**: This powerful feature is enabled by the `onBehalfOf` parameter. * It allows a **delegator** (the `onBehalfOf` address, e.g., Alice) to grant another user, the **delegatee** (the `msg.sender`/`user`, e.g., Bob), permission to borrow against the delegator's collateral. * The **delegator (`onBehalfOf`) accrues the debt** (receives the debt tokens). * The **delegatee (`msg.sender`/`user`) receives the borrowed underlying assets.** * This process requires prior approval from the delegator to the delegatee. Alice would typically call a function like `approveDelegation` on the specific Variable Debt Token contract, granting Bob a borrow allowance. The `_decreaseBorrowAllowance` function, seen in `VariableDebtToken.sol` or its base, consumes this pre-approved allowance during Bob's borrow transaction. ## Aave V3 Borrowing: Best Practices and Notes * **Gas Optimization**: The `BorrowLogic.cache` step is a common optimization pattern. Loading necessary state variables (like reserve data) into memory at the beginning of a complex function can significantly reduce gas costs by avoiding multiple expensive SLOAD operations. * **Aave V3 Debt Models**: It's important to remember that for new borrows initiated in Aave V3, only the variable interest rate model is generally available. ## Credit Delegation Example: Alice and Bob Let's crystallize the credit delegation flow: 1. **Alice (Delegator)** possesses collateral in Aave and wishes to allow Bob (Delegatee) to borrow 100 DAI against it. 2. Alice calls the `approveDelegation` function (or a similar approval function) on the Variable Debt DAI token contract, specifying Bob's address and an allowance (e.g., 100 DAI or more). 3. **Bob (Delegatee)** initiates the borrow by calling `Pool.borrow()` with the following parameters: * `asset`: Address of DAI. * `amount`: 100 DAI (in wei). * `interestRateMode`: `2` (Variable). * `referralCode`: `0` (or a referral code). * `onBehalfOf`: Alice's address. 4. **Transaction Execution**: * `msg.sender` within the transaction context will be Bob's address. * The Aave protocol verifies Alice's approval for Bob. * Variable Debt DAI tokens (representing the 100 DAI debt) are minted to **Alice's address**. * 100 DAI (the actual underlying tokens) are transferred to **Bob's address**. * Alice's borrowing allowance previously granted to Bob is reduced by 100 DAI. This detailed examination clarifies how Aave V3 meticulously handles borrow operations, particularly leveraging the `onBehalfOf` parameter to enable sophisticated features like Credit Delegation. This ensures precise debt attribution while offering users flexibility in managing their DeFi interactions.