Dexscreener alerts are pair-level thresholds for active DEX traders

A matching ticker selects the wrong pool and corrupts the threshold

Pair selection is the most common Dexscreener alert mistake. A symbol such as USDC or WETH identifies an asset label, not the liquidity pool whose price drives the notification.

Start from the exact pair page. Confirm the chain, exchange, pair address, base token, and quote token before entering a level. A USDC/WETH pool on Uniswap V2 is a separate market from another USDC/WETH pool, even when both contracts represent the same assets. A Raydium SOL/USDC pool on Solana is different again. Each pool has its own reserves, trades, liquidity, and observed price.

Addresses provide the cleanest identity check. On EVM networks, an address occupies 20 bytes and is normally rendered as 40 hexadecimal characters after the prefix. Ethereum mainnet uses chain ID 1, while Base uses chain ID 8453. Solana account addresses encode 32-byte public keys. Recording these identifiers prevents a familiar ticker from silently directing an alert toward an unintended market.

Choosing an alert instead of an order determines what happens next

Dexscreener alerts, watchlists, on-chain limit orders, and API monitors perform four different jobs. An alert sends a notification. A watchlist organizes selected pairs, while Multicharts keeps several charts visible. An order service attempts execution under separately defined terms.

Uniswap limit orders use UniswapX and third-party fillers to seek a specified exchange rate before expiry. A pair alert holds no tokens, defines no trade amount, and submits no transaction. It therefore carries no gas cost at creation. After a notification, the trader still requests a fresh quote and authorizes any resulting swap.

Custom monitoring adds compound conditions beyond one threshold. The public pair, search, and token endpoints allow 300 requests per minute; profile and boost endpoint groups use 60 requests per minute. One token endpoint accepts up to 30 comma-separated addresses. Those limits support measured polling for rules that combine pair price, liquidity, volume, or transaction counts without confusing the script with the built-in alert service.

Indexed swaps move the pair price and activate the crossing rule

The Dexscreener pair price changes when its indexer processes blockchain records for the selected pool. The alert service evaluates that tracked value, rather than a centralized exchange mark or a broad average covering every venue.

On a Uniswap V2 pool, the constant-product relationship is expressed as x × y = k. A swap changes the two reserves and therefore changes their ratio. A Raydium constant-product pool follows the same reserve-ratio principle through Solana programs. Other automated market maker designs calculate prices differently, yet the alert remains attached to the selected pair record.

That pair record exposes two price representations: priceNative and priceUsd. It also identifies two token sides, base and quote. The interface groups recent activity into four standard windows: 5 minutes, 1 hour, 6 hours, and 24 hours. A threshold crossing follows an indexed price update, not a candle-close confirmation. Delivery time then reflects chain processing, indexer work, and the notification queue. The related steps are listed in Using Dexscreener.

Two directional levels turn a chart range into an operating plan

An upper threshold and a lower threshold create two separate decision boundaries around the current pair price. The Goes over condition belongs above the reference price; Goes under belongs below it. Setting both directions prevents one alert from carrying two incompatible meanings.

Measure each level from the displayed reference price. Percentage distance above the market equals the target divided by the reference price, minus one, then multiplied by 100. For a lower level, the same formula produces a negative percentage. This calculation exposes accidental decimal shifts before the rule is saved, particularly on pairs whose displayed price contains several leading zeros.

Open the verified pair, select its Alerts control, grant notification access, choose the direction, and enter the target in the displayed unit. Create the rule, then inspect the Alerts panel. The saved entry should repeat the intended pair and direction. Fixed-price conditions answer whether a pool crossed a known level; percentage-change conditions, where shown, measure movement across a defined interval and serve a different operating decision.

Notification permissions decide whether the crossed level reaches the device

Notification delivery has two gates: a saved platform alert and permission to display it on the device. A valid crossing produces little operational value when either gate remains closed.

The Web Notifications API has three permission states: default, granted, and denied. Only granted permits system notifications. Chrome and Firefox also restrict notification requests to a secure browsing context. On iOS and Android, the mobile app uses the operating system's notification controls. Browser settings and operating-system settings form two separate permission layers, so both require inspection when alerts stop appearing.

Recheck delivery after changing browser profiles, replacing a device, reinstalling the app, or restoring system settings. Create a temporary nearby threshold, wait for the tracked pair to cross it, and remove the test afterward. This verifies the complete route from indexed price to visible notification instead of checking one permission toggle in isolation.

Thin pool depth separates the alert price from an executable quote

Liquidity depth controls the difference between an observed pair price and an executable quote. In a constant-product pool, a trade changes the reserve ratio, and larger trades move farther along the pricing curve.

Uniswap V2 applies a 0.30% swap fee before enforcing its constant-product invariant. That fee is part of the pool mechanism; an alert adds no slippage control, order size, deadline, or minimum output. The same distinction applies when monitoring Raydium or another automated market maker. A notification reports an observed crossing, while a router quote estimates the output for a specific transaction.

A shallow pool may jump through a target in one swap. Before acting, inspect current liquidity, recent swap sizes, the latest buys and sells, and a fresh route from Jupiter or Uniswap. The alert price remains a review trigger. The executable rate comes from the available route, its pool fees, the requested size, and the reserves present when the transaction is prepared.

The quote asset changes what the same numeric threshold means

A quote asset determines the unit attached to every numeric target. The pair record separates base and quote into two token sides, so reversing that orientation inverts the displayed relationship.

Token precision matters near small thresholds. Native USDC uses 6 decimal places, WETH uses 18, and SOL uses 9. One SOL contains 1,000,000,000 lamports. ERC-20 exposes decimal precision through an 8-bit return value, while an SPL Token mint stores its decimals in an 8-bit field. Interfaces convert those integer units for display, but an alert still needs the correct visible decimal position.

Record the target together with its unit. The platform provides native and USD price fields for pair data, and the alert entry should preserve the unit selected in its form. A token paired with USDC and the same token paired with WETH require independent thresholds. Their charts may move together, yet neither pool supplies the other pool's trigger value.

A post-trigger verification prevents a stale chart from driving action

Post-trigger verification confirms that the notification still describes the intended pool. A fired alert opens the review process; it does not certify present liquidity or the next available exchange rate.

Return to the pair page and confirm the chain, pair address, latest indexed price, liquidity, and most recent transaction. Compare the 5-minute window with the 1-hour and 24-hour views. A brief crossing followed by immediate reversal conveys different information from sustained trading beyond the threshold. Recent transaction rows show whether the move came through several swaps or one larger update.

The platform lists a token automatically once it has been added to a liquidity pool and that pool has recorded at least one transaction. That one-transaction minimum explains why a new listing can still contain sparse activity. If liquidity later concentrates in a new pool, the original alert continues watching its original pair. Replace it deliberately rather than assuming the notification follows the token.

Scheduled maintenance keeps the alert board decision-ready

Even so, Dexscreener alert maintenance removes conditions that no longer represent an active decision. Review the board after three events: a target fires, liquidity moves to another pair, or the notification device changes.

Use this short decision checklist for each saved rule.

• Retain upper and lower levels only when each one leads to a distinct review action.
• Replace the rule when the active pool has a different chain or pair address.
• Remove the threshold when its quote asset no longer matches the intended accounting unit.
• Recheck delivery after a new browser profile, app installation, or device migration.
• Choose an on-chain order service when automatic execution is required instead of notification.

Market rotation leaves old pair pages behind quickly. A small, verified alert board preserves the connection between one pool, one unit, one direction, and one planned response. That structure also makes duplicate alerts visible. Maintenance then becomes routine: prepare the exact pair, execute the rule, verify each crossing, and retire conditions that have finished their job.