Purpose and Scope
This page provides an overview of the five system contracts in StableNet, their fixed addresses, and the genesis deployment and initialization model.These contracts implement the core governance mechanisms for validator management, mint/burn authorization, and ERC-20 compatibility for the native stablecoin. For detailed documentation of each contract, refer to the following pages:
- NativeCoinAdapter Contract – ERC-20 wrapper for native balances
- Validator Governance (GovValidator) – Validator set management
- Minting Governance (GovMasterMinter and GovMinter) – Minter registration and proposals
- Council Governance (GovCouncil) – Blacklist and Authorized account policies
- Mint and Burn Protocol – End-to-end mint/burn workflow
The Five System Contracts
StableNet deploys five system contracts directly at predefined addresses during genesis block creation.These contracts are deployed without owners and do not use common upgrade patterns (such as proxies); they can be replaced only via hard forks.
| Contract Name | Address | Primary Purpose | Version |
|---|---|---|---|
| NativeCoinAdapter | 0x0000000000000000000000000000000000001000 | ERC-20 wrapper for native stablecoin balances; entry point for mint/burn | v1 |
| GovValidator | 0x0000000000000000000000000000000000001001 | Validator set management, BLS key registration, gas tip (gasTip) governance | v1 |
| GovMasterMinter | 0x0000000000000000000000000000000000001002 | Registry of approved minters and global maximum mint allowance caps | v1 |
| GovMinter | 0x0000000000000000000000000000000000001003 | Creation, voting, and execution of proof-based mint/burn proposals | v1 |
| GovCouncil | 0x0000000000000000000000000000000000001004 | Management of blacklists and Authorized account sets; AccountManager integration | v1 |
Contract Deployment Architecture
System contracts are deployed during genesis block creation via a state transition mechanism that writes both bytecode and initialized storage directly into the genesis state.Genesis Configuration Structure
System contracts are defined in the genesis file under theconfig.anzeon.systemContracts section, where the address, version, and initialization parameters for each contract are specified.
Versioning and Bytecode Storage
Contract bytecode is embedded into the node binary at compile time and indexed by contract name and version.The
SystemContractCodes map provides version-controlled access to the deployable bytecode.
The version validation process ensures that only supported contract versions can be deployed.
Contract Initialization Parameters
Each system contract requires specific initialization parameters to construct its storage state at genesis.These parameters are interpreted and validated by the contract-specific initialization functions.
Contract Dependency Graph
System contracts form a dependency hierarchy in which some contracts reference others.Understanding these dependencies is essential for correct configuration.
Storage Initialization Process
Each contract’s initialization function writes values to predefined storage slots.Initialization follows Solidity storage layout rules to compute slot addresses for mappings and dynamic arrays.
Contract Upgrade Mechanism
System contracts are deployed without owners and cannot be upgraded through standard contract mechanisms.The only supported upgrade path is via a hard fork.