# Reference Architecture

## 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](https://docs.sign.global/s.i.g.n./governance-ops)
* Privacy and threat model: [Security & Privacy](https://docs.sign.global/s.i.g.n./security-privacy)
* Use cases:
  * [New Money System](https://docs.sign.global/national-systems/new-money-system)
  * [New ID System](https://docs.sign.global/national-systems/new-id-system)
  * [New Capital System](https://docs.sign.global/national-systems/new-capital-system)
* Deep developer docs (protocol layer): [For Builders](https://docs.sign.global/for-builders/getting-started)