I have a few major complaints about lending markets and crypto-native stablecoins on Ethereum today —
They rely on trusted oracles using potentially manipulable near-realtime data to price loans and trigger liquidations
They are vulnerable to bank runs in the event of bad debt
Their governance processes are slow, inefficient, and do not scale. They can only offer a very limited number of loan terms and adjust parameters infrequently
They lack good ways to price liquidity, and have large amounts of idle capital which reduces yield for holders and drives up cost for borrowers
The solution to all four is related: a simple and robust mechanism for defining new lending terms, adjusting their credit limits, offboarding them if needed, initiating new borrowers, and calling extant loans.
You can see all the details of our work on Github. The core of the solution is as follows.
Holders of the GUILD governance token can propose new lending terms, which define:
collateral token
borrow token
collateral ratio (in terms of borrow token/collateral token)
interest rate
call fee (paid by whoever calls the loan, deducted from borrower debt)
call period (how long after loan is called borrower has to repay before liquidation)
debt ceiling (starts at zero)
expiration date (the last date at which these terms can be used to issue new loans)
If the proposal is not vetoed, then GUILD holders can vote for that lending term in the gauges to increase its debt ceiling. Borrowers can use any term with an available debt ceiling, depositing the appropriate collateral and minting CREDIT.
The system does not permit arbitrary code changes, only defined actions such as adjusting debt ceilings or offboarding an existing lending term.
When a loan is called, a borrower has a length of time known as the call period to repay their debt, which is reduced by the call fee to compensate them for this inconvenience. If they fail to do so, the loan can be liquidated.
We can envision automation tools being built on top of this core primitive, for example, a contract that automatically refinances loans if new terms are available. The core protocol is kept as simple as possible for security and cost reasons.
If an auction fails to repay the full debt, the loss is marked down internally in the protocol, such that the ratio between CREDIT circulating to units of debt remains constant. This means any bad debt is distributed uniformly among CREDIT holders, and it will be minted and redeemed at a discounted price from all lending terms. So long as risky assets have a shorter call period than the safest assets, this risk of bad debt that is unfairly distributed (vulnerable to runs) is very low.
I believe that this model eliminates the capital drag found in Compound or Aave style pools with large idle reserves, while also ensuring fair and rational pricing of liquidity demand. The downside is that lending is too complex for the average Compound or Aave user to participate in directly, but better to reveal the complexity than to hide it. Automation or intermediation layers can exist on top. The end result is:
higher rates for lenders (reduced spread)
lower and more predictable cost for borrowers
reduced governance risk (no arbitrary code changes)
no oracle risk (no oracles are used)
Next time, we’ll go into more detail about what the initial set of lending terms might look like, walk through some use cases and failure modes, and broach the subject of multiple denominations of credit token.