Treasury security & recovery
The treasury's job is to make a single compromise insufficient. This page states what it defends against, where the trust boundaries are, and how a lost signer is recovered.
Trust boundaries
- On chain — the real barrier. M-of-N is enforced by the smart account; each signature is verified independently (ECDSA for an address signer, WebAuthn/P-256 for a passkey), and the biometric user-verification is signed into every passkey approval.
- The phones — the signers. Passkeys live in the device keychain and are never exported; before signing, each phone re-derives the transfer locally (WYSIWYS) and refuses a mismatch.
- Keyban's backend — trusted, and the custodian of last resort. It relays the signed envelopes and cannot forge a signature, but its operators can add and remove signers on chain (recovery — see below).
What the enrollment ceremony protects
The 4-digit verification (Organization Treasury) defends against two concrete threats:
- A compromised dashboard presenting a signing key nobody holds: the code is derived from the candidate's real key and read off the candidate's own phone, so a substituted key produces a code that will not match.
- Human error: an admin who was not expecting to validate anyone sees an unexpected code request and stops.
It does not defend against a compromised signer: one validation admits one
key, so a single malicious existing signer can grow the set toward the threshold.
This is the reason to keep N comfortably above M and to treat signer
admission as a real event — every admission is broadcast to all admins.
What it does not try to be
The backend is trusted (it relays the signed envelopes and cannot forge a signature, but it sees every field). The passkey approvals bind the biometric user-verification and the exact transfer hash, so a backend cannot silently redirect a signature — but it is not a zero-trust custody product. Keyban's operators can, by design, add and remove signers on chain: this is what makes recovery possible, and it makes Keyban the custodian of last resort.
Recovery
Passkeys synchronize, so the ordinary case — a lost or replaced phone — needs nothing: the signer's passkey reappears on the admin's next device signed into the same account. Recovery procedures exist only for the harder cases:
| Situation | Resolution |
|---|---|
| Lost / replaced phone (same ecosystem) | Nothing — the synced passkey follows the account |
| Lost Apple/Google account | Cold replacement if N ≥ M+1, else the operator procedure |
| Switching iOS ↔ Android | Operator procedure (passkeys do not sync across ecosystems) |
More than N − M signers lost, or a hostile signer | Operator procedure |
The operator procedure is a formal, out-of-band process — identity verified on a video call and confirmed by a second admin of the same organization, all current signers and owners notified, an objection window observed before any on-chain change, and a full audit trail. It is documented for operators in the treasury signer recovery runbook and governed by ADR 0098.
Why P-256 passkeys work on every chain
A passkey signs with the P-256 curve, which most chains cannot verify cheaply in a precompile. Keyban's verifier tries the RIP-7212 precompile where it exists (Base) and falls back to a Solidity implementation where it does not (XDC, local devnets) — the same verifier, transparently, on every supported network. Gas is not a decision factor at treasury volumes (fractions of a cent per signature either way).