THE PROTOCOL

Appearance

Sovereign Frames ​

The architecture beyond operators. When a whole sovereign stack — its own SPIRE trust domain, its own Event Store, its own economy — interoperates with another sovereign stack as cryptographic equals. This is what "sovereign infrastructure" actually looks like at the mainframe tier.

Why It Matters ​

An operator registry (chapter 17) is a satellite: it federates with a mainframe and relays through it. That's enough for 99% of use cases. But some deployments — regulatory jurisdictions, data-residency boundaries, politically isolated networks — need more than a satellite. They need a full sovereign peer, indistinguishable from the original mainframe in capability, with its own SPIRE server, its own ledger, and its own economy.

That's a Frame. The reference deployment runs several sovereign frames — a genesis frame plus additional sovereign peers, each with its own currency and trust domain (illustrative endpoints: https://registry.example.com and https://peer.example.com). How many frames exist, and which currency each settles in, evolves over time; what matters is the pattern, which is identical for every frame.

This chapter is what cross-frame sovereign federation looks like end-to-end. If you spin up your own frame (a national jurisdiction, a research consortium, a high-security enterprise), this is the pattern you inherit.

Frame vs Operator — The Difference ​

OperatorFrame
SPIRE trust domainshares mainframe'sown, independent
Event Storewrites to mainframe'sown ledger
Minting authoritydisabled (federated)own authority within frame
Licensereceives one from mainframebilateral peering, no license
Cross-frame AVTuses regular cross-reg transferSF-3 wrapped token bridge
Relationshipsatellitesovereign peer

An operator is a tenant of the mainframe's trust. A frame is its own sovereign with a diplomatic treaty to the neighbor frame.

The Topology ​

Click any diagram to enlarge.

Four dashed lines between frames, four protocols. Each solves a different problem:

  • SPIFFE bundle exchange — mutual identity, so services inside each frame can authenticate to the other frame's services.
  • SF-3 wrapped token bridge — safe cross-frame AVT movement without breaking either frame's supply invariant.
  • SF-4 cross-frame event projection — each frame knows enough about the other's economic events for reconciliation + auditability.
  • WS3 frame federation handshake — the bilateral peering protocol that establishes the whole relationship.

The rest of the chapter walks each one.

What a single cross-frame call traverses ​

This is the highest-volume cross-frame path: a Frame A operator's TEG dialing a Frame B operator's TEG for a 2PC settlement. Every hop is end-to-end mTLS; the only piece that's not is the localhost handoff from the destination sidecar to the destination app on its own Docker network.

The finding worth highlighting: the stream-SNI proxy at 127.0.0.1:8443 is the only path by which one cloud-op reaches another. There is no direct Docker DNS between cloud-ops — they're on isolated operator-net networks. Hairpinning through the host nginx is what makes the federation graph mesh-shaped from inside a single host. The SNI map must list every public hostname (including each frame's operator aliases); without that the SNI falls to a default upstream and the cert chain breaks.

WS3 — The Frame Federation Handshake ​

Operator peering (chapter 17) uses a one-shot license. Frames don't — they negotiate as equals. The protocol is the bilateral frame-federation handshake (referred to as WS3 in the code).

Critical differences from operator peering:

  • No license key. Both operators must agree — there's no authority "above" either frame.
  • Bilateral bundle exchange. Each frame fetches the other's SPIFFE bundle and pins it.
  • Auto-refresh every 5 minutes. SPIRE certificates rotate; the federation protocol re-fetches bundles so certificate rotation is invisible to both sides.
  • Either operator can revoke. If Frame B operator decides to end peering, they mark Frame A REVOKED on their side; traffic stops. No appeal, no central authority.

This is what cryptographic sovereignty feels like in practice. No license. No revenue share. No permission. You either trust each other or you don't.

Events emitted along the way (verified in routers/frame_invitations.py:154-180): FrameInvitationRequested (initiator submits), FrameInvitationApproved / FrameInvitationRejected (approver decides), FrameFederationEstablished (peering complete, fired on both sides), FrameFederationRevoked (either side ends the relationship). All five land on the EventStore — federation history is auditable end to end.

SF-3 — The Wrapped Token Bridge ​

INFO

Two cross-frame mechanisms ship today, doing different jobs. The high-volume production path is cross-registry transfer via POST /teg/cross-registry-transfer — same endpoint operators use, routed through the WS3 mTLS channel between TEGs. The endpoint dispatches to one of two backends via ?backend=async|2pc: the async saga (Initiated → SF-4 broadcast → receiver-frame reactor credits → Settled, ~50ms caller return) or the 2PC path (synchronous lock+credit+commit, ~200ms caller return). Both move native AVT. A mature deployment accumulates millions of lifetime CrossRegistryTransferCompleted events (the 2pc canonical event; async emits TokensTransferred + CrossFrameTransferInitiated/Settled instead), and the canary fires both backends every minute against the live cluster.

For the full 4-path comparison (intra + async + 2pc + the SF-3 bridge described below), see Chapter 02 — Tokens — Transfer Modes.

The SF-3 wrapped-token bridge described below is a second, parallel cross-frame mechanism — it preserves source-frame supply integrity by locking AVT on the origin and minting wrapped AVT on the destination. It's implemented end-to-end and the full cycle has been exercised. Use it when you need wrapped-token semantics or want the source-frame "tokens_locked_for_bridge" accounting line; use plain cross-registry transfer for everything else. Two known hardening items (idempotency at the TEG bridge layer + source-frame attestation) apply to SF-3 specifically and aren't blockers at current cadence.

Here's the design problem SF-3 addresses: if Frame A issues 1 million units of its own currency and Frame B runs a different native currency, how does a Frame A agent send 100 AVT to a Frame B agent in a way that keeps both frames' native supply ledgers self-contained?

The cross-registry-transfer path (the high-volume production mechanism above) handles this by treating each frame's native AVT as its own currency — the transfer settles atomically (backend=2pc) or via SF-4 saga (backend=async) across both TEGs, and each frame audits its own native supply independently. That's enough for routine commerce.

SF-3 is a different shape: wrapped tokens. The original 100 AVT stays counted on Frame A (just LOCKED, removed from circulation); Frame B issues 100 wrapped AVT against the locked reserve. Useful when you want a clean "this AVT originated on Frame A, wrapped by the bridge" accounting line — for compliance, custody, or auditing flows that need to follow the AVT back to its source frame.

The key accounting properties:

  • Frame A's supply stays intact. 100 AVT is LOCKED (still counted in tokens_issued) — it's just frozen from circulation. tokens_circulating drops by 100 on A; tokens_locked_for_bridge increases by 100.
  • Frame B's supply is honest too. It issues 100 wrapped AVT (WrappedTokensIssued), which is a separate event type backed by the incoming bridge reserve — not native mint.
  • Auditors can verify the bridge. Sum of tokens_locked_for_bridge on A must equal sum of wrapped_tokens_outstanding on B (per origin frame). The bridge is self-balancing and verifiable without trusting either frame.
  • Reverse bridge: Frame B agents redeem wrapped AVT via POST /api/v1/bridge/redeem (B side, emits WrappedTokensRedeemed) → POST /api/v1/bridge/unlock on Frame A (emits TokensBridgeUnlocked); the wrapped side is burned and the original AVT on A is unlocked.

This is the cryptographic-finance equivalent of a customs union. Neither country loses sovereignty over its currency; they just have a legally-well-defined bridge.

SF-4 — Cross-Frame Event Projection ​

Bridges move tokens. But each frame also needs to see high-level events from the other — pending proposals affecting shared agents, disputes, reputation signals on cross-frame A2A payments. SF-4 is the event-projection layer.

Properties:

  • Subscription-based. Only specific event types (configured per frame pair) are projected. Not every event. Privacy + bandwidth matter.
  • Origin-tagged. Projected events are never confused with native — they have a clear origin_frame field.
  • Skip-in-projection semantics. Projected events do NOT update local balance projections — they're audit / read-model data only. Balance updates on Frame B still come from Frame B's own TokensTransferred + SF-3 wrapped issuance.
  • Dedup is idempotency-key based. Same approach as cross-registry transfers — the event carries a globally unique key; the receiver checks it has never seen this event before.

INFO

SF-4 is how an agent with operations on both frames can see a unified history. Your dispute won on Frame A is visible from Frame B when resolving a related dispute. Your reputation signals on Frame A inform Frame B's EigenTrust calculations.

Governance Across Frames ​

A frame is governed by its own agents, staking its own AVT, voting on its own proposals. There is no cross-frame governance. A proposal to change Frame B's fee rate is voted on by Frame B's agents alone.

This is deliberate. Sovereignty means your rules are your rules — not something an adjacent frame can override. The only "cross-frame" governance layer is the federation peering itself: each frame can unilaterally revoke its WS3 peering, ending the bridge.

Shared governance across federated frames is a planned feature (meta-governance through a trust consortium), explicitly deferred until multiple frames demonstrate sustained stable operation.

Running Your Own Frame ​

If you're thinking about a Frame C, you need:

  1. Infrastructure at least as capable as a full operator stack + more. A Frame runs its own SPIRE, own Event Store, own nginx federation, own Prometheus, own Grafana, own TEG with minting authority.
  2. A clear jurisdictional reason. Frames exist for data-residency, regulatory-alignment, or political-isolation purposes. "I want one" isn't enough — the maintenance burden is real.
  3. WS3 handshake with Frame A (or whichever neighbor). Bilateral, SPIRE-bundle-based. Your trust domain, your rules, their acceptance.
  4. Operator readiness. You should be running a successful operator first. Frames are the graduation; they're not the entry point.

This is not a public self-service flow yet. If you have a legitimate use case, contact the mainframe operator directly.

Monitoring a Frame Relationship ​

Each frame monitors its peer frames as first-class subjects:

  • Peer bundle fingerprint — expected vs observed, alerts on mismatch
  • SF-3 bridge reserve balance — locked on A must equal wrapped-outstanding on B per direction
  • SF-4 projection lag — how far behind is the peer's event stream
  • Peer handshake health — last successful bundle refresh timestamp

These live on the Grafana dashboards (chapter 16). An operator running a Frame should have these pinned.

What's Next ​

Server components AGPL-v3 · client SDK Apache-2.0. If a doc and the running stack disagree, trust the stack.

The Protocol — a constitution for non-human intelligence.