KIP-2┃Deploy KUMA Protocol on Ethereum

[JeanBrasse]

Summary:
Mimo Labs proposes to deploy the KUMA Protocol on Ethereum.

Context
Since Mimo Labs gives the ownership of the newly KUMA Protocol to the vMIMO holders, it is now their decision whether or not to deploy the protocol.

The proposal presents an overview of the KUMA smart contracts (the “KUMA Protocol”) with the main features and requests a vote from vMIMO holders regarding a potential deployment.

The features associated with the KUMA Protocol represent a significant technological advancement for Real World Assets tokenization protocols as we know them today.

Rationale:

KUMA Protocol Overview

The KUMA Protocol is a decentralized protocol issuing interest-bearing tokens backed by regulated NFTs, themselves backed by Real World Assets (RWA). At start the KUMA Protocol could (depending on a vote from the vMIMO holders) accept regulated KUMA NFTs that are backed by a variety of real world assets, starting with sovereign bonds.

The KUMA Protocol and tokens have been designed to be more user-friendly than traditional assets. Unlike the latter, which can be difficult for business & retail investors to understand and access, the KUMA interest-bearing tokens (KIBT) can be easily bought and sold on decentralized applications, making them accessible to a broader range of users. Furthermore, because the KUMA Protocol uses blockchain technology, the entire process of issuing the tokens is audited, transparent and secure.

How does it work ?

The KUMA Protocol accepts to swap regulated NFTs backed by RWAs (soarting with bonds) in exchange of composable interest-bearing tokens (KIBT) based on the metadata of the NFT. A fixed number of KIBT will be minted with parameterised interest rates. The KIBT interest rate can be updated by having a user exchanging its regulated NFT from the same risk category, or when central bank rates change.

The KIBT (Kuma Interest Bearing Token) are ERC-20 stablecoins whose balance changes over time due to interest accrual. They can be used across the broader blockchain ecosystems such as DeFi, GameFi or NFT platforms.

Smart Contract Architecture

Mimo Capital AG (MCAG):
The centralized entity that holds the physical bonds backing KUMA Bonds NFTs is MCAG (via custody partners). It ensures that for every KUMA NFTs in circulation, an underlying bond is backing its value off-chain. Users are able to trade, transfer their NFTs by themselves, but the physical assets are always held solely by MCAG. Additionally, MCAG maintains the central bank oracle and a multisig with a manager role in the MCAG access controller to manage centralized aspects of the system.

KUMA Bonds NFTs:
While KUMA is not limited to bonds, the first KUMA regulated NFTs will be sovereign bonds. Each KUMA NFT is non-fungible and transferable. They follow the ERC-721 standard, the NFT standard. The NFT holder can sell back the NFT off-chain to MCAG for the market-rate bond value at any point. Some bonds can be represented by clone bond NFTs (More details below). Each token contains metadata that provides details about the underlying asset backing its value.

Metadata include:

• currency Currency of the bond - example : USD
• country Treasury issuer - example : US
• term Lifetime of the bond ie. maturity in seconds - issuance date - example : 10 years
• maturity Date on which the principal amount becomes due - timestamp is seconds
• issuance Bond issuance date - timestamp in seconds
• coupon Annual interest rate (minus commission) paid on the bond per - rate per second
• principal Bond face value
• cusip-isin Identification number of the underlying bond
• riskCategory Unique risk category identifier computed with keccack256(abi.encode(currency, country, term)) - each token belongs to a single riskCategory

Note: KUMA NFTs are minted unilaterally by Mimo Capital AG. The KUMA DAO has no control over them.

Note 2: By CBR we mean Central Bank Rate minus MCAG commission.

KUMA Interest Bearing Bond Tokens (KIBT):
KIBTs are rebase ERC-20 tokens that accrue interest based on Bond Interest configuration of the KUMA NFT, meaning that users balances will increase over time just by holding the token in their wallet address. This allows users to interact with a more liquid and divisible form of bonds while still earning real-time interest on their tokens. KIBTs are backed by the bonds held in the KUMA Interest Bearing Swap Contract (see next point). Each risk class has its own KIBT.

KUMA Interest Bearing Swap Contract:
The KUMA Swap contract holds all KUMA Bonds NFTs that back the KIBT. The KUMA Swap contract allows users to sell KUMA Bond NFTs in exchange for KIBTs using sellBond, and buy back KUMA Bonds NFTs with KIBTs using buyBond.

The KUMASwap contract is responsible for:

1.Ensuring KIBTs backing by :

• Minting KIBT upon KUMA Bonds NFT sale
• Burning KIBT upon KUMA Bond NFT sale purchase

2.Generating fee income for the KUMA DAO.
There is one KUMASwap contract per existing risk category similar to the KIBT. Each risk class has its own Interest Bearing Swap Contract.

Central Bank Oracle:
This oracle will Inform the protocol of the changes of rates of the underlying bonds within the KUMA Swap contract. The CBR is used to keep the protocol competitive and avoid an excessively high KIBT rate. There is one oracle for each risk class, since different risk classes have different interest rates.

Rate Feed:
The rate feed contract reads rate data from the central bank oracles. Unlike oracles, of which there is one oracle per risk category, there is only one RateFeed for the whole protocol, and the risk category is passed in as an argument for fetching data.

Keepers:
Keepers do the work of making sure that the KIBT yield is always at the highest possible rate that is backed by existing bonds in the KUMASwap contract, and that all bonds in the KUMASwap contract can be bought with the circulating KIBT supply.

This is done through relying on keepers to call the following functions:

• KUMASwap.expireBond() when a bond held by the KUMASwap contract has reached maturity but hasn’t been bought. This adds the expired bond id to the set of _expiredBonds and sets the KIBT accrual rate to 0% (corresponding to a yield of 1e27) until all expired bonds are bought.
• KIBT.refreshYield() when the KIBT rate needs to be updated to reflect that of the bonds held in the KUMASwap contract and the central banks bond rates. This can sometimes occur after the central bank oracle rate is updated.

Access Controller:
All access control logic for the decentralized contracts (KUMASwap, KIBT, KBCT, and MCAGRateFeed) is handled by the KUMA protocol’s AccessController contract. The following roles will be added to the KUMA protocol’s access control:

• KIBT_MINT_ROLE: Mints KIBT
• KIBT_BURN_ROLE: Burns KIBTs
• KUMA_SWAP_PAUSE_ROLE: Pauses KUMASwap, which prevents all transfers, minting, and burning of KUMA Bonds NFTs
• KUMA_SWAP_UNPAUSE_ROLE: Unpauses KUMASwap, which re-enables transfers, minting, and burning of KUMA Bonds NFTs after a pause
• KIBT_SET_EPOCH_LENGTH_ROLE: Sets KIBT epoch length
• KUMA_MANAGER_ROLE: Sets configs of the protocol like sellBond fees, minGas in KUMASwap , KIBTFeeCollector payees and shares, and contract addresses in the KUMAAddressProvider
• KIBT_SWAP_CLAIM_ROLE: Claims the parent bonds of a clone bond in

Additional features:

KUMA Clone Bond Tokens:
When the CBR drops lower than the current KIBT yield, Clone Bonds lower the coupon of bonds that were bought by users from the KUMASwap contract. This ensures that at any point in time there are enough KIBT in circulation to buy all the bonds from the KUMASwap reserve.

The lowest paying yield corresponds to the lowest yield between the CBR and the lowest coupon in the KUMASwap reserve. The KIBT yield always corresponds to the lowest paying yield.

To understand why KIBTSupply might be a problem without clone NFTs, consider the case where the KUMASwap contract holds 2 different one year $1,000 bonds - one with a 3% coupon and one with a 5% coupon. If we also assume the central bank rate is higher than either bond coupon, the KIBT yield will be that of the lowest bond in the swap contract (in this case 3%). Since the 5% bond appreciates more quickly than the KIBT total supply, there won’t be enough KIBT for users to buy both bonds from the KUMASwap. Clone NFTs fix this through lowering the reward coupons of the bond so that they can be redeemed by the circulating KIBT supply. In this case, a Clone NFT would be issued for the 5% bond so that it can be redeemed as a 3% bond.

A clone bond is always paired with a parent bond from the reserve and will have a lower coupon overriding its parent coupon when the bond is valued. For each clone bond present, the parent bond cannot be redeemed by a user and can only be redeemed by the issuer of the NFT (in this case the MCAG multisig) when the clone bond has been redeemed by MCAG. KBCT can only be issued by the KUMASwap in the buyBond function.

Clone bond coupons are only created if the bond’s face value is greater than that of the amount of KIBT the bond has backed in the KUMASwap contract. This happens when the central bank bond rate for a given risk category decreases past the minimum coupon held by the KUMASwap

Deprecation Mode:
KIBT is minted and burned such that the total supply is always sufficient to buy out all of the KUMA Bonds NFTs held in the contract. However, in extreme cases, some of the KIBT supply may become inaccessible (e.g. if large amounts of KIBT are hacked or lost to unknown addresses). This could result in Kuma Bonds NFTs being locked in the KUMASwap contract. To mitigate this scenario, the DAO can vote to put the KUMASwap contract in deprecation mode where users can buy bonds with stablecoins through voted-on parameters. Since there is a unique KUMASwap contract for each risk category, one deprecated KUMASwap contract for a given risk category does not impact other KUMASwap contracts for different risk categories.

When deprecation mode is activated, the KIBT yield is set to 0 (i.e. all KIBT tokens stop earning interest). After all of the bonds have been bought in the corresponding KUMASwap contract, users can redeem any of their leftover KIBT for stablecoin held in the KUMASwap contract through redeemKIBT(). The KIBT to stablecoin conversion rate is determined by how much stablecoin is held in the KUMASwap contract - e.g. If there’s 100k KIBT and 100k stablecoin, each KIBT gives you the right to redeem 1 stablecoin.

Once entered, deprecation mode is irreversible for a given KUMA Bonds NFT risk category. After deprecation mode is enabled, sellBond in the KUMASwap contract is disabled; so users who have outstanding KUMA Bonds NFTs from the deprecated risk category can only redeem them directly through MCAG.

Means:

• Human Resources: Multisig signers will need to sign transactions to execute the proposal

• Treasury Resources: There is no cost for the treasury to deploy the protocol on Ethereum. (Mimo Labs team will cover the cost of deployment)

Technical implementation:

If the proposal is approved, a second proposal will be posted detailing the protocol deployment plan, including:

• KUMA NFT(s) accepted (Rebase Epoch, Sell bond fee per KIBT, Set Central Bank rate oracle per KIBT)
• Deployment of smart contracts

Voting Options:

• Accept to deploy the protocol on Ethereum
• Against/Rework the proposal
• Abstain

Authors: @starny & @JeanBrasse from Mimo Labs

Sentiment poll:

• Accept to deploy the protocol on Ethereum
• Against/Rework the proposal
• Abstain

[arjpet]

Will mimo (the token) have a role in the protocol?

[Starny]

Hey @arjpet

I suggest you to read twice the “context”

Context
Since Mimo Labs gives the ownership of the newly KUMA Protocol to the vMIMO holders, it is now their decision whether or not to deploy the protocol.

The proposal presents an overview of the KUMA smart contracts (the “KUMA Protocol”) with the main features and requests a vote from vMIMO holders regarding a potential deployment.

vMIMO will govern Kuma protocol.

[arjpet]

I read and understand that mimo will be the government token. I can say that compared to the most of you i am a tech/defi noob. I don’t have feedback at the tech part of this proposal. As a (v)MIMO holder i am certain that we will benefit from KUMA protocol. I am just curious how and when that will be more in the open. For the creators it will be clear as ever, but with the experience over the last two years, i am not feeling it yet, although i am certain it will be fantastic.

[0xEvi]

Hey

1. What are the Oracles for the Central Bank interest rate?

2. What would be the/the means for a third party (a Country) to freeze/blacklist addresses?

3. Can the KUMA protocol (by DAO) freeze/blacklist addresses?

4. As each NFT that represents a RWA is really unique and transparent (we have all the information to identify them), is there a way to go through the company Mimo Capital AG to seize (freeze or any witchcraft) the underlying of the NFT and therefore the underlying of the KIBT?

5. Each token represents a share of the NFT (1 NFT can be divided into a certain number of token) or each Token = 1 NFT?

6. What fees do KIBT fees collect? Are they redistributed to vMIMO holders?

7. There comes a time when in the case of bonds there is an end date. What happens with the KIBT at that time?

8. Which custody partners hold the bonds on behalf of MCAG?

9. So there is a multisig within the company (MCAG) for the management of physical assets?

10. If a user holds an NFT how does he recover the interests?

11. What exactly is Access Controler? It’s KUMADAO?

12. I didn’t understand what the KUMA Clone Bond Tokens was, can you please explain it to me?

13. During the Deprecation Mode we offer the possibility to buy the NFT contained in the KumaSwap contract, and the harvested stable are then exchangeable for KIBT?

14. To resell the NFT to MCAG you have to be a “regulated” user?

15. Users who hold KBTs can mint KIBTs through the sale of theirs NFT to the Swap Contract. Holders of KIBTs can belly redeem their KIBTs in exchange of KBTs. So far I understand, but how can a user come up with USDC to buy KIBT? As the NFT in the contract are already the KIBT guarantee issued at the time of its submission, I do not understand ?

[Biscuit]

1. The Oracles have been built by Mimo Labs and will be online soon for you to see!
2. The freezing mechanism does not apply to the assets minted by KUMA Swap. So far, there is a possibility to freeze the NFTs issued by MCAG though.
3. No
4. There is no way to seize the KIBT from the NFT as the NFT belongs to the protocol from the moment it is sold against KIBT.
5. 1 NFT can be sold to the protocol for multiple tokens.
6. This current version of the protocol can collect fees on swap. These fees belong to the Mimo protocol. Whether they will be redistributed directly to vMimo holders is a question of another vote.
7. When a bond reached maturity it stops paying. When a bond stops paying, its effective interest rate becomes zero, and all the IBT’s interest rates drop to zero until someone buys back this bond from the smart contract.
8. The custody partners will be revealed soon.
9. MCAG works with a board of directors, as opposed to only a multisig.
10. A user who buys an NFT for a price X can sell it to MCAG and will recoup price Y. Except for unexpected bond market fluctuations, Y>X in general. This is how the interest is recovered.
11. The access controller is what manages the rights on the DAO.
12. The clone bond token system allows for the protocol to gain revenue when NFTs backing IBTs pay more than the effective interest rate published. More documentation is coming to describe it further.
13. I’m not sure I understand the question, but deprecation mode is about allowing users to buy what’s left in the contract with stablecoins that have been voted as acceptable by the DAO for this purpose.
14. You have to be a MCAG customer, so effectively the customer of a regulated entity.
    15.USDC to KIBT can only happen if there is a pair between these two tokens existing on an exchange, this is separate from KUMA.

[N.L1]

Where does the risk category come from and is it rock stable? Also known from the movie “the big short”?
Because once the deprecation mode for a certain risk category starts, it cannot be undone right?

[N.L1]

Once NFT’s will be bought back with KIBT, what will happen to the clone bonds?

How will a retail user know what risk category KIBT they are buying?

How will a retail user know which interest percentage they will receive at the point of buying-transaction?

How will a retail user know which timeframe the NFT backing the KIBT has?

What will the KIBT be sold with? USDC or PAR?

[Biscuit]

• Risk Category is a set of parameters including the country, the term, the currency, and the size.
• The concept of KUMA is to allow different risk classes to mint different interest bearing tokens. Some will be volatile, some will be less volatile, but the protocol itself should not have to care about this, and provide the infrastructure for enabling activity.

[Biscuit]

• When you redeem a clone bond you have access to its parent if you’re the issuer.
• The Metadata of NFTs include risk & coupon parameters related to the bonds. This will include the maturity date.
• Regarding accepted currencies for KIBT, as far as KUMA is concerned, it’s about NFT/KIBT and KIBT/NFT.

[N.L1]

So in case of a Black Swan event, the defaulting of a country on its bonds, the KUMA protocol will just start depreciation mode?

[Biscuit]

A country defaulting on its bonds is not depreciation mode. What would happen is that KIBTs would still redeem NFTs and that these NFTs would be redeemed to MCAG for a much lower value. All in all these KIBT should trade down to reflect the expected value of the NFT. Here’s an example: in the case of Ghana right now, the bonds have very high interest but are trading at very low price because of the expectation of default. With KUMA’s model, it means that the KIBT should naturally trade down, as the arbitrage can happen on both sides.

[Starny]

With over 6.7M votes, $vMIMO holders approved the deployment of the Kuma protocol on Ethereum !

Results: https://snapshot.org/#/kumaprotocol.eth/proposal/0x48fd8e0743f98ff48fbe3852be2157e5e2f3a20ce4424431de111a188298d8c1