Mechanism · Zero-Knowledge Mandates · Open standard

Authorized spend without exposing the principal.

ZKM lets an autonomous agent prove that a spend sits inside a valid, unrevoked, cap-and-expiry-bounded mandate without revealing who granted it, the original cap, or anything spent before.

The verifier learns only what matters.

A mandate is a principal-issued grant of spend authority held as a private note. Its proof answers five questions while keeping the principal, limits, policy parameters, and history concealed.

Valid mandate

The note was issued from authority whose preimage the principal knows.

Within cap

The private spend amount does not exceed the note’s private remaining authority.

Unexpired

The settlement target’s clock is earlier than the mandate’s committed expiry.

Unrevoked

The lineage is absent from the current revocation accumulator within the deployment’s disclosed freshness window.

Policy satisfied

The spend satisfies the published policy circuit committed inside the note. The SDK refuses predicates the agent cannot inspect.

Authority moves like value.

A cap is consumable, not a static credential. ZKM uses a note-and-nullifier model so parallel agents can spend independently without a trusted balance keeper.

SPEND(M, amount) → M′

Spend, then return private change.

The input mandate note is nullified. A successor carries the unspent authority, while the conjoined ZKA proof settles the same private amount. Both effects are accepted atomically or neither happens.

successor cap + spent amount + retired amount = input cap
SPLIT

Prepare concurrency

Divide one cap into disjoint notes before dispatching parallel agents.

DELEGATE

Narrow and rebind

Pass full or partial authority to another holder. Cap, expiry, and policy cannot widen; depth increments and must remain within its configured limit.

ROTATE / RETIRE

Move or surrender

Rebind a whole note to a new key for the same holder without changing depth, or destroy remaining authority with no successor.

Over-consumption is impossible by construction. There is nothing to detect later.

Every transition emits a pseudorandom nullifier bound to the consumed note, its holder secret, and the settlement context. Two races against the same note produce the same nullifier, so canonical settlement accepts exactly one.

Parallelism comes from pre-splitting authority into separate notes, never from weakening serialization. Successor caps conserve the authority the principal issued across spends, splits, rotations, and delegation.

Delegation without a public delegation graph.

A delegate receives a new note bound to its own key. Full delegation requires a separate possession proof from the delegate, preventing an irreversible rebind to a key nobody controls.

Each hop can only preserve or narrow authority. Cap, expiry, policy, and depth constraints are enforced inside the transition circuit, not by an operator’s policy engine.

Revocation is principal-only and applies to the original mandate’s whole subtree. A principal proves knowledge of the issuance preimage; no operator or observed third party can insert a revocation.

Revocation is prospective and its effectiveness window is deployment-disclosed. Verifiers that cannot obtain a fresh accumulator root must fail closed.

One stage in a three-part transaction.

The protocol family separates interaction, authorization, and settlement so each proof discloses only what its counterparty needs.

ZKC

May these parties interact? Prove regulatory or policy facts without exposing the underlying data.

Explore ZKC →
ZKM

Is this spend authorized? Prove live authority, private limits, policy compliance, and conservation.

Review ZKM ↑
ZKA

Does it settle? Bind the authorized spend to confidential value whose custody no admin key can touch.

Explore ZKA →
v0.1.0 draft · Apache 2.0 · normative direction

The current draft specifies mandate issuance, private cap consumption, atomic ZKA spending, delegation, rotation, retirement, principal-only revocation, policy narrowing, receipts, voluntary disclosure, and same-subject ZKC composition. Eight statement circuits stand behind the enforced parts, digest-pinned in a statement registry the protocol family composes against; open items remain enumerated in the specification.