New Money System (CBDC & Stablecoins)

CBDC and regulated stablecoin infrastructure with dual public/private rail architecture, bridging, and sovereign controls.

Purpose

The New Money System provides a sovereign digital money rail that supports:

• CBDC (privacy-sensitive, permissioned mode), and/or

• regulated stablecoins (transparent public mode)

under one national infrastructure with policy-grade controls, real-time settlement, and supervisory visibility.

Audience

• Central banks / treasury operators

• Regulated financial institutions (banks, PSPs, telcos)

• Builders integrating wallets, merchant acceptance, or program disbursement

• Auditors and supervisors

---

Architecture overview (dual-path)

S.I.G.N. supports two complementary approaches:

A) Public blockchain approach (transparent mode)

Reference options:

• Layer 2 sovereign chain (max operational independence)

• Layer 1 smart contracts (direct access to existing ecosystems)

Use when:

• transparency is desired (public finance reporting),

• global liquidity and composability matter,

• cross-border interoperability and open verification are required.

B) Private blockchain approach (CBDC mode)

Reference: Hyperledger Fabric X–based CBDC for privacy-first operations.

Use when:

• retail privacy is required,

• strong permissioning is required,

• supervisory visibility must be controlled with lawful access.

---

Public blockchain approach (reference)

Deployment option 1: Layer 2 sovereign chain

Characteristics:

• operational independence: government controls block production and validator/sequencer set

• customizable consensus (PoA / PBFT variants)

• security inheritance via state commitments to an underlying L1

• exit mechanisms to L1 in case of failure

• governance: chain-level governance for parameters and upgrades

Reference specs (illustrative; may vary by deployment):

• Runtime: EVM-based

• Block time: < 1 second

• TPS: up to ~4000

• Finality: 1–5 blocks

Deployment option 2: Layer 1 smart contracts

Characteristics:

• simpler deployment (no separate consensus infrastructure)

• inherits L1 security model

• direct ecosystem integration (where policy allows)

• governance via upgradeable patterns and multisig

• compliance controls via contract-level access control (roles/whitelists)

Quick decision guide

Choose Layer 2 if you need:

• maximal operational independence

• customizable consensus and chain parameters

Choose Layer 1 contracts if you need:

• fastest path to integrations

• lowest operational overhead

---

Private blockchain approach (CBDC reference)

Reference capabilities:

• Consensus: Arma BFT

• Throughput: 100,000+ TPS (reference)

• Finality: immediate upon commitment

• Privacy: namespaces + configurable ZK privacy

• Token operations: UTXO model (Fabric Token SDK)

• Transaction model: peer-to-peer negotiation (Fabric Smart Client)

• Identity: X.509 certificates with MSP

• Governance: central bank–controlled consensus nodes

• Standards: ISO 20022 compatible

• Namespaces: wCBDC / rCBDC / Regulatory

  • wCBDC: RTGS-like transparency

  • rCBDC: high privacy (potentially ZK)

Interpretation:

• This model supports privacy-sensitive flows without sacrificing auditability for authorized authorities.

• It enables multiple privacy tiers under one rail.

---

CBDC ↔ Stablecoin bridge (controlled interoperability)

The bridge enables conversion between:

• private CBDC accounts (confidential mode), and

• public stablecoin accounts (transparent mode)

Security requirements (reference)

A bridge should implement:

• atomicity (no partial completion)

• policy checks (limits, eligibility, AML/CFT checks per local policy)

• rate/volume controls (per identity, per institution, per day)

• emergency controls (pause, rollback procedures)

• evidence logging (signed approvals plus conversion record)

Operational flow (reference)

1. User or institution requests conversion

2. Compliance checks run (identity, limits, sanctions/AML per policy)

3. Convert:

   • burn/lock on source rail

   • mint/release on destination rail

4. Emit evidence artifacts:

   • conversion request ID

   • approvals and ruleset version/hash

   • settlement references (tx hash or commit ID)

---

Program flows (canonical)

Flow 1: Government-to-person (G2P) disbursement

1. Verify identity + eligibility (New ID System)

2. Select rail:

   • CBDC for privacy-sensitive programs

   • stablecoin/public rail for transparency-first programs

3. Generate distribution batch (TokenTable)

4. Settle payments

5. Produce an audit package (manifest + settlement refs + rule version)

Flow 2: Merchant acceptance

Typical requirements:

• wallet compatibility and recovery model

• settlement finality expectations

• fee model (sponsored vs user-paid)

• refund/reversal policy (governed)

• evidence logging for disputes

Flow 3: Cross-border flows (reference)

When required, align with ISO 20022 message structures for interoperability and reporting.

---

Evidence artifacts (minimum set)

Distribution batch manifest (example)

{
  "program_id": "WELFARE_Q2_2026",
  "ruleset_version": "v3",
  "ruleset_hash": "0xabc...",
  "generated_at": "2026-04-01T12:00:00Z",
  "asset": "CBDC",
  "rail": "private",
  "recipients": [
    {
      "subject_ref": "did:example:citizen:8f1c...",
      "eligibility_proof_ref": "attestation:0x123...",
      "amount": "100.00",
      "currency": "CBDC",
      "settlement_ref": "fabric_commit:0000a1b2..."
    }
  ]
}

Compliance check log (example)

{
  "check_id": "AMLCHK_2026_04_01_00042",
  "subject_ref": "did:example:citizen:8f1c...",
  "checks": ["sanctions", "limits", "jurisdiction"],
  "result": "pass",
  "performed_by": "operator:cb-compliance",
  "performed_at": "2026-04-01T11:59:20Z"
}

---

Where to go next

• Identity prerequisites: New ID System

• Distribution engine: New Capital System and TokenTable

• Evidence layer (developer docs): Getting Started