The dashboard message is a generic symptom, not proof of one root cause. Separate project ownership, the submitted production response, current Base.dev metadata, and Base App runtime before changing anything.
Stop at the first mismatched layer. Preserve the evidence, correct that layer, and retry once. Repeated blind submissions can obscure the actual state without proving anything.
Something went wrong does not identify which verification layer failed. Preserve the timestamp, exact project, submitted URL, visible dashboard step, and sanitized error before changing code. Do not infer a Base platform outage, a manifest defect, or an ownership failure from the message alone.
Base documentation says an unregistered app should have one Base.dev project with its primary URL and metadata completed. Already registered apps should not be registered again merely because the platform model changed. Confirm that you control the project and that its primary URL is the production URL you intend to verify; avoid creating a second project as a troubleshooting experiment.
Proof to keep: the sanitized project view and exact primary URL. Never publish dashboard credentials or private account data.Fetch the exact submitted URL from a fresh, unauthenticated client. Record its redirect chain, final URL, status, content type, and initial HTML. If the Base.dev dashboard gives you a project-specific ownershipbase:app_id tag or another project-specific token, verify that the exact value appears in the response bytes where the dashboard instructs, rather than only after client-side JavaScript runs. Do not copy an identifier from another project.
Base documentation says that after April 9, 2026 the Base App treats apps as standard web apps regardless of Farcaster manifests. A clean /.well-known/farcaster.json, fc:miniapp embed, or Farcaster account association can still matter for a Farcaster target, but it does not prove Base.dev ownership verification or current Base App readiness.
For a new project, verify the name, icon, tagline, description, screenshots, category, primary URL, and builder code against the current Base documentation. Saving metadata is not proof of search placement, rewards, review approval, or future client behavior. Avoid repeatedly resubmitting unchanged data.
Proof to keep: a dated metadata checklist and the deployed asset URLs, without account credentials.Load the production URL in a mobile browser and the Base App in-app browser. Exercise wallet connection, wagmi or viem interactions, SIWE where used, rejection, confirmation, and recovery. Private Base.dev project state and in-client behavior cannot be certified by a public Farcaster scanner or a successful build.
Proof to keep: dated before-and-after evidence for the one failing Base flow, not a broad release claim.If the exact production response matches the dashboard instruction and the project metadata is complete, use the official support path shown by Base.dev. Include the timestamp, exact URL, redirect chain, response status, and a minimal reproduction. Never publish private keys, auth tokens, wallet signatures, API keys, or unrelated account details.
Proof to keep: the support reference and the sanitized reproduction. Do not post credentials or payment signatures.Base's terms describe application verification as a limited technical process. It is not an endorsement, audit, security guarantee, ranking promise, or recommendation.
A successful Base.dev step also does not prove wallet flows, transactions, notifications, or a separate Farcaster target. Verify the affected production flow independently.
The official Base pages define the current platform boundary. The community report only demonstrates that builders have seen this generic message; it does not establish its cause.
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.