Wallet Control Passkey
Wallet Control Passkey is the approval and ceremony layer for wallet-sensitive actions in Fased. Use it for:- send approvals
- policy changes
- wallet security setup
- unlock
- recovery
- device-share and second-device changes
What it protects today
Current runtime behavior is:- ordinary user sends create an approval request first
- passkey is used on
Approve, not onCreate Approval Request - wallet security actions require Wallet Control Passkey before they proceed
Browser and origin requirements
Passkeys need a secure browser context. Practical rule:- use HTTPS
- or use
http://localhost:18789on the gateway host
Step 1: enable passkey approval
In the Wallets page:- open Wallets
- open the
Accesstab - find
Wallet Control Passkey - click
Enable passkey approval
Step 2: enroll the first passkey
Still inWallet Control Passkey:
- optionally set a label
- click
Enroll passkey - complete the browser’s passkey ceremony
- approving sends
- changing wallet policy
- setting up split-key security
- unlock and recovery actions
Step 3: use passkey in the send flow
The current send flow is:- open the send modal
- choose source wallet, chain, amount, and destination
- click
Create Approval Request - review the pending request
- click
Approve - complete passkey verification if enabled
- let the runtime execute and log the send
Step 4: turn on wallet security
For Agent and Vault wallets, you can then enable split-key custody. Current operator flow:- select the wallet
- go to its security section
- initialize split-key security
- export or print the recovery share
- decide whether this browser may keep an encrypted device share
- the wallet is locked by default
- unlock requires Wallet Control Passkey plus device or recovery share
Device share and recovery share
The current split-key model has two operator responsibilities:- device share
- recovery share
- belongs on a trusted browser or second device
- can be exported for second-device setup
- should not be stored together with the recovery share
- is the offline backup
- should be downloaded, printed, or otherwise stored offline
- should stay separate from both the host and any device share
Encrypted browser storage
Some browsers can keep the current device share in encrypted browser storage. That is helpful, but it is not a replacement for the recovery share. Practical rule:- encrypted browser storage is convenience for this client
- offline recovery share is the real backup
Unlock, recovery, and second device
Current operator model:unlockopens a signing window for a secured walletrecoverrotates the wallet onto a new device share and new recovery shareenroll devicecreates a second-device handoffrevoke deviceremoves a stale or lost device share
- unlock only when you intend to sign
- recover immediately if a device share is lost or compromised
- after recovery, export the new recovery share right away
Best practices
- enroll at least one passkey before turning on wallet security
- keep passkey, device share, and recovery share as three separate concerns
- keep the recovery share offline
- do not rely on one browser profile as your only recovery path
- do not remove the last passkey while secured wallets still depend on it