Dexscreener alerts are pair-specific: price triggers depend on the selected pair
Dexscreener alerts are pair-specific price notifications that fire when the displayed price for one selected liquidity pool crosses a chosen level. They do not combine every market carrying the same token symbol. The chain, decentralized exchange, pair address, base asset, and quote asset determine the monitored price stream, so choosing a thin or inactive pool produces a signal that differs sharply from the token's busiest market.
Updated
Monitoring SOL against USDC on the intended Raydium pool
A SOL/USDC price alert on Raydium must point to the exact pool whose chart informs the intended decision. Raydium CPMM and CLMM pools are separate on-chain accounts, and an Orca Whirlpool for the same assets is separate again. Each pool contains exactly 2 asset mints and produces its own price from its reserves, active liquidity, and recent swaps.
Consider a token that trades against SOL in a busy Raydium pool and in a lightly used secondary pool. A threshold attached to the secondary pair follows that pool even when most trading moves through the first one. Arbitrage aligns accessible markets over time, yet fees, depth, and limited activity leave temporary differences. Dexscreener alerts are most useful here when the selected pool matches the venue and quote asset being monitored.
Lock the pool identity before saving the trigger
The pool identity is the decisive setup detail for a pair-specific alert. Before saving a threshold, record the chain, decentralized exchange, pair address, base asset, and quote asset. An EVM address contains 20 bytes and appears as 40 hexadecimal characters plus the 2-character 0x prefix, making 42 characters in total. Solana account addresses are 32-byte values represented in base58.
Search by the full pair address when a token has several pools or shares its ticker with unrelated assets. Etherscan identifies contracts on Ethereum and Base, while Solscan exposes Solana pool accounts and token mints. The token contract or mint identifies the asset; the pair or pool address identifies the monitored price stream. A matching name, icon, or ticker does not establish either identity.
When saving Dexscreener alerts, compare both token addresses shown on the pair page with the intended ERC-20 contracts or SPL Token mints. Then confirm that the displayed exchange is Uniswap, Raydium, Orca, or the other intended venue. This short identity pass prevents a numerically valid threshold from being attached to the wrong market.
Read the quote unit before typing the threshold
The quote unit determines what the alert's number means. Dexscreener exposes 2 distinct price representations in its pair data: priceNative expresses the base asset through the pair's quote asset, while priceUsd supplies a USD value when available. In a token/SOL pool, the native figure represents SOL per token; it is not interchangeable with the threshold for a token/USDC pool.
Precision follows the assets as well. USDC uses 6 decimal places on Ethereum and Base, whereas WETH uses 18, although the alert field works with a human-readable price rather than the raw ERC-20 integer. For a value with many leading zeros, expand the displayed decimal and preserve enough significant digits to distinguish the intended crossing from ordinary rounding.
The visible 5-minute, 1-hour, 6-hour, and 24-hour panels form 4 separate summary windows for activity and price change. Those windows do not redefine an absolute threshold. In Dexscreener alerts, "above" and "below" are directional price conditions, so the saved direction, unit, and expanded decimal should agree before the notification is enabled.
Same assets, separate price streams
Separate liquidity pools remain independent price sources even when they contain the same 2 assets. Uniswap V3 defines 4 standard fee tiers - 0.01%, 0.05%, 0.30%, and 1.00% - so identical ERC-20 assets may have several separately addressed pools. Uniswap V2 uses a distinct pair contract, while Solana protocols distinguish pools through their program-owned account addresses.
| Venue and pool form | Distinguishing identity | Prerequisite already established |
|---|---|---|
| Uniswap V2 | EVM pair contract for two ERC-20 tokens | Chain and both token contracts |
| Uniswap V3 | EVM pool contract plus fee tier | Chain, token contracts, and fee tier |
| Raydium CPMM or CLMM | Solana pool account and program type | Two mint addresses and pool account |
| Orca Whirlpool | Solana Whirlpool account and tick spacing | Two mint addresses and Whirlpool account |
Uniswap V2, Uniswap V3, Raydium, and Orca therefore provide concrete examples of why a token-level assumption fails. Liquidity depth, fee rules, concentrated ranges, and order flow differ by pool. A Dexscreener alert remains bound to the chosen pair rather than switching automatically to whichever pool later attracts the most liquidity or volume.
Thin liquidity and notification timing
A thin liquidity pool makes a threshold sensitive to a single swap because the trade changes the pool's quoted balance or active price tick. One modest transaction relative to available depth may cross the selected level and then be offset by later trading. The crossing is a genuine observation for that pool, although deeper pools carrying the same token may never print the same price.
The delivery path for Dexscreener alerts has 4 stages: an on-chain swap, block acceptance, Dexscreener indexer processing, and device or browser notification. Dexscreener builds its market data from blockchain logs, while the final banner also relies on network access and notification permissions. This sequence has no fixed zero-latency guarantee, particularly when the chain, indexer, or device is busy.
Creating or firing a price alert submits 0 blockchain transactions, spends 0 gas, and grants 0 token approvals. It also reserves no liquidity. The message reports that an observed pair price crossed a level; it does not promise that a later swap will execute at that figure. An active condition and a delivered push banner are separate outcomes when operating-system notifications are disabled.
Maintain alerts through pool migrations and API checks
An alert associated with an old pool address remains tied to that old market after activity shifts elsewhere. When liquidity moves from a Raydium CPMM pool to a CLMM pool, or from a Uniswap V2 pair to a Uniswap V3 pool, create the replacement threshold on the new address and retire the stale condition. Reconsider the number as well if the quote changes from USDC to SOL or WETH.
Programmatic verification adds another identity check for a larger alert set. Dexscreener's pair and token lookup endpoints allow 300 requests per minute, and the multi-token lookup accepts up to 30 comma-separated token addresses. Responses expose fields including chainId, dexId, pairAddress, baseToken, quoteToken, priceNative, and priceUsd. These read endpoints validate pair mapping; they are not a documented alert-creation interface.
Dexscreener alerts stay meaningful when each saved condition retains its full context: chain, venue, pool address, quote unit, direction, and threshold. Review that context whenever a project changes its main liquidity venue or a new pool becomes dominant. A price number by itself carries none of the identity needed to determine which on-chain market crossed it.
Frequently asked questions about Dexscreener alerts
Can I keep several active thresholds for the same selected pair?
Yes, several thresholds can be retained for the same selected pair. Dexscreener describes its mobile product as offering unlimited price alerts, while each alert still records its own pool, direction, and target. Separate upper and lower levels are clearer than trying to encode a range in one condition. Identify the pair by chain and address when many alerts share the same ticker.
Does adding a pair to a watchlist create an alert automatically?
No, a watchlist entry and a price alert are separate controls. The watchlist preserves a pair for quick viewing, whereas the alert stores a threshold condition and notification behavior. A pair appearing in a watchlist therefore does not prove that an active threshold exists. Open the Alerts view and confirm the chosen chain, pair, direction, and numeric level.
Will reaching a price threshold execute a swap?
No, crossing the threshold only produces a notification. It does not sign a transaction, route through Uniswap or Raydium, reserve liquidity, or protect an execution price. By the time a user opens a trading interface, the selected pool price and available depth may have moved. Treat the message as a prompt to inspect the pool rather than as an order confirmation.
Which chains can supply pair-specific price alerts?
Price alerts work from indexed pair pages on supported chains, including examples such as Ethereum, Base, and Solana. Compatibility is tied to the exact pair page rather than to an ERC-20 or SPL Token standard in isolation. If the Alerts control is absent for a particular market, the token's presence elsewhere does not create coverage for that pool.
Are market-cap or volume conditions part of the same price-alert control?
No, the built-in alert described by Dexscreener is a price alert, while volume, liquidity, transactions, price change, and market cap belong to screener and chart metrics. Seeing those fields near the alert button does not turn them into conditions. For a non-price monitor, use an explicitly documented metric rule or a separate read-only process instead of assuming the price control watches every panel.
How should I enter a threshold for a token with many leading zeros?
Enter the full human-readable decimal in the unit shown by the selected pair, not a shortened ticker-card rendering or an ERC-20 raw integer. Leading-zero tokens make rounding consequential, so expand the displayed value and retain enough significant digits to distinguish the intended crossing. Confirm whether the field represents USD or the quote asset before saving, because identical digits describe different levels in SOL and USDC.
What happens if phone notifications are disabled?
The alert can remain configured while the operating system suppresses its notification. Device permission, browser push permission, background restrictions, and network availability govern whether a banner appears after Dexscreener processes the crossing. Re-enable notifications, confirm that the app or browser is permitted to run in the background, and test with a non-urgent level. The Alerts view remains the place to inspect configuration status.