PRE-LAUNCH

Stable Value for Zimbabwe's Digital Economy

ZiGX is a reserve-backed digital settlement asset designed for USD-parity stability. Every token is backed by verified reserves, held by FCA-regulated institutional custodians, and enforced on-chain.

View Whitepaper

At a Glance

100% Reserve-Backed

ZiGX cannot be minted unless verified reserves equal or exceed total supply. Enforced at the smart contract level.

USD Parity

Designed for stable value referenced to the US Dollar. Settlement, not speculation.

FCA-Regulated Custody

Reserves are to be held by FCA-regulated institutional custodians. Segregated and independently auditable.

Locked Until 2030

Reserve assets locked on-chain until 1 January 2030. Immutable. No early withdrawal possible.

How It Works

Step 1

Reserves Deposited

Fiat reserves are deposited with FCA-regulated custodians. Oracle confirms reserve balance on-chain.

Step 2

Tokens Minted

ZiGX is minted only when the oracle verifies reserves ≥ total supply. Rate limits, proof validation, and staleness checks all enforced automatically.

Step 3

Transparent & Auditable

Proof-of-reserve merkle roots and IPFS report CIDs are published on-chain. Quarterly audit hashes stored immutably in the contract.

Technical Specs

Core Specifications

• Token standard: ERC-20 (Ethereum)
• Decimals: 6
• Max supply: 1,000,000,000 (1 billion)
• Minimum reserve ratio: 100% (10,000 bps)
• Reserve lock: Until 1 January 2030
• Smart contract developer: Boosty Labs
• Security audit: Pending (Hacken)

Governance

• Three-role model: Governance (Gnosis Safe multisig), Timelock (OpenZeppelin TimelockController), Guardian (emergency unpause only)
• All critical parameter changes require timelock delay (minimum 1 hour)
• Two-step propose/activate pattern for oracle and vault changes
• No single person can mint, pause, or alter parameters alone

Security

• ReentrancyGuard on all mint/burn functions
• Domain verification for oracle calls (chain ID + contract address)
• Proof replay protection (each proof can only be used once)
• Oracle staleness and TTL checks (stale data blocks minting)
• Per-transaction, hourly, and daily mint rate limits
• Emergency pause with guardian override
• 168 unit tests, fuzz testing, invariant tests, integration tests

Minting Process

1. Governance submits mint request with reserve proof
2. Oracle validates reserves and returns signed attestation
3. Contract verifies: reserve ratio ≥ 100%, rate limits OK, proof unused, oracle data fresh
4. Tokens minted, reserve cache updated
5. Events emitted for full transparency