Issue work

[Dannnyhamps]

Closes #815

[vercel]

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

A member of the Team first needs to authorize it.

[Miracle656]

The code here is good — better than the title suggests. I'm requesting changes on the packaging only, and the main reason is that as submitted this PR pays you about a quarter of what the work is worth.

You've closed one issue and implemented at least four.

The body says Closes #815 (150 points). What's actually in the diff:

Work	Issue	Points
One asset registry — delete both lib/assets.ts copies, re-export from packages/agent	#815	150
AddressRecovery.tsx — sign in on the web wallet by C-address + passkey	#769	150
restoreBackup() — sign in from a backup file	#765	150
establishRecoveredFeePayer / fee-payer PRF on recovery	#766 (partly)	150

Split into four PRs and you get credit for four issues. Left as one, GitHub closes #815 and the other three stay open with their work already merged — and I'd have to ask you to re-open them as empty PRs to fix it. Please split; that's the whole ask.

What I verified, and it's clean:

• No new signing path. Nothing here reimplements signAuthEntry / signXdrPayload / the 5-element sigVec, which is the mistake I was most worried about in a diff this size.
• No register() call outside the create flow, so nothing strands a wallet by overwriting invisible_wallet_key_id.
• AddressRecovery guards with if (walletLocal.getItem('invisible_wallet_address')) router.replace('/lock') before writing anything — so it can't clobber an existing wallet. Exactly right.
• recoverWalletByAddress + matchWebAuthnSigner verifies the assertion against the on-chain signer set rather than trusting the address the user typed. That's the correct shape for this feature.
• The @veil/sdk/recovery/signerVerification and @veil/agent/assets path aliases are added to tsconfig.json properly, and the existing @veil/prf / @veil/backup aliases already resolve on main.

The #815 half in particular is exactly what that issue asked for — deleting frontend/wallet/lib/assets.ts and frontend/mobile/lib/assets.ts outright rather than leaving re-export shims that drift again.

Two collisions to be aware of when you split:

• #904 also does fee-payer PRF hardening (#682, C2/C3), on mobile. Yours is web-side, so they should compose — but whoever lands second needs to check the derivation agrees across platforms, because a fee-payer derived two different ways is a stranded account.
• #884 covers backup-file sign-in and the fee-payer funding banner (#765, #766). That's a genuine overlap with two of your four pieces. Land #815 and #769 first — those are uncontested and yours — and we can sort #765/#766 between the two of you after.

Also: the branch is currently CONFLICTING against main, and a 64-file conflicting diff is painful to resolve in one go. Splitting fixes that too.

Suggested order: #815 first (self-contained, no conflicts with anyone, merges immediately), then #769. Retitle each one properly — "Issue work" makes it impossible for anyone to tell what they're reviewing. Ping me on each and I'll turn them around quickly.

[Miracle656]

New commit today (fix(recovery): share signer errors with mobile), but the packaging ask is unchanged and the branch has drifted badly since:

  base=main   ahead_by 4   behind_by 168   CONFLICTING

168 commits behind is the more urgent problem now — whatever the split ends up looking like, this needs a rebase before it can merge at all.

The body still says only Closes #815, and the diff still carries the work for #769, #765 and #766 alongside it. I know splitting a branch you have already built is unglamorous, so to be concrete about why I keep asking: merged as-is, GitHub closes #815 for 150 points and the other three issues stay open with their implementations already on main. There is then no clean way to pay you for them — I would be asking you to open empty PRs against issues whose code already shipped, which is worse for both of us than a split now.

The order I would take it in:

1. Rebase on main first. At 168 behind, splitting before rebasing means resolving the same conflicts several times.
2. #815 on its own — deleting both lib/assets.ts copies and re-exporting from packages/agent. That half is finished and I would merge it the day it lands alone.
3. #769 (AddressRecovery.tsx), #765 (restoreBackup()), #766 (establishRecoveredFeePayer) as three more.

One thing to carry into the recovery PRs, since it is the same code as #851 and #852 and I have just flagged it on both: sdk/src/recovery/signerVerification.ts hashes clientDataJSON into the signed message and never parses it — no type, no origin, no challenge check. On /recover that was survivable because possession was already proven; on a sign-in path it means a captured assertion is accepted again. Worth fixing in whichever PR carries that module rather than three times over.

Nothing in my verification notes above has changed: no new signing path, no stray register(), and AddressRecovery still guards against clobbering an existing wallet. The code is good. It is the packaging and now the rebase.