mobile: implement onboarding create flow (backlog #25)

[popdadyrisky]

Implement mobile onboarding create flow that:
Registers a WebAuthn passkey via the Invisible Wallet SDK
Derives a deterministic fee-payer Keypair from the passkey credential ID (HKDF → Ed25519)
Funds the fee-payer via Friendbot (testnet) or verifies mainnet funding
Deploys the wallet contract through the factory using wallet.deploy()
Writes session state (invisible_wallet_address, veil_signer_secret) to sessionStorage and navigates to /dashboard
Files:
frontend/mobile/app/(onboarding)/create.tsx
Acceptance:
WebAuthn credential created → wallet contract deployed → session set → dashboard landing (see QA steps)
Notes:
The mobile flow keeps the signer secret ephemeral until after deploy (opt-in reveal). Web onboarding persists the secret prior to deploy; consider aligning behavior if desired.

closes #453

[vercel]

@popdadyrisky is attempting to deploy a commit to the miracle656's projects Team on Vercel.

A member of the Team first needs to authorize it.

[drips-wave]

@popdadyrisky Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits

[Miracle656]

Thanks! One thing to reconcile before this lands: main already has a create-wallet flow at frontend/mobile/app/create-wallet.tsx, and this adds a separate app/(onboarding)/create.tsx — so the app would have two create screens on different routes. Could you rebase onto main and either fold this into the existing create-wallet.tsx or clearly replace it (and update the navigation), rather than adding a parallel route? Then I'll re-review.

[Miracle656]

Thanks @popdadyrisky — nice onboarding UX. Blocker: this is written for the web runtime and won't run on React Native as-is — it uses next/navigation, localStorage, window/document, and qrcode.react (a react-dom library), none of which exist on native. It also uses deriveFeePayerKeypair, which ADR 0003 deprecated (C2/C3 — deriving the fee-payer from the credential ID).

#594 just landed the correct native pattern — please rebuild on top of it:

• expo-router for navigation (not next/navigation)
• expo-secure-store / AsyncStorage for storage (not localStorage)
• react-native-passkeys for registration
• react-native-qrcode-svg for the QR
• the SDK's PRF-based fee-payer, not deriveFeePayerKeypair

Happy to help scope it.

[Miracle656]

Apologies for the month this waited — that is on us.

Reviewed it against current main, and there is one thing to resolve before it can land.

Nothing routes to this screen. The onboarding folder currently holds only _layout.tsx and welcome.tsx, and welcome's create button goes elsewhere:

// app/(onboarding)/welcome.tsx:51
const handleCreate = async () => {
  await AsyncStorage.setItem(SEEN_WELCOME_KEY, '1');
  router.push('/create-wallet');
};

app/create-wallet.tsx exists and is ~10.5KB of working create flow. So as it stands, adding (onboarding)/create.tsx gives us a second create screen that no path reaches — 439 lines of dead code, and two implementations of the same flow to keep in step.

Which is the intent?

1. Replace — this supersedes create-wallet.tsx. Then the PR should also repoint handleCreate to /create and delete the old screen, so there is exactly one create flow.
2. Complement — it does something create-wallet.tsx does not. Then say what, in the PR description, and wire the route that reaches it.

Either is fine; what cannot land is a screen with no way in. We have had that pattern bite twice recently — most recently a hook that was added but never mounted, so the feature it described never ran.

If you would rather not carry this forward after the delay, that is completely fair. Not closing it either way. If option 1 is the intent and you want me to check the two screens against each other and tell you what create-wallet.tsx has that this does not, say so and I will.

[Miracle656]

I've been going through every open PR now that the wave has closed, fixing things myself where a PR needed work rather than leaving it to sit. I can't do that here, and I'd rather explain exactly why than leave this quietly open.

This is a Next.js page committed into the React Native app. frontend/mobile/ is Expo / React Native, and the file uses the web stack throughout:

• 'use client' — a Next.js directive, meaningless in RN
• useRouter from next/navigation — mobile uses expo-router; next/navigation appears nowhere in frontend/mobile and is not a dependency
• 8 calls to localStorage — React Native has no localStorage. Mobile persists through expo-secure-store / AsyncStorage
• @/lib/deriveFeePayer, @/lib/network, @/lib/supabase — those resolve in frontend/wallet, not here
• qrcode.react — a DOM renderer, not installed in mobile

It does not compile. tsc --noEmit -p tsconfig.typecheck.json on the mobile workspace:

app/(onboarding)/create.tsx(4,27):  error TS2307: Cannot find module 'next/navigation'
app/(onboarding)/create.tsx(7,39):  error TS2307: Cannot find module '@/lib/deriveFeePayer'
app/(onboarding)/create.tsx(8,61):  error TS2307: Cannot find module '@/lib/network'
app/(onboarding)/create.tsx(9,36):  error TS2307: Cannot find module '@/lib/supabase'
app/(onboarding)/create.tsx(10,30): error TS2307: Cannot find module 'qrcode.react'
app/(onboarding)/create.tsx(71,22): error TS18047: 'derived' is possibly 'null'
app/(onboarding)/create.tsx(72,19): error TS18047: 'derived' is possibly 'null'

And fixing the imports would not be enough. The file has 76 web elements — <div>, <button>, className — and zero React Native components. There is no <div> in React Native, so every element in the render tree would need rewriting against View / Text / Pressable / StyleSheet, and every localStorage call swapped for the async secure-storage API, which changes the control flow because those calls return promises.

At that point it is not a rebase, it is writing the screen again — and mobile onboarding already exists at frontend/mobile/app/create-wallet.tsx, with app/(onboarding)/ already holding _layout.tsx and welcome.tsx. So the honest outcome would be a third creation path that duplicates a working one.

I've left this open rather than closing it, so it stays on the record.

What would make this mergeable, if you want to take it further: port the flow against create-wallet.tsx as the reference — expo-router for navigation, mobile's own lib/ modules, react-native-qrcode-svg instead of qrcode.react, and RN primitives for the markup. If you do, say so and I'll review it properly.

For what it's worth, the flow is sensible — the landing → registering → deploying → done → error state machine, checking for a stored passkey before registering rather than prompting again, and holding the fee-payer keypair in a local variable rather than state. That reasoning ports; the platform code does not.

[Miracle656]

I've been reworking every open PR myself now that the wave has closed, rather than leaving them to sit. I couldn't land this one, and I want to show you exactly what I hit rather than leave it quietly open.

The work itself is careful. The parts I'd single out: the fee payer is derived and shown before deploy, so a user whose Friendbot call fails can fund it by hand instead of being stuck; the secret QR is opt-in behind a confirmation modal rather than rendered by default; and handleCreate is resumable — it checks for a stored passkey first, so a retry after a failed deploy doesn't mint a second credential. That last one is a bug most onboarding flows ship with.

What stopped me: this is the web page, in the mobile app's folder

The file lands at frontend/mobile/app/(onboarding)/create.tsx, but it's built against the browser:

import { useRouter } from 'next/navigation'
import { trackWalletCreated } from '@/lib/supabase'
import { QRCodeCanvas } from 'qrcode.react'

localStorage.getItem('invisible_wallet_key_id')
sessionStorage.setItem('veil_signer_secret', signerSecret)
const out = document.createElement('canvas')
<div className="min-h-screen flex flex-col items-center justify-center p-6">

React Native has no localStorage, no sessionStorage, no document, no <div>, and no Tailwind class names. next/navigation and qrcode.react aren't in frontend/mobile/package.json at all, and @/lib/supabase doesn't exist under frontend/mobile/ — only under frontend/wallet/. So it can't typecheck in that project, and on a device it would fail at the first localStorage read.

It's also unreachable: (onboarding)/welcome.tsx routes to /create-wallet, and (onboarding)/_layout.tsx declares no create screen. Nothing would ever render it.

Why I can't just port it

Mobile already has this flow — frontend/mobile/app/create-wallet.tsx, reachable from Welcome, and it covers #453's acceptance end to end. It also does two things this branch's approach can't:

The fee payer comes from the passkey's WebAuthn PRF output, not from the credential ID. That difference decides whether the wallet is recoverable. A credential ID is a public handle — it's returned by the authenticator and stored in the clear, so anyone who reads it can re-derive the fee-payer secret from it. The PRF output is a secret only the authenticator can produce, and only for the right user. lib/passkeyWallet.ts also surfaces a recoverable flag when PRF is unavailable and it has to fall back to a random keypair, rather than letting the user believe their wallet survives a lost phone when it doesn't.

Secrets go to the secure store, not to storage the OS can read. setSignerSecret writes through expo-secure-store (Keychain / Keystore). sessionStorage on mobile is either absent or, under Expo web, plain readable storage.

So porting this would mean rewriting all 439 lines against React Native APIs, and landing on a screen that does less than the one already shipped. That's not a rework I can do honestly on your behalf.

What I'd genuinely like from it

One idea here is better than what's on main, and it isn't platform-specific: when Friendbot fails, show the fee-payer address and let the user fund it manually. Right now create-wallet.tsx says "Friendbot was busy — you can still receive funds and retry later" and moves on, which leaves the user with no way to unblock themselves. Your flow's answer — surface the G… address with a QR, let them fund it, then continue — is the right one.

If you want to take that further as a small mobile-native PR against create-wallet.tsx, I'll review it properly. react-native-qrcode-svg is already in the project (app/receive.tsx uses it), and the address is right there in CreatedWallet. That's a contained change and a real improvement.

I've left this open rather than closing it, so it stays on the record. And to be clear about where the mismatch came from: #453 didn't say which app it targeted, and the web onboarding page is the obvious reference implementation to work from. That's on the issue, not on you.