KIP-9.1┃KUMA Protocol on Sei V2 Testnet, Deployment Plan

Summary:

This proposal aims to determine the deployment plan for KUMA Protocol on Sei V2 Testnet.

Context:

Yesterday, KIP-9, which is proposing the deployment of the KUMA Protocol on Sei V2 Testnet was posted on the governance forum. In continuation of the possible approval of the proposal, the DAO must determine the deployment plan of the protocol on Sei V2 Testnet.

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-9 is also approved. If KIP-9 is not approved, then KIP-9.1, regardless of the vote result, will be automatically rejected.

Below is the proposed detailed plan for the deployment of KUMA smart contracts on Sei V2 Testnet:

  1. 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)
  1. 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
  1. 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)
  1. Setters on the MCAGRateFeed :
  • setOracle : Setter for each KIBT (1 setter per risk category)
  1. 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: Kenneth Lim from Sei Foundation

Community poll:

  • Accept the deployment plan

  • Against the deployment plan / Rework the proposal

  • Abstain

0 voters
2 Likes

The vote is now live on Snapshot: Snapshot