rUSDC Token Standard
The rUSDC Token Standard (ERC-7770) makes any ERC20 token borrowable by default.
Motivation
The Cambrian explosion of new L1s and L2s has given rise to bridged assets which are synthetic by nature.
rUSDC allows an ecosystem (chains, L2s, and other networks of economic activity) to increase supply by allowing users to mint the asset not only by bridging into the ecosystem, but also by borrowing it within the ecosystem (typically against bluechip collateral).
Example 2.1
Consider a rUSDC token, namely, rUSDC.x, that represents a synthetic USDC.
Such token will allow users to mint 1 rUSDC.x upon a deposit/ bridging of 1 USDC, or by providing collateral that is worth more than 1 USDC.
Quick redemption of rUSDC.x to USDC is available as long as there is still a USDC balance in the instance LPSM.
In a scenario where there is no USDC in the instance LPSM, the price of reUSD may temporarily fluctuate until borrowers repay their debt or more USDC is added to the LPSM from the Global PSM.
rUSDC tokens may delegate minting capabilities for multiple risk curators and lending markets. Hence, a uniform standard for rUSDC minting is needed.
Specification
The proposed standard has the following requirements:
MUST be ERC-20 compatible.
Interface
Reserve ratio
The reserve ratio reflects the ratio between the token that is available as cash from the instance PSM, i.e., available for immediate redemption and the total supply of the token.
Segregated accounts (see below) MUST be subtracted from the cash balance.
A lower reserve ratio gives rise to higher capital efficiency, however, it increases the likelihood of a depeg or a run on the bank, where token holders cannot immediately redeem their synthetic tokens.
Formally, the reserve ratio is denoted by
Mint and burn functionality
The rUSDCMint
and rUSDCBurn
functions SHOULD be called by permissioned addresses, e.g., risk curators or lending markets. These entities SHOULD mint new tokens only to addresses that have locked collateral in a dedicated contract.
rUSDCMint
MUST revert if the reserve ratio, multiplied by e18
exceeds requiredReserveRatio()
.
A successful call to rUSDCMint(_to, _amount)
MUST increase the value of totalSupply()
, totalBorrowedSupply()
, and the token balance of address _to
, by _amount
units.
A call to rUSDCMint
MUST emit a MintrUSDC
event.
A call to rUSDCMint
MUST revert if after the mint, the reserve ratio multiplied by 1e18
exceeds the value of requiredReserveRatio()
.
Similarly, a successful call to rUSDCBurn(_from, _amount)
MUST decrease the value of totalSupply()
,totalBorrowedSupply()
, and the token balance of address _from
by _amount
units.
A call to rUSDCBurn
MUST emit a BurnrUSDC
event.
Account balance
The rUSDCMint
SHOULD be used in conjunction with a lending operation, where the rUSDC is borrowed. The lending operation SHOULD come with an interest rate, and some of the interest rate proceedings SHOULD be distributed to Global PSM suppliers.
This standard does not dictate how distribution should occur.
Rationale
The proposed standard aims to standardize how multiple lending markets and risk providers can interact with rUSDC. The actual lending operation should be done carefully by trusted entities to make sure the parties who have rUSDC minting credentials are reliable.
Understanding how much additional supply is available for borrowing and at what interest rate is the core of this token standard. The additional borrowable supply is deduced from the required reserve ratio and the total borrowable amount. The interest rate SHOULD monotonically increase with the current reserve ratio.
The standard does not dictate how the accrued interest rate is distributed.
While rUSDC is most useful when it is backed by a known asset, e.g., USDC, it can also be used in isolation. In such a case, a token will have a fixed initial supply, however additional supply can be borrowed. The supply may temporarily increase, but the net holdings (totalSupply() - totalBorrowedSupply()
) remain unchanged.
Backwards Compatibility
rUSDC tokens are backwards compatible with ERC-20.
Reference Implementation
Last updated