Two familiar choices, both unworthy of a sovereign
A nation or a regulated institution that wishes to settle value on a blockchain has, until now, been offered only two paths -- and each asks it to surrender something it cannot afford to give up.
The first is to rent a public chain. A public network such as Ethereum grants programmability and a large developer ecosystem, but it is governed by an anonymous, global community, subject to no jurisdiction, and deliberately blind to policy: it will settle any validly signed transfer between any two addresses. Compliance -- identity, sanctions, transfer limits -- can only be layered on top, in an application or an off-chain gatekeeper, where it can be bypassed, forked, or simply ignored. A regulator can never obtain, from the protocol itself, the assurance that a prohibited transfer is impossible, because the protocol holds no concept of prohibition.
The second is to build a chain from scratch. This restores control, but at a price few ministries or central banks can bear: a consensus engine, a virtual machine, a compliance layer, currency issuance, cross-border settlement, upgrade tooling, key custody, and a continuous operations fabric -- each a specialist discipline, together a programme of roughly forty to one hundred million dollars over three to four years, with a high failure rate and no ecosystem to inherit.
The Sovereign Cell is the answer to a nation that concludes, rightly, "we need our own chain -- but we cannot build one."
The third path: your own chain on a shared core
A Sovereign Cell collapses the multi-year build into a provisioning exercise. It is a distinct, self-governing blockchain -- its own chain identity, its own genesis, its own validators, its own currency, its own rulebook -- provisioned upon the shared JIL Core. "Shared core" means the same proven engine, never the same chain: every cell runs the identical software, yet each is a separate network under the exclusive command of its operator.
That engine pairs two well-understood technologies. CometBFT provides Byzantine-fault-tolerant consensus -- standard, production-class agreement, not novel cryptography a state must accept on faith. Above it sits a deterministic Rust application that executes transactions and commits state so that every node agrees on a single hash at every block. To this the cell adds a real Ethereum-style virtual machine, so that developers deploy contracts with the tools and patterns they already know.
Compliance native to consensus
The single property that sets a Sovereign Cell apart from any public chain is that the rulebook lives inside the protocol, not above it. Identity and KYC level, jurisdiction zone, sanctions status, per-transaction limits, and reserve policy are evaluated within consensus and within the virtual machine as a condition of finality. The compliance engine fails closed: an action that breaches policy is not settled, and its rejection carries an explicit, auditable reason -- identity below the required level, over limit, sanctions match, missing attestation.
The virtual machine itself is extended so that a contract may ask the protocol, at the moment of execution, whether a transfer is permitted, and receive an authoritative answer drawn from live on-chain state. Movement across jurisdiction zones is denied by default. The result is a paradox resolved: the open, permissionless developer experience of a public chain, held within the permissioned control of a sovereign rulebook. Developers build freely; the state's rules are never optional.
The essence of a cell
Your chain, your validators, your rules, your currency -- with the programmability of a public network and enforcement written into consensus, standing on a core that JIL keeps hardened on your behalf.
Currency issued under the rulebook
Upon its cell, an authorized issuer may bring a regulated digital currency into being -- a stablecoin or a CBDC-adjacent instrument -- defined by a currency object that names its issuer, its authorities, its maximum supply, and the very policy that governs it. Every mint is issuer-signed; every transfer passes the same in-consensus compliance gate. The instrument therefore cannot move to an ineligible or sanctioned holder, because the protocol itself refuses the transfer. A reserve reference may be pinned on-chain, so that backing is a matter of record rather than assertion.
Cells that federate
A Sovereign Cell need not stand alone. Two or more nations, each running its own cell, may settle between them across governed corridors and trust-minimized inter-cell transport. Neither surrenders its rulebook to a shared intermediary: incoming value is re-examined against the destination's own arrival policy before it is credited, and cryptographic proof of the source's finality is verified rather than trusted. Each state keeps its rules; value still crosses the border.
Provisioned in about two weeks, kept hardened by JIL
Because the hard, domain-specific work is already built into the core, standing up a cell is a matter of roughly two weeks rather than years: preflight, a genesis ceremony, the service stack, the binding of the jurisdiction's policy zone, and certification against live signals before the cell is permitted to activate. Thereafter JIL maintains the shared core -- security patches, hardening, and improvements -- while the sovereign retains exclusive command of its chain, its keys, and its currency.
An honest word on maturity. The capability is demonstrated today on live reference cells, each issuing its own regulated currency and federated with the other. Those reference cells run as a single validator node at present; genuine multi-host Byzantine fault tolerance, and post-quantum signatures within the consensus finality path, are on the hardening roadmap and are addressed as part of a sovereign engagement -- not represented as already shipped. What is proven is the model itself: a compliance-native chain, under a nation's own control, standing on a shared and maintained core.