Milestone 5: Non-Custodial MetaMask Snap — Delivery Portion Complete
Combines the pluggable-signer architecture refresh and the MetaMask Snap.
-
Architecture & Design Refresh
- Updated architecture diagrams covering the pluggable signer interface and each of its implementations (custodial, Snap, custody partner, KMS).
- Snap signing flow: browser → Snap → API server → Canton Interactive Submission. Deterministic Canton-party derivation from the MetaMask seed phrase, including new-device recovery.
- Institutional custody flow: API server → custody partner API (or KMS) → Canton Interactive Submission. Per-key authorization policies, audit logging, operational runbooks.
- Threat model for each signing path, including supply-chain considerations for the Snap and key-policy considerations for the institutional path.
- Custody partner evaluation framework: capability checklist (Ed25519 support, programmatic signing, latency, audit log access, jurisdictional coverage, compliance posture), commercial criteria, and go/no-go decision gate for the in-house KMS fallback.
- Custodian-status disclosure: at the time of grant submission, ChainSafe has not engaged any custody partners. The evaluation framework runs in the first four weeks of the custody workstream. Candidate providers in the evaluation set include Fireblocks, BitGo, Anchorage Digital, and Copper; this is the set ChainSafe will approach during evaluation and is not a list of existing engagements.
-
MetaMask Snap for Canton Signing
- MetaMask Snap package providing Ed25519 signing for Canton transactions, with key material derived deterministically from the user's existing MetaMask seed phrase and stored inside MetaMask's isolated origin (so the user's existing seed-phrase recovery flow also recovers the Canton party).
- Snap integration with the API server: the server returns prepared transaction hashes from PrepareSubmission, the Snap signs them inside MetaMask, the server submits via ExecuteSubmission. No private key ever touches the server; no key file ever touches the user's disk or browser storage.
- Browser onboarding flow: install Snap, allocate external party from the Snap-derived public key, register with the API server, recover on a new device via the standard MetaMask seed-phrase restore.
- Snap distribution: published to the MetaMask Snap registry; versioned, signed, user-confirmed updates.
- Snap test suite covering signing correctness, key derivation determinism, signing-UX prompts, and cross-device recovery.
| Field | Details |
|---|---|
| Estimated Resources | Engineering: 11 weeks; Project Management: 2 weeks |
| Estimated Duration | 6 weeks |
| Amount | 5,000,000 CC (4,000,000 delivery + 1,000,000 adoption gate) |
| Delivery Criteria 1 | The Snap is published to the MetaMask Snap registry and installable by any user. |
| Delivery Criteria 2 | A non-custodial CIP-56 token transfer, signed inside the Snap with no private key on the server or on disk, is demonstrable end-to-end. |
| Delivery Payment | 4,000,000 CC on committee acceptance of delivery criteria. |
| Adoption Gate | At least 100 independent users have each installed the Snap and executed a real non-custodial CIP-56 transfer through the Snap on MainNet (or 50 with at least 2 transfers each), evidenced by on-chain party IDs (or attestation). |
| Adoption Payment | 1,000,000 CC upon meeting the adoption gate. |