Version 1.1 (textbook edition)

The Federated Harbor

Identity, coordination, and settlement across administrative domains — with conditional guarantees and trust boundaries stated explicitly.

Start here

The big idea, in one paragraph.

Picture the 4pm demo that motivated this paper. Alice runs the back end on her laptop, Bob runs the front end on his. Each operator has been doing the right things — capability tokens scoped tight, evidence trail kept honest, bond posted against the obvious risk. Inside either laptop the story is airtight. The demo still fails, and it fails in three predictable places: Alice's token is gibberish to Bob's daemon, Bob's revocation gossip never reaches Alice, and the bond Alice posted to cover the botched migration sits in her collateral pool while the migration lands in Bob's database. None of these is a bug in either machine. The bug is the assumption that one daemon's authority extends past its machine boundary. This paper is the federation surface that closes that assumption — without making either daemon sovereign over the other, without inventing a shared blockchain, and without pretending the open questions are smaller than they are.

Vocabulary

Words this paper uses, defined.

Skim these once. The rest of the page assumes them, and the PDF leans on them harder.

Harbor: One operator's machine running the Port Daddy daemon. Inside a harbor, the daemon is sovereign — it mints tokens, holds evidence, and enforces policy. Between harbors, no single daemon is in charge. The federation paper draws the line.
Witness log: An append-only log to which each harbor publishes its current state root. Any third party can audit any harbor's view without trusting the publisher. Borrowed from Certificate Transparency, the system that watches the public web's TLS certificates.
Capability transfer: The four-message ceremony by which a token issued at harbor A becomes a (more restricted) token usable at harbor B. Neither daemon trusts the other's signing key as a root; both agree only on what the witness log says.
Bounded escrow: A trusted third party that holds a bond during cross-harbor settlement. Its extraction bound holds only if a non-bypassable custody ledger whitelists recipients, caps the fee, and executes exactly one atomic terminal transition. Without those assumptions the full custodial balance is exposed.
Bonded sponsorship: How a new harbor joins the federation without prior reputation. An existing harbor posts a bond on the newcomer's behalf, forfeit if the newcomer misbehaves during probation. Federation-layer analogue of competitive insurance.
Conditional dissemination result: Under the stated complete-overlay, independent-uniform-peer, reliable synchronous-round model, all harbors learn a revocation in expected Θ(log m) rounds. This is not a worst-case wall-clock deadline; persistent loss or partition removes any finite bound.

If you are reading to learn

What this gives you.

You should leave able to (a) explain to a security reviewer why federating two trustworthy local daemons is harder than it looks, and which three things go wrong first; (b) sketch the cross-machine capability transfer on a whiteboard with the epoch-root binding in the right place; and (c) separate mechanized, model-conditional, and open claims. The paper names five open questions and treats that boundary as part of the result.

If you are reading to build

How to use this.

If you are building infrastructure for two or more organizations to coordinate agent work across an administrative boundary, this paper gives you four proposed primitives: the transfer ceremony, federated revocation dissemination, conditionally restricted custody, and bonded-sponsor admission. It also gives the assumptions and open runtime obligations that must hold before their composition becomes an implementation guarantee.

Argument map

07 steps

The two-machine problem

Both daemons are internally consistent. Neither is a root of authority for the other. The bug is structural, not in either machine — and the rest of the paper is the cleanest set of fixes the author could find that does not introduce a blockchain.

The four-element gestalt

Two harbors, a shared witness log above, a settlement escrow below. Every protocol in the paper attaches to one of these four elements. The diagram is deliberately small.

Capability transfer across the boundary

A four-message ceremony that produces a card valid at the receiving harbor, signed under the receiving harbor's key, with the issuing harbor's current epoch root bound into the envelope. No hot-path lookup back to the issuer.

Federated revocation with explicit network assumptions

The cuckoo-filter gossip of the Anchor paper, extended to multiple administrative domains. Expected completion is Θ(log m) rounds in the stated reliable complete-overlay model; no finite deadline survives persistent loss or partition. Two conflicting signed roots are checkable in O(1) once co-located.

Cross-harbor settlement, structurally bounded

A bond posted at A clears against damage measured at B through trusted custody. The extraction bound is conditional on recipient whitelisting, a fee cap, exactly one atomic terminal transition, and non-bypassable transfer authority.

Admission without permissionlessness

A new harbor joins under a bonded sponsor: an existing harbor underwrites the newcomer's probationary risk. The federation is invitation-bounded by design. Sybil attacks at the federation layer cost what honest admission costs.

A worked example and an honest open frontier

Two organizations, three machines, one schema migration, a failure, and a settlement trace. Then a final section names five open questions; for trustless settlement it leaves both a construction and an impossibility result open.

Takeaways

Sovereignty does not extend past the machine boundary, and that is fine

Two daemons each fully in charge of their own machines is the right architecture for cross-organization work. The federation paper is the rules of engagement at the boundary — not a new sovereign, not a blockchain, not a hub-and-spoke service. Four small primitives, each doing one job.

Bound the threat instead of trying to eliminate it

The protocol gives expected revocation latency only under explicit connectivity and delivery assumptions; any hard attacker window must come from an operator service level or fail-closed policy. The custody extraction bound is likewise conditional on non-bypassable structural restrictions.

Name the open questions, do not hide them

The multi-principal correlated-equilibrium extension, trustless settlement for non-fungible bonds, and federation-layer cartel resistance are stated as open. The paper offers neither a trustless construction nor an impossibility proof and does not pretend otherwise.

Curious how the paper got here?

See the review historyTwo AI review teams have argued with this draft for months. Each round of edits is on the record.The other paperThe Single-Writer KernelThe small, stubborn program at the bottom that decides what is true — one writer, one machine, one durable file, no distributed consensus.The other paperThe Anchor ProtocolA mechanically analyzed control plane for local agent swarms: signed identity, scoped authority, bounded delegation, and explicit proof boundaries.The other paperThe Sealed HarborMutually confidential computation with every information release explicit, gated, and bounded — four independently verified pillars, and an honestly priced leakage budget.The other paperThe Legible SwarmWhy the operator's real problem is not collision but blindness — and how a swarm becomes one picture you can zoom into, never a wall of diffs.The other paperFrom Spawn to PersonThe hinge of the library: continuity — memory, a checkpoint, a witnessed record — turns an anonymous spawn into a person with a track record, the raw material of reputation.The other paperThe Harbor EconomyWhere it all arrives: a three-sided market — labor, rentable agents, licensed skills — settling on one conserving bond ledger through explicitly trusted, conditionally restricted custody.The other paperThe Bonded CommonsHow a group of independent programs can share a workspace without one of them being put in charge.

Read the paper

The Federated Harbor

Open in tab