How a transaction happens

This is the part that makes Canonical different from an ordinary wallet, so it is worth five minutes. In most wallets, sending money is one button: sign and it is gone. Here it is four small steps, and the gap between them is exactly where your safety lives.

  1. Propose   →   2. Review   →   3. Approve   →   4. Execute
     (draft it)      (see what        (the right       (final check,
                      it does)         people say yes)   then send)

• Propose. You (or an agent) draft the transaction. Nothing is signed. The wallet writes down a durable "to-do" with its own id and remembers it.
• Review. The wallet decodes the transaction into plain terms and simulates what it would do, then freezes that reading in place.
• Approve. The people your rules require give a thumbs-up. Each approval is tied to the frozen review, not just to "transaction #47."
• Execute. The wallet double-checks nothing changed, signs, and broadcasts. The result goes into the history log.

At any point before execution you can just walk away and the draft keeps waiting. Nothing irreversible has happened yet.

Out of the box, one person cannot send a transaction alone.

The wallet ships set to "two approvals, at least one of them human" for anything that moves money. And a brand-new wallet has exactly one person in it. So your first transfer will sit there, approved once, refusing to go — not because something is broken, but because it is doing precisely what it promised: requiring a second signer.

This is what "multisig by default" means, spelled out. It is a feature, and it is also the reason your first transaction starts by adding a second approver. If you are flying solo, you will hold two approval tokens yourself; if you are a team, your co-signer holds the other.

You can dial this down to one-approval, but the wallet makes that deliberately hard — changing the rule itself needs two approvals — so a single key can never quietly weaken its own protection. Multisig & policy covers the trade-off.

When the wallet reviews a transaction, it writes down exactly what that transaction does and takes a fingerprint of that description. Your approval is recorded against the fingerprint.

The payoff: nobody can show you a harmless transaction, get your approval, and then swap in a different one. Change a single detail and the fingerprint no longer matches — every approval on it instantly becomes worthless, and the wallet refuses to sign.

A couple of practical notes that follow from this:

• If the review comes back uncertain (usually because it could not reach the network for full data), a machine is not allowed to approve it at all, and a person approving a high-risk uncertain review has to type a reason.
• Right before signing, the wallet rebuilds the review and compares ("drift check"). If the on-chain world moved since you approved, it stops. You can run that check yourself: canonicalwallet proposal compare-review --id <id>.

When a few people share a wallet, a pile of pending transactions gets messy fast. The workflow tools keep it orderly — without ever changing who approved what:

• claim a transaction so others see you are on it,
• hand it off to someone else,
• mark it reviewed or request changes with a note.

None of these approve anything. Claiming a transfer is saying "I've got this," not "I approve this." A person can bump another person's claim if needed; a bot cannot.

Rather than scrolling every pending transaction, ask:

canonicalwallet inbox me

It shows only the ones where you can do something — review, approve, or send.

The wallet will always tell you exactly what is blocking a transaction:

canonicalwallet proposal why-not-executable --id <id>

Usual answers: it still needs another approval, it needs the human approval, the world drifted since review, or your token is not allowed to send. Troubleshooting turns each answer into a fix.