The Role of Network Governance on Nolus
The Cosmos ecosystem prides itself on sovereignty and the ability of appchains to govern themselves through on-chain governance. In this post, we will explore how on-chain governance works on Nolus Protocol and some of the key parameters that the community will control through governance!
How Does On-Chain Governance Work?
Submitting a proposal on Nolus Protocol is permissionless. Any user can create a proposal that automatically enters a deposit period where a minimum bond is required to bring it to the voting period.
In the voting period, validators and delegators are able to place their vote on the proposal. Delegators can vote with their total stake while validators can vote with the total delegations to their validator. This means that if a delegator has a different view from their validator, they can override the validator’s vote.
To pass a proposal, three criteria must be met at the end of the voting period:
- Quorum: A minimum amount of total staked tokens must vote on a proposal. For Nolus Protocol, this is 33.4% of staked $NLS
- Threshold: More than 50% of all decisive voters (excluding voters that abstain) on the proposal voted to pass the proposal
- Veto: Less than 33.4% of all decisive voters (excluding voters that abstain) on the proposal vetoed the proposal
Through this process, the community can come together to agree on passing proposals to change parameters, for community pool spending, or even to signal a stance.
Note that if a proposal is vetoed, the deposit is not returned to the proposer and any other party that contributed towards the deposit.
Moreover, the parameters detailed above in regard to passing a proposal are also controlled by on-chain governance (as part of the Governance Module) and can be adjusted by the community as well.
What Network parameters will the community control?
Below, we explore a number of key modules (and some of their parameters) that Nolus Protocol will leverage. These are:
The Staking Module:
- ‘max_validators’: this parameter determines the size of the active set for consensus purposes. Increasing the size of the validator set is beneficial as it can support decentralization through a wider distribution of staked $NLS, increasing the number of entities required to collude for a successful attack. For Nolus Protocol, the validator set will commence with 40 validators.
However, increasing the validator set can increase block latency as Tendermint uses an all-to-all gossip mechanism which means each additional validator creates significantly more messaging.
- ‘unbonding_time’: this parameter determines the time required to unbond staked $NLS and return it to liquid $NLS which is not participating in consensus. This is to protect against a validator attacking the Network and immediately withdrawing their stake. For Nolus Protocol, the unbonding period will be initiated at 21 days.
The Slashing Module:
- ‘slash_fraction_double_sign’ and ‘slash_fraction_downtime’: these parameters determine the amount of stake that is slashed from a validator for either double signing or for prolonged downtime (note that prolonged downtime is also determined through on-chain parameters).
Double signing occurs when a validator submits two signed messages for the same block and generally happens due to misconfiguration or during maintenance of their hardware. Downtime occurs when a validator misses a minimum threshold number of blocks to be signed in a period. This could happen for a whole host of reasons such as a loss of internet or loss of power.
On Nolus Protocol, double signing will be punished with a 5.00% slash of a validator’s stake while downtime will be punished with a 0.01% slash of a validator’s stake.
- ‘downtime_jail_duration’: this parameter determines how long a validator is “jailed” or unable to return to the validator set subsequent to prolonged downtime. When a validator is jailed, they no longer participate in consensus or earn rewards. However, it also means they are no longer at risk of further slashes for downtime.
On Nolus Protocol, a validator will have to serve a period of 10 minutes “jailed” before they can become unjailed and participate in consensus again.
Interchain Accounts:
- ‘controller_enabled’: this parameter can either be set to ‘true’ or ‘false’ and determines whether an appchain can service controller-specific logic.
A controller chain is that which registers and controls an account on a host chain. The controller chain sends IBC packets to the host chain to control the account.
This is critical to Nolus Protocol as it will be how stablecoins are swapped to other assets for the purpose of a DeFi Lease meaning this will be set to ‘true’ from Genesis.
- ‘host_enabled’ and ‘allow_messages’: the first parameter can either be set to ‘true’ or ‘false’ and determines whether an appchain can service host-specific logic.
A host chain is a chain where the interchain account is registered. The host chain listens for IBC packets from a controller chain which should contain instructions (e.g. cosmos SDK messages) that the interchain account will execute.
On Nolus Protocol, this will be set to ‘true’. Although the majority of Nolus’ usage of Interchain Accounts will be as a controller chain, this keeps the door open to allow other appchains to create DeFi Leases!
The Tax Module:
A custom module designed by Nolus Protocol — as an aside, this is what is wonderful about the Cosmos SDK! The modular nature of it allows appchains to use existing modules as well as design their own for whatever they deem necessary!):
- ‘fee_rate’ and ‘contract_address’: these parameters determine the size of the tax applied to transactions as well as the destination for the tax.
This will be leveraged by Nolus Protocol to grow the lender’s incentive pool. By existing as a module governable by on-chain governance, the community has the ability to increase or reduce the tax as well as the ability to wind down this source of funding for the incentives pool by reducing the tax rate to 0%.
Altogether, there are dozens of parameters that on-chain governance has the ability to adjust. A full list of modules available to Cosmos SDK chains to implement can be found at https://docs.cosmos.network/main/modules/, and each module contains a “parameters” section detailing what can be changed through on-chain governance.
Closing Remarks
As you have seen, on-chain governance has the ability to control large parts of the blockchain without requiring an upgrade. It allows the community to fine-tune the Network to keep it in good health.
As we edge closer to Mainnet, and as the Network continues to gain valuable contributors, in the form of potential validators and future delegators, we are optimistic that Nolus Protocol will be in the hands of a strong decentralized community that ensures its long-lasting future!
We welcome you to our social channel if you have questions on Cosmos SDK and modules, or anything else related to Nolus Protocol!
___
#GetToNolus more by staying up-to-date with our social channels!
