01 / Overview
What Dexscreener Is and How to Read It
Dexscreener is a real-time market data terminal for tokens that trade on decentralized exchanges. Rather than listing coins the way a centralized venue does, Dexscreener indexes individual liquidity pools on automated market makers across many blockchains and rebuilds price, liquidity, volume, and trade flow from the swap events those pools emit. If a pool exists on-chain and has seen a trade, it generally appears on Dexscreener within seconds, whether it holds a blue-chip asset or a token deployed one minute ago.
That single design decision, pair-first instead of token-first, explains most of what newcomers find confusing. One token can have a dozen pools spread over several chains, each with its own price, its own depth, and its own chart. Dexscreener shows each of those pools as a separate row and a separate page, then rolls them up into a token-level view so you can see which pool actually carries the volume.
This page is a working guide to Dexscreener. It covers where the numbers originate, what each field on a pair page actually measures, how the screener and its filters behave, how trending and paid boosts interact, what the public API returns, and where the data can mislead you if you read it too literally. It is written for people who already trade or build on-chain and want fewer surprises.
Two habits separate people who get value out of Dexscreener from people who get burned by it. The first is always checking the contract address instead of the ticker, because tickers are free and infinitely reusable. The second is reading liquidity before reading price change, because a percentage move in a pool with almost nothing in it is a rounding error dressed up as a signal.
02 / Where the numbers come from
An automated market maker pool is a smart contract holding reserves of two tokens. Every swap changes those reserves, and the ratio between them defines the price. There is no order book and no matching engine, so there is nothing to subscribe to in the traditional market-data sense. Everything Dexscreener displays has to be reconstructed from blockchain state and event logs.
The pipeline works roughly like this. Indexers follow the chain, watch factory contracts for pool-creation events, then decode the swap, mint, and burn events of every pool they have discovered. Each decoded swap becomes a trade record with a timestamp, a direction, an amount on each side, and a maker address. Dexscreener aggregates those records into candles, rolling volume windows, and transaction counts. Because discovery is driven by factory events, a brand new pool on a supported exchange usually needs no manual listing at all.
Price is two hops away from the swap
A pool prices its base token in its quote token: units of WETH, SOL, USDC, or whatever the other side happens to be. To show a dollar figure, Dexscreener converts that ratio using a reference price for the quote asset. This is why the pair page gives you both the native ratio and the USD number, and why the USD number can wobble slightly when the quote asset itself moves. When you are comparing a token against the market, the quote-denominated price is often the cleaner read.
Liquidity is derived the same way: the reserves on both sides, valued and summed. For classic 50/50 pools that number is a fair proxy for depth. For concentrated liquidity designs, where providers place capital in price ranges, the value sitting in the contract is not the same as the value available at the current price, and Dexscreener cannot make that distinction visible in a single figure. Treat concentrated-liquidity numbers as an upper bound on usable depth.
Volume, transaction counts, buy and sell splits, and maker counts are all rolling windows computed from the same trade stream: five minutes, one hour, six hours, twenty-four hours. They are simple sums and counts, which makes them fast and transparent, and also makes them trivially inflatable by anyone willing to trade against themselves. Dexscreener reports what happened on-chain; it does not judge intent.
One more mechanical detail worth knowing: chains reorganize, nodes lag, and metadata arrives late. In the first minutes of a pool's life, values on Dexscreener can revise as blocks settle and as token supply and decimals are read from the contract. If a figure looks impossible on a one-minute-old pair, refresh before you conclude anything.
03 / Anatomy of a pair page
The pair page is the core unit of Dexscreener. Its header identifies the pool: base token over quote token, the exchange the pool belongs to, the chain it lives on, and the pool address itself. Everything below that header describes this pool and nothing else. Two pools for the same token are two different markets, and Dexscreener treats them that way on purpose.
Next to the identifiers sits the price block, with the dollar price, the native ratio, and the change chips for the standard windows. The chips are the fastest read on the page and the easiest to misread, because a window that contains only three trades will produce a dramatic percentage from almost no money changing hands.
Below the price sits the metric block: liquidity, fully diluted valuation, market capitalization where circulating supply is known, volume by window, transaction counts split into buys and sells, distinct makers, and the current pooled amounts of each token. Dexscreener also stamps the pair with a creation time, which is the moment the pool was created rather than the moment the token contract was deployed. Those two dates can be far apart.
The right side of a Dexscreener pair page carries the live trade feed. Each row is a decoded swap: time, type, price, amounts, and the maker address. The feed is the highest-resolution data on the page and it answers questions the aggregates cannot. Is this volume made of many small trades or two large ones? Are buys arriving from many distinct wallets or from the same address cycling? Is every green candle immediately followed by a sell from the same maker?
There is also an information panel with the token's website and social links, a description when one has been submitted, and on some chains a security readout covering things like mint authority, freeze authority, and whether pool tokens have been burned. Dexscreener surfaces these fields because they are useful, not because it has audited them, and the depth of the readout varies by network.
Finally, the page lists other pools for the same token. This is the part most people skip and should not. If the pool you are looking at holds a small fraction of the token's total depth, the pool with the real liquidity is the one setting the price that arbitrage will drag yours back toward.
04 / Metric reference
The table below defines each headline field and names the way it most often gets misread. Keeping these definitions straight removes most of the friction of using Dexscreener at speed.
| Field | What it measures | Common misread |
|---|---|---|
| Price USD | Last trade price in this pool, converted through the quote asset. | Taken as a market-wide price rather than one pool's price. |
| Price (quote) | The raw reserve ratio, in WETH, SOL, USDC and similar. | Ignored, so quote-asset moves get read as token moves. |
| Liquidity | Value of both reserves currently held by the pool. | Assumed to be tradeable depth at the current price. |
| FDV | Price multiplied by total token supply. | Confused with money actually invested in the token. |
| Market cap | Price multiplied by circulating supply, where that is known. | Expected to differ from FDV even when no supply data exists. |
| Volume 5m / 1h / 6h / 24h | Sum of swap value in the pool over a rolling window. | Treated as organic demand rather than raw throughput. |
| Txns, buys / sells | Count of swaps and their direction against the base token. | A high buy count is read as pressure, ignoring trade size. |
| Makers | Distinct addresses that traded in the window. | Read as distinct people; fresh wallets are cheap. |
| Change chips | Percentage move over each window. | Baseline may be a single thin trade, not a real level. |
| Pooled amounts | Current reserve balance of each side of the pool. | Not watched, so liquidity withdrawal goes unnoticed. |
| Pair created | Timestamp of the pool creation event. | Mistaken for the age of the token contract. |
| Socials and site | Metadata attached to the token entry. | Presence is read as verification of the project. |
If you internalize one row, make it liquidity. Almost every other figure on Dexscreener is conditioned on it: volume relative to liquidity tells you turnover, price change relative to liquidity tells you whether the move cost real money, and your own realistic position size is a fraction of it.
05 / Charts and candles
Charts on Dexscreener are built from the pool's own swap history, aggregated into whatever interval you select, from very short intervals for fresh launches up to daily and weekly bars for established pairs. Drawing tools and standard indicators are available, and the chart can usually be switched between the dollar series, the quote-denominated series, and a valuation series so you can look at market cap instead of unit price.
The valuation toggle matters more on-chain than off. Two tokens at very different unit prices can sit at the same valuation, and traders comparing charts by candle shape often forget that supply differs by orders of magnitude. Charting valuation on Dexscreener puts them on a comparable axis.
Why DEX candles look strange
A candle on a centralized exchange summarizes thousands of matched orders. A candle in a thin pool can summarize one transaction. That produces the long solitary wicks that make Dexscreener charts look violent: a single large buy pushes the pool price far up the curve, then the next trade or an arbitrage bot pulls it back within the same minute. The wick is real, but it represents one participant, not a market consensus.
Sandwich activity leaves similar marks. A bot buys ahead of a pending swap and sells straight after it, so the chart records a spike and a recovery separated by a single block. In the Dexscreener trade feed those three swaps sit next to each other and the pattern is obvious, which is one more reason to keep the feed open while reading the chart.
Chart history is also pool history. When a project moves liquidity to a new pool, launches on a second exchange, or migrates from a launchpad curve to a standard pool, a new chart starts and the old one stops. Dexscreener is not deleting the past; the past belonged to a different contract. Use the token-level view and the other-pools list to reconstruct the full story.
Multichart layouts help here. Dexscreener can display several pair charts in a grid on one screen, which is the practical way to watch a token across two chains, or to keep a basket of candidates in view without cycling tabs.
06 / Screener and filters
The screener is the table where Dexscreener earns its name. Every indexed pair is a row, every headline metric is a sortable column, and the filter panel narrows the set by chain, exchange, liquidity, volume, transaction count, valuation, pair age, and price change over a chosen window. Sorting alone is rarely enough, because the top of any single-metric sort is dominated by whatever is easiest to inflate on that metric.
The useful pattern is to filter first and sort second. Set a liquidity floor that matches the size you actually trade, add a minimum transaction count so you exclude pools that moved on two trades, bound the age range to the kind of opportunity you are hunting, then sort by whatever you were going to sort by anyway. The result set on Dexscreener shrinks by orders of magnitude and gets far more honest.
Filter combinations worth saving
- Established but active: liquidity above a level you can exit into, age over a month, 24h volume between one and three times liquidity.
- Fresh with substance: age under a day, a liquidity floor, and a minimum maker count, which filters out most single-wallet theater.
- Turnover outliers: volume many multiples of liquidity, which surfaces both genuine frenzies and obvious wash trading, then read the feed to tell them apart.
- One chain, one exchange: narrow to a single venue when you are learning how a specific ecosystem behaves on Dexscreener.
Alongside the general table, Dexscreener maintains standing views: newly created pairs, gainers and losers, and trending. The new pairs feed is a live stream of pool creation, which means it is also a live stream of everything anyone deploys, good and bad, in equal measure. Nothing filters it for you.
Search behaves the way you would want in a terminal: paste a contract address and Dexscreener takes you to the pools for that exact token, or type a ticker and get a ranked list of candidates. For anything you intend to trade, the address is the only search input that cannot be spoofed.
07 / Trending, profiles and boosts
Trending on Dexscreener is a ranking built from activity and attention signals rather than a simple volume sort. That makes it responsive: something with real traction climbs quickly. It also makes it a target, since visibility on a widely used terminal has commercial value.
Dexscreener is unusually direct about this. It sells promotion products openly instead of pretending rankings are untouched. Token teams can pay for an enhanced token profile, which attaches a logo, description, and verified social links to their entry, and they can buy boosts, which temporarily lift a token's standing in the trending system and mark it with a badge. Larger boost packages come with more prominent treatment.
Understood correctly, the promotion layer is information in its own right. A token that has bought boosts within minutes of its pool being created is telling you something about its marketing budget and its timeline. Reading Dexscreener well means noticing both the metric and the fact that someone paid for you to see it.
An enhanced profile does carry one genuine, narrow benefit. Because it must be submitted by whoever controls the token, verified social and website links reduce the risk of following an impostor account, and Dexscreener displays them consistently. That is identity confirmation of the listing, not an endorsement of the project.
Dexscreener has also extended beyond pure analytics with Moonshot, a consumer mobile trading app in the same family, which sits alongside the terminal rather than replacing it. The charting and screening product remains the thing most people mean when they say they use Dexscreener.
Trending answers the question of what people are looking at right now. It does not answer whether they should be. Treat every list on Dexscreener as a queue of things to investigate, never as a queue of things to buy.
08 / Liquidity and price impact
The single most useful calculation to keep in your head while reading Dexscreener is how much a trade of your size will move the price in the pool you are looking at. For a classic constant-product pool, that follows directly from the reserves, and the arithmetic is simple enough to model exactly.
In a fee-free two-sided pool, if you spend an amount equal to a fraction of the quote reserve, your average execution price sits above spot by roughly that same fraction, and the pool's spot price ends up higher by about that fraction applied twice. Since the liquidity figure on Dexscreener counts both sides, a buy worth a given percentage of displayed liquidity consumes roughly twice that percentage of the quote reserve. The table below applies that model.
Modeled impact of a buy, by trade size vs displayed liquidity
-
0.5% of liquidityavg fill +1.0% / spot +2.0%
-
1% of liquidityavg fill +2.0% / spot +4.0%
-
2.5% of liquidityavg fill +5.0% / spot +10.3%
-
5% of liquidityavg fill +10.0% / spot +21.0%
-
10% of liquidityavg fill +20.0% / spot +44.0%
-
25% of liquidityavg fill +50.0% / spot +125%
Model, not market data. Derived from the constant-product formula for a balanced two-sided pool, excluding swap fees, gas, and token transfer taxes. Concentrated-liquidity pools and launchpad curves follow different curves, so use this as a floor for expected impact rather than a precise quote.
Two conclusions fall out of the model. First, exits are subject to the same curve as entries, so a position that was cheap to build in a thin pool is expensive to unwind. Second, the eye-catching percentage moves you see in the Dexscreener gainers list are often the arithmetic signature of small pools rather than evidence of demand.
Do the division before the trade, not after. Divide your intended size by the liquidity number on the Dexscreener pair page, double it, and you have a workable estimate of the slippage you are volunteering for.
09 / Watchlists, multicharts and alerts
Monitoring tools are what turn Dexscreener from a lookup tool into a workspace. A watchlist keeps chosen pairs in one table so you are tracking specific pools instead of re-searching them, and because the watchlist is pair-based, you can hold two pools of the same token side by side and watch the spread between them.
Multicharts serve the visual half of the same job. A grid of charts on one screen suits a handful of correlated pairs, a token trading on several chains, or a narrative basket you want to see move together. It is a much lower-effort way to keep context than a wall of browser tabs.
Alerts let you leave the screen. Attach a condition to a pair and Dexscreener notifies you when it triggers, which is particularly valuable on-chain because the interesting events happen at inconvenient hours. Since alert conditions and delivery options are extended over time, check the current alert menu in the app rather than assuming a fixed feature set.
A practical note on alert design: set them on levels that matter mechanically, not on round numbers. A liquidity threshold catches providers leaving. A valuation level catches a genuine re-rating. A price alert three percent away in a thin pool will fire on noise and train you to ignore Dexscreener notifications entirely.
10 / API and integrations
Dexscreener publishes a public read-only REST API that returns the same pair objects the interface uses. It requires no key for basic access, responds with JSON, and is rate limited per endpoint. That combination is why so many bots, dashboards, Telegram tools, and internal spreadsheets are quietly built on top of Dexscreener.
| Endpoint shape | Returns |
|---|---|
| /latest/dex/search?q= | Pairs matching a free-text query, ticker, name, or address. |
| /latest/dex/tokens/{addresses} | All indexed pools for one or more token addresses, batched. |
| /latest/dex/pairs/{chainId}/{pairId} | One specific pool, addressed by chain slug and pool address. |
| /token-profiles/latest/v1 | Recently published token profiles with their metadata. |
| /token-boosts/latest/v1 | Recent boost activity, useful as a paid-attention feed. |
Paths, response fields, and limits are versioned and can change, so treat the table as orientation and confirm the current contract in the official Dexscreener API documentation before you ship anything. Published limits differ by endpoint, with the market-data lookups allowing a considerably higher request rate than the profile and boost feeds.
One important gap to design around: the public Dexscreener API is oriented toward current state, not deep history. There is no general endpoint that hands you years of candles for arbitrary pairs. If your project needs historical series, poll and store snapshots yourself, or pull history from an indexer or archive node and use Dexscreener for the live layer.
Sensible integration hygiene applies. Batch token lookups instead of firing one request per address, cache aggressively since sub-second freshness rarely changes a decision, back off on errors rather than retrying in a tight loop, and always key your records on chain plus address rather than on the ticker. Bots that ignore rate limits get throttled, and bots keyed on tickers eventually resolve the wrong token.
For teams building their own front ends, Dexscreener also offers embeddable chart views, which is a fast way to give a token page or a portfolio tool a live chart without maintaining a charting stack.
11 / Chain and exchange coverage
Coverage is one of the main reasons Dexscreener became a default. It spans the major EVM networks, including Ethereum, BNB Chain, Polygon, Arbitrum, Optimism, Base, and Avalanche, alongside non-EVM ecosystems such as Solana, and reaches well into newer and smaller networks. Because pools are discovered from factory events, each supported exchange brings its whole long tail with it.
Chains appear in Dexscreener URLs and API responses as short slugs, and those slugs are not always the marketing name of the network. Storing the slug your integration receives, rather than a name you typed, avoids a whole class of mismatched-lookup bugs.
Coverage breadth does have a consequence for reading. The same token bridged to several chains produces separate pools with separate prices, and those prices drift with bridge friction and local depth. Dexscreener shows every one of them, so the pool you happen to open may not be the venue where the token actually trades. Background on the exchange model itself is well summarized in the Wikipedia entry on decentralized exchanges.
12 / Limits, red flags and safe reading
Dexscreener is a mirror of on-chain activity, and on-chain activity includes deliberate deception. The platform's job is to report the pool faithfully; it is not a security auditor, a legal filter, or a quality screen. Every limitation below follows from that division of labor.
Volume can be manufactured
Nothing stops an operator from trading with themselves across many wallets. The swaps are genuine transactions, so they are counted, and volume, transaction counts, and maker counts all rise together. Dexscreener gives you the tools to notice: open the trade feed and look for uniform sizes, metronomic timing, buys and sells alternating from a small set of addresses, and volume that dwarfs liquidity with no price discovery to show for it.
Liquidity can leave
Liquidity is a current balance, not a commitment. Unless pool tokens are burned or locked, whoever provided the liquidity can withdraw it, which collapses the depth and the price at once. Dexscreener surfaces pooled amounts and, on some chains, whether pool tokens have been burned, so check those fields rather than assuming the number you saw an hour ago still holds.
Contracts can restrict selling
Some tokens carry transfer taxes, blacklists, or logic that permits buying while blocking selling. The market data can look perfectly healthy in that situation, because the buys are real. Dexscreener may display a security readout where the chain supports it, but it is a partial view: before committing size, verify the contract yourself with a dedicated scanner and a small test exit.
Tickers are not identifiers
Anyone can deploy a token with any name and symbol, which makes ticker-based searching genuinely dangerous during hyped launches. A search on Dexscreener will show you clusters of identically named tokens, and the one with the largest liquidity is not automatically the real one. Get the contract address from a source you trust, paste it into Dexscreener, and only then look at the chart.
Valuation fields flatter
Fully diluted valuation multiplies the last pool price by the entire supply, so a token with a tiny pool can display a large valuation. When circulating supply is unknown, market cap and FDV converge and the display stops distinguishing them. Read both numbers on Dexscreener next to liquidity, and the gap between headline valuation and actual invested capital usually becomes obvious.
Finally, a category of tokens simply breaks the assumptions. Rebasing supplies, fee-on-transfer mechanics, and unusual pool designs distort reserve-derived math, so figures on Dexscreener for those tokens should be treated as approximations. When the arithmetic on a page refuses to reconcile, the token design is a more likely explanation than a data error.
13 / What is free and what is paid
For a reader, Dexscreener is free. Charts, the screener, filters, the trade feed, watchlists, multicharts, the mobile app, and basic API access all cost nothing, which is a large part of why it spread so quickly. Revenue comes from the token side of the marketplace: teams paying for visibility and presentation.
| Item | Who pays | What it changes |
|---|---|---|
| Charts, screener, feed | Nobody | Full read access for any visitor. |
| Public API | Nobody, within limits | Programmatic access, rate limited per endpoint. |
| Token profile | Token team | Adds logo, description, and verified links to the listing. |
| Boosts | Token team or supporters | Temporary lift in trending standing plus a badge. |
| Advertising | Advertiser | Placement in ad slots, labeled as such. |
Prices for the paid products are set in crypto and revised over time, so exact figures are not quoted here. Check the current rates inside Dexscreener before budgeting, and expect them to differ by chain and by package size.
The trade-off is worth stating plainly. Free access for readers, paid visibility for issuers, and the paid layer marked so you can discount it. Dexscreener is more transparent about that arrangement than most platforms, but the burden of skepticism still sits with you.
14 / Compared with the alternatives
Dexscreener sits in a specific niche, and the honest comparison is against categories of tool rather than against one rival. Token-first aggregators, other DEX terminals, and raw on-chain queries each answer a different question.
| Dimension | Dexscreener | Token-first aggregators | Direct on-chain queries |
|---|---|---|---|
| Unit of analysis | The individual pool | The asset, blended across venues | Whatever you write the query for |
| New pool latency | Automatic, effectively immediate | Depends on a listing process | As fast as your indexer |
| Long-tail coverage | Very broad by design | Curated, so thinner | Total, chain by chain |
| Deep history | Limited via the public API | Often a strength | Complete, at engineering cost |
| Effort to use | Open a page and read | Low | High, needs infrastructure |
| Best for | Live pool-level trading and monitoring | Portfolio and research on established assets | Custom analytics and backtests |
Peer terminals such as DEXTools, GeckoTerminal, and Birdeye overlap heavily with Dexscreener in purpose, and each has its own emphasis in chain focus, ranking logic, and extra tooling. Comparing them on your own chain, with a token you already understand, will tell you more than any feature grid.
In practice most people run a combination. Dexscreener for what is happening in a pool right now, an aggregator for supply and long-run context, and a contract scanner before any transaction. Where Dexscreener is hardest to replace is the moment between a pool being created and anyone else having written about it.
15 / How to get started
A first session on Dexscreener goes better if you look up something you already know than if you go hunting. The sequence below builds the habits in the right order.
-
STEP 01
Look up a token you understand by pasting its contract address into Dexscreener search. Note how many pools exist and which one holds most of the liquidity.
-
STEP 02
Read the metric block top to bottom and check it against the reference table above, so liquidity, valuation, volume, and makers stop blurring together.
-
STEP 03
Watch the trade feed for a few minutes and try to explain each candle from the swaps that produced it. This is the fastest way to learn how Dexscreener charts are actually formed.
-
STEP 04
Build one filter set in the screener with a liquidity floor and a transaction minimum, and keep it as your default view instead of browsing unfiltered lists.
-
STEP 05
Add three or four pairs to a watchlist, set one alert that matters, and install the Dexscreener mobile app so the same views follow you off the desk.
After a week of that routine, Dexscreener stops looking like a wall of numbers and starts reading like a market you can question.
16 / Glossary
Terms used across Dexscreener and throughout this guide.
- Pair
- One liquidity pool holding two tokens. The unit Dexscreener organizes everything around.
- Base / quote
- The token being priced, and the token it is priced in.
- AMM
- Automated market maker. A formula-driven pool that replaces an order book.
- LP token
- A claim on pool reserves. Burning or locking it prevents withdrawal.
- Price impact
- How far your own trade moves the pool price along the curve.
- Maker
- A distinct address that traded the pair in the selected window.
- Honeypot
- A contract that allows buying but restricts selling.
- Boost
- A paid, temporary visibility lift within the Dexscreener trending system.
- Chain slug
- The short network identifier used in URLs and API responses.
- Migration
- Moving liquidity to a new pool, which starts a new chart.
17 / Frequently asked questions
Is Dexscreener free to use?
Yes. Browsing charts, the screener, the trade feed, watchlists, and basic API access cost nothing. Dexscreener charges token teams and advertisers for visibility products, not readers for data.
Why does the same token show different prices?
Because each pool is its own market. Dexscreener prices each pool from its own reserves, so pools on different exchanges or chains can diverge until arbitrage closes the gap. The deepest pool is normally the reference.
Why do market cap and FDV look identical?
When reliable circulating supply data is not available, there is nothing to distinguish the two, so both are computed from total supply. Read valuation against liquidity on Dexscreener rather than treating either figure as invested capital.
Does appearing on Dexscreener mean a token is legitimate?
No. Listing is automatic once a pool trades. Dexscreener indexes pools, it does not vet projects, and a paid profile or a boost badge is purchased placement rather than approval.
How quickly does a new pair appear?
Usually within seconds of the first trade, since discovery is driven by on-chain factory events. Very fresh pairs on Dexscreener may briefly show incomplete metadata while supply and decimals are read from the contract.
Can I get historical candles from the API?
Not in bulk. The public Dexscreener API is built around current pair state, so long time series need to be collected by polling and storing snapshots yourself, or sourced from an indexer or archive node.
What do boost badges actually do?
They add temporary weight in the trending ranking and mark the listing, and larger packages get more prominent treatment. Read them as evidence that someone is spending on promotion, and keep judging the pool on liquidity and trade flow.
Huge volume with tiny liquidity, what is going on?
Often self-trading, sometimes a genuine frenzy in a small pool. The Dexscreener trade feed decides it: repeated sizes from few addresses at regular intervals point to wash activity, while varied sizes from many new addresses point to real interest.