Governance
How Tenzro Network is governed: Tenzro Foundation stewardship, on-chain proposals and stake-weighted voting.
Tenzro Network is open, permissionless and open source under Apache 2.0. Two things govern it: the Tenzro Foundation, which stewards the project, and on-chain governance, in which staked TNZO votes on the parameters the protocol runs by.
The Tenzro Foundation
The Tenzro Foundation is the steward of the network. It is responsible for:
- The protocol and network primitives, published under Apache 2.0.
- The repositories, documentation and tools that developers and operators use.
- Distribution and outreach, making the network's resources known and available.
- TNZO, as the governing body for the token that pays all network fees and transaction settlement.
The Foundation works with the people and companies building on the network: individual developers and the open-source community, and commercial partners who help operators of any background get onboard. Tools, including abstraction layers for payments and TNZO, are built by the Foundation, by independent developers and by partners.
Anyone can be an operator, a developer or a user. No role requires the Foundation's permission. See Foundation.
On-chain governance
Protocol parameters change through proposals that bonded stake votes on, on-chain. A proposal that passes is executed by the protocol, not by hand.
What a proposal can change
A proposal carries one action, tagged by "action" in its JSON. The node accepts 32 actions, each with a stable kind label that tenzro_getProposal and the event stream report. Every action belongs to one of three domains:
- Network: operational settings that another vote can put back.
- Treasury: moves value, so a later vote cannot take it back.
- Sanction: takes something from a named party.
Agents originate nothing by default (governance.agent_phase is 0). At phase 1 they may originate network actions only; treasury and sanction actions need phase 2, which a vote must set explicitly.
| Action | Domain | Changes |
|---|---|---|
parameter_change | Network | A governed parameter, switch or status lever |
policy_update | Network | Structured policy: the economic policy, the burn dial and supply targets, TPM endorsement roots, a bridge route's limits or circuit, the finality program, or a protocol upgrade |
set_delegate_code | Network | Lists or delists the code hash of an EIP-7702 delegate |
set_rate_stream, remove_rate_stream | Network | Installs, replaces or removes the signer set of a signed rate stream validators quote from |
set_reserve_feed, remove_reserve_feed | Network | Installs, replaces or removes the Proof-of-Reserve feed validators read for an asset |
set_settlement_asset | Network | Installs or replaces the entry that lets payments settle in a token other than TNZO |
remove_bridge_route | Network | Removes an inbound bridge route |
lift_module_freeze | Network | Lifts a freeze the value-invariant monitor put on a module; the monitor refreezes it while the vault is short |
approve_validators | Network | Approves accounts to register as validators while admission needs approval |
recall_sponsored_bond | Network | Recalls a validator's sponsored bond to the treasury after the governed unbonding period |
revoke_operator, revoke_grantee | Network | Withdraws an approval; later payments stop at once |
treasury_grant, release_grant_tranche | Treasury | Pays a grant to an approved grantee, then each tranche |
running_cost_payment | Treasury | Pays the network's running costs from the running-cost reserve |
recover_unowned_funds | Treasury | Reassigns funds at a system address that the accounting shows belong to nobody |
set_network_payout | Treasury | Sets where the network's share of an off-ledger rail's payments is paid |
set_bridge_route | Treasury | Installs or replaces the inbound route for one bridge protocol and source chain |
set_agent_account_chain | Treasury | Installs or replaces the record of a chain agents hold accounts on |
treasury_remote_action | Treasury | Moves treasury funds on another chain through the treasury's keyless account there |
sponsor_validator_bond | Treasury | Bonds existing treasury TNZO on a validator's behalf; slashable, never votes, earns nothing |
approve_operator, approve_grantee | Treasury | Opens the gate that sponsorship and grants pay through |
sponsor_operator_running_cost, sponsor_operator_stable | Treasury | Pays an approved operator part of its running cost for verified hours, in TNZO or in an approved USD stable asset |
revoke_identity | Sanction | Revokes a registered identity and everything it controls |
set_guardian, remove_guardian | Sanction | Seats a human guardian for a fixed term, or unseats one early |
retire_registry_entry | Sanction | Retires an abusive registry entry; its bond goes to the insurance pool |
reinstate_validator | Sanction | Returns a jailed or slashed validator that a vote put out to candidacy at the next epoch boundary |
An economic-policy proposal carries the complete policy rather than one field, so a change can never leave the rates half-applied or a revenue split that does not sum to the whole payment. Start from the policy the network applies today:
tenzro governance economic-policy --jsonPayments out of the treasury are described in Sponsorship and grants.
Voting power
Voting power is the stake bonded behind a validator at the proposal's snapshot. A ballot is cast for a validator by its root: the operator's passkey identity signs it, or, for a validator that is an autonomous machine, the machine's own identity key approves it. Read an address's voting power with tenzro governance voting-power <ADDRESS> or tenzro_getVotingPower.
Lifecycle
- Propose. An account with bonded stake opens a proposal carrying its action as JSON.
- Vote. While the proposal is open, validators vote yes or no, weighted by bonded stake.
- Timelock. A proposal that passes waits out a timelock. During it, governance guardians can veto (it takes
governance.guardian_thresholdof them), and people can raise a concern from their own passkey identity; past a quorum of concerns the timelock doubles, once. - Execute. Once the timelock has run, anyone may enact the proposal, and the protocol applies it.
Quorum, approval threshold, voting duration and the timelock are themselves governance parameters (governance.*), and a proposal keeps the rules it opened under.
Tracks
Most proposals run on the standard track. Two more exist for urgent work.
- Expedited. A
parameter_changethat only sets a status lever to paused (1) runs on the expedited track: a short voting window and timelock, a higher approval threshold, and open to a veto by the guardians and stewards. It applies at the next epoch. - Security fix. A policy update can run on the security-fix track. Its proposer commits to the vulnerability when proposing and must reveal it within a window after enactment, or a share of the proposer's stake is slashed.
Levers
Every integration and extension point ships with levers that governance can operate at an epoch boundary through the same parameter_change proposal, with no code change:
- Status levers (keys ending in
.status):0enabled,1paused,2retired. Paused means nothing new starts on the feature and what already started finishes or winds down under its own rules; another vote resumes it. Retiring is final. - Switches (keys ending in
_enabled):1on,0off. - Values: amounts, caps, rates and windows, each within hard bounds.
Pausing and resuming apply at the next epoch. Retiring waits out the tightening grace window as well. Registration stays permissionless where the rules require it: a lever only opens, bounds or closes a class, and never admits or refuses a named party.
Guardian feature pause
Protocol guardians can also stop one running feature without a vote. governance.guardian_threshold of them signal the same lever and the same number of epochs, at most governance.feature_pause_max_epochs, with a GovernanceFeaturePause call. The lever then reads paused until those epochs pass, and guardians cannot pause the same feature again until governance.feature_pause_cooloff_epochs after it lifts. Guardians can only stop an enabled feature: they cannot enable, resume or retire one, or change a value, and the chain keeps running. Read the levers and any running guardian pause with tenzro governance levers or tenzro_listLevers, and the seats with tenzro governance guardians.
Activation-epoch gates
A new state-transition rule ships in the binary dormant and is switched on for every node at one epoch by a vote. The gate is the parameter feature.<name>.activation_epoch: the first epoch whose blocks run the rule. While the rule is dormant a vote may set the epoch at least two epochs ahead, or back to never; once the rule is live its epoch is final.
Jail and reinstatement
A validator that signs two checkpoints with one index is slashed and jailed: it leaves the active set. Jail is never permanent. It ends in one of two ways, and the validator then returns as a candidate, admitted again like any candidate by the activation churn cap and the self-stake floor:
- The term runs out.
slashing.jail_term_epochs(720 at genesis, between 24 and 8766) counts from the epoch of the jailing. A longer term asks more of a validator, so raising it waits out the tightening grace window; shortening it applies at the next epoch and also shortens the jail of a validator already jailed. - Governance reinstates it. A
reinstate_validatorproposal, with a stated reason, names the validator. Once enacted, the validator is released at the next epoch boundary if it was jailed at or before the epoch of the enactment. It does not undo the slash, and for a validator that is not jailed it does nothing.
tenzro_listValidators shows the epoch a jailed validator is released from (jailed_until_epoch). See Slashing.
Using the CLI
# See what is being decided
tenzro governance list --limit 20
tenzro governance show <PROPOSAL_ID>
# Propose a parameter change
tenzro governance propose \
--action '{"action":"parameter_change","key":"<PARAMETER>","value":1,"memo":"Rationale and expected effect"}'
# Vote for the validator you operate
tenzro governance vote <PROPOSAL_ID> --validator <VALIDATOR_ACCOUNT> --yes
# Enact a passed proposal once its timelock has run
tenzro governance execute <PROPOSAL_ID>Every call that creates a proposal, votes or enacts must be signed by the account that acts. Reads are open to anyone:
curl -s https://rpc.tenzro.com \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"tenzro_listProposals","params":[]}'| Method | Class |
|---|---|
tenzro_listProposals, tenzro_getProposal, tenzro_getVotingPower | open |
What governance controls
- Fees and burn. The split of the base fee between burn and treasury. See Token economics.
- The economic policy. The network's share of settled payments and the RPC provider's share for nodes that do not validate. See Settlement.
- Bonds. The bond amount for each operator role and the withdrawal cooldown.
- The treasury. Every grant and sponsorship payment from it.
- Levers. Whether each integration, proof system, recovery path, verification level and bridge transport is enabled, paused or retired.
- Upgrades. Which protocol version the network runs.
Some things are not up to a vote. TNZO enters circulation only through the work-gated rewards path, and an operator's majority of each settled payment is enforced by the protocol. No proposal can change either.
Related
- Token economics for supply, staking and fees.
- Foundation for the Tenzro Foundation.
- Partners for the partners who help operators onboard.