This page talks about 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 loan enforcement and its terms are agreed upon between the depositor and borrowers, either off-chain via legal agreements or on-chain via smart contracts. This enables:
- The supplier (aka delegator) to earn an extra yield on top of the yield they already earn from the protocol,
- The borrowers (aka delegatees) access an un-collateralized loan.
Borrow by delegatee must be consistent with the delegator E-Mode category. For e.g., if a delegator E-Modecategory is
- delegator can only borrow
STABLECOINSE-Mode category asset.
- in case delegator approve credit to delegatee for non
STABLECOINScategory (for e.g. weth), then borrow would revert.
The delegatee cannot abuse credit approval to liquidate the delegator i.e., if the borrow puts delegator's position in HF <
HEALTH_FACTOR_LIQUIDATION_THRESHOLD, then borrow will fail.
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 the delegator in the protocol.
The borrower (delegatee) calls the
borrow()method on the
Pool, using the supplier's (delegator's) address in the final parameter
onBehalfOf.The borrower's available credit is reduced by the borrowed amount.
Anyone can repay the debt OnBehalf of the user by calling one of the methods -
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.