Dexscreener alerts are pair-level DEX price triggers

The wrong pool can make a correct threshold useless

Pair identity is the most important failure point in a price-alert setup. A ticker identifies a label, while the chain, decentralized exchange, token contracts, quote asset, and pair address identify the market whose price the trigger actually follows.

Every pair contains two assets: a base token and a quote token. An Ethereum address occupies 20 bytes and is normally displayed as 40 hexadecimal characters after the 0x prefix, while a Solana pool or mint is identified by a 32-byte public key encoded in Base58. Check those identifiers before saving the condition. A USDC pool on Uniswap differs from a WETH pool for the same token, and both differ from markets carrying the same symbol on PancakeSwap or Raydium. Their liquidity, trades, and quoted prices remain independent.

Pair triggers, token-wide trackers, and API monitors

A pair-level trigger answers a narrower question than a token-wide price alert: did this specific liquidity pool cross the selected boundary? CoinGecko and CoinMarketCap publish aggregated token prices, whereas Dexscreener alerts preserve the chain, exchange, pool, and quote asset attached to the chart. The companion material covers Dexscreener explained.

A custom monitor offers more programmable conditions but also needs polling, deduplication, state storage, and a notification channel. The Dexscreener API exposes separate priceNative and priceUsd fields; its pair-oriented endpoints allow 300 requests per minute, and the multi-token endpoint accepts up to 30 token addresses per call. The native app removes that engineering work and supplies fixed pair-price notifications, while a custom process remains appropriate for combined liquidity, volume, or multi-pool rules.

What exactly counts as a threshold crossing?

A threshold crossing occurs when the observed pair price moves from one side of a saved numerical boundary to the other. The two basic directions are above and below, and each condition contains one direction with one target value.

The absolute boundary is separate from the chart's retrospective change windows. The 5-minute, 1-hour, 6-hour, and 24-hour percentages describe movement during defined lookback periods; they do not turn an absolute target into a percentage-change rule. A notification also does not prove that the price remained beyond the line. An automated market maker can move through a level and reverse before the recipient opens the chart, particularly when the pool has limited depth.

USD and quote-asset prices create different conditions

The price unit is part of the alert condition, not a cosmetic display choice. A WETH/USDC pair expresses the native ratio as USDC per WETH, while a token/SOL pair expresses it as SOL per token; the USD field adds a separate conversion into dollars.

Token precision explains why apparently similar targets can contain very different numbers. USDC uses 6 decimal places on Ethereum and Solana, WETH uses 18 on Ethereum, and SOL uses 9, with 1 SOL equal to 1,000,000,000 lamports. Those constants define atomic units rather than alert accuracy. Before saving a target, match its unit to the selected price field and preserve every leading zero. Changing from a SOL quote to a USDC quote requires a newly calculated boundary.

How the pair update becomes a phone notification

Notification delivery has three distinct stages: blockchain data reaches the market indexer, the alert service evaluates the saved condition, and iOS or Android presents the push message. A delay at any stage separates the pool's crossing time from the moment the phone displays the notice.

Dexscreener constructs charts and analytics from a custom indexer that parses raw blockchain logs rather than an external market-price API. For Dexscreener alerts to reach a phone, operating-system notification permission must remain enabled, the device must have network access, and battery or focus settings must permit delivery. The service publishes no fixed delivery-time guarantee, so the notification should be treated as an observation rather than an execution timestamp.

Build upper and lower boundaries as two alerts

A two-boundary plan requires two saved conditions because an upward crossing and a downward crossing evaluate opposite inequalities. Neither condition is a limit order, stop order, or instruction to exchange tokens.

1. Open the exact pair page rather than selecting a result by ticker alone.
2. Confirm the chain, exchange, pair address, base token, and quote token.
3. Choose the upper direction and enter the first absolute threshold.
4. Create a second alert with the lower direction and its own threshold.
5. Enable app notifications and review both saved conditions for the intended units.

No wallet approval, blockchain transaction, or network fee occurs when either boundary fires. Trading still happens separately through venues and routers such as Uniswap, Jupiter, or 1inch, where the available route, pool liquidity, price impact, and transaction costs determine the executable result.

A worked two-threshold example with hypothetical inputs

A hypothetical worked example shows how two percentages become two absolute alerts. Every changing input here is hypothetical: the monitored market is an unnamed token/USDC pair, its starting USD price is $0.80, the desired upward distance is 20%, and the desired downward distance is 12.5%.

The upper boundary is $0.80 × 1.20, which equals $0.96. The lower boundary is $0.80 × 0.875, which equals $0.70. The concrete setup therefore contains two alerts: one above $0.96 and one below $0.70. These remain absolute targets after creation; they do not move with the starting price. If the market reaches a boundary, the app reports the event, while any later trade uses the price and liquidity available when that trade is submitted.

Decimal precision matters most at tiny prices

Token decimal precision controls how raw integer balances become human-readable amounts, but the alert compares a normalized market price. The ERC-20 decimals field uses an 8-bit unsigned integer, and a Solana Token Program mint also stores decimals as an 8-bit value; that format represents integers from 0 through 255.

A token's configured decimals do not imply that every displayed price digit carries equal market significance. With 18-decimal assets, an interface can represent values far below one whole token, yet a shallow pool may move several visible places after one swap. Copy the full threshold from the intended USD or quote-asset view, check the count of leading zeros, and avoid deriving the target from a rounded watchlist label.

Thin liquidity turns one swap into a noisy signal

Liquidity depth determines how much trading is required to move a pool through an alert boundary. In an automated market maker, a swap changes the pool reserves and therefore its quoted price; the alert reflects that pool observation rather than an executable quote for every possible order size.

Uniswap v2 uses the constant-product relationship x × y = k and applies a standard 0.30% swap fee. Uniswap v3 supports four standard fee tiers - 0.01%, 0.05%, 0.30%, and 1.00% - which allow the same token combination to exist in separate pools with different economics and liquidity. Raydium and PancakeSwap likewise expose pool-specific markets. A modest swap can cross a target in a thin pool while deeper venues remain elsewhere, so inspect current liquidity and recent transactions after the notification arrives.

Why alert design follows the AMM pool model

Pair-level alerting follows the structure of decentralized exchanges, where price formation occurs inside individual liquidity pools rather than in one universal order book. Uniswap, PancakeSwap, and Raydium can each host independent markets for related assets, and concentrated-liquidity designs divide capital across chosen price ranges.

Day to day, Dexscreener automatically lists a token after it enters a detected liquidity pool and records at least 1 transaction. That indexing rule explains why a new market can become monitorable without first receiving an aggregated listing from CoinGecko or CoinMarketCap. It also explains the narrow scope of the alert: the first indexed pool does not become a permanent token-wide reference, and later pools continue producing their own prices.

Retire stale triggers when the market moves elsewhere

Alert lifecycle management keeps saved conditions attached to active, decision-relevant pools. Dexscreener alerts stay useful while the selected pair retains meaningful trading activity, the quote asset matches the intended unit, and the original threshold still represents the event being monitored.

The mobile app describes its price alerts as unlimited, yet an old condition can remain technically valid after liquidity and trading concentrate in another pool. Review triggered and untriggered entries, remove targets tied to inactive markets, and create fresh conditions for replacement pair addresses. A short record of the chain, pair address, direction, unit, and threshold makes similarly named markets easier to distinguish when several app notifications arrive close together.