> ## Documentation Index
> Fetch the complete documentation index at: https://docs.stablenet.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Governance System

## 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:

* System contract deployment and initialization: [System Contracts Overview](/en/governance-system/5.1-system-contracts-overview)
* Native stablecoin ERC-20 wrapper: [NativeCoinAdapter Contract](/en/governance-system/5.2-nativecoinadapter-contract)
* Validator management and gas policy: [Validator Governance (GovValidator)](/en/governance-system/5.3-validator-governance-\(govvalidator\))
* Minting authority hierarchy: [Minting Governance (GovMasterMinter and GovMinter)](/en/governance-system/5.4-minting-governance-\(govmasterminter-and-govminter\))
* Account policy (Blacklist / Authorized): [Council Governance (GovCouncil)](/en/governance-system/5.5-council-governance-\(govcouncil\))
* Proof-based mint and burn protocol: [Mint and Burn Protocol](/en/governance-system/5.6-mint-and-burn-protocol)

For consensus and validator operations, see\
[Anzeon WBFT Consensus Protocol](/en/consensus-and-block-production/4.1-anzeon-wbft-consensus-protocol) and\
[Validator Governance (GovValidator)](/en/governance-system/5.3-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 Layer         | Contract        | Address                                      | Primary Responsibility                                                                      |
| ------------------------ | --------------- | -------------------------------------------- | ------------------------------------------------------------------------------------------- |
| Validator Governance     | GovValidator    | `0x0000000000000000000000000000000000001001` | Validator set management, gasTip policy, providing validators/BLS keys at epoch transitions |
| Master Minter Governance | GovMasterMinter | `0x0000000000000000000000000000000000001002` | Approved minter registry, minter list and per-minter allowance caps                         |
| Minter Governance        | GovMinter       | `0x0000000000000000000000000000000000001003` | Proof-based mint/burn execution, actual issuance and burning via NativeCoinAdapter          |
| Council Governance       | GovCouncil      | `0x0000000000000000000000000000000000001004` | Global 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.