Guide

Set up yourapproval quorum.

Three decisions and a policy change: who signs, how many must agree, and what limits apply even after they do.

Decision 1

Who are the signers?

Each signer is a principal with their own token: you at your laptop, a co-founder on their machine, a service account on a hardened box. Register each one with approval rights — and nothing more than they need.

read -r -s CLIENT_TOKEN
printf '%s\n' "$CLIENT_TOKEN" | canonicalwallet client register \
  --label cofounder --principal-kind human_operator --client-token-stdin \
  --capability view_proposal --capability approve_proposal \
  --capability reject_proposal --json
unset CLIENT_TOKEN

Decision 2

How many must agree?

Set the approval requirement in policy: a plain count (any 2 of 3), named principals who must be among the approvers, or human-required so machine tokens can never satisfy the quorum alone. Policy changes are themselves proposals — your quorum guards its own rules.

route the change through approval

canonicalwallet proposal change-policy   # the policy change becomes a proposal
canonicalwallet policy list              # see active templates
canonicalwallet policy inspect           # read one in detail

Decision 3

What can never happen, even with approvals?

Guardrails apply on top of the quorum: per-origin permissions restrict which accounts and methods an app may touch, and fail-closed review means a transaction that can't be decoded and simulated cleanly can't be machine-approved at all.

Verify

Prove it works before it matters.

dry run

canonicalwallet proposal tx --to 0x… --value-wei 1 --rationale "quorum test"
canonicalwallet proposal approve --id <id>      # first signer
canonicalwallet proposal why-not-executable --id <id>   # shows the missing approval
# second signer, own token:
canonicalwallet proposal approve --id <id>
canonicalwallet proposal execute --id <id>