Before describing Namada governance, it is useful to define the concepts of NAM, validators, delegators, and delegates.
Namada's economic model is based around a single native token, NAM, which is controlled by the protocol.
A Namada validator is an account with a public consensus key, which may participate in producing blocks and governance activities. A validator may not also be a delegator (although, of course, a user can control both validator and delegator keys).
Non-validator addresses on Namada are able to bond their tokens. When doing so, they specify a validator which is now responsible for voting on blocks on the bonder's behalf. The validator's voting-power is proportional to the sum of its self-bonded tokens and all the bonded tokens from other addresses to their own address.
With the above definitions in mind, we define the following terms:
A Namada delegator is an account that delegates some tokens to a delegate for governance voting purposes. Any address is either a delegator or a delegate, but not both.
A Namada delegate is an account that has been given the right to vote on the behalf of a delegator. A delegate may not also be a delegator.
When an address bonds tokens, the address is able to specify a delegate.
The respective validator of that address becomes the default delegate (explained below) of that address.
Similarly, a delegate's
voting-power (now in terms of voting on governance proposals, not blocks) is proportional to the sum of its self-bonded tokens and all the bonded tokens from other addresses to their own address.
Namada introduces a governance mechanism to propose and apply protocol changes without the need for a hard fork, and to signal stakeholder approval for potential hard forks.
Any user able to deposit the correct amount of
NAM is able to propose some changes in a proposal for which delegators and validators cast their
It is also possible to attach some payloads to proposals, in specific cases, to embed additional information.
Governance on Namada supports both
The signaling mechanism is used for changes which require a hard fork, while the voting mechanism is used for changes which merely alter state. In cases where the chain is not able to produce blocks anymore, Namada relies on off-chain signaling to agree on a common move.
Further information about delegators, validators, and NAM can be found in the economics section.
There are two ways to propose a change to the Namada protocol:
- On-chain - A proposal is submitted to the Namada blockchain, and the Namada blockchain handles the voting process.
- Off-chain - A proposal is submitted to a focal point outside of the Namada blockchain, and the voting process occurs off-chain.
Namada governance implements a spam resistance mechanism to prevent the network from being spammed with proposals.
This mechanism is based on the fact that a proposal must be submitted with a deposit of
This deposit is returned to the proposer if the proposal is accepted, and burned otherwise.
This is only possible if the proposal is submitted on-chain, as off-chain proposals are not able to submit a deposit.