The CBDC runs inside the jurisdiction that issues it. The central bank holds the signing keys, the data never crosses a border, and no operator — including us — can transact on the nation's behalf.
In-nation deployment means the entire issuance and settlement stack is physically and legally domiciled within the sovereign's territory.
Ledger state, transaction history, and account records are written only to storage located inside the jurisdiction. Replication targets are constrained to in-country facilities, so no operational data is ever staged, cached, or backed up abroad.
The stack is designed to run in the sovereign's own data centers or in facilities under its direct legal control. Sovex operates on-site or hands over operations entirely, rather than routing the nation's money supply through externally hosted infrastructure.
Signing, validation, and settlement compute run on nodes inside the border. There is no design path where a transaction is authorized or finalized on hardware outside the sovereign's legal reach.
Operational metrics and logs required for monitoring are kept in-nation by design. The deployment does not depend on phoning home to an external control plane to issue currency or clear payments.
Sovereignty is meaningless if the issuer cannot hold its own root of trust; the architecture puts every signing key in the state's custody.
The keys that authorize issuance and redemption are generated and held by the central bank. Sovex builds and operates the engine but never possesses the private material that mints or burns the currency.
Root keys are designed to live in hardware security modules under the sovereign's physical control, with generation ceremonies witnessed and recorded by the state. Key export is not part of the operational path.
Issuance and settlement are authorized with ML-DSA-65 (FIPS 204) signatures, so the custody model is built against a quantum-capable adversary rather than only classical attackers.
Holders and the issuer control their own keys; the platform validates signatures and enforces rules but cannot move value on anyone's behalf. There is no vendor master key that can seize, freeze, or transact against balances.
In-nation deployment is a handover model, not a hosting contract — the sovereign can take the wheel.
The platform is designed so operational responsibility can move from Sovex to the central bank's own staff over time, with runbooks, upgrade procedures, and incident playbooks transferred alongside the software.
Binaries the sovereign runs can be rebuilt from source they hold, so the state can verify that what executes matches what was audited rather than trusting an opaque vendor artifact.
Version changes to the issuance engine are gated behind the sovereign's approval. No remote party can push a silent update to the code that governs the national currency.
Because keys, data, and binaries are all in-nation, the deployment is designed to keep issuing and settling even if the relationship with the vendor ends or external connectivity is cut.
Sovereign control is paired with a ledger the sovereign — and its auditors — can independently verify.
Each block of state changes is cryptographically linked to its predecessor, so any retroactive edit to history breaks the chain and is detectable by anyone holding the head hash.
The central bank and its supervisors can run full verification against the ledger inside the border, without exporting sensitive records to a third party to prove correctness.
Every issuance, redemption, and policy change carries a post-quantum signature bound to the authorizing key, giving a durable, non-repudiable record of who acted and when.
The design lets the issuer reconstruct total money in circulation directly from signed ledger state, so the outstanding supply is a proven quantity rather than a reported figure.
Talk to us about sovereign in-nation deployment in a sovereign deployment.