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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sign.global/national-systems/new-money-system.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.