Spending wallets and Safe approvals
Set up wallet B or Safe approvals and resume an operation without changing what was signed.
Separate account access from spend approval#
Account keys let you discover notes and prepare ownership proofs. A spending controller adds an approval requirement when you execute them. Recovering the keys cannot remove that requirement. Decide who approves each operation before asking for signatures.
A registered wallet-A recovery account can fix an approval wallet B: an EOA, Safe or another supported ERC-1271 wallet. The app also has a separate Safe-controller workflow that collects Safe owner signatures itself. Choose the flow for your account type; they use different account records and approval collection.
| Flow | Account type | How approvals are collected |
|---|---|---|
| Approval wallet B | Registered account with recovery wallet A | Fuyu accepts B's final EOA or contract-wallet signature |
| Safe controller | Notes controlled by a supported Safe | Fuyu shares private review material and imports owner signatures |
| No extra controller | Account access authorizes its notes | The holder approves the operation and its submission path |
Approve with wallet B#
Choose B while setting up wallet-A recovery. Its address is fixed once setup starts. B approves account configuration, recovery-record updates and spends from controlled notes. The funding wallet supplies deposits. B approves later spending without receiving private account keys.
Use the connected wallet, a separate WalletConnect session or an imported signature to approve. The connected wallet must be B. If B is a Safe, its own tools collect owner approvals and supply a final contract signature; this flow does not collect the owners inside Fuyu. Read the app's operation review before signing, since the wallet prompt may show hashes instead of payment details.
Sign the operation you reviewed#
The approval covers the Pool and chain, controller, proof, ordered public signals, request, sender capsule and verification-key hash. A different recipient, minimum output, fee or proof needs a different approval. Signing one operation gives no blanket account access.
The app encrypts and saves the pending operation before sending a signature request. If remote backup is enabled, it also needs the acknowledgement required by that recovery flow. It checks the signer and contract-wallet rules before continuing. After an interruption, restore the original authorization and inspect it before asking for another signature.
// The app constructs SafeSpend EIP-712 approval data with this helper.
import { prepareSafeSpendApproval } from './safe-approval.ts';
const approval = prepareSafeSpendApproval(reviewedProofContext);
// reviewedProofContext includes the exact proof, 39 public signals,
// request, sender capsule, chain, Pool and verification-key hash.
// Independently verify its private output review before signing.
const { domain, types, message, digest } = approval;Collect Safe owner approvals#
For a Safe-controlled account, the initiator prepares a proof and gives owners a private review file or fragment link. The file opens private outputs so owners can check recipients and amounts themselves. Their browser verifies the proof, replays finalized Pool and Safe state and signs its digest. Share the review only with the owners who need it.
Import the signatures and check the Safe's owner threshold before submitting. This client supports specified owner types, including plain EOAs and its supported contract-owner paths. Other contract or delegated-code owners may not count. Every batch step needs enough approvals from owners still in the Safe. A removed owner's signature stops counting.
Check Safe and route support#
The Safe-controller tools support their configured Safe 1.4.1 contracts on chain 1 and disposable fork chain 31350. They refuse a Sepolia Pool without a supported Safe deployment. Recognizing chain 1 in this code is separate from releasing Fuyu on mainnet. Wallet B uses another external-wallet flow; do not apply the Safe-controller interface's assumptions to it.
A route must give co-signers enough material to check its external calls independently. If a route is refused for Safe-controlled notes, choose a supported route. The client offers creation of a Safe passkey signer only on the disposable fork. Other networks and physical devices need separate rollout and compatibility checks.
Resume a proposal that is still pending#
A shared proof with enough approvals can execute while its inputs are unspent and its controller and time checks pass. Closing the editor or keeping the proposal does not revoke shared signatures. Its inputs stay reserved; you can use unrelated notes for other operations.
If submission is uncertain, check Pool history and Safe state. A changed fee schedule may cause the relay to refuse the original fee without spending the inputs. Do not automatically generate another proof. A canceled local wait, signed authorization and confirmed revert mean different things. Keep the encrypted journal until you know what happened to the original operation.