HANSA

Forty-one sovereign registries moving one container, with no shared database and no landlord.

Open the live chamber in the app
The animated flow, the attack replays and the deep architecture run there; this page is the reference text.

Who this serves

• Freight forwarder. One shipment, six parties, and no shared platform anyone must become a tenant of.
• Customs broker. Attest arrival with a token that can do exactly that and nothing else.
• Cargo insurer. Watch the signed replica, price the risk, never touch the escrow.
• Commodity trading desk. Escrowed milestones from Busan to Rotterdam without a platform landlord.

The problem

A container crossing four jurisdictions is tracked by six organisations in six databases, none of which the others can read, all of which disagree, and the disagreements are resolved by email. Every proposed fix for thirty years has been the same fix: everyone move into one shared system, owned by someone. Nobody wants to be the tenant, so nothing moves.

The system

HANSA is 340 agents across 41 sovereign registries in 19 countries. There is no shared database and no central operator. Each party runs its own registry on its own hardware under its own law, and they federate bilaterally, the way the Hanseatic cities did, by mutual agreement that either side can end.

A shipment of lithium cells leaves Busan. Its bill of lading is a contract with six milestones, and the money sits in escrow on the frame that holds it. That frame is the only settlement authority for that contract. Every other party holds a signed, read-only replica: they can see the terms, verify the signature, and prove nothing has been altered, and they cannot release a cent. Two frames both able to settle would be a double-spend waiting for a network partition, so the design does not allow it.

Customs clearance in Rotterdam is an agent on a different registry, run by a different company, under a different jurisdiction profile that its operator has publicly declared and cryptographically signed. That agent holds a capability token that can do exactly one thing: attest arrival on one contract reference. It cannot read the other five milestones. It cannot touch the escrow. When it attests, milestone four releases 18,400 units to the carrier automatically, and the ledger entry is signed, replayable, and byte-identical on both sides.

In March, one participant’s licence was revoked for policy drift. Their agents stopped being able to move value inside the network within one sync cycle. Their existing contracts did not vanish and their counterparties did not lose their records, because the replicas are signed documents rather than database rows in someone else’s schema. Quarantine is economic, not existential.

The cast and their ceilings

The flow, step by step

1. The bill of lading is six milestones. The money enters escrow on the frame that holds it.
2. Rotterdam attests physical arrival. Its token can do exactly this and nothing else.
3. The attestation lands on the milestone gate.
4. The carrier claims milestone four.
5. Release. 18,400 units to the carrier, automatically.
6. The entry is signed, replayable, identical on both sides.
7. Every party holds a signed replica. None of them can release a cent.

Each need, mapped to a live primitive

The attack this chamber refuses: The compromised customs agent

The attack. The customs agent is compromised and attempts to release milestone four to an account the attacker controls, through the copy of the contract its own side holds.

Why it fails. The replica carries no escrow reference and no settlement columns. The end-to-end suite asserts their absence, not their protection. There is no code path from a replica to money, so there is nothing to defeat.

What actually happens. Escrow untouched, on a frame the attacker cannot reach, under a rule that is structural rather than configured.

The attack this chamber refuses: The forged relay

The attack. The compromised party’s own registry sends a forged relay claiming the shipper approved the release.

Why it fails. The relay is authenticated by mTLS, which proves the channel and nothing else. The principal is the actor DID inside the request, and the gate checks that this principal is party to that contract. A peer is a courier and never a principal.

What actually happens. The relay is refused before the gate. The channel being trusted never made the claim inside it true.

Deep architecture

HANSA at deployment scale: the shipper’s frame holds the contract and the escrow, the carrier and the port authority act from their own registries, and the fabric between them carries signed commands without ever becoming a principal. The insurer reads a mirror nobody can rewrite. The trace replays one container, Busan to Rotterdam.

The deployment, traced

1. The booking and its documents arrive from the ERP. Logistics stays where it lives.
2. The shipper instantiates the contract: milestones, terms schema, annex references.
3. Escrow funds at agreement. The carrier watches the money exist before the ship sails.
4. Weeks later in Rotterdam, the carrier claims the arrival milestone from its own registry.
5. The port authority attests the physical arrival, as itself, from a foreign frame.
6. The fabric couriers the signed commands home. The relaying peer is never the principal.
7. The escrow-holding frame, and only it, releases the tranche.
8. Payment crosses registries with an idempotency key.
9. The carrier’s own TEG credits it, under its own law.
10. One truth per tranche, on the home ledger, append-only.
11. A signed replica mirrors to every party. The insurer reads; nobody rewrites.

Adoption, phase by phase

Discover: Map one lane, touch nothing.

• Runs. Nothing in your estate. One lane of your network drawn against the rails: who would sign what.
• Agents. None. The counterparties are named on paper, not enrolled.
• Integrates. Nothing. The TOS, the ERP and the carrier links stay untouched.
• Deliberately not yet. No contract, no escrow, no registry.
• Proof that gates the next phase. One historical shipment re-told as milestones and attestations, and every party agrees the telling is correct.

Pilot: One lane, real contract, small money.

• Runs. The shipper runs one hosted registry seat or a single-VM frame; counterparties join as L1 accounts.
• Agents. shipper agent, carrier-ops, one attestor; the arbiter exists but expects boredom.
• Integrates. ERP bookings in via SDK; terminal gate records photographed into evidence, not yet wired.
• Deliberately not yet. One lane only. Parametric insurance observes nothing yet. Amounts are pocket-sized.
• Proof that gates the next phase. Five consecutive shipments settle from escrow on attested milestones with zero settlement emails.

Production: The lane goes to real volume; the port signs natively.

• Runs. Sovereign frame at the shipper; the port authority and large counterparties stand up their own or use hosted seats.
• Agents. Full cast per lane; customs attests from its own registry; insurer-watch reads the replica for parametric cover.
• Integrates. TOS gate-out events feed attestations; ERP receives the evidence chain continuously.
• Deliberately not yet. Other lanes. Each lane onboards as configuration, not as a project.
• Proof that gates the next phase. A disputed milestone resolves through the four-phase process with the ruling executing the split from held escrow.

Federation: Forty-one registries, no landlord.

• Runs. Unchanged. New parties bring their own frames or seats.
• Agents. Per-lane casts; reputations travel with DIDs across the mesh.
• Integrates. Each new corridor is a signed card, a license, and a template instantiation.
• Deliberately not yet. No shared database is ever built. That is the point.
• Proof that gates the next phase. A new counterparty ships on the network without a single bilateral integration meeting.

Sizing

One milestone, claim to credit

sequenceDiagram
  participant Car as carrier-ops (their frame)
  participant Cus as customs (port frame)
  participant Fab as federation fabric
  participant CS as contract spine (home)
  participant TEG as home TEG escrow
  participant XT as cross-registry pay
  participant ES as home event ledger
  Car->>Fab: milestone claim, signed
  Cus->>Fab: arrival attestation, signed
  Fab->>CS: relayed commands (principal checked)
  CS->>TEG: release tranche
  TEG-->>ES: tranche event, append-only
  TEG->>XT: pay carrier (idempotency key)
  XT->>Car: their TEG credits, exactly once
  ES-->>Fab: signed replica update
  Fab-->>Cus: mirror (read-only)

Topology, as declared

flowchart LR
  SB["shipper registry<br/>frame: Busan"] -->|"POST /api/v1/contracts<br/>fund escrow"| CS["contract spine<br/>6 strict-order milestones"]
  CU["customs agent<br/>foreign registry"] -->|"X-Capability-Token<br/>attest, one ref"| CS
  CA["carrier-ops"] -->|"milestone submit"| CS
  CS -->|"release via /teg/transfer"| TEG["TEG escrow mover"]
  TEG --> ES[("event store<br/>signed, replayable")]
  ES -->|"federation sync<br/>watermark + digest"| REP["peer replicas<br/>read-only, no escrow ref"]
  PR["peer relay"] -. "courier only<br/>actor_did must be party" .-> CS

Standing it up

• Infrastructure. One registry per participant. Free licence, 9 containers, about two minutes each. Raspberry Pi to datacentre.
• Agents. 5 roles. Most participants run two.
• Integration. Customs APIs, EDI, telematics. Weeks, and it is your existing integration debt, not ours.

What this does not claim

• HANSA does not make customs declarations and does not constitute a trade finance product.
• No assertion of compliance with any jurisdiction’s import regime.
• Jurisdiction profiles are declared by the operator who runs the deployment, and the operator warrants their own legality. We supply the mechanism and never the legal conclusion.