SOVEX
CBDC Data Centers Sovereign AI Tokenization Deep Tech Architecture About Team Request access
Architecture / Architecture / Zero-custody isolation

Zero-custody isolation.

The owner holds the root of trust, and nothing built or operated by Sovex can move value without a signature the owner alone produces. There is no operator override, no recovery backdoor, and no privileged path around the keys.

The signing authority begins and ends inside the owner's boundary

Every settlement action traces to a key the central bank or institution generates, holds, and never exports.

01

Owner-generated root keys

Root signing keys are generated inside the owner's hardware security modules during a witnessed ceremony. Sovex supplies the procedure and the software, not the entropy, and never receives the private material.

02

ML-DSA-65 signatures

Issuance and settlement authorizations are signed with ML-DSA-65 (FIPS 204), a post-quantum lattice scheme. Verification keys are public; the private half exists only within the owner's HSM boundary.

03

No shared custody tier

There is no escrow account, omnibus wallet, or Sovex-held reserve through which funds transit. The system is non-custodial by construction, so there is no balance for an operator to freeze, lend, or lose.

04

Delegation is explicit

Operational sub-keys can be derived and scoped by the owner, but each carries a signed delegation record naming its authority and expiry. Revoking the delegation is a single signed act that the ledger enforces immediately.

There is no privileged path that bypasses the owner's key

The absence of a backdoor is a design property that can be inspected, not a promise in a contract.

01

No master or recovery key

The codebase contains no escrow key, no vendor-held recovery seed, and no dual-control override reserved for Sovex. Loss of the owner's keys is a governance event for the owner to plan for, not a door Sovex can open.

02

Verification-only software

Sovex-operated components verify signatures and enforce the ledger; they never hold the authority to originate one. A compromised operator process can halt or be halted, but it cannot mint, move, or reassign value.

03

Reviewable signing surface

The set of code paths that can produce a valid authorization is small, isolated, and available for external audit. Owners and their auditors can confirm that path runs only inside owner-controlled hardware.

04

Reproducible builds

Deployed binaries are built reproducibly from published source so the owner can confirm the running system is the audited system. A backdoor cannot be smuggled in through an opaque build.

Operating the rails is separated from authorizing them

Sovex can run availability, upgrades, and observability without ever crossing into signing authority.

01

Least-privilege operations

Operational access covers uptime, patching, and telemetry. None of it grants read access to key material or the ability to submit a settlement instruction on the owner's behalf.

02

In-nation residency

Keys, ledger state, and the authorization boundary reside on infrastructure inside the owner's jurisdiction. Cross-border operation of the software never implies cross-border movement of the trust root.

03

Break-glass is owner-owned

Emergency procedures such as halting issuance or rotating a compromised sub-key are actions the owner signs. Sovex can recommend and prepare them, but cannot execute them unilaterally.

04

Auditable operator actions

Every operational change to the deployment is logged into the same tamper-evident record as settlement events. Who deployed what, and when, is as inspectable as who authorized a transfer.

Isolation is anchored in hardware, not policy alone

The boundary between operators and keys is enforced by the silicon that holds the private material.

01

HSM-resident keys

Private keys never leave the HSM in plaintext. Signing happens inside the module; the outside world sends a payload to be signed and receives only the signature.

02

Quorum-gated signing

High-authority operations such as issuance require an m-of-n quorum of owner-held credentials to activate the HSM. No single officer, and no Sovex party, can unlock the signing function alone.

03

Attested execution

The verifying and ledger components run in environments that produce remote attestation, so the owner can confirm the exact code holding the boundary. Drift from the approved image is detectable.

04

Physical residency of the root

The HSM cluster is sited within owner-controlled facilities under owner physical security. The most sensitive part of the system is the part the owner physically holds.

The owner can prove custody rather than assume it

Isolation is only meaningful if the owner can independently confirm it holds.

01

Public verification keys

Anyone can check that a given settlement was authorized by the owner's published key. Authenticity of an action does not depend on trusting Sovex's word.

02

Independent audit path

External auditors can exercise the signing boundary, inspect the source, and confirm no alternate authorization route exists. The design invites this inspection rather than obscuring it.

03

Continuous integrity checks

The ledger's hash chain lets the owner detect any attempt to insert an action that its key did not produce. A forged or backdoored entry breaks the chain and is caught.

04

Exit without dependence

Because the owner holds the keys and the state resides in-nation, the owner can operate, migrate, or wind down the system without Sovex holding a hostage credential. Sovereignty includes the freedom to leave.

Build it sovereign.

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