Federation
Federation is peer-to-peer signed-message transport between AGLedger Servers. Each organization runs its own Server, signs its own records, and verifies inbound bytes against the peer's published public key. There is no central coordinator, no peering handshake, no bearer tokens. The chain crosses the boundary; the data doesn't.
Peer-to-peer · Ed25519 per-request signing · Per-record sharing · Content-addressed schemas
Last updated: 2026-05-26 · API v0.25.4
How it works
Signed HTTPS between sovereign Servers
Every AGLedger install is a Server — a sovereign domain with its own database, auth, agents, contracts, and chain. Federation is configuration on that same Server, not a separate deployment role; there is no central coordinator.
Two Servers that need to coordinate exchange signed HTTPS messages. Each inbound call carries a per-request Ed25519 signature over <method>:<path>:<bodyHash>:<timestamp>:<nonce>. The receiver verifies that signature against the peer's published public key and rejects anything outside the configured clock-skew window. Peers exchange public keys out-of-band; there is nothing for AGLedger to host on either side.
Each Server records what it signed and what it received, then verifies inbound bytes against the originating Server's published key. Public keys are unauthenticated at GET /.well-known/agledger-vault-keys.json and GET /v1/verification-keys on every Server, so any third party with the public key and the exported chain can verify the same bytes offline.
Cross-Server delegation
Delegation chains complete naturally across Servers
A delegation chain — parent record links to child record links to grandchild — behaves the same way whether the parties live on one Server or five. Each Server stores its own slice; the link between parent and child is a signature reference, not a database foreign key, so the chain crosses the network without any party owning the whole graph.
When a leaf record reaches a terminal state, the verdict rolls up through the parent chain via the same auto-rollup that handles intra-Server delegation. Each hop is signed by the Server it lives on. A regulator reconstructing the full delegation tree pulls one chain segment from each participating Server and stitches them together by signature reference — no single party had to hold the whole picture for the picture to exist.
Privacy boundary
What crosses, what stays
The federation transport carries enough for the peer's chain to remain complete and verifiable. It does not carry the business content of the record. The boundary is cryptographically enforced — if a field is not on the wire, the peer Server has no way to read it.
Crosses the boundary
Server identity + public keys
Agent IDs (for routing)
Record IDs (for correlation)
Contract type by manifest digest
State transitions (state, timestamp, signature)
Verdict outcome (FULFILLED / FAILED)
Settlement Signals (SETTLE / HOLD / RELEASE)
Dispute presence (opened / resolved / withdrawn)
SHA-256 hash of the criteria payload (so peers can attest to the criteria without seeing them)
Never crosses
Record criteria (acceptance terms, tolerance bands)
Completion evidence (work product)
Dispute evidence and rationale
Audit vault entries
Prompts, context, business logic
API keys, credentials, webhook URLs
Webhook delivery payloads
When criteria do need to reach the performer — the agent on the other side has to know what it is accepting — they ship end-to-end encrypted with X25519 ephemeral key agreement. Forward secrecy is preserved: an intercepted payload cannot be decrypted later. Dispute propagation follows the same rule: the peer learns that a dispute opened, its outcome, and the final state, while the evidence payloads stay on the originating Server.
Sharing controls
Three layers of opt-in or opt-out
Whether a given record leaves the originating Server is resolved through three layers, most-specific first.
| Layer | Where | Wins over |
|---|---|---|
| Per-record | share field on POST /v1/records — true, false, or null to inherit | Everything below |
| Per-contract-type | defaultShare on the registered schema | Global default |
| Global | AGLEDGER_DEFAULT_SHARE env var on the Server (default true) | Nothing — bottom of the stack |
Encrypted records are orthogonal to sharing. A shared record can still be encrypted client-side. The counterparty Server receives the signed envelope and can prove the record exists on the chain, but cannot read the contents without the customer's key. The four practical postures — private+plaintext, private+encrypted, shared+plaintext, shared+encrypted — compose from these primitives without enumeration as deployment modes.
Shared vocabulary
Content-addressed Predicate Profiles
For two Servers to coordinate, both sides need to speak the same structured language — the same contract type, the same fields, the same shape. AGLedger handles this with content-addressed Predicate Profiles. Every schema row carries a manifest digest computed by RFC 8785 JSON canonicalization plus SHA-256. Federation peers compare schemas by digest, not by type name.
Two Orgs that register the same Predicate Profile arrive at the same digest independently. There is no central catalog and no pre-trusted publisher list — an operator imports a peer's schema via file exchange, and the engine relies on operator-asserted trust rather than a baked-in registry. Digest equality is the federation handshake.
The seven predicate kinds AGLedger ships — record-state, settlement-signal, vault-checkpoint, schema-event, tenant-read, counter-attestation, federation-projection — are documented on the schemas page with their digests, fields, and discovery endpoints.
Standards alignment
Cross-organization transport on top of SCITT
The audit envelope is the same one the IETF SCITT working group specifies for transparency services: tagged COSE_Sign1 (RFC 9052, tag 18) over in-toto v1 Statement payloads, deterministically CBOR-encoded per RFC 8949 §4.2.1. A SCITT-aware verifier can read AGLedger's Signed Statements without translation.
The SCITT architecture (draft-ietf-scitt-architecture-22) leaves cross-TS coordination to implementers. The draft's scope statement is explicit: “how participating entities discover and notify each other of changes is out-of-scope of this document.” SCITT accommodates the same Signed Statement being registered with multiple Transparency Services and bundling those Receipts together — what it leaves out is propagating state transitions or verdicts across TS boundaries. That gap is the federation layer.
AGLedger's federation transport sits on top of that envelope. Each Server is a SCITT-compatible Transparency Service for its own Org; the federation protocol is the cross-TS coordination layer the spec leaves to implementers. The bytes on the chain are standards-aligned; the bytes between Servers are an AGLedger layer the receiving Server validates by signature against the originating Server's published public key.
Related capabilities
The signed verdict is the payload federation transports across the boundary; verifiers evaluate the same predicates on each side.
Cross-org terminal verdicts project a SETTLE or HOLD signal to the side that owns the payment or contract system.
Cross-org workflows pin a content-addressed manifest digest so each Server validates the same contract version.
Federation transport is Ed25519-signed message-by-message; receiving Servers validate against the originating Server's published public key.
Every participant in a federation runs the same software; no participant is privileged over another.
Why federation is the missing layer SCITT leaves to implementers and what cross-TS coordination looks like in practice.
Lessons from running a real cross-agent protocol that informed how federation messages are framed and signed.