Crypto guides
Dexscreener alerts are pair-level price controls for precise thresholds
Dexscreener alerts are pair-specific notifications that compare one selected pool's displayed price with a user-set level. Choose the correct chain, decentralized exchange, base asset, quote asset, and pair address, then set a trigger above or below the present price. When the indexed pair price crosses that boundary, the notification tells you to inspect the pool; it does not place a swap, close a position, or watch every market sharing the same ticker.
They are pair-specific price notifications that fire above or below a set threshold, helping traders confirm the pool and retire stale triggers.
A quieter workflow for traders following one pool
Pair-level price monitoring reduces constant chart watching without merging separate markets. A Dexscreener alert tracks the selected liquidity pool and its displayed price. That precision matters when one token trades against several quote assets or appears on multiple exchanges. The notification returns attention to a known pair at a chosen boundary. It does not ask the trader to rescan every pool carrying the token symbol.
Pool specificity separates markets that only look identical in search results. An ERC-20 token paired with USDC on Uniswap has a different price source from the same token paired with WETH on Aerodrome. Solana markets on Raydium and Orca also maintain distinct liquidity and swap histories. One pool may cross the level while another remains below it. The selected pair address decides which market the alert observes.
Select the pool before entering a threshold
Pair selection is the first operational control in an alert workflow. A trading pair always contains 2 assets: a base token and a quote token. DEX Screener automatically surfaces a token after it enters a liquidity pool and that pool records at least 1 transaction. Search results may therefore contain several valid markets for the same asset, including inactive or thinly traded pools.
- Search by token contract or mint address rather than relying on a ticker.
- Open the intended chain, such as Ethereum, Base, BNB Chain, or Solana.
- Confirm the exchange and pool, such as Uniswap, Aerodrome, PancakeSwap, Raydium, or Orca.
- Read both base and quote assets before choosing the displayed price unit.
- Copy the pair address into an operating record, then create the boundary.
Liquidity and recent swaps help distinguish the active venue from an abandoned pool. A high-liquidity market and a low-liquidity market may display different prices because each pool processes its own trades. The alert button on the pair page inherits that page's market identity. Returning through a generic ticker search and choosing another pool creates a different monitor.
Contract addresses settle duplicate-ticker ambiguity
Contract and pair addresses provide durable identity for price alerts. Ticker symbols do not carry that guarantee. An EVM address contains 20 bytes and appears as 40 hexadecimal characters after the prefix. EIP-55 defines the mixed-case checksum used by many Ethereum interfaces. Solana public keys represent 32-byte values and are commonly displayed with base-58 encoding.
Chain identity completes the match. Ethereum mainnet uses chain ID 1, BNB Smart Chain uses 56, Polygon PoS uses 137, Base uses 8453, and Arbitrum One uses 42161. DEX Screener presents readable chain names, while wallets and explorers expose these numeric identifiers. Record the token address and pair address separately: the first identifies an asset, while the second identifies the exact pool whose price drives the notification. A related walkthrough covers Using Dexscreener.
Choose the threshold unit deliberately
Price units determine what an alert boundary means. A DEX Screener pair page exposes a USD price and a native quote price when a USD estimate is available. A SOL-denominated threshold follows the token-to-SOL ratio. Its USD equivalent moves whenever SOL moves, even if that native ratio stays unchanged. A USD threshold instead follows the pair's displayed dollar value.
Token precision also affects very small entries. USDC uses 6 decimal places, WETH on Ethereum uses 18, and wrapped SOL uses 9. One SOL contains 1,000,000,000 lamports, while 1 ETH contains 10 18 wei. DEX Screener formats these raw units into readable prices. Preserve every meaningful leading zero when copying a threshold, and write the chosen unit beside it in the operating record.
Build an upper and lower monitoring band
A two-boundary plan identifies both upward and downward departures from a reference price. The worked example below labels every changing value as hypothetical. It demonstrates the arithmetic only; none of its values represents a live token or market.
Hypothetical changing inputs: the market is a sample ERC-20/USDC pool on Base through Aerodrome; the displayed USD price is $0.0040; the desired upper move is 25%; and the desired lower move is 15%. The pool, price, percentages, and intended response are all hypothetical inputs.
Calculate the hypothetical upper target as $0.0040 × 1.25, which equals $0.0050. Calculate the hypothetical lower target as $0.0040 × 0.85, which equals $0.0034. Create 2 alerts on that exact pair: one above $0.0050 and one below $0.0034. This produces a concrete $0.0016 monitoring band, while each boundary remains independent.
Crossing logic stops at the notification
Alert crossing logic compares the indexed pair price with an upper or lower boundary. The comparator does not require a trade to print at the exact threshold. A swap may move the displayed price from one side to the other in a single update, especially in a shallow pool. The condition is therefore a crossed boundary, not a guaranteed fill at that number.
Creating or firing the alert submits 0 on-chain transactions, consumes 0 gas, and grants 0 token approvals. Execution remains separate. A swap on Uniswap, PancakeSwap, Raydium, or Jupiter requires its own transaction and wallet confirmation. The notification reports an observable market state; it neither reserves liquidity nor controls the price available for a later trade.
Unlimited slots still require an alert register
Alert capacity removes a hard slot-allocation problem, but it does not organize active thresholds. The published mobile-app allowance for price alerts is unlimited. Dexscreener alerts remain easier to operate when every boundary has a purpose, pair address, unit, creation reason, and retirement event. A short register also exposes duplicate rules created from repeated searches.
Group the register by chain and position state, not ticker alone. Separate research boundaries from position-monitoring boundaries. Mark whether each rule watches an upper or lower crossing. If both directions matter, store them as 2 independent records. This structure keeps a large alert set readable and makes stale thresholds visible before they generate irrelevant notifications.
Liquidity determines what a crossed level means
Pool liquidity determines how much trading activity moves the displayed price. A price alert confirms a threshold crossing in one pool; it does not promise equivalent execution depth. Constant-product pools such as Uniswap v2 and PancakeSwap v2 update price as their 2 reserves change. A relatively small swap moves the ratio sharply when those reserves are small.
Concentrated-liquidity designs place another constraint around the current price. Uniswap v3, Orca Whirlpools, Raydium CLMM, and Aerodrome Slipstream distribute liquidity across selected ranges rather than one uniform curve. A threshold may sit near the edge of an active range. After the notification, inspect current liquidity and recent swaps before treating the displayed level as an executable reference.
Verify the pair feed after a notification
Notification verification uses the saved pair identity, recent swaps, and current price unit. The DEX Screener pair page displays rolling windows of 5 minutes, 1 hour, 6 hours, and 24 hours. TradingView Advanced Charts also supports chart intervals from 1 minute through 1 month. Those windows provide context, but the saved alert remains tied to its threshold rather than one candle interval.
Start with the pair address shown in the alert. Then compare its latest swaps, displayed price, liquidity, and quote asset with the saved record. DEX Screener builds its market data from blockchain logs processed by a custom indexer. Notification arrival therefore follows log processing and the device's delivery channel. A chart from another pool, unit, or chain does not verify the original trigger.
API polling supports compound alert rules
The DEX Screener API supplies pair snapshots for operators who need conditions beyond one price boundary. Pair, search, and token-data endpoints carry a published limit of 300 requests per minute. The multi-token endpoint accepts up to 30 comma-separated token addresses in one request. Profile, boost, advertisement, and order endpoints use a separate 60-requests-per-minute limit.
A custom monitor can combine pair price with liquidity, transaction counts, or several pools, then send notifications through a privately operated service. That flexibility introduces code, scheduling, state storage, and duplicate-event handling. The built-in alert remains the lower-maintenance choice for one pair and one boundary. API polling fits rules whose decision depends on several indexed fields at once.
Retire thresholds when the pool context changes
Alert maintenance follows the liquidity pool's lifecycle. A pair-specific threshold becomes stale when attention moves to another pool, the quote asset changes, liquidity disappears, or the monitored position closes. Editing only the target price does not repair a wrong pair address. Create a replacement on the intended market, verify its identity, and remove the old rule.
Review both sides of every monitoring band after a trigger. An upper boundary may no longer matter after the position is reduced, while a lower research boundary may remain useful. Archive the fired time, pair address, unit, threshold, and resulting decision. A maintained set of Dexscreener alerts mirrors the pools still under observation instead of preserving every historical idea indefinitely.
Things people ask about Dexscreener alerts
-
Can a saved alert notify me while the chart is closed?
- Yes, a saved mobile alert is designed to deliver without leaving the chart open. The phone still needs notification permission for DEX Screener, and operating-system focus or battery settings must allow delivery. Browser notifications require equivalent site permission. Test one non-urgent boundary before relying on the channel, then confirm that the notification appears while the app or tab is in the background.
-
Why did a candle wick cross my level without producing a notification?
- A visible wick does not prove that the saved alert matched the same pair, unit, and direction. Confirm the pair address, chain, quote asset, threshold unit, and alert status. The chart may show another pool or a market-cap view, while the rule watches pair price. Device permissions also govern final delivery after DEX Screener processes the underlying blockchain data.
-
Which token standards work with pair price alerts?
- Pair alerts operate on indexed liquidity pools, so the token standard alone does not determine compatibility. ERC-20 markets on Ethereum or Base and SPL Token markets on Solana qualify when DEX Screener indexes the pool and exposes its price. Uniswap, Aerodrome, Raydium, and Orca provide familiar cases. A token without an indexed, transacted pool has no pair-level price for the alert to monitor.
-
Does a price-mode alert follow market-cap changes?
- No, a price-mode alert compares the selected pair price with its saved boundary. Market capitalization and fully diluted valuation are separate calculated fields that combine price with supply data. A supply update may change one of those figures without the pair price crossing its threshold. Use the metric named in the alert control and record it explicitly rather than treating price and valuation as interchangeable.
-
Are saved Dexscreener alert events available through a webhook?
- No public webhook for saved DEX Screener alert events is documented. The public API exposes pair and token data that a separate service can poll, but it does not deliver a user's saved alert history as webhook events. Programmatic delivery therefore requires an external scheduler, stored condition state, crossing detection, deduplication, and a notification provider chosen by the operator.
Published