Skip to main content

​
Purpose and Scope

This document provides an overview of the StableNet governance system, which implements a protocol-native, three-layer governance architecture.
The governance system manages validator operations, token mint/burn authority, and protocol-level decisions through a set of genesis-deployed system contracts. For detailed information on specific components, refer to: For consensus and validator operations, see
Anzeon WBFT Consensus Protocol and
Validator Governance (GovValidator).

​
Three-Layer Governance Architecture

StableNet implements a three-layer governance model, where each layer has clearly separated responsibilities and is operated through quorum-based voting among its members. Unlike public blockchains where governance is driven by token holders, StableNet governance is distributed across professional operators, financial institutions, and protocol administrators, reflecting its stablecoin-centric design.

​
Governance Layers

Governance LayerContractAddressPrimary Responsibility
Validator GovernanceGovValidator0x0000000000000000000000000000000000001001Validator set management, gasTip policy, providing validators/BLS keys at epoch transitions
Master Minter GovernanceGovMasterMinter0x0000000000000000000000000000000000001002Approved minter registry, minter list and per-minter allowance caps
Minter GovernanceGovMinter0x0000000000000000000000000000000000001003Proof-based mint/burn execution, actual issuance and burning via NativeCoinAdapter
Council GovernanceGovCouncil0x0000000000000000000000000000000000001004Global blacklist and authorized account sets, integration with AccountManager
The NativeCoinAdapter, deployed at
0x0000000000000000000000000000000000001000,
provides an ERC-20 interface for the native stablecoin. Decisions made by GovValidator, GovMasterMinter, GovMinter, and GovCouncil are ultimately reflected as actual balance changes through this adapter.

​
Validator Governance

Purpose:
Manage the validator set that operates the blockchain and participates in consensus. Key Responsibilities:
  • Registering and removing validators through collective approval
  • Managing operator keys, validator keys, and BLS keys
  • Defining the network-wide mandatory gas tip (gasTip)
  • Handling epoch transitions and validator set rotation

​
Minter Governance

Purpose:
Control the issuance and destruction of the native stablecoin. Key Responsibilities:
  • Proof-based minting and burning tied to fiat deposits and withdrawals
  • Quorum-based approval and execution
  • Preventing arbitrary issuance by a single entity

​
Master Minter Governance

Purpose:
Manage the registry of entities allowed to participate in mint/burn operations. Key Responsibilities:
  • Adding and removing minters
  • Enforcing per-minter maximum allowance limits
  • Supporting future extensible minter types (e.g., bridges, system minters)

​
Council Governance

Purpose:
Manage global account-level policies across the network. Key Responsibilities:
  • Defining and updating the blacklist account set
  • Defining and updating the authorized account set
  • Enforcing Anzeon-specific policies during transaction validation and state transitions via integration with the AccountManager precompile

​
Immutability and Upgrade Model

All governance contracts are deployed at genesis with immutable code.
They cannot be upgraded through on-chain permissions or proxy mechanisms. Any change to governance logic requires a protocol upgrade (hard fork), ensuring predictability and resistance to governance capture.

​
Quorum-Based Voting Mechanism

All governance contracts share a common governance base (GovBase) and therefore follow the same proposal lifecycle:
  • Membership snapshot–based proposal creation
  • Bitmap-based vote tracking
  • Transition to executable state upon quorum reach
  • Automatic invalidation via expiry, cancellation, or member version changes

​
Integration with Consensus

The governance system is directly integrated with Anzeon WBFT consensus:
  • Validator sets are loaded from GovValidator at epoch blocks
  • BLS keys are included in consensus message signing
  • Validator additions and removals take effect starting from the next epoch

​
Relationship with Other Components

The governance system coordinates and constrains StableNet’s:
  • Consensus and validator operation
  • Transaction pool admission rules
  • Block production
  • State transition rules
  • Gas fee and priority policies
Together, these governance layers form the policy backbone of StableNet, ensuring that operational authority, monetary control, and account-level restrictions are applied consistently and transparently across the protocol.