Governance
Currently, the MUX protocol governance process involves forum proposals and community discussions. Any proposed modifications to the protocol will be openly discussed on the forum, and the team will execute each proposal under the premise of shared opinions. The executions will be transparent, and the MUX team will notify the community through various channels before the implementation occurs. Except for an emergency protocol pause that prevents security incidents, all protocol modifications will only take effect after a 48-hour timelock; the delay would give community members a time window to take needed actions.
After the protocol reaches a self-sufficient state (supported by POL), veMUX voting will be added to the governance process. The voting process will initiate when the community comes to a rough consensus on a proposal.
The decentralization of protocol governance needs to be phased due to development prioritizations. Upon protocol launch, the highest priority is to ensure positive performances and efficient adaptation to the ever-changing market. Leading the governance allows the MUX team to implement constant improvements faster, further helping the protocol build a steady POL foundation. When the protocol reaches a broad user base and can stably provide optimized experiences for all trades, elevating the degree of decentralization will be the new priority. Voting will be progressively introduced to the governance process, starting from major protocol updates polling, then expanding to comprehensive protocol modifications. In future phases, trust will be minimized as veMUX holders are onboard to govern and shape the protocol into a better state.

MUX DAO multi-sig currently governs the MUX protocol smart contracts, and the scope includes general operation, maintenance and emergency actions.
The governance involves two types of permission: time lock required and non-required. For general operation actions, time locks are required; all the proposed changes will only take effect after a 48-hour time lock. Maintenance actions won't affect protocol core features, so that they won't need a time lock. Emergency actions can take effect immediately and won't require time locks; these actions can potentially occur during security incidents or other events that can severely damage LPs and traders.
Please check the detailed list below for all general operation, maintenance and emergency actions.

  • Upgrade this smart contract
  • Transfer / Renounce owner (the TimeLock smart contract)
  • Add new type of assets to the pool
  • Set underlying asset symbol string
  • Set underlying asset initial margin rate
  • Set underlying asset maintenance magin rate
  • Set underlying asset open / close fee rate
  • Set underlying asset spread
  • Set underlying asset maximum open interest cap
  • Set underlying asset minimum profit limit
  • Set liquidity asset weight
  • Set base funding rate
  • Set dynamic funding rate
  • Set the address of on-chain oracle
  • Set fee rate for adding / removing liquidity
  • Set gas rebate rate
  • Set the dampener range of the stablecoin's price
  • Set funding payment collection time interval
  • Set who can execute emergency functions (who can skip the TimeLock)

  • Upgrade this smart contract
  • Transfer / Renounce owner (the TimeLock smart contract)
  • Add broker
  • Remove broker
  • Add rebalancer
  • Remove rebalancer
  • Set add / remove liquidity lock time
  • Set order overtime limit
  • Set who can execute emergency functions (who can skip the TimeLock)

  • Upgrade this smart contract
  • Transfer / Renounce owner (the TimeLock smart contract)
  • Set vault smart contract address
  • Set pool smart contract address
  • Set handler (broker)
  • Configure DEX mining assets type and their weight
  • Modify the weight of DEX mining assets
  • Configure DEX mining assets type
  • Configure DEX mining interface adapter
  • Configure slippage for adding liquidity on DEXes
  • Pause DEX mining mining interface adapter
  • Add / remove universal plug-in smart contract (bridging, etc)
  • Transfer owner (the TimeLock smart contract)
  • Renounce owner (the TimeLock smart contract)
  • Set maintainer address (maintainer can execute assets bridging)
  • Set allowed assets for bridging along with their targeted networks
  • Bridge assets using cBridge
  • Directly withdraw assets (for manual bridging)
  • Directly withdraw assets and assign targeted receiver (for manual bridging)

  • Set ETH unwrap smart contract whitelist
  • Transfer / Renounce owner (the TimeLock smart contract)

  • Upgrade this smart contract
  • Manage pre-minted mux tokens
  • Transfer / Renounce owner (the DAO multi-sign)
  • Set proposers
  • Set executors

  • Upgrade this smart contract
  • Transfer / Renounce maintainer (the DAO multi-sign)

  • Collect and distribute protocol fees
LiquidityManager
  • Transfer liqudity tokens among blockchains through whitelisted bridges
LiquidityPool
  • Set MUXLP token price protection range

  • Enable / disable trading of specific assets
  • Enable / disable using specific assets as underlying assets
  • Enable / disable using specific assets for opening positions
  • Enable / disable using specific assets for shorting
  • Enable / disable taking profits with stablecoin when trading specific assets
  • Enable / disable specific assets to be considered as stablecoin
  • Enable / disable using specific assets for adding liquidity

  • Pause fill position & liquidity orders (the orders to pause during broker maintenance)
Copy link
On this page
MUX Protocol Governance Scope
General Operation
Maintenance
Emergency