# Zero-Knowledge Mandates (ZKM)

> Privacy-preserving spend authorization for autonomous agents. An agent proves a spend is within a valid, unrevoked, cap-and-expiry-bounded mandate from a principal, without revealing who that principal is.

ZKM is the authorization layer of the Pyramidal ZK protocol family, sibling of ZKA (settlement) and ZKC (compliance/eligibility). It uses zero-knowledge proofs (Noir/UltraHonk over BN254, Poseidon2 hashing) reused from the same composition baseline as ZKA and ZKC.

## Core Principle

ZKC decides whether parties may interact. ZKM decides whether a spend is authorized. ZKA decides whether it settles. The issuer of a ZKM mandate is the principal itself — self-issued authority, no external attestor — and the issuer is hidden. This inverts ZKC, where issuers are public accepted-set authorities and the holder is hidden.

## Mandate Artifact

A mandate is a principal-issued, scoped grant of spend authority held only as a commitment. Its opening carries: `root_id` (stable issuance identifier, the revocation anchor), `settlement_domain`, `asset_id`, `remaining_cap` (u128), `expiry` (u64), `policy_hash` (blinded), `holder_key`, `depth`, and commitment `randomness`.

## Cap-Consumption State Model

A mandate is held as a note in a settlement-layer state tree, structurally parallel to ZKA's value-note tree. Cap consumption follows the UTXO change pattern:

| Transition | Effect |
|------------|--------|
| SPEND(M, a) → M' | Nullifies M, creates one successor with cap reduced by `a`; conjoined ZKA proof settles `a` |
| SPLIT(M) → M'1, M'2 | Nullifies M, creates two successors whose caps sum to M's cap |
| RETIRE(M) | Nullifies M with no successor — voluntary surrender |
| ROTATE(M) → M' | Nullifies M, creates one successor at a new key, same holder, same depth |
| DELEGATE_FULL(M) → M' | Nullifies M, creates one successor at the delegate's key, depth+1 |
| DELEGATE_PARTIAL(M) → M'd, M'r | SPLIT where one successor rebinds to the delegate (depth+1), the other is retained |

Every transition proof enforces in-circuit: conservation of authority, range-checked bounds, monotone narrowing (successors cannot widen cap/expiry/policy/depth), membership + nullification, non-revocation, and temporal validity. Over-consumption is impossible by construction, not merely detectable — two concurrent spends of the same note emit the same nullifier, and a settlement layer accepts only one.

## Authorization Proofs

Two proof forms:

- **Spend-conjoined** (SPEND only) — conjoins the transition statement, the policy predicate, and the ZKA spend statement; settles value and authorization atomically.
- **Mandate-only** (SPLIT, RETIRE, DELEGATE_FULL, DELEGATE_PARTIAL, ROTATE) — the transition statement alone, with no ZKA value leg; structurally incapable of authorizing value movement.

A verifier learns only: valid mandate, unrevoked, within remaining cap, unexpired, policy satisfied — never the principal, the original cap, or spend history.

## Delegation

Full rebind and partial delegation both require a companion possession proof from the delegate before a settlement layer accepts the transition, preventing a rebind to an uncontrolled key from silently destroying delegated authority. Delegation depth is bounded by a deployment-disclosed `depth_max` baked into the verification key, and optionally by a per-mandate `depth_limit` policy parameter (Standard Policy v2).

## Revocation

Revocation is `root_id` insertion into a version-2 depth-254 sparse exclusion accumulator, exercisable only by proof of knowledge of the principal's issuance preimage. Because every successor preserves `root_id`, one revocation kills the entire delegation subtree. Revocation is principal-only and subtree-total — an intermediate delegator cannot revoke just its own delegate. Revocation encumbers authority, never value: ZKA notes already held remain fully spendable regardless of mandate state.

## Standard Policy

- **v1**: `max_per_spend`, `recipient_restricted`, `recipient_set_root`, `policy_blinding`. Delegation permitted, bounded only by `depth_max`.
- **v2**: adds `depth_limit` — a per-mandate delegation depth ceiling; `depth_limit = 0` forbids delegation outright.

A proof against any policy other than the one committed in the mandate's `policy_hash` cannot verify.

## Composition

- **ZKC**: optional same-subject composition is current: registry-pinned
  `zkm:issuance-zkc:v1` and `zkm:spend-zkc-binding:v1` bind a mandate's
  issuance or spend to a ZKC `v0.4.1-draft` credential presentation without
  linking the two proofs to different people. The current carriage is direct
  atomic settlement; current `zka:bundle:v1` has no standardized ZKM member.
- **AFP §14**: bilateral, negotiated limit envelopes between federated tenants compose with, but never subsume, ZKM's unilateral, principal-issued, stranger-verifiable mandates.
- **ZKA**: the spend-conjoined proof mirrors ZKA's value-note commitment, nullifier, and address derivation constructions verbatim.

## Freedom Safeguards (Normative)

ZKM inherits ZKA's six Freedom Safeguards in full:

- **Predicate Pluralism**: no policy circuit is canonical; a deployment may accept any policy circuit satisfying the open-source publication rule.
- **Minimal Disclosure**: a mandate proof discloses exactly the design-goal statement, nothing more.
- **No Revocability (of value)**: revocation encumbers authority, never value; no ZKM mechanism enables third-party or operator freeze, seizure, or redirection.
- **Open-Source Predicates**: every circuit, including every policy predicate, is published, versioned Noir source with a public review period; an SDK refuses by default to prove against an uninspectable policy.
- **Agent Exit Rights**: RETIRE is always available unilaterally, with no counterparty, policy, or principal consent required.
- **Verifier Accountability**: authenticated per-transition demands with in-lineage standing, holder-retained self-contained receipts, no operator custody, no principal-wide query surface.

## Specification

- [Full Specification](/spec/)
- [Markdown](/zkm_specification.md)

## Version

ZKM Specification Version: 0.1.0-draft (rev 11)
Family Compatibility Pin: 0.1.0-draft (rev 10)