Euler Governance

Every market also has a DToken. This is the primary interface for the tokenisation of debts in the Euler protocol: - borrow: If you have sufficient collateral, Euler sends you the underlying tokens and issues you a corresponding amount of debt tokens. - repay: Transfer tokens from your wallet in order to burn the DTokens, which reduces your debt obligation. DTokens also implement a partially ERC-20 compliant interface. Unlike AAVE, where these are non-transferrable, DTokens can be transferred. The permissioning logic is the opposite of ETokens: While you can send your ETokens to anyone without their permission, with DTokens you can "take" anybody else's DTokens without their permission (assuming you have sufficient collateral). Similarly, just as you can approve another address to take some amount of your ETokens, you can use approveDebt() to grant another account permission to send you some amount of DTokens. The approveDebt() name was used instead of the ERC-20 approve() due to concerns that some contracts might unintentionally allow themselves to receive "negative value" tokens. As well as providing a flexible platform for debt trading and assignment, this system also permits easy transferring of debt positions between sub-accounts (see below). Unlike ETokens, DToken balances do increase block-to-block as interest is accrued. This means that in order to pay off a loan in full, you should specify MAX_UINT256 as the amount to pay off, so that all interest accrued at the point the repay transaction is mined gets repaid. Note that most Euler methods accept this MAX_UINT256 value to indicate that the contract should determine the maximum amount you can deposit/withdraw/borrow/repay at the time the transaction is mined. In the code you will also see INTERNAL_DEBT_PRECISION. This is because DTokens are tracked at a greater precision versus ETokens (27 decimals versus 18) so that interest compounding is more accurate. However, to present a common external decimals amount, this internal precision is hidden from external users of the contract. Note that these decimal place amounts remain the same even if the underlying token uses fewer decimal places than 18 (see the Decimals Normalisation section below).

Borrowers must maintain sufficient collateral in order to support their borrows. In particular, each account must maintain a "health score" above 1. The health score is computed by dividing the account's risk-adjusted collateral value by its risk-adjusted liability value. Since the collateral factor decreases the effective value of the collateral, and the borrow factor increases the effective value of the liability, when the health score is 1, then the account is still technically solvent (assets are worth more than liability), but the account is said to be in "violation". When an account is in violation, the liquidate() method of the Liquidation module can be invoked by anyone (except by the violating account itself, to avoid aliasing bugs). The account invoking this method is called the "liquidator".

SwapHub is a generic swapping interface where users can select their desired swapping handler without any changes needed to Euler contracts. When a user invokes a swap, the input amount (or maximum input) is transferred to the handler contract. The handler contract should then perform the swap by whatever means it chooses, then transfer back any remaining input and all the output. SwapHub will ensure that the amounts returned satisfy the user's slippage settings and process the corresponding withdrawal and deposit on behalf of the user.