Dexscreener is where Enhanced Token Info orders become trackable updates

Walk through the Enhanced Token Info order screen

The Enhanced Token Info order screen presents three stages: set token info, pay, and wait for processing. Two identifiers establish the target before any descriptive choice matters - the selected chain and the token address. Signing in is the first prerequisite, because the marketplace does not let a guest proceed from the product page to an order.

After choosing the chain, paste the mint or contract address and let the form resolve the token before filling in its description, links, icon, header, locked-supply details, and contact fields. Read the chain and full address again at confirmation. The amount shown there is a live checkout value, while the fixed payment choices are cryptocurrency or credit/debit card. Confirmation should happen only after the resolved token matches the project you intend to update (see Dexscreener filters ).

Prepare the project copy and assets before opening checkout, because a resolved target proves that the address is recognized, not that unfinished text or placeholder artwork is ready. Keep locked-supply entries distinct from contact details, and decide which links belong in the public profile before payment. This preparation prevents a technically correct order from publishing incomplete material.

Choose the chain before pasting the address

The chain selector forms one half of the token identity, so it must be set before the address is interpreted. EVM networks reuse the same 20-byte address structure: an ordinary display has a 2-character 0x prefix followed by 40 hexadecimal characters, making 42 characters in total. EIP-55 adds a mixed-case checksum, yet the formatting alone cannot distinguish Ethereum from Base or BNB Smart Chain.

Numeric mainnet IDs provide a useful independent cross-check even though the order screen presents network names: Ethereum is 1, BNB Smart Chain is 56, Polygon PoS is 137, Base is 8453, Arbitrum One is 42161, and Avalanche C-Chain is 43114. Solana uses a different model; an SPL Token mint is a base58 representation of a 32-byte account address and has no 0x prefix. Select Solana for that mint, not an EVM network that happens to host a token with the same symbol.

Token address or pair address?

The token address identifies the asset whose profile will change, while the pair address identifies a particular liquidity pool. On Ethereum, an ERC-20 contract is distinct from a Uniswap pair or pool contract. On Solana, the SPL Token mint is distinct from a Raydium market or Meteora pool account. Copy the full value beside the intended token, never the value labeled Pair.

Dexscreener automatically lists a token after it has been added to a liquidity pool and recorded at least one transaction. Enhanced Token Info then attaches descriptive data to the existing chain-and-token identity; it does not use the pool as the order target. When several pools show the same ticker, compare the complete mint or contract address with the deployment record before moving forward.

The distinction remains visible on a pair page: the Pair row holds the pool identifier, while the individual token rows hold the base and quote token addresses. A Pumpfun token remains identified by its Solana mint even when it later trades in a Raydium or Meteora pool, so the mint remains the Enhanced Token Info target.

What the form changes on the pair page

The token-profile form controls four practical groups of information: project description, visual assets, community or project links, and eligible supply context. The icon and header identify the profile visually, while the description and links populate the information area on pair pages. Every value belongs to the single chain-and-address target chosen at the start of the order.

Locked-supply entries have a narrower purpose. They identify wallets holding supply under a lock so the interface can present market capitalization from an appropriate circulating-supply figure. Fully diluted valuation follows (total supply − burned supply) × price; where Enhanced Token Info supplies self-reported circulating supply, market capitalization uses that figure instead. A polished description does not correct a wrong locked wallet, so review supply entries separately from the visible copy.

Five-condition review before confirmation

The confirmation review is the final point where all inputs remain editable without creating a paid order. Use this five-item decision checklist against the actual values on screen:

• The selected chain matches the network where the mint or contract was deployed.
• The target is the token address, not the pair, pool, wallet, or transaction address.
• The description and each link belong to the same project and render as intended.
• The icon, header, and locked-supply entries correspond to that exact token identity.
• The checkout amount, payment method, account, chain, and full address are acceptable together.

If any condition fails, return to the relevant field before pressing the final order button. A symbol, token name, or familiar logo does not replace the two-part identity check, because duplicate tickers exist across chains and within the same chain.

Payment creates a trackable token-profile order

The payment step changes an editable submission into a paid order associated with the selected chain and token address. Checkout supports two payment families - cryptocurrency and credit/debit card - but both lead to the same service-side order target. A crypto payment pays for the service; it does not rewrite ERC-20 or SPL Token state.

After successful execution, a Dexscreener order record exposes three core status fields: type, status, and paymentTimestamp. Enhanced Token Info appears as the tokenProfile type, and a newly accepted job can report processing. That state means payment has produced a queued profile request; it does not yet mean the submitted fields are visible on the pair page.

Save the payment confirmation separately from the profile draft, since the first proves the checkout event while the second preserves what was requested. If publication differs from the submitted material, the order number and saved field values describe the discrepancy more precisely than a payment transaction alone.

Read paid-order status without guessing

The paid-orders status check uses the chain ID and token address as two path inputs, matching the target chosen in the form. The public API permits 60 requests per minute for this check, and an HTTP 200 response returns an array of matching paid-order records. A successful response confirms that the query ran; the returned object determines whether a token-profile order is present.

For a matching entry, read type, status, and paymentTimestamp together. A processing value is an intermediate state, not a second payment request. An empty array calls for a comparison of the queried chain and full token address with the saved order. It does not establish that the token lacks a pair page, because listing and paid-profile status are separate records.

Publication is the completion check

The published token profile is the final completion check for an Enhanced Token Info order. The service allows up to 12 hours for processing, even though many orders finish within minutes. During that window, a recorded processing state is consistent with an accepted order still moving through the queue.

Completion means the submitted description, images, links, and applicable supply information are visible for the correct token on the Dexscreener website and apps. Refresh the page resolved from the full chain-and-address identity, then compare the displayed fields with the submitted copy. Price, volume, and transaction counts continue to come from trading activity, so changes in those figures are not publication signals (more on this in Dexscreener alerts ).

When the token trades in several pools on the selected chain, inspect more than one pair page after publication. The paid order is keyed to the token address rather than a single pool identifier, so consistent profile fields across those pages provide a stronger completion check than watching only the pool used to open the form.

Correct a chain-and-address mismatch before checkout

A chain-and-address mismatch is the most useful setup error to resolve before payment. The Dexscreener form may resolve an unexpected token, report existing enhanced information, or fail to find the intended target when a pair address was pasted. Return to the chain selector, choose the deployment network, and paste the token contract or mint again from its full record.

For an EVM token, confirm all 42 displayed characters, including the 0x prefix, and preserve EIP-55 checksum casing when available. For Solana, confirm the base58 mint represents the 32-byte token-mint address rather than a pool or wallet. Address format identifies a network family, not the exact chain. If payment already succeeded, keep the existing order and raise the mismatch with its order number instead of creating an immediate duplicate.

Keep the order record for support and refund handling

The order record is the support packet for any status that remains unresolved after the processing window. Save the marketplace account email, order number, selected chain, full token address, payment evidence, and submitted profile fields together. A support request should come from the same email used for the order and should state the order number, token address, and concrete reason for the request.

The refund window for a fully paid order is 14 days from order completion, not an open-ended cancellation period. Three published eligibility categories cover a platform-caused technical delay, multiple charges applied to one order, and a qualifying platform cancellation. An inactive token, a request to delete an existing profile, or a user-side condition that prevents the token from going live on supported pools does not qualify. The saved identifiers let support examine the exact paid order without relying on a ticker or display name.