After April 9, 2026, Base App uses a standard web app + wallet model powered by Base.dev. This is a Base App-specific migration, not evidence that your Farcaster integration should be removed or that one manifest fix makes both clients ready.
Preserve the working target while you migrate the broken one. Verify the exact production flow after every material change instead of treating a build or metadata save as completion.
Base documentation says that after April 9, 2026 the Base App treats apps as standard web apps, regardless of Farcaster manifests. If you still ship inside Farcaster, keep that integration as a separate target. Do not use a clean /.well-known/farcaster.json response as proof that the current Base App path is ready.
Search the Base-facing flow for signIn, ready, addMiniApp, Farcaster user context, FIDs, and Mini App navigation actions. Base App no longer invokes those methods. Map every dependency to a standard web alternative before deleting the old code; a dual-target app may still need the Farcaster branch.
Use wagmi and viem for wallet connection and contract interactions. Where authentication is required, use Sign-In with Ethereum. A production session needs a server-issued nonce, backend signature verification, expiry, and replay protection; client-side signature recovery alone is not a complete session design.
Verify disconnected, connecting, connected, wrong-chain, rejected-signature, expired-nonce, and replay cases.If the app is not already registered, create its Base.dev project and complete the primary URL, name, icon, tagline, description, screenshots, category, and builder code. Base documentation says already registered apps do not need to re-register or update metadata merely because of this migration. Avoid duplicate projects.
Keep a sanitized metadata checklist and the exact production primary URL; never publish account credentials.Neynar webhooks, FIDs, and Farcaster notification tokens do not address Base App users under the new model. Use the Base.dev notification path and opted-in wallet addresses where notifications are part of the product. Do not add a notification dependency to an app that does not need one.
Test opt-in, send, opt-out, and stale-address handling without exposing a notification credential.Test the production URL in a mobile browser and the Base App in-app browser. Exercise wallet connection, SIWE where used, chain switching, transaction rejection, confirmation, and recovery. Confirm the Base.dev project points to the deployed URL. None of these checks guarantees ranking, rewards, approval, or future client behavior.
Keep dated before-and-after evidence for the one failing flow, not a broad claim that the whole app is certified.A Base-specific pass can show that one reproduced Base App flow now works against the documented standard-web contract. It does not prove that the Farcaster manifest, embed, account association, or runtime remains correct.
Conversely, a clean Farcaster dossier does not expose Base.dev project state or guarantee Base App discovery. Keep the evidence, fixes, and acceptance decisions separate.
This migration changed in 2026. Check the official Base documentation before implementation; use Farcaster documentation only for a Farcaster target you still support.
TLMNT accepts one bounded failure only after it can be reproduced and the required access is agreed. We deliver before-and-after evidence, and request payment only after you verify the fix. We do not promise Base.dev approval, search placement, rewards, or future client behavior. Submitting the form authorizes neither access nor payment.