Euler

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.

This module lets a particular privileged address update market configuration parameters, such as the TWAP intervals, borrow and collateral factors, and interest rate models. Eventually this logic will be enhanced to support EUL-token driven governance.

Every market has an EToken. This is the primary interface for the tokenisation of assets in the Euler protocol: - deposit: Transfer tokens from your wallet into Euler, and receive interest earning tokens in return. - withdraw: Redeem your ETokens for the underlying tokens, which are transfered from Euler to your wallet, along with any interest accrued. Additionally, ETokens provide an ERC-20 compliant interface which allows you to transfer and approve transfers of your ETokens, as is typical. Like Compound, but unlike AAVE, these tokens have static balances. That is, accrued interest will not cause the value returned from balanceOf to increase. Rather, that fixed balance entitles you to reclaim more and more of the underlying asset as time progresses. Although the AAVE model is conceptually nicer, experience has shown that increasing balance tokens causes a lot of pain to integrators. In particular, if you transfer X ETokens into a pool contract and later withdraw that same X, you have not earned any interest and the pool has some left over dust ETokens that typically aren't allocated to anyone. A downside of the Compound model is that the values returned from balanceOf are in internal bookkeeping units and don't really have any meaning to external users. There is of course a balanceOfUnderlying method (named the same as Compound's method, which may become a defacto standard) that returns the amount in terms of the underlying and does increase block to block.

This module allows you to activate new markets on the Euler protocol. Any token can be activated, as long as there exists a Uniswap 3 pair between it and the reference asset (WETH version 9 in the standard deployment, although any 18-decimal token could be used). It also allows you to enter/exit markets, which controls which of your ETokens are used as collateral for your debts. This terminology was chosen deliberately to match Compound's, since many of our users will be familiar with Compound already. Unlike Compound which keeps both an array and a mapping for each user, we only keep an array. Upon analysis we realised that almost every access to the mapping will be done inside a transaction that also scans through the array (usually as a liquidity check) so the mapping was (nearly) redundant and we thus could eliminate an SSTORE when entering a market. Furthermore, instead of a normal length-prefixed storage array, we store the length in a packed slot that is loaded for other reasons. This saves an additional SSTORE since we don't need to update the array length, and saves and SLOAD on every liquidity check (more important post Berlin fork). Taking it one step further, there is also an optimisation where the first entered market address is stored in a special variable that is packed together with this length. Finally, the markets module allows external users to query for market configuration parameters (ie collateral factors) and current states (ie interest rates).

Other than the proxies, contracts/Euler.sol is the only other code that cannot be upgraded. It is the implementation of the main Euler contract. Essentially its only job is to be a placeholder address for the Euler storage, and to delegatecall() to the appropriate modules. When it invokes a module, contracts/Euler.sol:dispatch() appends some extra data onto the end of the msg.data it receives from the proxy: - Its own view of msg.sender, which corresponds to the address of the proxy. - The msgSender passed in from the (trusted) proxy, which corresponds to the original msg.sender that invoked the proxy.

This is an internal module, meaning it is only called by other modules, and does not have a proxy entry point. RiskManager is called when a market is activated, to get the default risk parameters for a newly created market. Also, it is called after every operation that could affect a user's liquidity (withdrawal, borrow, transferring E/DTokens, exiting a market, etc) to ensure that no liquidity violations have occurred. This logic could be implemented in BaseLogic, and would be slightly more efficient if so, but then upgrading the risk parameters would require upgrading nearly every other module. In order to check liquidity, this module must retrieve prices of assets (see the Pricing section below).

This module allows users to swap their deposited underlying tokens on Uniswap V3 and 1inch DEXes. Under the hood, the tokens are swapped directly from the pool, thus saving gas, which would normally be spent to withdraw and deposit back the traded assets. From the user's perspective the swap will change the balances of their eTokens. Paired with deferred liquidity check (see below), the swap module allows users to put on one-click leveraged long and short positions on any collateral vs collateral asset pairs and one-click leveraged short positions on any collateral vs non-collateral pairs.

Staking on Euler is based on Synthetix’s staking contracts. This is an overhaul to Euler’s gauge system, which thanks to eIP 24 is modified from its previous iteration coming into effect with the arrival of Epoch 18. For the duration of the three month trial, 5000 EUL a month (for a total of 15000 EUL) will be distributed to users staking these assets: USDT, USDC and WETH. To stake an asset and receive some of the EUL being distributed, users should stake their eTokens into the staking contract. Should you please, you can immediately unstake your tokens at any time and the accrued EUL earnings will be instantly claimable. There is no lockup period for this staking process.