SOVEX
CBDC Data Centers Sovereign AI Tokenization Deep Tech Architecture About Team Request access
Security & Post-Quantum / Key custody / Zero-custody keys

Zero-custody keys.

The root of trust never leaves the owner. Sovex operates the rails; the state holds the keys — and no line of our code can sign in its place.

Sovereignty begins where the private key is generated

Zero-custody means the vendor is architecturally incapable of producing a valid signature on the owner's behalf.

01

Owner-generated roots

Root signing keys are generated inside the owner's own security boundary — their HSM cluster, their facility, their operators. Sovex software provisions the ceremony but is never present at generation.

02

No vendor key material

Sovex holds no copy, escrow, or derivative of any root private key. There is no master key, service key, or maintenance key that shadows the owner's authority.

03

No backdoor by construction

The absence of a vendor signing path is a structural property, not a policy promise. Signing endpoints require the owner's key handle; there is no alternate code path that bypasses it.

04

Post-quantum root

Roots are ML-DSA-65 (FIPS 204) signing keys, so the owner's long-lived authority is designed to survive the transition to quantum-capable adversaries.

The signing boundary is drawn around the owner, not the operator

Every privileged action resolves to a signature that only the owner can produce.

01

Sign-then-submit model

Clients construct a transaction or weight-release request, the owner's key signs it in their own boundary, and Sovex rails only accept an already-signed, verifiable payload.

02

Verification, not possession

The platform's role is to verify signatures against the owner's registered public keys and enforce policy — it never needs the private key to do its job.

03

Detached signatures

Signatures are detached and travel with the object they authorize, so authority can be checked independently of the service that transported it.

04

Air-gap compatible

Because signing is decoupled from submission, the owner can keep signing capability on an offline or network-isolated tier and move only signed artifacts across the boundary.

Non-custodial issuance means the central bank alone mints authority

For a sovereign CBDC, zero-custody is what makes issuance genuinely non-custodial.

01

Issuance under owner key

Minting, burning, and monetary-policy operations are authorized by the central bank's root key. Sovex cannot create or destroy value on the ledger without a signature it cannot forge.

02

Hash-chained accountability

Every signed monetary action is appended to a tamper-evident, hash-chained ledger, binding the owner's signature to an immutable position in history.

03

Delegated operational keys

The central bank can issue subordinate keys for day-to-day operations while retaining the root that certifies them, so operational convenience never dilutes ultimate control.

04

Revocable delegation

Delegated authority is expressed as owner-signed certificates with explicit scope and expiry, and can be revoked by the root without touching the underlying rails.

The same custody model governs sovereign AI weights

Owners hold the keys and the weights; releasing a model is a signing event.

01

Weights as signed assets

Foundation and specialized model checkpoints are sealed and released only under the owner's signature, so the nation controls which weights ever leave the training enclave.

02

In-nation residency

Key generation, signing, and weight storage all remain inside sovereign infrastructure, keeping the entire chain of authority within the owner's jurisdiction.

03

No silent export

There is no vendor path to extract, copy, or re-license weights, because every access-granting action must resolve to the owner's key.

04

Provenance binding

Signed release records tie a specific weight artifact to the training run and approving authority, giving the owner an auditable lineage for every deployed model.

Zero-custody is a claim the owner can independently verify

The design is meant to be inspected, not trusted on faith.

01

Auditable signing paths

The code paths that consume owner signatures are scoped and reviewable, so an auditor can confirm there is no parallel route that admits vendor authority.

02

Owner-controlled key registry

The set of public keys the platform will honor is administered by the owner, so no third party can inject a key that would be accepted as legitimate.

03

External audit underway

The custody boundary and its enforcement are part of the production-hardening and independent audit now in progress across the engines.

04

Fails closed

Any request lacking a valid owner signature is rejected rather than degraded to a lesser check, so the default outcome of ambiguity is no authority granted.

Build it sovereign.

Talk to us about zero-custody keys in a sovereign deployment.