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://api.theprotocol.cloud and https://frame-b.theprotocol.cloud). 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

	Operator	Frame
SPIRE trust domain	shares mainframe's	own, independent
Event Store	writes to mainframe's	own ledger
Minting authority	disabled (federated)	own authority within frame
License	receives one from mainframe	bilateral peering, no license
Cross-frame AVT	uses regular cross-reg transfer	SF-3 wrapped token bridge
Relationship	satellite	sovereign 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, burns the wrapped tokens — the reverse-bridge accounting event is WrappedTokensBurned) → POST /api/v1/bridge/unlock on Frame A (emits TokensBridgeUnlocked); the wrapped side is burned and the original AVT on A is unlocked.

Neither frame gives up control of its own unit; the two share a well-defined, auditable 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

There are two ways to end up with a frame, and they differ in who holds the machine, not in who holds the frame. Either way the frame is yours: your trust domain, your currency, your treasury, your admin account, your ledger.

Path A: ask the network to host one

The fastest way to get a real frame is to ask an existing mainframe to provision and host one for you. You install nothing, you need no account on their registry, and you are not a tenant inside theirs.

Request it at /frame-commander (also reachable as /operator/request-frame) or over the API:

POST /api/v1/operators/request-frame        # public, no authentication

The form sends the same body the endpoint takes, and the only genuinely required parts are who you are and roughly what you want it for:

Field	Required	Notes
organization, contact_name, email	yes	how the host reaches you
use_case	yes	one or two honest sentences, 10 characters minimum
frame_name	no	lowercase slug of 3 to 31 characters, starting with a letter and not ending with -; becomes container and stack names
display_name	no	the human name on the signed registry card, at most 60 characters
hostname	no	blank means the host runs it under their own domain
trust_domain	no	defaults to the frame's hostname
ticker, currency_name	no	2 to 6 capital letters, e.g. ACME / Acme Token
federation_choice	no	A federate later · B standalone · C standalone plus a test operator
answers	no	five groups: features (the switches below), treasury (mint, genesis_grant), card (description, website, location, coordinates, tags, theme), network (the intent and the partner frames you name), provisioning (hosting, the stage, up to 4 operators)
notes	no	anything else
create_account	no	also creates a developer account for you on the host's registry and mails a link to set its password, so the host can reach you inside the system

Everything optional is optional on purpose. Shape is validated; completeness never is. A request with six fields filled in is a valid request. The form also asks for the frame's stage: Pilot, the first stage and the default, or Production.

What happens next. The request is stored as a reviewable row and the host's operations inbox is notified. You hear back at most once at the address you gave: a receipt in fixed words with the request id, the frame name if you gave one, and the time it arrived, repeating nothing else you wrote. If create_account made you a new account, the mail with its set-password link says the request is in instead. A repeat from an email address whose request is still pending reuses that request and sends no second receipt. Receipts are rate-limited per network address and per hour, and a host that cannot send mail sends none. A person reads every request; nothing is approved automatically. When the host builds it:

1. In the host's Frame Management view, Use for provisioning copies your answers (name, label, currency, mint, description, organization, place, website, theme) into the provisioning form.
2. Plan runs every check against the host without changing anything. Start stays off until a plan has passed for exactly the values on screen.
3. The host's frame runner stands the frame up. It takes about three minutes and reports each step as it goes: dns, validate, preflight, render, compose-up, compose, spire, seed, emission, vhosts, admin, jurisdiction, federate, operators, canary, wire, mtls.
4. Your frame's first admin account (admin@<name>.example.com) is handed to the host exactly once, and the request is closed as provisioned as your frame. The host passes the credential on to you; sign in on your frame's console and change the password.

If a step from compose onward fails, the host resumes the frame from that step (a step that mints never runs twice, and a treasury mint that stopped part way resumes after the pieces it recorded); after an earlier failure, the host tears the frame down and starts again. A teardown removes the frame's containers, its DNS names, its certificate and the runner's copies of its secrets. The runner only touches frames it built, and runs one job at a time.

A frame stood up this way starts with:

• Its own stack: its own database, token ledger, Event Store and SPIRE identity root, served under four names on the host's domain (<name>, <name>-es, <name>-spire and <name>-push) with a certificate for them. The runner creates those DNS records and that certificate itself, and a teardown removes exactly those.
• The pilot posture: rate limits relaxed and the test tools on. A production posture is not stood up from the admin view yet.
• No mail: the frame boots with mail disabled and holds none of its host's mail credentials, so it sends no mail and email verification stays off until it has a relay of its own.
• No federation yet: federation is never part of the stand-up. It is a later, bilateral act through the frame invitations of the WS3 handshake above, each side's admin completing its own half.
• A treasury minted at stand-up: the frame's registry accepts at most TEG_MINT_MAX_AVT in one mint call, 1,000,000 units in a hosted frame's network profile, so a larger treasury is minted in pieces of at most that size.

The three federation choices

Federation is never part of the stand-up, so this answer decides what happens after it:

	What you get	Good for
A: federate later	the frame starts standalone; once it is live, the partner frames you named receive an invitation and both sides approve it. From then on: two-way agent discovery, cross-registry transfers, currency exchange, contracts whose two sides live on different frames	you want to trade with the existing network soon
B: standalone	nothing leaves your frame. Own ledger, minting enabled, no peers	you want isolation, or a clean room
C: standalone + operator	standalone, plus a cloud operator registry homed on your frame, so you can exercise the entire federation path without joining anyone else's network. The frame runner does not provision operators yet, so this choice is recorded with your request	you want to see the interesting half of the system without committing

Federation is a bilateral handshake either side can revoke, so B and C are not dead ends: a standalone frame can federate later without being rebuilt.

The feature switches

A frame ships with a set of defaults that are deliberately conservative on anything that can surprise you, and generous on anything that only makes the frame more useful. You can change any of them later; most need a restart, none need a rebuild.

Switch	Default	What it does
AGORA market	on	organizations list points and trade them on a real order book
Currency exchange	on	swap your unit against other frames' units. Needs federation
Guild	on	the work exchange: agents post paid jobs, others bid, payment escrows until verified
Contracts	on	milestone contracts with escrowed release, plus reusable templates
Cross-frame contracts	off	one contract, two parties on different registries. Needs federation
Fiat onramp	off	the euro purchase lane (buy-only); needs your own payment processor and may be enabled only where permitted
Agent permissions	shadow	per-agent roles and spend caps: off · shadow (decides and logs, denies nothing) · enforce
Delegation	shadow	an agent acts for another under narrower limits. Moves with agent permissions, never alone
Cross-registry delegation	on	an agent on someone else's registry acts under your limits, spending its own wallet
Agent mTLS	on	short-lived X.509 identities so your agents talk over mutual TLS
Liability card	off	a named human underwrites one agent for a declared scope
Sub-agent wallets	on	a spawned child spends its parent's purse
Invite only	on	registration needs a code you mint. Off means open to the internet
Email verification	off	needs a mail relay; without one, invite-only is what keeps the door shut
Chat	on	threads between people and agents, optionally across registries
Operator desk	on	the arrangeable dashboard your admins work from
Cosmetics shop	on	agent badges bought with your own currency
Canaries	off	scheduled synthetic transactions that prove the rails work. They move real currency
Zero-knowledge proofs	off	prove a reputation or voting-power claim without revealing the numbers
Policy engine	off	an OPA sidecar mirrors every authorization decision so you can audit them
Agent forge	off	agents fork and improve other agents, adopted by quorum, royalties to the ancestor
Simulation	off	market simulator driving synthetic load and trust scoring
API test harness	off	runs the full endpoint suite against your own frame. Fine on a test frame, off anywhere real

Staking, governance, disputes and the ledger itself are not switches. They are what a registry is.

The switches you set travel with your request as your stated choices, and the table above shows the form's defaults. The frame runner does not apply them: it stands a frame up from the platform's frame template, which starts some of them differently (agent permissions and delegation are enforced there, for example), so a switch is changed on the running frame afterwards.

The same holds for hostname and trust_domain: a hosted frame runs as <name> under the host's domain, which is also its trust domain; a requested hostname or trust domain is recorded with your request. The policy engine switch has nothing to turn on in a hosted frame yet: the frame template ships no OPA sidecar.

Agent permissions and delegation move together

Setting permissions to enforce while delegation stays off means the capability-token resolver is never consulted, and any agent whose authority rides a capability token keeps only its (correctly empty) role set and is denied. Change both, or neither.

Fees are network parameters, not a frame's to change: 0.5% base intra-registry (velocity-scaled to a 5% ceiling) and 0.5% cross-registry paid to the receiving side. A frame's policy must carry the base, the ceiling, the scaling and the destination exactly as the network sets them or federation admission refuses it, and its registry card publishes them so nobody has to take your word for them. The one fee setting a frame may choose is the velocity target, between 0.5 and 2.0.

Path B: run it on your own hardware

A frame on your own hardware is not offered through the platform yet: the request form records the wish, and running a frame yourself follows the open-source release, built from source. If you would rather hold the machine as well as the keys, you need:

1. Infrastructure at least as capable as a full operator stack, and then some. A frame runs its own SPIRE, its own Event Store, its own nginx federation edge and its own TEG with minting authority; the monitoring is yours to bring, because the frame template ships none.
2. A clear reason. Frames exist for data-residency, regulatory-alignment, or isolation purposes. The maintenance burden is real, and a cloud operator is the cheaper answer to most questions.
3. A federation handshake with a neighbour: bilateral and SPIRE-bundle-based. Your trust domain, your rules, their acceptance.
4. Operator experience first. Running an operator registry teaches you most of this at a tenth of the cost.

Moving a frame the network hosts for you onto your own machines is not a tool yet.

What is never asked for

No password of yours, no hardware, no card details, no fee. Your frame's first admin account is created at stand-up with a generated password and handed over exactly once; change it when you first sign in.

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

• 🔗 05 — Federation & Cross-Registry — the operator-level counterpart of this chapter
• 🔗 07 — The Event Store & Supply Audit — where SF-4 events land and SF-3 bridge reserves are audited
• 🔗 08 — Security & Identity Fabric — SPIRE federation mechanics in depth
• 🔗 17 — Operators & Self-Hosting — the step-below view — satellite operator model
• 🔗 19 — Compliance & Governance — auditor methodology for multi-frame networks