Credit Delegation

Credit delegation allows a depositor to deposit funds in the protocol to earn interest, and delegate borrowing power (i.e. their credit) to other users. The enforcement of the loan and its terms are agreed upon between the depositor and borrowers, which can be either off-chain via legal agreements or on-chain via smart contracts.
This enables:
The supplier (aka delegator) to earn extra yield on top of the yield they already earn from the protocol,
The borrowers (aka delegatees) to access an uncollateralized loan.
Borrow by delegatee must be consistent with delegator eMode category.
For eg. if a delegator eMode category is STABLECOINS, then
delegator can only borrow STABLECOINS eMode category asset.
in case delegator approve credit to delegatee for non STABLECOINScategory (for eg. weth), then borrow would revert.
The delegatee cannot abuse credit approval to liquidate delegator i.e. if the borrow puts delegator's position in HF < HEALTH_FACTOR_LIQUIDATION_THRESHOLD, then borrow will fail.
Approving the delegation
The approveDelegation() or delegationWithSig() must be called by the supplier (delegator), approving the borrower (delegatee) a certain amount.
This is done for each debt token that needs to be delegated.
The delegator does not need to already have supplied funds in the protocol to approveDelegation(). However, before the delegatee executes borrow(), there must be sufficient collateral supplied by delegator in the protocol.
Borrowing the credit
The borrower (delegatee) calls the borrow() method on the Pool, using the supplier's (delegator's) address in final parameter onBehalfOf.
The borrower's available credit is reduced by the borrowed amount.
Repaying the credit
Anyone can repay the debt OnBehalf of the user, by calling one of the methods - repay() or repayWithPermit(). The supplier (aka creditor) can also use repayWithATokens() method to repay debt with their aTokens of the underlying debt asset in the same pool.
Last modified 9mo ago