Federation
A single piece of automated work is captured as one signed span: intent and authority at the start, the delegation handoffs in the middle, the result and verdict at the end. Federation is how that span extends across organizations. When the work hands off to an agent in another Org, the chain crosses the boundary; the business data does not. Each Server signs its own portion with its own key, so a cross-org span is signed by genuinely different signers.
It 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.
Peer-to-peer · Per-instance Ed25519 federation key · Per-record sharing · Content-addressed schemas
Last updated: 2026-06-10 · API v1.2.0
The one span, scaled
The signed span doesn't stop at the org boundary
Inside one Org, the span scales through delegation: an agent records its intent, hands work to a sub-agent, and the child record links to the parent. Federation is the next turn of the same screw - the delegation handoff crosses a network and an organizational boundary instead of staying in one database. The object does not change. It is still one signed span over one piece of work; more of it simply lives on more than one Server.
That is the meaning of the four-layer arc: notarize, then delegation, then federation, then federated gates with Settlement Signals. It is not four products. It is one signed span shown at four magnifications, and federation is the magnification at which the span reaches across Orgs.
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>, produced by the Server's federation signing key - a per-instance key distinct from the vault key that signs the audit chain. 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.
Genuinely different signers
Each side signs its own portion with its own key
Within one Org, the notary signs every chain entry with that instance's single vault key, naming the accountable principal inside the signed payload. Across Orgs the cryptography gets stronger, not weaker: there is no shared key and no privileged coordinator that could speak for both sides. Org X's portion is signed by Org X's key; Org Y's portion is signed by Org Y's key. A reader reconstructing the cross-org span verifies two independent signatures from two independent custodians.
For contract types declared coSignRequired, the state transition is bilaterally co-signed: both Servers attach their signatures before the transition is accepted, so neither side can later claim the other acted alone. That is a property a single-custodian ledger structurally cannot offer - the boundary between the Orgs is exactly what makes the attribution non-repudiable to a zero-trust auditor.
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. The deeper data-sovereignty model - where the database, keys, and records live, and what never leaves your infrastructure - is covered on the deployment page.
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
Per-record, per-contract, or global
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; the principal on each side renders accept or reject, and we hold the signed decision.
Cross-org terminal verdicts project a SETTLE, HOLD, or RELEASE signal to the side that owns the payment or contract system. The mechanics live on that page.
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 runs the same software, holds its own database and keys, and 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.