Federation Model
The federation is a notary, not a host. Think of it like DNS or a notary public: you use it when you need to prove something to strangers or resolve disputes, not for every operation. Most routine agent-to-agent interactions do not need the federation at all.
What the Federation Provides
| Function | When Needed |
|---|---|
| Ordering | When two sovereign cells interact with the same third party and sequence matters |
| Nullifier tracking | When a sovereign cell spends a note from the shared note tree (double-spend prevention) |
| Discovery | When you need to find someone you do not already know (intent gossip) |
| Root anchoring | Periodic checkpoints so you can prove to strangers "my state was valid as of height H" |
What the Federation Does NOT Do (Sovereign Mode)
- Does NOT store your cell state -- only a 32-byte commitment hash.
- Does NOT execute your transitions -- you prove locally, it verifies the proof.
- Does NOT see transfer amounts -- committed conservation uses Pedersen commitments.
- Does NOT know recipients -- stealth addresses hide who receives value.
- Does NOT participate in peer-to-peer interactions between known parties.
When Do You Need the Federation?
| Situation | Need Federation? | Why |
|---|---|---|
| Transfer to a known peer | No | Direct proof exchange, both verify locally |
| Exercise capability on a peer's cell | No | Proof-carrying capability exercise |
| Prove state validity to a stranger | Yes | Needs an attested root anchor |
| Spend a note from the shared note tree | Yes | Nullifier ordering (double-spend) |
| Resolve a dispute over state | Yes | Need arbiter with ordering authority |
| Be discoverable (intent posting) | Yes | Gossip network for discovery |
| Trade on a public DEX (hosted cell) | Yes | DEX state is federation-maintained |
Federation Topologies
Single Federation
The simplest deployment: N nodes (typically 4-7) run Blocklace consensus with Cordial Miners, producing attested roots at regular intervals. A single-node federation (n=1) is the same code path -- no special "solo mode."
Cross-Federation
Bridge nodes connect to two (or more) federations' gossip networks and relay:
- Attested roots -- So agents in federation A can verify proofs from federation B
- Revocations -- Token revocations propagate across boundaries
- Receipts -- State proofs can reference cross-federation transitions
- Conditional proofs -- Atomic cross-federation operations via ConditionalTurn + ProofObligation
External Chains
- EVM (Base Sepolia): SP1 wraps STARK proofs in Groth16 for ~200k gas on-chain verification
- Midnight: Level 1 attestation bridge (implemented) + Level 2 ZKIR proof-carrying (designed)
- Mina: Native Pickles recursion via STARK-in-Pickles pipeline
Federation Exit and Sovereignty
Agents own their state. In sovereign mode, your cells exist on your machine. The federation stores only your commitment hash. To exit a federation, simply stop anchoring. Your state continues to exist locally. You can present it to any verifier who trusts your last attested checkpoint.
For hosted cells, export the receipt chain (or IVC-compressed constant-size proof). Any verifier can check the chain's integrity without contacting the original federation.
Persistence
Nodes survive restarts via redb (ACID, WAL, crash-safe embedded database):
- Blocklace blocks: Persisted incrementally. On restart, the node reconstructs its DAG view.
- Ledger checkpoints: Full state snapshot every 100 committed blocks.
- App state: JSON atomic snapshots for application services.
New nodes fast-sync by fetching the latest checkpoint instead of replaying the full Blocklace history.
Further reading
The cross-federation handshake, observation-bridge model, and threat
analysis for bridges to external chains live in
docs/anonymous-bridging-design.md and
TRUST_MODEL.md. The summary above covers the in-federation
consensus shape; the docs cover what changes when you span two of them.