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:

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

Controllable privacy
- private to the public,
- auditable to lawful authorities,
- minimal disclosure by default.
National performance
- built for millions of users, multi-operator workflows, strict SLAs.
Sovereign control
- key custody, upgrades, emergency controls, and oversight remain under sovereign governance.
Interoperability
- standards-aligned identity (VC/DID),
- standards-aware payments (ISO 20022),
- compatibility with public + private rails.
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

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

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.

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

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

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)

Issuer issues VC (eligibility credential) to holder wallet
Holder proves eligibility to a program engine (selective disclosure)
Program engine generates a distribution batch
Settlement occurs on:
- private rail (CBDC) for confidentiality, or
- public rail (stablecoin) for transparency
Evidence is produced:
- eligibility proof reference
- rule version hash
- distribution manifest hash
- settlement references

Registry authority validates a property/asset record
TokenTable tokenizes ownership/transfer rules
Transfers are permitted only for eligible parties (whitelists, jurisdiction rules)
Evidence: registry sync logs + transfer approvals + ownership chain

Last updated 6 months ago

Was this helpful?