Safe Proof Delegation

Let a user delegate zero-knowledge proof generation to an external prover (a privacy RPC, a hardware accelerator, or a third-party service) without giving that prover the ability to forge, redirect, or overspend. The user signs a canonical intent digest that binds every material parameter; the prover can produce a valid proof that executes exactly that intent and nothing else.

Works best when

  • Users cannot generate zero-knowledge proofs locally (mobile wallets, hardware wallets, constrained devices).
  • A server-side prover or privacy-aware RPC bridges the gap before native wallet support.
  • Delegation must be revocable without moving funds to new notes or a new address.

Avoid when

  • Client-side proving is already available and performant for the target workload.
  • The prover seeing transaction details is unacceptable even temporarily; prefer a distributed or TEE-hosted prover instead.

I2I vs I2U — context differences

Institution to institution

I2I

Between institutions, proof delegation typically happens under bilateral contracts with SLAs and audit rights. The authorising institution can demand operational logs and, through legal recourse, punish deviation even though deviation cannot be prevented cryptographically.

Institution to end user

I2U

For users, the prover is usually an external service. The pattern must assume the prover can be adversarial at any moment: output-secret rotation and short-lived intents are how the user retains the ability to unplug a compromised prover without moving funds.

Post-quantum exposure

Risk · high
Vector
Pairing-based proof systems and ECDSA/Schnorr intent signatures are broken by a CRQC. HNDL risk applies: an attacker recording today's intent signatures could forge future spends once quantum capability is available.
Mitigation
Post-quantum signature schemes (ML-DSA, SLH-DSA) for the intent layer and STARK-based circuits for the proof system. See Post-Quantum Threats.

Components

  • Canonical intent digest that binds operation kind, token, recipient, amount, nonce, expiry, chain identifier, and any required additional fields such as policy version and pool address.
  • Two protocol secrets: an immutable spending key that controls nullifier derivation, and a rotatable output secret that controls deterministic output randomness. Note-delivery encryption is handled by companion standards.
  • Intent nullifier set, distinct from the note nullifier set, that prevents replay of a signed intent.
  • Zero-knowledge circuit that checks the signature against the authorising address, verifies that every public input matches the intent digest, validates note openings and Merkle paths, and enforces value conservation.

Protocol

  1. user Compute the canonical intent digest and sign it inside the wallet; the signed intent is never broadcast.
  2. user Send the signed intent plus witness data (note openings, Merkle paths, keys) to the prover over an encrypted channel.
  3. prover Run the circuit to produce a proof that binds the witness to the signed intent.
  4. prover Submit the proof and public inputs to the pool contract.
  5. contract Verify the proof, consume note nullifiers, and record the intent nullifier to prevent replay.
  6. user When switching provers, rotate the output secret so the former prover can no longer derive output randomness for future transactions; existing notes remain spendable because the spending key is unchanged.

Guarantees & threat model

Guarantees:

  • No custody: the prover never holds keys that can unilaterally spend. Every spend requires a user-signed intent.
  • Tamper-proof intents: modifying any bound parameter invalidates the proof.
  • Replay prevention: each signed intent can execute exactly once via the intent nullifier set.
  • Revocable delegation: rotating the output secret cuts off a former prover's ability to derive future output randomness without moving funds.

Threat model:

  • Soundness of the underlying proof system.
  • Correctness of the intent-digest schema and domain separation; a bug that lets the prover substitute a public input breaks the tamper-proof guarantee.
  • Confidentiality of the note-delivery channel. A malicious prover can emit unusable delivery payloads, rendering outputs unrecoverable by the recipient (funds are not lost for the sender, but the recipient cannot claim them).
  • Liveness of at least one prover; a single offline prover stalls the user until they switch.
  • Microarchitectural or supply-chain attacks on the prover that leak plaintext are in scope for this pattern but are mitigated by combining with a TEE-hosted or MPC-based prover.

Trade-offs

  • The prover sees transaction plaintext. Privacy from the prover operator itself requires a TEE-based or distributed prover, at the cost of more infrastructure.
  • Liveness depends on the prover. If the prover is offline, the user must switch or move to client-side proving.
  • Expiry tuning matters: too short and transactions fail before submission, too long and a compromised prover has more room to manoeuvre within the fixed intent.
  • Output-secret rotation has an operational cost: the user must retain the prior secret until the stale-root window expires and authorised transactions have settled.

Example

A user holds shielded balances in a mobile wallet that cannot generate zero-knowledge proofs. The wallet signs an intent to send 100 units to a specific recipient with a ten-minute expiry and forwards the signed intent plus witness data to a privacy RPC. The RPC generates the proof and submits it on-chain within three minutes. The RPC sees the transfer details but cannot redirect funds. When the user later switches RPC providers, they rotate the output secret; the former RPC can no longer derive output randomness for future transactions, and existing notes remain spendable.

See also

Open-source implementations