A token can have a logo, a trading page, and an active chat while its official identity remains hard to check. Paying for a faster review does not resolve that problem. For Jupiter token verification, your first job is to make the correct mint and the evidence behind the project easy to find.
Jupiter’s verification process, VRFD, combines data-driven signals with human review (VRFD Overview). Therefore, treat the application as an evidence packet: show consistent public information, genuine participation, and the context a reviewer needs. This guide takes you through ten preparation steps, a review-options comparison, and a checklist you can use before applying.
Review terms below use the September 29, 2026 source baseline. Before submitting, confirm current fees and review terms in the official portal.
What Jupiter token verification means
The green checkmark identifies a token as the canonical version associated with a project. It is not a security audit, investment recommendation, or endorsement of the team. Trading access is also separate. An unverified token can still trade through Jupiter when suitable liquidity is available on integrated venues (Frequently Asked Questions).
For a project team, the right goal is therefore not “make the token look approved.” It is “make the official token easy to identify and the project’s activity easy to evaluate.” The checklist below contains practical preparation advice, not a set of additional mandatory Jupiter requirements.
Jupiter token verification requirements
Jupiter considers market capitalization, Organic Score, holder distribution, ticker uniqueness, social validation, and onchain liquidity together. Its FAQ identifies duplicate tokens, weak trading activity, and insufficient social proof as common reasons for non-verification (Frequently Asked Questions). There is no published universal combination of liquidity, holders, volume, and score that guarantees approval.
Expectations vary with the token’s circumstances (Token Verification). That distinction matters because more visible activity is not automatically better evidence. A polished application cannot substitute for the underlying facts.
From scattered information to a reviewable request
- Identify: Publish the official mint and resolve identity conflicts.
- Document: Link public evidence for the project’s claims and activity.
- Choose review: Compare timing and cost without assuming approval.
- Track and maintain: Record the result and keep information current.
Step 1: Confirm the mint for Jupiter token verification
On Solana, the mint address uniquely identifies a token. In contrast, a liquidity-pool address, trading-pair address, or wallet address identifies something else (Create a Token Mint). Before preparing an application, confirm the mint through the project’s official records and a blockchain explorer. In particular, do not copy an address from a trading page without checking what account it represents.
Jupiter explicitly recommends displaying the mint prominently on the project website (Frequently Asked Questions). For example, a useful implementation is a permanent token-information page that distinguishes the official mint from any pool addresses. Link that page from the project’s documentation and pin a matching announcement on its official X account.
During a migration, preserve an accessible explanation of the old and new token identities. Similarly, for a naming conflict, explain which project the application represents and provide dated public evidence. Avoid expecting reviewers to reconstruct the history from scattered community messages. For the related explorer task, use Tokpie’s Solscan token logo guide.
Keep that work separate from this review: a recognizable logo does not establish the full verification case.
Step 2: Give the project one consistent, supportable description
Audit the website, documentation, social profiles, and token descriptions as though you were seeing the project for the first time. Start with one sentence describing the project. Then check whether every official channel supports it and separates live features from planned features. A community-focused token does not need an invented utility narrative.
By comparison, a product-linked token should explain what users can actually do today. Where a project describes commercial integrations, asset backing, payments, or other functionality, attach evidence rather than relying on promotional language. Also, keep risk disclosures, but resolve contradictions between those disclosures and the rest of the site. As a result, readers should be able to distinguish current features, development work, and ambitions.
This is an editorial recommendation for a clearer application, not a claim that Jupiter requires every project to publish a formal roadmap or reveal its founders’ identities.
Step 3: Check liquidity before Jupiter verification
For spot swaps, Jupiter sources routes through integrated trading venues, including decentralized exchanges (DEXs). Consequently, a project does not need to create a pool owned by Jupiter. Supported markets may be discovered automatically, while continued routing depends on the relevant routing engine’s liquidity checks (Market Listing). Start with quotes in both directions: buying the project token and selling it back into another liquid asset.
Next, compare several realistic trade sizes and inspect price impact and the route used. However, a token-information page alone does not prove that a usable swap route currently exists. Therefore, treat quotes as a diagnostic, not proof that a transaction has executed successfully. For technical validation, use an appropriately controlled test rather than making unnecessary large trades.
Also, record where liquidity resides and how the project manages it. Where liquidity is described as locked, provide independently verifiable evidence and disclose the lock conditions. Jupiter publishes specific market-routing tests, but those are not verification thresholds. A market can pass a routing check without earning a verification badge (Market Listing).
Step 4: Improve genuine participation, not manufactured volume
Jupiter’s Organic Score is a relative measure of activity it classifies as organic. Specifically, it incorporates organic volume, holders, traders, and buyers. The application programming interface (API) supplies a numeric score and broad labels. However, Jupiter advises using the raw score because tokens within one label can differ substantially (Tokens API).
Therefore, do not interpret the score as an approval probability. Nor should the label “medium” become an invented eligibility rule. For preparation, monitor changes over time instead of selecting the most flattering daily snapshot. Then investigate whether participation reflects continuing interest or a brief campaign. Instead, focus on useful releases, clear onboarding, accessible documentation, and community activities people would join without being paid to trade.
Avoid wash trading, circular transactions, purchased volume, and artificial wallet splitting.
However, automated trading is not inherently fraudulent. Jupiter’s own explanation distinguishes non-organic activity such as market making and arbitrage from the organic participation its score measures. These activities can support a functioning market without demonstrating the same kind of user demand (How Does Jupiter Decide If a Token Is Real?).
A developer can use Jupiter’s Tokens API to inspect verification status, liquidity, holder information, Organic Score, and available audit fields. In either case, treat missing data as unknown, not as a clean bill of health (Token Information). For a community-led launch, Tokpie’s meme coin launch planning guide provides broader positioning and transparency context.
Use that planning to explain the project clearly, rather than inventing utility or manufacturing demand.
Jupiter’s verification guide emphasizes social support and requires the linked X account to be dedicated to the project, rather than a personal or influencer account (Token Verification). VRFD also uses Smart Followers and Smart Likes to represent support from recognized ecosystem participants. However, a large follower total is not the same thing as this signal (Official Portal and Open-Contribution Overview).
Give the project account a clear identity, current website link, pinned token information, and a history of substantive updates. For example, useful posts can explain releases, governance decisions, community initiatives, treasury activity, or independently confirmable collaborations. Instead of chasing a headline count, seek genuine participation from people who understand the project.
Do not buy endorsements, impersonate ecosystem figures, or present paid promotion as independent validation.
For an agency helping a client, the deliverable should be an evidence-based communication plan, not a package promising a particular follower count or a guaranteed badge. Also, keep paid campaign results distinct from independently earned engagement in any supporting report.
Step 6: Explain token distribution and project-controlled wallets
A holder count does not, by itself, explain how supply is distributed. Jupiter evaluates distribution as part of its review (Frequently Asked Questions). Therefore, prepare a concise transparency page covering the wallets the team can reliably identify. For clarity, separate treasury, team allocations, liquidity positions, vesting arrangements, and distribution wallets.
State who controls them and which restrictions are independently verifiable. Where an airdrop accounts for a substantial part of the holder base, explain its purpose and method. However, do not present every recipient as an active user or independent buyer. Likewise, do not assume that every large wallet belongs to an insider.
When ownership is unknown, label it unknown. Also, distinguish onchain evidence from project disclosures.
For related token launches, explain shared ownership, treasury arrangements, or distributions where relevant. The aim is not to overwhelm the reviewer with every transaction; it is to make material relationships understandable without speculation.
Step 7: Review technical permissions and risk warnings
VRFD displays onchain risk information, including liquidity issues, holder concentration, authorities, transfer fees, and sellability signals (Official Portal and Open-Contribution Overview). However, warnings can affect the assessment without automatically determining the outcome (Token Verification). Ask the technical team to explain any active mint or freeze authority, transfer restrictions, fee mechanisms, and unusual controls.
Then check that public claims match the implementation. Do not describe supply as fixed, trading as unrestricted, or liquidity as permanently unavailable for withdrawal unless the evidence supports that description. Where a permission is necessary, document why it exists, who controls it, and what safeguards apply. Alternatively, where it is unnecessary, review whether removal is appropriate.
However, do not revoke permissions solely to make a dashboard look cleaner. Solana’s authority documentation explains that revocation permanently removes the selected authority role. Therefore, assess the operational consequences before signing any change (Set Authority). If your team needs a separate security review, compare smart contract audit providers by relevant scope and expertise.
Keep audit work and Jupiter verification as separate workstreams, because a badge does not replace a security assessment.
Step 8: Align metadata for Jupiter token verification
Compare the token’s displayed identity across the website, explorer, trading interfaces, and Jupiter. Specifically, check its logo, description, social links, and supply information. Remove broken links and distinguish current channels from abandoned ones. Jupiter offers a separate metadata-review process covering these fields. For example, public announcements and information on the official domain can help substantiate a correction.
However, updating onchain metadata does not automatically synchronize changes after verification. Jupiter requires manual review for that synchronization (Token Metadata Updates). Verification and metadata updates can be requested together through the Express flow, but the decisions are independent. Consequently, a successful metadata update does not mean verification was approved (Express Verification API).
For an unchanged application, do not request cosmetic edits merely to create the impression of progress. Instead, correct actual errors and provide proof for each requested change.
Similarly, use the Phantom token logo and price guide when checking wallet presentation. Record the actual display you observe, and do not treat a correct icon as evidence that Jupiter approved the token.
Step 9: Submit your Jupiter verification application
Who can apply?
Anyone can submit a token for verification, including a community member. In other words, applications are not restricted to the creator or project team (Official Portal and Open-Contribution Overview). However, connecting the project’s X account is optional and can strengthen the identity link (Token Verification). A third-party applicant should describe their role honestly.
Accordingly, use the project’s public information without claiming to control its accounts or represent its team unless authorized. The optional account connection and the required project handle serve different purposes. Specifically, providing an X handle in the Express API is not the same action as connecting that account. Keep the project handle accurate even when the applicant is a community member.
Prepare the submission
Open the official VRFD portal and locate the token using its mint. Follow the token-verification workflow and connect a supported wallet when prompted. Prepare the correct mint, project X account, reason for verification, and public evidence. The Express API documents the project’s X handle and request description as required fields; metadata changes and the submitter’s own X handle are optional (Express Verification API).
Before paying, also check for an existing pending request. The Express eligibility check identifies submission restrictions, including pending applications (Express Verification API). A compact evidence statement can follow this structure:
This request concerns the canonical Solana token associated with the project.
Official token-information page: [link]
Official project X profile: [link]
Public announcement confirming the mint: [link]
Documentation and supply disclosures: [link]
Relevant context:
[Explain any migration, naming conflict, community takeover, or related
project relationship. Include only facts supported by public evidence.]Use this as a structure, not a substitute for completing the form’s required fields. In particular, put the strongest identity evidence first. Avoid unsupported superlatives, price predictions, and promises about future listings.
Choose Standard or Express
| Review option | Published terms | Practical use |
|---|---|---|
| Standard | Free; no guaranteed review deadline. | Suitable when timing is flexible. |
| Express | At the source-check date, 1,000 units of Jupiter’s governance token per submission; first review within 24-48 hours. | Suitable when faster review itself has value, even if the outcome is rejection. |
The two options buy different review timing, not different approval standards (VRFD Overview Frequently Asked Questions). In addition, Express may include up to two further reviews, at 24-48-hour intervals (Token Verification). Before paying, confirm the current payment asset and amount in the official interface. Also, budget separately for each token application.
Do not assume one fee covers a portfolio (Express Verification API). A rejection does not entitle the applicant to a refund. However, Jupiter’s published terms provide a refund exception if the guaranteed first-review window is missed (Token Verification). Before signing, inspect the transaction and verify the domain. Never disclose a seed phrase or send payment to an address supplied by an unsolicited message.
Step 10: Track your Jupiter verification result
After submission, save the confirmation, transaction record where applicable, and public request link. Jupiter directs applicants to the Submissions page to track their requests (Express Verification API). However, do not confuse payment confirmation or successful request creation with approval. In the API, verificationCreated confirms that an application was created, not that the token passed (Express Verification API).
Express rejection feedback can use broad categories such as ticker conflict or insufficient metrics. There is no formal reapplication waiting period, but a fresh Express application requires another fee (Token Verification). Instead of paying again immediately, treat rejection as a prompt to identify what was missing. Check whether the official identity was unclear or the trading and social signals were weak.
Also, consider whether a migration or project relationship needed explanation.
When relevant evidence may have been overlooked, use official Jupiter support before paying again (Frequently Asked Questions). In that case, submit specific public evidence, not an argument that payment should have purchased approval. Therefore, a useful resubmission should explain what materially changed and link to proof. Rewording the same unsupported claims is not progress.
Before reapplying, write a short change log with three fields: the issue, the change, and its public evidence. For example, a corrected mint announcement can resolve an identity mismatch. A new slogan cannot prove a change in participation. This is an internal preparation habit, not an additional Jupiter requirement.
Jupiter token verification checklist
Before applying, ask five questions:
- Identity: Can an unfamiliar reviewer confirm the official mint from the project’s own public channels?
- Consistency: Do the website, documentation, metadata, and X account tell the same supportable story?
- Participation: Is there evidence of genuine activity beyond paid attention, giveaways, or automated trading?
- Transparency: Are material supply allocations, controls, and project relationships explained accurately?
- Submission: Does the application contain accessible evidence, with the applicant understanding the cost and possible rejection?
Together, these questions form a preparation tool, not an official scoring system. They should help a team decide what to fix, not produce an invented percentage chance of success. Give each unresolved checklist item an owner and a link to the missing evidence. Then ask a teammate who did not prepare the application to follow those links.
If they need private chat history to understand the token, make the public explanation clearer before submitting. Do not convert this exercise into a numerical probability of approval.
Jupiter verification: frequently asked questions
What does Jupiter token verification prove?
It identifies the canonical token associated with a project. However, the badge is not a security audit, investment recommendation, or endorsement of the team.
Can an unverified token trade on Jupiter?
Yes, when suitable liquidity is available on integrated venues. Therefore, diagnose trading routes separately from verification status.
What Organic Score guarantees approval?
No published universal score or combination of metrics guarantees approval. Instead, evaluate the score alongside identity, distribution, liquidity, and credible social evidence.
Does Express guarantee that my token will pass?
No. Express changes review timing, not approval standards. Consequently, pay only if faster review itself has value to your team, even if the result is rejection.
Is the Express fee refundable after rejection?
Rejection does not entitle the applicant to a refund. However, the published terms include an exception when the guaranteed first-review window is missed. Confirm current terms before paying.
Can a community member submit the application?
Yes, anyone can submit a token for verification. However, describe your role honestly and do not imply that you control project accounts without authorization.
Does an approved metadata update mean verification passed?
No, the decisions are independent even when requested together. Therefore, check verification status separately from the outcome of a metadata correction.
Can Jupiter remove verification later?
Yes, verification is not permanent. Accordingly, keep official channels accessible and maintain accurate metadata, migration records, and public disclosures.
After Jupiter verification: keep the evidence current
Verification can be removed; Jupiter’s FAQ makes clear that the badge is not permanent (Frequently Asked Questions). Therefore, treat approval as the beginning of ongoing information maintenance, not the end of responsibility. Keep official channels accessible, document migrations and material changes, and review outdated metadata. Also, preserve the submitted evidence so future team members can understand what was verified.
The strongest long-term approach is also the most defensible application strategy: make the token’s identity clear, its public claims accurate, and its participation genuine. Then let the submission present those facts without exaggeration.
Start by fixing the weakest item in your readiness checklist. Then submit through the official portal when the evidence is accessible and the review terms make sense for your team. If you are also preparing broader token discovery, use Tokpie’s Solana CoinMarketCap and CoinGecko listing guide to organize that separate workstream.
Keep each platform’s application, evidence, and decision in its own record.