Reference Architecture

Reference architecture for S.I.G.N. (Money, ID, Capital) and how Sign Protocol + TokenTable compose across public/private rails.

Purpose

This page defines a reference architecture for S.I.G.N. deployments. It is written to be:

• implementation-neutral (works with different sovereign constraints),

• operator-friendly (clear roles and trust boundaries),

• audit-ready (explicit evidence artifacts),

• integration-ready (legacy rails + standards).

Audience

• Sovereign operators (central bank infra, GovTech platform teams)

• System integrators (banks/PSPs/telcos, identity vendors)

• Builders (wallets, program operators, auditors)

Architectural invariants

S.I.G.N. is designed around five invariants:

1. Controllable privacy

   • private to the public,

   • auditable to lawful authorities,

   • minimal disclosure by default.

2. National performance

   • built for millions of users, multi-operator workflows, strict SLAs.

3. Sovereign control

   • key custody, upgrades, emergency controls, and oversight remain under sovereign governance.

4. Interoperability

   • standards-aligned identity (VC/DID),

   • standards-aware payments (ISO 20022),

   • compatibility with public + private rails.

5. Inspection-ready evidence

   • every critical action emits durable evidence:

     • who authorized what

     • under which authority

     • when

     • based on which identity/eligibility proof

     • with what rule version

---

High-level component diagram

A reference decomposition (logical, not vendor-specific):

• Public Rail (Transparent Mode)

  • L2 sovereign chain or L1 smart contracts

  • suitable for public finance transparency, open verification, global access

• Private Rail (Confidential Mode)

  • permissioned CBDC infrastructure (e.g., Fabric-based)

  • suitable for privacy-sensitive retail flows and regulated confidentiality

• Identity Stack

  • issuers (government agencies / authorized institutions)

  • holder wallets (non-custodial)

  • verifiers (banks, agencies, service providers)

  • trust registry + revocation/status

• Trust & Evidence Layer (Sign Protocol)

  • schema registry (structured templates)

  • attestations (verifiable records)

  • privacy modes (on-chain / off-chain / hybrid / ZK)

  • indexing + query (SignScan / REST / GraphQL)

• Program Engine (TokenTable / Distribution + Asset Engine)

  • eligibility rules

  • batch distribution

  • scheduling

  • conditional logic

  • asset tokenization + registry integration

  • audit trail + reconciliation

---

Trust model and roles

A typical sovereign trust model uses explicit roles:

• Sovereign Authority

  • defines policy rules, signs governance approvals

  • owns root governance keys or approval process

• Operators

  • run infrastructure components (indexers, APIs, chain nodes, bridges)

  • do not unilaterally control policy

• Issuers

  • issue credentials (VCs) and/or attestations

  • must be registered in a trust registry

• Holders

  • citizens, residents, businesses

  • hold credentials in non-custodial wallets

• Verifiers / Relying Parties

  • service providers verifying credentials/attestations

• Auditors / Supervisors

  • authorized parties that can inspect evidence and reconcile programs

Design rule: Separate duties between (i) policy definition, (ii) issuance, (iii) operations, and (iv) audit.

---

Data placement model

S.I.G.N. deployments must explicitly define where data lives.

1) What should be off-chain (typical)

• PII (name, address, biometric templates, passport scans)

• sensitive program enrollment payloads

• internal case files

2) What should be on-chain (typical)

• commitments/hashes of records

• attestations and schema IDs (when safe)

• revocation/status registries

• audit hashes + rule version hashes

• transaction settlement references

3) Hybrid patterns (recommended)

• keep sensitive payloads off-chain (encrypted),

• store references + integrity anchors on-chain,

• index only what is needed for verification.

---

Reference technical specifications (summary)

This section is meant to guide planning and procurement, not constrain implementations.

Public rail (Layer 2 reference)

• Runtime: EVM-based

• Block time: < 1 second

• TPS: up to ~4000 (reference)

• Consensus: PoA / PBFT variants

• Finality: 1–5 blocks (reference)

Private rail (CBDC reference)

• Consensus: Arma BFT

• Throughput: 100,000+ TPS (reference)

• Finality: immediate on commitment

• Privacy: namespaces + configurable ZK privacy

• Token model: UTXO via Fabric Token SDK

• Identity: X.509 certificates (MSP)

• Standards: ISO 20022 compatible

• Namespaces: wCBDC, rCBDC, Regulatory

  • wCBDC: RTGS-like transparency

  • rCBDC: high privacy (ZK)

National Digital Identity stack (reference)

• VC model: W3C Verifiable Credentials 2.0

• DID: W3C DIDs

• Formats: VC-JWT, SD-JWT VC, JSON-LD with BBS+

• Signatures: ECDSA, EdDSA, RSA

• ZK: Groth16 / Plonk / BBS+ (unlinkability)

• Issuance: OIDC4VCI

• Presentation: OIDC4VP

• Revocation: W3C Bitstring Status List

• Offline: QR + NFC presentation

• mDL compatibility: ISO/IEC 18013-5/7

TokenTable (reference)

• Distribution size: unlimited

• Throughput: max chain TPS

• Scheduling: second-level granularity + calendar months

• Audit trail: on-chain

---

End-to-end flows (canonical)

Flow A: Eligibility → Distribution → Audit (most common)

1. Issuer issues VC (eligibility credential) to holder wallet

2. Holder proves eligibility to a program engine (selective disclosure)

3. Program engine generates a distribution batch

4. Settlement occurs on:

   • private rail (CBDC) for confidentiality, or

   • public rail (stablecoin) for transparency

5. Evidence is produced:

   • eligibility proof reference

   • rule version hash

   • distribution manifest hash

   • settlement references

Flow B: Cross-rail conversion (CBDC ↔ Stablecoin bridge)

1. User requests conversion

2. Compliance checks run (identity, limits, AML)

3. Atomic mint/burn or lock/release occurs

4. Evidence: signed approval + conversion record + settlement references

Flow C: Registry update (RWA tokenization)

1. Registry authority validates a property/asset record

2. TokenTable tokenizes ownership/transfer rules

3. Transfers are permitted only for eligible parties (whitelists, jurisdiction rules)

4. Evidence: registry sync logs + transfer approvals + ownership chain

---

Where to go next

• Governance and operational control: Governance & Operations

• Privacy and threat model: Security & Privacy

• Use cases:

  • New Money System

  • New ID System

  • New Capital System

• Deep developer docs (protocol layer): For Builders