Skip to main content

Organization Treasury

The Organization Treasury is a shared, on-chain account an organization's admins control together: moving its funds takes M of N admins, each signing from their own phone. No single person — and no single compromised device — can move the money alone.

It is built on the same ERC-7913 smart account as Wallet for Agents, configured as a real multi-signer account: the threshold M is chosen at creation and frozen into the deployed address.

The shape of it​

  • Signers are passkeys. Each admin's signing key is a WebAuthn/P-256 passkey held in their device keychain (Face ID / fingerprint), synchronized by iCloud Keychain or Google Password Manager. Losing the phone no longer loses the signer — the passkey follows the person. The biometric check is signed into every approval and verified on chain, not merely a screen the app draws.
  • The signer app only signs. Admins navigate in the web dashboard; the companion mobile app opens directly on the signer's pending duties — a code to show, a peer to verify, a transfer to sign — reached by a deep link from a push or an email. It never lists treasuries.
  • Transfers are intents. An admin opens a transfer from the dashboard; it becomes an intent that each signer's phone signs after re-deriving, locally, exactly what will happen on chain (destination, amount, network). The M-th signature broadcasts it.

Enrolling a signer — the verification ceremony​

A new signing key is admitted only after an existing signer confirms it, out of band, so that a compromised dashboard cannot slip in a key nobody holds:

  1. The candidate's phone creates its passkey and enrolls it, publishing a commitment to a secret nonce.
  2. An existing validator opens the check from their phone — this draws a second nonce.
  3. The candidate's phone reveals its nonce and displays a 4-digit code.
  4. The candidate reads the code to the validator, in person or on a call.
  5. The validator types it. A match admits the key; a mismatch does not.

The 4-digit code (a short authentication string) is derived on both phones from the candidate's key and the two nonces; the candidate commits to its nonce before the validator's exists, so the short code cannot be ground to a chosen value. A wrong code burns the enrollment — one online guess, never a retryable search. The code is never served by the API: the validator must read it off the candidate's screen, which is exactly what makes the check out-of-band.

The wallet creator is the one exception — their first key is self-validated, so a 1-of-N treasury deploys as soon as the creator enrolls.

Signing a transfer​

  1. An admin opens a transfer from the dashboard.
  2. Each active signer's phone re-derives the transfer and shows the destination, amount and network.
  3. The signer approves with Face ID / fingerprint.
  4. The M-th signature hands the transfer to the relay, which broadcasts it.

What the phone displays is what the signature authorizes: the app rebuilds the transfer's on-chain hash from the fields it shows and refuses to sign if that disagrees with what the server sent. A tampered transfer shows an alarm, never a sign button.

What it protects, and what it assumes​

See Security & recovery for the full trust model. In short: the ceremony defends against a compromised dashboard and human error; Keyban's operators remain the custodian of last resort for recovery, and that is an assumed, documented part of the design — not an accident.