# New Money System (CBDC & Stablecoins)

## 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](https://docs.sign.global/national-systems/new-money-system))
2. Select rail:
   * CBDC for privacy-sensitive programs
   * stablecoin/public rail for transparency-first programs
3. Generate distribution batch ([TokenTable](https://docs.sign.global/products-sign-ecosystem/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](https://docs.sign.global/national-systems/new-id-system)
* Distribution engine: [New Capital System](https://docs.sign.global/national-systems/new-capital-system) and [TokenTable](https://docs.sign.global/products-sign-ecosystem/tokentable)
* Evidence layer (developer docs): [Getting Started](https://docs.sign.global/for-builders/getting-started)