KIP-6.1┃KUMA Protocol on Mantle Mainnet, Deployment Plan

Summary: This proposal aims to determine the deployment plan for KUMA Protocol on Mantle Mainnet.

Context: Yesterday, KIP-6, which is proposing the deployment of the KUMA Protocol on Mantle Mainnet was posted on the governance forum. In continuity of the possible approval of the proposal, the DAO must determine the deployment plan of the protocol on Mantle Mainnet.

Rationale: The deployment of smart contracts cannot be performed via the KUMA Protocol multisig. A wallet created especially for the occasion will be used to deploy the smart contracts, the ownership of these smart contracts will then be transferred to the KUMA Protocol multisig.

The proposal can only be approved if the KIP-6 is also approved. If KIP-6 is not approved, then KIP-6.1, regardless of the result of the vote, will be automatically rejected.

Below is the proposed detailed plan for the deployment of KUMA smart contracts on Mantle Mainnet:

Smart contracts:

• KUMAAccessController : single deployment
• KBCToken : single deployment
• KUMAAddressProvider : single deployment
• MCAGRateFeed : single deployment
• KUMASwap : Deployment for each KIBT (1 deployment per risk category)
• KIBToken : Deployment for each KIBT (1 deployment per risk category)
• KUMAFeeCollector : Deployment for each KIBT (1 deployment per risk category)

Transfer of roles to the KUMA Protocol multisig:

• DEFAULT_ADMIN_ROLE
• KUMA_MANAGER_ROLE
• KUMA_SET_EPOCH_LENGTH_ROLE
• KUMA_SWAP_PAUSE_ROLE
• KUMA_SWAP_UNPAUSE_ROLE
• KUMA_SET_URI_ROLE

Setters on the KUMAAddressProvider smart contract:

• setKBCToken : single setter
• setRateFeed : single setter
• setKUMABondToken : single setter
• setKIBTToken : Setter for each KIBT (1 setter per risk category)
• setKUMASwap : Setter for each KIBT (1 setter per risk category)
• setKUMAFeeCollector : Setter for each KIBT (1 setter per risk category)

Setters on the MCAGRateFeed :

• setOracle : Setter for each KIBT (1 setter per risk category)

Roles attributions :

• Attribution of KUMA_MIN_ROLE to each KUMASwap contract : Attribution for each KIBT (1 attribution per risk category)
• Attribution of KUMA_BURN_ROLE to each KUMASwap contract : Attribution for each KIBT (1 attribution per risk category)

Means:

• Human resources: If the proposal is approved, the KUMA Multisig signers will have to execute the proposal following the technical voted implementation.
• Treasury resources: There is no treasury cost.

Technical implementation: Described in the proposal.

Voting options:

• Accept the deployment plan
• Against the deployment plan / Rework the proposal
• Abstain

Authors: Jean Brasse from Mimo Labs