Skip to main content

​
Purpose and Scope

This document provides an overview of the StableNet blockchain protocol, its relationship with go-ethereum, and the key features added to support stablecoin operations. It includes the Anzeon WBFT consensus mechanism architecture, as well as system contracts that implement governance and stablecoin functionality. For detailed information on each subsystem, refer to the following documents:

​
StableNet Overview

StableNet is an EVM-compatible blockchain built as a fork of the WBFT protocol (originally derived from go-wbft). WBFT is an enhanced version of QBFT, and StableNet is designed for stablecoin operations using a Proof-of-Authority (PoA) architecture with Byzantine Fault Tolerance (BFT) consensus. The codebase extends go-ethereum in the following ways:
  • Anzeon WBFT Consensus Engine – Performs BFT consensus based on a validator set determined through governance, leveraging BLS signature aggregation to improve the efficiency of consensus message verification.
  • Five system contracts — Deployed at genesis and composed of NativeCoinAdapter (an ERC-20 wrapper for the native coin), GovValidator, GovMasterMinter, GovMinter, and GovCouncil. These contracts manage validator and minting governance while ensuring compatibility with stablecoin services by exposing an USDC-compatible interface.
  • Stablecoin-Optimized Gas Policy – Provides governance-controlled priority fees and a stable base fee mechanism.

​
Architecture Foundation

StableNet preserves the core go-ethereum architecture while adding StableNet-specific consensus and governance layers.

​
Diagram: StableNet Component Stack

Image Core Ethereum components (BlockChain, StateDB, EVM, TxPool) are retained, while Anzeon WBFT acts as the consensus engine. System contracts are deployed at genesis and can only be upgraded via hard forks.

​
Core Components

​
Consensus Engine: Anzeon WBFT

Anzeon WBFT is a Byzantine Fault Tolerant consensus protocol tailored to StableNet’s stablecoin-centric requirements. Unlike WBFT for public blockchains, it is optimized as follows:
  • No staking – Validators are managed through governance.
  • No block rewards – Maintains a non-inflationary token supply.
  • Governance-based validator selection – Determined by voting in the GovValidator contract.
  • Genesis-based activation – Not activated via mid-chain forks.
Consensus proceeds through the PREPARE → COMMIT → FINALIZATION stages, with BLS signature aggregation improving message verification efficiency. For detailed protocol behavior, refer to Anzeon WBFT Consensus Protocol.

​
System Contract Architecture

Five system contracts are deployed at fixed addresses at genesis to manage the protocol: Image

​
Contract Responsibilities

  • NativeCoinAdapter – Native ERC20 wrapper
  • GovValidator – Gas tip and validator management
  • GovMasterMinter – Minter registration
  • GovMinter – Mint/burn voting
  • GovCouncil – Blacklist and authorized account management
For details, refer to Governance System. For NativeCoinAdapter specifics, see the “NativeCoinAdapter” section below.

​
NativeCoinAdapter (Bridging Native Coin and ERC20)

NativeCoinAdapter provides an ERC20 interface over native balances without separate storage. It is compatible with the FiatTokenV2_2 specification (Circle USDC), allowing existing dApps to use the stablecoin without modification.

​
Stablecoin-Specific Features

​
Base Coin Policy

Unlike traditional blockchains that pre-mint the base coin at genesis, StableNet implements dynamic supply management:
  • Minimal genesis issuance – Only the funds required for initial operations are issued.
  • Minter-controlled supply – Approved minters can mint and burn tokens throughout operation.
  • Oracle role – Minters verify fiat deposits and withdrawals in traditional financial systems.
  • No inflation – There are no block rewards; total supply changes only via minting and burning.
  • Auditable supply – Total issuance always matches on-chain balances, with no hidden inflation.

​
Mint/Burn Protocol

Minting and burning are executed via quorum-based voting, preventing unilateral actions by a single minter and maintaining 1:1 fiat backing.

​
Gas Fee Policy

StableNet modifies EIP-1559 to preserve stablecoin stability. The Base Fee adjusts based on network utilization and is paid to validators instead of being burned. The Priority Fee is determined through GovValidator governance, and regular accounts must follow a mandatory tip. For details, refer to Gas Fee Policy.

​
Genesis Configuration

The genesis block initializes consensus timing (anzeon.wbft), initial validators (anzeon.init), and the configuration of the five system contracts. The genesis_generator CLI can be used to generate an appropriate genesis file. For detailed configuration, refer to Getting Started.

​
Node Architecture

Nodes initialize in the following order: load configuration → initialize genesis → set up P2P, blockchain, and consensus backends → start services. For detailed configuration and execution instructions, refer to Getting Started.

​
Development Tools

Key tools for working with StableNet include:
  • gstable – Main client binary (equivalent to geth functionality)
  • genesis_generator – Interactive genesis file generation tool
  • bootnode – Lightweight discovery node for private networks
  • devp2p – P2P network testing and DNS discovery deployment
  • clef – External signer for secure key management