Governance
MAYAChain governance is deliberately minimal. It decides which chains and assets are listed, and when the protocol gets upgraded.
Last updated
MAYAChain governance is deliberately minimal. It decides which chains and assets are listed, and when the protocol gets upgraded.
Last updated
MAYAChain aims to have as little governance baked into the system as possible. This is done so that nodes don't communicate or learn who one another are. This is important for security because it makes sure that nodes don't act together to take control.
MAYAChain governance decides:
which assets are listed/delisted
which chains are listed/delisted
when the protocol gets upgraded
the economic limit – how many nodes can participate
Users signal which assets they want on the network by staking in a new pool. MAYAChain will realise it is a new asset it hasn't been seen before and create a new pool and place it in bootstrap mode. This is a normal asset pool except swapping is disabled on it. Every few days the networks looks at all the bootstrapping pools and lists the one with the highest value.
Assets are delisted when all liquidity providers have taken all their assets out of it, or its pool depth drops too low. The logic is:
When a new bootstrap pool is enabled, its depth is compared with the depth of the smallest active pools.
If it is deeper, the smallest active pool is placed back into bootstrap mode, and the new pool replaces it.
The process is repeated to re-list an asset.
When the community wants to support a new chain
Community developers write a new Bifröst module and propose it via a MAYAChain Improvement Proposal (MIP).
MAYAChain developer community decides whether or not to approve it
If approved, the code gets tested and validated by core developers
If accepted, it gets added to MAYANode software
Nodes upgrade their software as they are cycled off and back onto the network
When 67% of nodes are running the new software, the new chain is connected
To delist, nodes stop watching a chain. When 67% are no longer watching, it gets removed. A process begins and the assets of that chain are returned to their owners.
Developers from the community submit MAYAChain Improvement Proposals (TIPs) to improve the network. The community discusses, tests and validates the software. If they decide that the change is beneficial, it's merged into the MAYANode software.
The protocol is made up of 3 main pieces, run by the nodes:
application logic – runs the blockchain
schema – stores key values of vaults
network software – keeps the TSS protocol key generation and signing
When nodes are churned off the network they can choose to update their software version. Over time more and more nodes will run the latest version. When 67% of nodes are running the new software, the network is automatically updated. This is how application logic, chain connections and schema are updated.
When upgrading the network software, a certain block number in the future is set when the upgrade will happen. When the network reaches that point, the whole chain stops running and a genesis import to a new network occurs and operations continue normally.
Emergency changes are difficult to coordinate because nodes cannot communicate. To handle an emergency, nodes should leave the system. When the number of nodes falls below 4, funds are paid out and the system can be shut-down. This process is called Ragnarök.
There are only so many nodes who can participate on the network. This is because there's a minimum bond amount and a fixed supply of Cacao. If the system is ever found to be always under-bonded or over-bonded, the minimum bond limit can be changed.
Mimir is a feature to allow changes in the constants of the chain, such as MinimumBond, ChurnSpeed and more.
There are two types of mimir
Node Mimir: set by each node. Once 2.3rds have set a mimir, it is enacted. Only active nodes have their votes counted
Admin Mimir: set by admins to over-ride constants during testing. Admin-mimir can't control funds, but it can set parameters. Ultimately admin-mimir will be removed.
