On this page

Controllers & Authorization

Require a wallet or claim controller to approve spending a note.

A controller adds approval#

The note commitment fixes its controller. The spend relation covers that field, and the Pool checks the controller before execution. A valid ownership proof and value conservation are still required.

Ordinary notes use the same Pool without an extra wallet controller. Show whether approval is needed when the user opens the account or reviews a spend.

Wallet and Safe approval#

A spending wallet can be an EOA, Safe or supported ERC-1271 account. A Safe applies its current quorum and authorization rules. Recovering private keys does not remove those approvals.

The holder chooses this external authority. Owner changes, wallet upgrades and delegated account code can change whether an authorization is accepted later.

How the wallet, Pool and disclosure tools fit together
How the wallet, Pool and disclosure tools fit together

Approve a claim or refund#

A claim controller supports a private payment to an unregistered wallet. Its descriptor fixes the recipient, refund signer and deadline. The recipient can authorize before the deadline; from the deadline, the sender's one-time refund signer can authorize the refund.

The recipient is named onchain when the controller is deployed for claim or refund. Protect the claim secret and read the balance from authenticated history rather than amount hints in the link.

Recheck at execution#

An ERC-1271 wallet can change policy or revoke approval after offchain verification. Recheck when the operation executes. The payment SDK rejects contract signers by default; enabling them requires a reviewed acceptance policy.

Keep the original request and signatures during submission and recovery. A current controller check tells you whether that saved authorization can still execute.