Introduction
the why and how of trust minimized pooled lending
Last updated
the why and how of trust minimized pooled lending
Last updated
The Ethereum Credit Guild is a collective dedicated to building trust minimized lending and borrowing tools for use on Ethereum and its L2s. Credit v1 is deployed on Arbitrum One, with support for Ethereum mainnet and other high quality rollups planned for the near future.
Credit v1 was designed to overcome the problems that existing onchain lending pools face, such as reliance on manipulable oracle price feeds, incentive misalignment and voter apathy in governance, and bank run risk.
This page provides an overview of how to use the protocol and its advantages compared to earlier lending pools.
Lending on Credit is simple – users provide an asset, like USDC or WETH, and use it to mint the corresponding gToken and, if it’s their first time minting, enter the savings rate.
A gToken represents an asset that is being lent out on the Credit Guild. The number following the gToken name is a market ID – each pool has a unique ID reflecting its order of deployment. In the future, it’s possible Credit will have more than one pool where users can lend the same asset, but for now there is just one for each lending asset. gWETH-3, pictured above, is the lending pool on Credit for Ether, which uses wrapped Ether tokens (WETH).
When borrowers pay interest, it is streamed to gToken holders, minus the shares that go to Stakers and the surplus buffer (currently, 5% each, so 90% of interest goes to lenders). gToken holders who have entered the savings rate will see their gToken balance increase.
For example, if there are 1,000 gWETH3 tokens total, you are holding 10 of them, and borrowers pay 100 gWETH-3 in interest, your balance will increase to 11 gWETH-3 over the distribution period of 30 days.
One gToken corresponds to one unit of the underlying token, unless bad debt occurs and the exchange rate is marked down accordingly. Today’s largest lending protocols like Aave, Compound, and MakerDAO have no way to mark down bad debt, meaning that if a loss occurs greater than the reserves, there is a bank run risk where the first out get the full value of their deposit, while those who are too slow could be stuck with nothing. Proper bad debt markdown removes this risk.
Users can usually redeem their gTokens for the underlying at any time. There are two exceptions:
When there is not enough liquidity to redeem, because most of the available supply has been borrowed. In this case, users must wait until either loans are repaid, or new mints occur.
While a liquidation auction is in progress. Redemptions are paused while liquidation auctions are underway so that sophisticated actors cannot front-run bad debt events at the expense of passive lenders.
gToken holders have veto rights over governance proposals in the protocol, and can delegate this power to chosen representatives.
To borrow on Credit v1, a user first selects their desired lending term. A lending term contains all the information for the loan, including collateral asset, borrow ratio (how many debt tokens can be borrowed per collateral token), interest rate, which auction house the loan will use, hard cap (the maximum debt allowed under that term) and some other optional parameters. Note that there can be numerous lending terms available for a given collateral asset.
Each loan is handled separately for the purposes of interest rate calculation and liquidation. To open a loan, the borrower supplies the desired amount of collateral and mints an amount of gTokens less than the maximum, which they then redeem to access the underlying asset. By using flash loans, borrowers can conveniently loop their position to reach the desired amount of leverage. Read here to learn more about how debt accounting works on Credit v1.
There are two situations in which a loan on Credit v1 can be liquidated :
The debt exceeds the maximum level allowed by the lending term due to accrued interest. It’s wise to leave a safety margin when opening a new loan proportional to how long you plan to keep the position open.
A quorum of GUILD holders votes to offboard the lending term, in which case all loans under that term proceed to liquidation auction.
Unlike most lending protocols, there is no fixed liquidation penalty on Credit v1. A competitive auction-based liquidation system means that instead of charging a fixed 5-10% fee to borrowers upon liquidation, the expected liquidation penalty is equal to the slippage of selling enough collateral to repay the debt, plus the DEX swap fee, gas cost, and a small liquidator premium on top. For many collateral types, the liquidation cost is likely to be less than 1%.
Since Credit is oracle-free and uses auctions for liquidation, borrowers don’t risk being liquidated at below-market prices due to oracle manipulation attacks, and the protocol can support a wider variety of collateral than other markets.
Protocol liquidity is allocated among the different lending terms by stakers. Users can stake either the protocol governance token GUILD, or gTokens. The debt ceiling of a given lending term is proportional to the amount of tokens staked on it, with a tolerance that gives wiggle room for the protocol to grow smoothly and avoid idle liquidity.
Stakers earn a share of the interest paid by borrowers on the terms they stake on (currently, 5% of total interest), and will be slashed if there is any loss on the term they vote for. Keep in mind that slashing is total if any bad debt occurs, so stakers have a strong incentive to vote responsibly.
A user can stake at any time, and can unstake unless the liquidity on that lending term is in use. If the lending term’s debt ceiling has been used up, stakers must wait for borrowers to repay loans or new users to stake. Alternatively, they can offboard the lending term if enough GUILD holders agree.
Allowing different risk tolerances to exist in governance with skin in the game avoids the tragedies of the commons that exist in traditional onchain governance models.
