Wallet Authorization

Four separate boundaries#

1. 01
   Connection selects a wallet provider and account.
2. 02
   EIP-4361 or Sign-In With Solana proves ownership where the flow requires it; this is not a transaction authorization.
3. 03
   Fresh simulation and explicit Strategy Manifest approval bind the reviewed workflow.
4. 04
   Your wallet signs the applicable transaction or supported permission request.

FloFi does not hold the user’s private key or seed phrase. Never enter them into a chat, API request or approval link.

An integration can ask, not authorize#

Developer keys and MCP OAuth authenticate integrations or accounts. They do not prove wallet ownership. Approval links carry a view/claim handoff secret in the URL fragment; opening or claiming a link does not approve the Manifest or sign a transaction.

One owner signing journey#

ChatGPT, Claude, WhatsApp and Telegram handoffs use the same /approve journey. FloFi opens with the proposal’s actions already on the Canvas; proving wallet ownership (a sign-in message, or your existing FloFi sign-in) loads that exact proposal for your wallet. Then run a fresh simulation, review the Strategy Manifest and authorize with your own wallet. An embedded agent panel cannot sign for you.

If an interrupted handoff was already applied, recovery can restore only the proven claimant’s authoring proposal. It does not restore simulation, review or spending authority. A different approval link cannot inherit the previous proposal’s recovery state.

Understand the actual enforcement#

Direct signing and finite Safe/Zodiac Roles permissions have different enforcement models. The bounded Safe/Roles demonstrations are controlled local-fork profiles; they do not establish general production automation. A review commitment is not a substitute for contract-enforced limits.

Account changes, stale hashes and unsupported paths invalidate unused authority. For unknown submissions, follow Execution & Verification.