Frequently Asked Questions

What is AFP?

AFP is the protocol layer for verifiable, metadata-private federation between tenants. A tenant is any runtime that federates as a principal under its own tenant root AID. Every tenant must satisfy the AFP tenant conformance profile; a shortfall makes it a non-conforming tenant, not a non-principal. ADAMAS is the reference implementation, not the definition.

What are AFP's three relationships?

AFP defines exactly three relationships between identifiable, cryptographically verifiable principals: tenant ↔ tenant, where two tenants coordinate work across organizational lines with neither side revealing more than the work requires; tenant ↔ operator, where the operator of a transport verifies platform health through ZKC proofs rather than raw telemetry; and identity continuity, where a tenant's identity and accumulated relationships survive a change of deployment topology or operator.

What is AFP explicitly not?

AFP is not an agent marketplace, public registry, capability-discovery feed, task broker, observation-contribution surface, reputation system, NKey identity scheme, or HTTP bridge. Those were v0.2 draft surfaces; v0.3 retired them because ADAMAS's product scope narrowed to a platform for life-sciences work run by named domain entities that are themselves ADAMAS multi-agent systems — there are no third-party agents to integrate and no marketplace to police.

Does AFP include a public agent directory?

No. Federation is bilateral and agreement-scoped. AFP defines no marketplace, public registry, or capability-discovery feed. The one opt-in exception is the experimental introduction tier's willingness-to-federate directory: a tenant may publish that it is open to being approached by strangers, but the record carries no work descriptor and no open call for work — it reveals which tenants are open, never which tenants have paired, and first contact is still routed through the metadata-private mixnet.

Who are AFP's principals, and how does AFP identify tenants?

AFP recognizes exactly three kinds of principal, all identified by KERI AIDs: a tenant, a runtime that federates as a principal under its own tenant root AID governed by a Key Event Log (KEL); an entity, a named domain multi-agent system within a tenant, identified by a delegated AID whose inception is anchored in the tenant's KEL; and an operator, whoever runs an AFP transport, whose role is operational only and confers no protocol-level privilege or data path into tenant state.

Tenants and entities use KERI AIDs with KELs and witnesses. NKey-based identity is retired.

What is the operator-blindness invariant?

Operator Blindness (OB) states that no operator of an AFP transport can learn, from operating that transport, the content of any tenant's work (OB-1) or the coordination graph of which tenant is coordinating with which (OB-2). OB-1 is delivered by end-to-end encryption of every AFP payload; OB-2 is delivered by the metadata-privacy routing layer. Both are required — encrypted payloads over an operator-observable relationship graph does not satisfy the invariant.

OB is a statement about capability, not conduct: an implementation satisfies it only if the operator cannot obtain the protected information, not merely if it chooses not to look.

How does AFP hide metadata?

Tenant-to-tenant coordination is routed through the AFP Federation Mixnet. Deployments without the mixnet must not claim OB-2 conformance.

The mixnet is a Loopix-family design with mandatory cover traffic: a conforming tenant emits coordination-plane traffic into the routing layer at a constant, scheduled rate at all times while federated, whether or not it has real messages to send, with genuine work slotted into that stream. This defeats correlation by a passive observer of the links between relays, not just a single compromised relay.

How does tenant ↔ operator telemetry work?

An operator's only per-tenant knowledge is what a tenant proves via ZKC proofs, pushed by the tenant on its own schedule. AFP defines a starting telemetry predicate catalog — instance attestation, build currency, compute-quota compliance, and audit-log integrity — each an atomic, open-source, versioned predicate.

Self-attested predicates (compute quota, audit-log integrity) must additionally carry a public-sample binding, so the operator can check a signed claim against a verifiable sample without ever observing per-tenant traffic. A failed or missing telemetry proof produces an alert only; AFP defines no gate that lets an operator intervene in tenant state.

How do two tenants that don't already know each other establish trust to federate?

AFP recognizes three trust bases for opening a session:

• Bilateral federation agreement — an explicit, mutually signed record that two tenant AIDs have agreed to federate. This is the known-counterparty path.
• Open federation — two strangers with no prior agreement establish trust per-interaction through mutual ZKC compliance attestation.
• Introduction tier — an experimental profile in which a credential-plus-proof handshake auto-negotiates a scoped, collateral-priced provisional agreement, which then grows with ZK-provable interaction history and can graduate to a standard agreement.

None of the three is a portable reputation score, and a declined or failed attestation only ever causes the counterparty to decline the interaction — it never gates funds, notes, or credential validity.

How does AFP relate to ZKA?

ZKA is AFP's settlement and coordination substrate. Cross-tenant work artifacts, value transfers, and multi-step workflow attestations are ZKA constructs — ZKA notes for payment and ZKA/Coord recursive proofs for verifiable multi-step work — that AFP carries inside a session envelope without redefining them. This specification targets ZKA v0.9.0-draft.

How does AFP relate to ZKC?

ZKC is AFP's compliance substrate. Tenant-to-operator telemetry and tenant-to-tenant compliance claims are profile-aware ZKC proofs, wrapped in a ZKA compliance bundle. AFP decides which claims are proved, on what cadence, and how they bind to session and identity context; ZKC owns the proof circuits, the anonymous/scoped/linkable presentation profiles, and pseudonym and scope derivation. This specification targets ZKC v0.4.1-draft.

How does AFP relate to ZKM?

ZKM is an optional, principal-issued spend-authorization layer that composes with AFP as a peer rather than a new protocol layer. An AFP tenant's agent may exercise a ZKM mandate inside an AFP session; AFP owns bilateral session policy and ZKM owns unilateral mandate state, and both constraints must pass independently — neither subsumes or replaces the other.

AFP, ZKA, ZKC, and ZKM all share the same Key Derivation Core (AFP-KDC), a self-contained module specifying master-seed derivation, Poseidon2/BN254 domain tags, and per-entity sub-seed derivation that each protocol references rather than reimplements.

What is AFP's current status?

AFP is a Draft Specification, currently at version 0.3.9-draft. Version 0.3.0 was a deliberate narrowing of the earlier v0.2.0 open-marketplace draft into the smaller, sharper protocol described on this site; the historical v0.2 draft is retained only as a superseded reference.

Who maintains AFP?

AFP is developed by Pyramidal as part of the Pyramidal ZK protocol family, alongside ZKA, ZKC, and ZKM. ADAMAS, published by Pyramidal Inc., is the reference implementation of the tenant conformance profile — a statement of fact about one implementation, not a conformance gate or a source of protocol privilege. Conformance is asserted and verified bilaterally between counterparties; AFP defines no conformance registry, certification mark, or published implementer list.

What license applies?

The AFP specification is released under the Apache License 2.0.