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