Decentralizing Credit 103
scaling lending without deferring to trusted third parties
Last time, we discussed how the governance token GUILD is issued and redeemed through a LendingTerm in a similar manner to the CREDIT token, and some special types of lending terms such as swaps and bonds.
This article is about scaling, which we’ll cover in three sections.
Reducing coordination costs in governance
In our basic model, a GUILD holder votes in gauges for one or more lending terms, and earns yield whenever interest is paid on a loan originated under a term they voted for. This means that if a holder votes for a term that is never utilized, they waste gas and forgo yield they might otherwise have earned. For a large holder, gas costs are not a huge obstacle, so they can switch to a LendingTerm which has high utilization as needed. For small holders, this is likely to be cost-prohibitive.
We already have an in protocol mechanism for delegation, the GUILD minting which was described in the previous article. Users can require a delegate to post a collateral of their choice, and pay an interest rate in GUILD reflecting their staking returns.
One of the add-ons we’d like to include on top of the core mechanism is a good way for borrowers to signal to GUILD holders when they are looking for additional liquidity under a certain term. This might be an onchain borrow order, or a signed message.
Another possibility is that instead of directly voting for a LendingTerm, a GUILD holder could instead sign votes for several, and allow a borrower to post the message onchain and pull liquidity to whichever of them they want to utilize, first come, first served.
Expanding access to CREDIT tokens
There are three main directions to reduce the cost of buying and selling CREDIT for small holders:
provide liquidity on optimistic rollups
batch transactions with a zk rollup
onboard CREDIT to centralized exchanges
The first and easiest of these is providing CREDIT liquidity on AMMs on Optimism and Arbitrum. We (the Electric Development Company which is developing the Ethereum Credit Guild) can provide a small amount of seed liquidity, and then if there is enough demand to cause a premium on L2, it should be profitable for others to participate in arbitrage. To enhance this possibility further, we could allow LP positions from L2 to be used as collateral to mint CREDIT or GUILD. More on this in the next section about scaling borrowing.
Zk rollups like the recently deprecated Aztec Connect have an advantage in that they can access mainnet liquidity. While they don’t yet have the traction of their optimistic counterparts, maintaining only a single set of contracts and unified liquidity has natural appeal.
Finally, while we are decentralists, we must recognize that most users will benefit from cryptofinancial tools through some level of intermediation. Yield bearing assets with credibly neutral onchain governance offered on a centralized exchange would be a far cry better than the likes of Celsius or Gemini Earn. This may also include trust minimized, but white glove systems like Base, where users access smart contract tools through an interface maintained by an exchange or other party with existing reputation and clientele. To quote their website, “Seamless Coinbase integrations, easy fiat onramps, and access to the Coinbase ecosystem, which has 110m verified users and $80B+ assets on platform.”
Scaling Borrower Access
Allowing CREDIT tokens to be minted or redeemed on L2 against volatile collateral assets is a different matter from providing liquidity. If the rollup in question experiences downtime, whether through a software error or an attack, it may be impossible to successfully liquidate positions through forced transactions on mainnet.
That said, no downtime can last forever, so what this means is that lending terms on a rollup with higher risk of downtime than Ethereum must have smaller debt ceilings and more conservative collateralization requirements to match.
We can add a cross-layer lending term to our special terms collection, where voting still occurs on the mainnet gauges, but CREDIT allocated to the debt ceiling of a given term is bridged to the appropriate network, and the GUILD holders voting for it also have the ability to recall it from that network when they wish to unstake provided liquidity is available.
The other type of borrower scaling to consider is simplifying the UX. Most people don’t want to run bots to monitor for their loans being called, and if a lot of people are borrowing under the same terms and need to roll over, it’s inefficient for them all to do this individually. A borrower vault might help to solve this problem. A vault is built on top of the core protocol and would not need to be entirely trustless.
Consider the following example OUSG vault which might read in the oracle feed for OUSG price.
Collateral asset: OUSG
Target collateralization: 104%
Maximum interest rate: 4.25%
The vault will rebalance if:
a
LendingTermbecomes available offering better collateralization or interest rate than the vault is currently usingany of the currently utilized loans are called, in which case it will refinance if possible and deleverage if not
enough users have deposited or withdrawn OUSG that the vault is above or below its target collateralization
This way, lenders aren’t trusting an oracle to price loans or process liquidations, but borrowers can still benefit from automation tools to decide at which rates they are willing to borrow, and when they should open or close a position.
Next time we will cover launch plans, the initial set of lending terms (including initial feedback I have received about call periods, rates, and so on) and how prospective GUILD holders might go about pricing loans.