Governance PR: What It Actually Adds
The Governance Module PR introduces the first version of an embedded Governance contract for go-zenon.
The short version: it lets pillars vote on predefined on-chain actions, and if an action passes, the Governance contract can execute that action as an embedded contract sender.
This is not a general-purpose smart contract system. It is a constrained governance mechanism for a limited set of protocol-level operations.
Activation
The Governance contract is gated behind a new governance spork.
Until that spork is issued by the authorized key and becomes active/enforced, the Governance contract is not available in normal protocol execution.
The current governance spork hash is a placeholder until the authorized-key-issued spork exists. Tests override it locally so the governance flow can be exercised before the real activation hash is known.
New Embedded Contract
The PR adds a new embedded contract address:
z1qxemdeddedxg0vernancexxxxxxxxxxxklyh23
Once the governance spork is active, this contract exposes four methods:
ProposeActionExecuteActionVoteByNameVoteByProdAddress
The vote methods reuse the existing pillar voting model already used elsewhere in embedded contracts.
Proposing Actions
A user can submit a governance proposal with:
- name
- description
- URL
- destination contract
- encoded action data
The proposal is stored under the Governance contract, assigned the proposal send-block hash as its ID, and added to the votable hash set so pillars can vote on it.
The proposal must pay the configured ProjectCreationAmount, similar to existing proposal-style embedded flows.
Action Types And Thresholds
Governance actions are split into two types with different voting periods and approval thresholds.
Type 1: Spork Actions
Actions targeting the Spork contract are Type 1.
These include:
- creating a spork
- activating a spork
A Type 1 action requires:
- more yes votes than no votes
- yes votes greater than 66% of active pillars
Type 1 actions also have a longer voting period.
Type 2: Administrative Actions
Other allowed governance actions are Type 2.
The current scope includes selected Bridge and Liquidity administrative methods. These are actions that previously depended on the contract administrator, but can now also be executed by Governance after a successful vote.
A Type 2 action requires:
- more yes votes than no votes
- yes votes greater than 50% of active pillars
Type 2 actions have a shorter voting period than Type 1 actions.
The implementation uses strict greater-than logic. Exactly 66% for Type 1 or exactly 50% for Type 2 is not enough; the yes vote count must exceed the threshold.
Voting
Active pillars can vote by pillar name or producer address.
An action passes only if it satisfies the threshold rules above and has more yes votes than no votes.
Execution is permissionless after that: anyone can call ExecuteAction, but the contract only executes if the proposal is still valid, not already executed, and has enough votes.
Execution
When a proposal passes, the Governance contract emits a contract-send block to the approved destination with the approved encoded data.
That means Governance does not directly mutate arbitrary state. It calls existing embedded contract methods through the normal VM path.
The PR also adds additional validation so governance proposals are constrained before voting:
- action data must be valid base64
- decoded action data is capped in size
- destination contracts are restricted
- destination methods are restricted
- the target method payload is statically validated before the proposal is accepted
This prevents pillars from voting on malformed or unsupported actions that would fail later at execution time.
RPC API
The PR adds a public RPC namespace:
embedded.governance
With methods for reading governance actions, including:
- get action by ID
- list all actions with pagination
- include vote breakdown
- include expired status
Why This Matters
This PR moves some protocol administration from trusted key/admin flows toward an on-chain pillar voting process.
It is intentionally narrow in scope. Governance v1 does not allow arbitrary execution. It provides a controlled path for specific protocol operations, especially spork management and selected Bridge/Liquidity administration.
In practical terms, it gives the network a foundation for coordinating protocol changes through transparent on-chain proposals, votes, and execution.
