Technical Specifications¶
This appendix is a reference for technical evaluation. Component Specifications gives the specifications of each component, grouped by building block, with the DataHub in a table of its own. Performance Figures collects every quantitative figure in one place and states the basis of each, so that published benchmarks, typical requirements, and design targets are not confused.
Component Specifications¶
| Sign ID (National Digital Identity) | |
|---|---|
| Credentials and identifiers | |
| Credential data model | W3C Verifiable Credentials 2.0 |
| Identifiers | W3C Decentralized Identifiers (DIDs) |
| Credential formats | VC-JWT, SD-JWT VC, JSON-LD with BBS+ |
| Revocation | W3C Bitstring Status List v1.0 |
| Trust registry | Ledger-anchored, OpenID Federation 1.0 compatible |
| Issuer identifiers | did:web under government domains, then a government-operated DID method |
| Credential status | Active, suspended, revoked, expired; issuer-signed, cacheable status lists |
| Transparency log | Registry changes, schema versions, status-list digests; no personal data |
| Cryptography and keys | |
| Signature algorithms | ECDSA (secp256k1, P-256), EdDSA (Ed25519), RSA |
| Zero-knowledge proofs | Groth16, Plonk, BBS+ (unlinkable credentials) |
| Key management | HSM-backed (FIPS 140-3 Level 3) |
| Wallet security | Device secure enclave, biometric authentication, encrypted local storage |
| Holder binding | National identity root at onboarding and recovery; device key bound to each presentation |
| Protocols and interoperability | |
| Issuance | OpenID for Verifiable Credential Issuance (OpenID4VCI) |
| Presentation | OpenID for Verifiable Presentations (OpenID4VP) |
| Offline presentation | QR code and NFC |
| Mobile documents | ISO/IEC 18013-5/7 (mDL) compatible |
| Sign Protocol | |
| Signature schemes | ECDSA, EdDSA, RSA |
| Zero-knowledge proofs | Groth16, Plonk, Honk, BBS+ |
| ePassport integration | ICAO 9303 compatible |
Table 6: Digital identity and credentials specifications
| Sign DataHub | |
|---|---|
| Anchoring network | Private permissioned network by default, on Hyperledger Besu (QBFT) or Hyperledger Fabric (BFT ordering); a public blockchain after review of every exposed field; anchors recorded as Sign Protocol attestations |
| Data sharing | Common versioned schemas; owner-approved record types for each consumer; access checked by purpose, role, case, and field; exchange receipts |
| Validators | Four in the reference topology (one fault tolerated), expandable to seven (two faults tolerated) |
| Finality modes | Direct on-chain finality; Merkle-batched finality |
| Cryptography | Canonical JSON, SHA-256, Ed25519 or a national scheme, X.509, mTLS, HSM |
| On-chain data | Commitments and minimal technical metadata; no record payloads |
| Keys | Separate keys for the legal decision, the source evidence, and the anchor submission |
| Verification | Source authenticity, evidence integrity, anchor record, network confirmation, and current status; the first four run offline |
| Recovery | Site restored within 4 hours, losing at most 15 minutes of configuration (design target) |
Table 7: Sign DataHub specifications
| Public blockchain: sovereign smart contracts | |
|---|---|
| Runtime | EVM-compatible public Layer 1 network, such as Ethereum |
| Consensus | The host network’s consensus and validator set |
| Access control | Contract-level role-based permissions, address whitelisting, and KYC integration |
| Upgrades and governance | Upgradeable proxy contracts; changes approved through multi-signature wallets held by authorized government entities |
| Transaction fees | Sponsored through contract-level logic or meta-transactions |
| Token standards | ERC-20 for stablecoins; ERC-3643, ERC-1400, ERC-4626, ERC-721, and ERC-1155 for tokenized assets (Real-World Asset Tokenization) |
| Emergency controls | Government-held pause of contract operations |
| Sign CBDC on Hyperledger Fabric-X | |
| Ledger and tokens | |
| Ledger platform | Hyperledger Fabric-X |
| Token framework | Panurus with Fabric Smart Client |
| Token model | UTXO with account-style balance views |
| Ordering | BFT consensus; reference profile of four consenters across primary and disaster recovery sites |
| Endorsement policy | Central bank plus at least one eligible bank |
| Finality | Immediate upon block commitment |
| Privacy and authorization | |
| Token privacy | ZKAT-DLOG without trusted setup (Pedersen commitments, serialized proofs) |
| Owner authorization | Idemix anonymous credentials bound to each transaction challenge |
| Policy enforcement | Mandatory Monetary Auditor gate before ledger submission |
| Hosting, custody, and keys | |
| Wallet Node hosting | Central bank platform, partitioned per bank (recommended), bank-operated, or a combination |
| Credential custody | Hardware-backed TEE or secure enclave in the servicing bank’s domain |
| Key management | HSM-backed certificate authority, TLS, and issuer keys; three-tier PKI |
| Interfaces | |
| Settlement messaging | MT-based RTGS profiles and ISO 20022 |
| Programmability | Approved templates; deterministic chaincode for ledger-atomic rules |
| Interoperability | Direct bridge, indirect stablecoin route, interoperability control plane |
Table 8: Sovereign money specifications
| Public services platform | |
|---|---|
| Channels | Mobile app, web portal, and assisted service points |
| Sign-in | Sign ID, with the Sign ID wallet embedded in the app |
| Services | Configurable workflows: forms, eligibility rules, credentials and documents, fees, approvals, deadlines |
| Payments | Sovereign digital money (CBDC or stablecoin) and bank rails |
| Distribution | Batch and scheduled payments; throughput bounded by the underlying ledger |
| Audit trail | Case history for every application; on-chain distribution records |
| Sovereign AI (Sign AI) | |
| Control layer | Sign AI workflow controls: permissions, approvals, case status, audit |
| Models | Government-approved open-weight models; optional external service through a masking gateway, where policy allows |
| Hosting | In-country: government data center, domestic hosting provider, or new national facility; recovery at a second domestic site |
| Assurance | ISO/IEC 27001, ISO/IEC 27701, ISO 22301, and SOC 2 Type II as targets; ISO/IEC 42001 for AI risk management; HSMs certified to FIPS 140-3 Level 3 or Common Criteria |
| Knowledge | Approved, versioned sources with evaluation and rollback |
| Answer policy | Every released answer cites an approved source |
| Human oversight | Authorized review before any action |
| Decision record | Sources and versions, model and rule version, consent, reviewer, final action |
| Integrations | National identity, service portals, government data through the DataHub |
Table 9: Public services and sovereign AI specifications
Performance Figures¶
| Component | Measure | Figure | Basis |
|---|---|---|---|
| Credential verification | Verification latency | P95 under 300 ms | Design target |
| Revocation propagation | P95 within 5 minutes | Design target | |
| Availability | 99.9% at pilot, 99.95% at national scale | Design target | |
| Sign DataHub | Sustained event intake | 2,000 events per second | Design target |
| Burst event intake | 5,000 events per second | Design target | |
| Acceptance latency | P95 under 300 ms | Design target | |
| Proof lookup latency | P95 under 500 ms | Design target | |
| Chain finality | Under 10 seconds | Design target | |
| Batch root interval | 60 seconds or less | Design target | |
| Availability | 99.9% | Design target | |
| Fault tolerance | One faulty validator in the four-validator reference topology | Reference design | |
| Hyperledger Fabric-X | Throughput, one organization on 16 VMs | Above 150,000 transactions per second | Published benchmark |
| National retail CBDC | Peak throughput | Tens of thousands of transactions per second | Typical requirement |
| Confirmation | One to two seconds | Typical requirement | |
| Availability | 99.95% or higher | Typical requirement | |
| Fault tolerance | One faulty consenter in the four-consenter reference profile | Reference design | |
| Sovereign AI compute | Pilot configuration | 4 GPUs, 1 rack, 6 kW IT capacity | Reference design |
| Production configuration | 2 AI servers with 8 data-center GPUs each, 2 racks, 40 kW IT capacity | Reference design | |
| Server failure | Essential traffic resumes within 5 minutes | Design target | |
| Recovery point | Up to 15 minutes of data loss | Design target | |
| Recovery time | Essential service restored within 4 hours | Design target |
Table 10: Performance figures and their basis
Each figure is labeled with its basis. A published benchmark is reported by the upstream project; a reference design figure follows from the reference topology; a typical requirement is what national programs usually specify; a design target is the figure a deployment is engineered and tested against. The performance of each deployment is established by acceptance testing in its target environment.