Frequently Asked Questions
Common questions about ZKM, principal-hidden spend authorization, and cap-and-expiry-bounded mandates for autonomous agents.
Why ZKM?
What is ZKM?
Zero-Knowledge Mandates (ZKM) is the authorization layer of the ZK protocol family. It lets an autonomous agent prove that a spend is within a valid, unrevoked, cap-and-expiry-bounded authorization from a principal — without revealing who that principal is, the original cap, or prior spend history.
Agents do not own value — principals do. AP2 v0.2 is not structurally clear-text: it uses SD-JWT selective disclosure and requires a closed mandate to satisfy the applicable disclosed constraints. SEPA direct-debit mandates are clear-text. AP2 presentations can still be linked, and AP2's x402 examples settle transparently. ZKM extends privacy to settlement-enforced authority state, hiding the principal, private limits, spend history, and delegation graph from counterparties and public observers.
How is ZKM different from ZKC?
ZKC decides whether parties may interact. ZKM decides whether a spend is authorized. ZKA decides whether it settles.
The two protocols also invert who is hidden. In ZKC, issuers are public accepted-set authorities (KYC providers, jurisdiction attestors) and the credential holder is the one who stays hidden behind a proof. In ZKM, the issuer of a mandate is the principal — self-issued authority, no external attestor — and the issuer is the one who stays hidden.
How does the principal stay hidden?
Issuance binds a mandate's root_id to the principal's issuance key without revealing it, and the binding fact is preimage knowledge, not a signature. Because ZKM's issuer is the principal itself, there is no second party who needs to sign for it, unlike ZKC where a credential issuer and holder are different parties.
root_id is deliberately not a public input at issuance — publishing it would hand observers the revocation-watch handle for the whole subtree. It surfaces only if the principal ever revokes, and even then the disclosure is exactly one value: which lineage was killed, not who held it, how big it was, or what it did.
Why isn't a mandate "just a credential"?
A cap is a consumable, not a static fact. "Agent may spend up to 1000" must support many partial spends, by concurrent sub-agents, verified by strangers, with no trusted party tracking a balance — while revealing neither the original cap, the remaining balance, nor the spend history, and while making over-consumption cryptographically impossible, not merely detectable. A credential proves a fact once; a mandate proves a fact that keeps changing as authority is spent.
Technical Design
What cryptographic primitives does ZKM use?
ZKM circuits are written in Noir and proven with UltraHonk (Barretenberg) over BN254, hashing with Poseidon2 — the same composition baseline as ZKA and ZKC. Key derivation is AFP-KDC's; ZKM defines and owns its own domain-separated tags (zkm/mandate_commitment/v1, zkm/mandate_nullifier/v1, and others) rather than re-registering through a central authority.
ZKM's spend-conjoined proof mirrors ZKA's value-note commitment, nullifier, and address derivation constructions verbatim, so a ZKM spend and a native ZKA spend produce byte-identical commitments and nullifiers.
How does cap consumption work without a trusted balance keeper?
A mandate is held as a mandate note in a settlement-layer state tree, structurally parallel to ZKA's value-note tree. Consuming authority follows the UTXO change pattern: SPEND nullifies the input note and creates a successor with the spent amount deducted; SPLIT divides one note's cap across two successors; RETIRE surrenders remaining authority with no successor; ROTATE rebinds a note to a new key for the same holder.
Every transition proof enforces conservation in-circuit: the successors' caps, plus anything spent, plus anything retired, must equal the input note's cap — range-checked and asserted before any comparison, so the invariant cannot be silently bypassed.
How is over-consumption made impossible rather than merely detected?
Every transition emits a nullifier bound to the consumed note, the holder's secret, and the settlement context. Two concurrent spends of the same mandate note both emit the same nullifier; the settlement layer accepts at most one. The loser's transition is simply rejected — no balance oracle, sequencer, or coordinator is needed, and there is nothing to detect after the fact because there is nothing to race against.
The cost is that a single mandate note serializes its consumers. Parallelism comes from pre-splitting a mandate into disjoint sub-notes ahead of dispatch, never from relaxing nullification.
What does a verifier actually learn from a proof?
Exactly the statement in ZKM's design goal: valid mandate, unrevoked, within remaining cap, unexpired, policy satisfied — nothing else. Successive states are unlinkable: each successor commitment uses fresh randomness, nullifiers are pseudorandom, and neither cap values nor tree position appear in public inputs.
| Residual Surface | What It Discloses |
|---|---|
asset_id + settlement context |
Inherent to being paid in a named asset on a named settlement target |
| Timing | When a transition settled, not what lineage it belongs to |
| Transition kind & successor arity | The shape of activity on a target (counts of SPEND/SPLIT/DELEGATE/…), never who transacted or which lineage |
The per-spend amount is a private witness, not a public input — it is disclosed only to the counterparty receiving the ZKA note, never to an observer of the settlement record.
Delegation & Revocation
How does delegation work?
DELEGATE takes one of two forms. A full rebind consumes the delegator's note entirely and creates one successor at the delegate's key, with depth incremented — the delegator retains nothing. A partial delegation is a SPLIT in which exactly one successor rebinds to the delegate while the other keeps the delegator's key and depth unchanged.
Every hop can only preserve or narrow cap, expiry, and policy — never widen them — and a full rebind or rotation requires a separate possession proof from the delegate before it can settle. Without it, a rebind to a key no one controls would silently destroy the delegated authority.
What stops someone from revoking a mandate that isn't theirs?
A revocation insertion must be authorized by a proof of knowledge of the mandate's issuance preimage — the same material the issuance proof guarantees exists for every accepted mandate. A settlement layer accepts a revocation only against a verifying proof under that dedicated verification key. There is no operator-permissioned path and no way to revoke by observing a mandate's public identifiers.
Can a delegator revoke just their delegate's sub-mandate?
Not in v0.1. Revocation is deliberately principal-only and subtree-total: one revocation by the original principal kills the entire delegation subtree, because every successor and sub-mandate preserves the same root_id. An intermediate delegator has no mechanism to revoke just its own delegate.
The v0.1 mitigation is a short expiry on delegated authority combined with partial delegation, so re-delegation from the retained note acts as a soft revocation lease. A privacy-preserving per-hop revocation mechanism (delegation revocation handles) is a named design direction for a future artifact version, not yet shipped.
What happens to a delegate's funds if their mandate is revoked?
Nothing. Revocation encumbers authority — the mandate notes — never value. ZKA value notes held by any party, including a delegate whose mandate was just revoked, remain fully spendable and withdrawable. What stops is the ability to make new spends of the principal's value under the revoked authority. No ZKM mechanism enables third-party or operator freeze, seizure, or redirection of value.
Composition, Status & License
Does ZKM require ZKC or AFP?
No. ZKM's novel normative surface is the mandate artifact, the cap-consumption state model, and the authorization predicate — everything else is reused by reference, not restated: ZKC supplies epoch-pattern and envelope conventions (but not ZKM's issuance or accumulator semantics), key derivation is AFP-KDC's, and nullifier/note machinery and settlement are ZKA's.
ZKC composition (binding a mandate to a same-subject ZKC credential presentation) and AFP §14 bilateral limit envelopes are both optional. Neither subsumes ZKM: an AFP tenant's agents may carry ZKM mandates whose caps sit inside a separately negotiated bilateral envelope, verified by both systems independently.
What's the current status of the specification?
ZKM is at v0.1.0-draft, Apache 2.0. Every section carries normative direction, and eight reference statement circuits stand behind the enforced parts: mandate transitions, spend-conjoined proofs, delegate possession, issuance, revocation authorization, control attestation, and ZKC-bound issuance and spend companions. Open items — formal unlinkability proofs at machine-checked strength, per-hop revocation handles, replenishing mandates — are enumerated in the specification's open-questions section.