Post 2: Why One Chain Is Not Enough — The Multi-JAM Federation
This is the third post in a series expanding on our governance stack.
Today: Layer 0 - Infrastructure for planetary scale.
JAM is arguably the most ambitious distributed systems architecture ever seriously attempted. A single JAM instance with 1,023 validators and ~341 parallel cores can handle theoretical throughput that dwarfs anything that existed five years ago.
And it is still not enough for 8 billion people.
This is not a criticism of JAM. It is a physics constraint.
Why One Instance Has a Ceiling
The validator count in JAM is not an arbitrary engineering choice — it is an optimum. Network overhead grows quadratically: V × (V−1) / 2 connections. Erasure coding distribution scales with every validator. The QUIC networking layer is tuned for ~1,000 nodes. Beyond this range, you are fighting the speed of light.
Network overhead in BFT consensus grows quadratically with validator count — O(n²) message complexity (arXiv:2303.11045 ( [2303.11045] SoK: Scalability Techniques for BFT Consensus )). At 1,000 globally distributed nodes, a single consensus round already costs ~1–seconds in pure light-speed latency. At 5,000 nodes: 25× more connection pairs, but light doesn’t get faster. This is not an engineering limitation, it is physics.
For governance applications — one vote per person per day — a single JAM instance could theoretically serve tens of billions of daily transactions. But governance is the easy case. DeFi, identity revalidation, smart contract execution, and real-time applications generate 1–100 transactions per minute per user. At planetary scale with diverse applications, a single instance becomes a bottleneck not by design failure, but by physical necessity.
The solution is not to make the single instance bigger.
The Historical Pattern
Every major networked system that has successfully scaled to planetary scope has solved this problem the same way: federation of sovereign instances.
The Internet (1970s–present): Autonomous Systems, each internally optimised, connected via BGP (Border Gateway Protocol). BGP is slow, inelegant, and occasionally breaks the internet for hours. It also runs the entire global Internet because 95%+ of traffic is local and the border bottleneck is acceptable. Nobody seriously proposes replacing it with a single global routing authority.
Cosmos/IBC (2019–present): The most direct prior art in blockchain, sovereign zones connected via IBC (Internet-Blockchain Communication Protocol). It demonstrates that federation works in practice, also reveals its limits: no shared security model, fragmented liquidity, weak economic alignment between zones. The Multi-JAM Federation learns from IBC’s architecture while leveraging JAM’s shared-security foundation something IBC explicitly chose not to do.
Swiss Federalism (1291–present):26 cantons with extensive self-governance. The federal government has only the powers explicitly delegated to it by cantonal consensus. The bottleneck — federal legislation — is slow by design. The system has been stable for over 700 years.
The pattern is consistent: accept the bottleneck at the borders. Design for 99% local interaction, 1% cross-boundary. The border is slow; make it rarely necessary.
The Multi-JAM Federation
N independent JAM instances — JAM Regions — each with its own validator set, its own consensus, its own state, connected through an Inter-JAM Relay for cross-region communication.
Each region is fully sovereign. The federation imposes no rules on regions — it provides a protocol for voluntary cross-region interaction. Subsidiarity enforced by protocol.
Example configuration (8 regions, global scale):
Region Validators Population Served
JAM Europe 1,023 ~750M
JAM East Asia 1,023 ~1.7B
JAM South Asia 1,023 ~2B
JAM Americas 1,023 ~1B
JAM Africa 1,023 ~1.4B
JAM Middle East 1,023 ~400M
JAM Oceania/Pacific 1,023 ~50M
JAM Global Commons Cross-region services + dispute resolution
Aggregate throughput: ~8M TPS. Each regional validator set is economically self-sustaining. The bottleneck, the Inter-JAM Relay , handles only cross-region traffic.
The bottleneck is a feature. Economic crises don’t instantly propagate across regions. A governance capture in one region cannot immediately affect others. A validator cartel in one region cannot compromise the rest.
The Ring Closure Protocol
Cross-region finality is the hard problem. Within a single JAM instance, finality is local and well-defined. But cross-region transactions require both regions to agree that a state transition has occurred — and neither can simply trust the other’s internal finality.
We propose the Ring Closure Protocol: a periodic, VRF(Verifiable Random Function) triggered cross-region checkpoint.
At unpredictable intervals, determined by on-chain VRF, so no one knows when the Inter-JAM Relay broadcasts a Ring Closure Request to all regions. Each region’s active validators must respond with their current state root, signed with their session key. When a 2/3 supermajority of all registered regions have responded, the checkpoint is sealed: all state up to that point is globally final across the entire federation.
VRF fires (unpredictable timing)
→ Inter-JAM Relay: “Ring Closure Request, challenge C”
→ Each region: validators sign (state_root || C) with session key
→ When 2/3 regions respond: Global Checkpoint #N is sealed
→ All cross-region transactions before #N: globally final
→ Between checkpoints: local txs run freely, cross-region txs pending
The unpredictability of timing is intentional as it prevents validators from gaming the checkpoint by temporarily coming online only when needed. This mirrors the same VRF-challenge principle used in the Iris Oracle: the response must be immediate and involuntary, not premeditated.
This is conceptually related to GRANDPA extended across chain boundaries, and to Tendermint BFT commits — but asynchronous and federated. Between checkpoints, local transactions run freely and at full speed. Only cross-region finality requires waiting.
Four Open Engineering Challenges
We present the Multi-JAM Federation as an architectural direction, not a finished protocol. Four concrete problems must be solved. We describe each honestly, with our initial thinking — clearly marked as unvalidated.
Challenge 1: Validator Authentication Across Region Boundaries**
How does Region B verify that a message claiming to originate from Region A was actually signed by Region A’s active validator set, and not forged?
Our direction: A region identifier embedded in session keys at registration time, anchored to a root of trust in the Inter-JAM Relay — similar to TLS certificate chains. The hard problem is the constitutional bootstrap moment: who initially decides which regions are legitimate? We propose a one-time bootstrap via Polkadot OpenGov referendum — the founding regions are ratified by DOT holders, after which the federation is self-governing. One-time centralisation, then permanently decentralised.
Question for the community: Is there a trust-minimised alternative to an OpenGov bootstrap?
Challenge 2: Governance Coretime Must Be Free**
If every transaction costs coretime, and coretime costs DOT, then voting costs money. Plutocracy re-enters through the infrastructure layer, even if the governance mechanisms above are perfectly egalitarian.
Our position: Governance participation — identity registration, vote casting, delegation — must be constitutionally exempt from coretime fees. Not subsidised, but carved out at the protocol level. A dedicated Governance Service on each JAM Region, funded from staking rewards and treasury — not per-transaction coretime sales. The costs are socialised across all token holders.
Question for the community: Is a protocol-level carve-out for governance coretime feasible within JAM’s service model?
Challenge 3: Regional Citizenship and the Residency Problem**
The naive model — one global identity, one vote everywhere — creates an unsolvable cross-region nullifier problem. How does JAM-Asia know this person isn’t already registered in JAM-Europe?
*A better model: Citizenship is regional by default. A person is a citizen of exactly one JAM Region — their home region. Cross-region votes without proven residency are discarded. This reframes the problem: Sybil resistance is no longer about preventing double registration globally — it is about verifying regional residency. And double registration across regions is not an attack, because those votes don’t count anyway.
The hard question becomes: how do you prove regional residency without revealing your location?
Our strongest candidate: OSNMA — Galileo Satellite Authentication. Since 2023, ESA’s Galileo system broadcasts cryptographically signed positioning signals that cannot be spoofed without access to ESA’s signing keys. A ZK-proof over an OSNMA-verified position fix could assert “I am in Europe” without revealing precise coordinates. This is physically unfakeable without being physically present in the region.
Longer-term: cross-validating OSNMA with GPS (US), GLONASS (Russia), and BeiDou (China) — four independent sovereign systems — significantly raises the bar for spoofing even if no single system is fully trusted.
Question for the community: Has anyone explored ZK-proofs over authenticated Galileo/GPS signals in a blockchain context? The OSNMA specification is public — is a ZK circuit over OSNMA signatures feasible with current proving systems?
Challenge 4: What Happens When a Region Wants to Leave?
Secession. Cross-region state that exists at the moment of departure. We don’t have a clean answer. We raise it as an open question.
Relation to Polkadot’s Existing Architecture
This proposal is forward-looking. JAM is still pre-launch. The Multi-JAM Federation is the layer beyond JAM — it assumes JAM is operational and asks what comes next.
Within the current Polkadot architecture, the closest analog is parachains connected via XCM. The federation model extends this concept to the relay chain level: instead of one relay chain coordinating many parachains, multiple relay chains (JAM instances) coordinate among themselves.
This aligns with Gavin Wood’s design philosophy for JAM: provide infrastructure, let governance emerge from the community. We are not proposing to impose a model on Polkadot. We are proposing the infrastructure that makes better governance possible.
Next post: Layer 2 — Evidence-Based Democracy. Five mechanisms, Futarchy at the core, and the oracle problem that is Futarchy’s Achilles heel.