Decentralizing Credit 105
protocol launch plans, L2 instances, and risk isolation
Last time, we finished our introduction to how the CREDIT system works. This article will discuss considerations around lending terms in the early period, how the Ethereum Credit Guild will work on L2, and the possibility of diverse instances of the protocol specialized in handling certain collateral types or risk profiles.
Launch Lending Terms
At launch, there should be a low debt ceiling for CREDIT to minimize harm in case of smart contract vulnerabilities, which can be raised according to the votes of the GUILD holders after a suitable period of time has passed (say, one to three months).
There is an ongoing request for proposals regarding initial lending terms. The main categories of note are:
ETH and staked ETH
tokenized bonds (see the Dune dashboards for Backed Finance, Ondo by Steakhouse)
fiat stablecoins, especially stablecoin/CREDIT LP pairs
The ability of the protocol to flexibly offer a wide variety of lending terms for a given asset, duration, and collateralization will allow for more competitive lending terms against these high quality collateral assets than is available on other DeFi protocols.
In general, I do not think it is a good idea for the ECG to accept external deposit receipt or synthetic debt tokens as collateral, unless they have immutable code and robust controls against bad debt and oracle manipulation. This rules out the majority of DeFi stablecoins or lending market deposit tokens, while Uniswap LP positions and the like can be useful collateral.
It is an unfortunate reality that there is limited institutional and geographic diversity in fiat stablecoin issuers and tokenized asset custodians, but the situation can only improve with time. The ECG should endeavor to minimize single-custodian risk for real world assets and fiat stablecoins, while accepting the importance of ample decentralized exchange liquidity in fiat stablecoin pairs and the use of crypto rails to finance real world debt and investments.
Layer Two Lending Guilds
There is no way to ensure synchronous state across multiple L2 instances of a protocol. A fungible debt unit with shared state across layers is fundamentally vulnerable to bad debt. The natural conclusion is to have separate immutable instances of the protocol on distinct layers. The CREDIT tokens of each can be mutually accepted as collateral to unify liquidity with overcollateralization to account for latency risk.
Consider the possibility of the Arbitrum Credit Guild, Optimism Credit Guild, and Ethereum Credit Guild. GUILD holders might bridge to and stake in any of the three to vote on lending terms in the gauges. The Arbitrum Credit Guild would naturally lend against ARB collateral as well as against ETH, and so on. CREDIT_ARBITRUM, CREDIT_OPTIMISM, and CREDIT_ETHEREUM would exist as distinct tokens, and each would have its own savings rate based on the rates available in its respective Credit Guild instance. One might be able to mint 0.98 CREDIT_ARBITRUM against 1 CREDIT on Arbitrum, but only mint 0.7 CREDIT against 1 CREDIT_ARBITRUM on mainnet.
In the future, a custom Credit Guild scaling solution can be released as its own immutable instance, allowing for voluntary migration and allowing market governance to determine the extent of interoperability.
Credit SubDAOs
I welcome the possibility of independent groups forking the code behind the Ethereum Credit Guild, and will be well pleased if anyone adopts concepts like market governance in their own designs. Some of the assets issued by these groups may become interoperable with CREDIT through mutual lending terms. A particularly friendly fork might allow GUILD holders veto rights to new asset proposals in their system, but have their own ownership token with profit rights. This would give GUILD holders confidence that malicious lending terms will not be onboarded to the fork system, and thus make its ALTCREDIT token more appealing as collateral in the core system.
With a commitment to a simple and immutable core system, it won’t be long now before we are ready to schedule the protocol’s public audit. Next time, we’ll share an expected date and available prizes. Note that the repo is already public, though you’ll have to look in the pull requests for the most current code, so anyone interested can get a head start.