TL;DR / Key Takeaways
- Low liquidity can make the trade itself move the execution price, so price impact must be shown separately from slippage tolerance.
- Quotes should be refreshed at decision time and labelled with their source, timestamp and expiry state.
- Small, medium and large trade-size previews reveal risk more clearly than one generic warning.
- Wallet approval, on-chain confirmation and product fulfilment should appear as separate interface states.
On this page Jump straight to the sections you need Built for mobile reading and quick skimming.
Token liquidity is not just a market statistic that belongs on an analytics screen. In a Web3 interface, it directly affects what a user may receive, how quickly a quote becomes stale and whether a normal-looking swap can produce an unexpectedly poor fill. A safer interface therefore has to explain liquidity, slippage and price impact before a wallet signature—not after execution.
This checklist is for product teams building token dashboards, swap interfaces, airdrop claim flows with optional trading links, portfolio tools and other applications that expose users to thin markets. It focuses on interface decisions rather than price predictions.
Why low-liquidity token interfaces need different rules
A displayed token price can create false confidence when it is separated from executable depth. The latest trade may show one price, while the pool has too little liquidity to fill the user's intended size near that price. In that case, the trade changes the pool balance as it executes.
Uniswap defines price impact as the price change caused directly by the trade. Lower pool liquidity generally creates greater impact for the same order size. Slippage is related but different: it is the difference between the quoted outcome and the actual outcome when execution occurs. A useful interface names both instead of collapsing them into one vague “market risk” label.
| Signal | What it tells the user | What the interface should show |
|---|---|---|
| Pool liquidity | How much capital is available around the current market | Source, network, pool or route, and time checked |
| Price impact | How much this specific trade changes the execution price | Estimated percentage and value before signing |
| Slippage tolerance | How much quote deterioration the user permits | Current setting, minimum received and a plain-language consequence |
| Quote age | Whether the displayed route may already be stale | Timestamp, countdown or automatic refresh state |
1. Measure liquidity at the decision point
Do not treat liquidity as a profile attribute that is fetched once and reused indefinitely. Pool balances, routes, spreads and competing transactions can change between page load and wallet approval. Fetch the information used for the decision as close as practical to the confirmation step, and make stale quotes visibly expire.
Every material number should carry enough context to be checked:
- network and token contract or mint;
- venue, pool or aggregator route;
- quote timestamp and expiry condition;
- input amount and estimated output amount;
- minimum received after the selected tolerance;
- estimated fees that are known before signing.
A label such as “live” is not enough if the value is cached. Use a concrete age—such as “checked 12 seconds ago”—and require a refresh when the quote passes its validity window.
2. Show trade-size scenarios, not one generic warning
Low-liquidity risk is size-dependent. A small test trade and a larger position can face very different execution conditions in the same pool. A practical interface can show three non-prescriptive scenarios based on the user's current amount: smaller, current and larger.
Each row should recompute the estimated output and price impact. The purpose is not to steer users toward a trade; it is to show that risk changes with size. Avoid green “best return” styling. Neutral labels and consistent units make the comparison easier to understand without turning it into a recommendation.
A warning becomes useful when it identifies the cause, quantifies the current effect and gives the user a safe next action: reduce the amount, refresh the quote, inspect the route or cancel.
3. Keep price impact separate from slippage controls
Increasing slippage tolerance does not create liquidity. It only allows the transaction to execute across a wider range of outcomes. An interface should never imply that raising the tolerance “fixes” a high-impact trade.
Place the figures close together but explain them separately:
- Estimated price impact: the effect of this order on the route or pool.
- Slippage tolerance: the maximum additional quote movement the user permits.
- Minimum received: the enforceable lower bound encoded into the transaction, when supported.
Warnings should become progressively stronger as execution quality worsens. For severe conditions, require a deliberate acknowledgement rather than relying on color alone. Do not pre-check the acknowledgement or hide the expected loss behind an advanced-settings panel.
4. Separate product, on-chain and market state
Manukyan's original utility-first Solana architecture article makes a useful distinction between product state, on-chain state and market state. That separation is especially valuable in a safety interface because each layer has a different source and update speed.
- Product state covers accounts, permissions, feature access and off-chain fulfilment.
- On-chain state covers balances, program-owned data, signatures and confirmation status.
- Market state covers quotes, liquidity, price impact and rapidly changing execution conditions.
Never use a successful wallet connection as proof that a transaction succeeded. Never use a transaction signature alone as proof that the intended product action was fulfilled. And never carry a market quote forward as though it were permanent application state.
5. Preview the transaction in plain language
Before opening the wallet, summarize what the application is asking the user to approve. At minimum, show the action, network, assets that may move, destination or authority, estimated fees, minimum received and the expected product result.
Keep raw identifiers available for verification. Token names, symbols and logos are helpful for scanning, but contract addresses, mint addresses and program IDs are the authoritative identifiers. Let users copy the full value and open a relevant explorer.
The wallet remains an independent security boundary. Solana's official guidance for Actions states that clients and wallets should treat supplied transactions as untrusted and validate them. The application preview should complement the wallet view, not ask users to ignore it.
6. Treat confirmation as a sequence
A safer interface represents connection, signing, submission, confirmation and fulfilment as distinct states. This prevents a slow network response from looking like a completed action and reduces the chance that a user repeats a transaction unnecessarily.
On Solana, the official getTransaction documentation notes that a lookup can return no result when a transaction has not been found or confirmed at the requested commitment. The UI should therefore distinguish “submitted,” “confirmed,” “failed,” “expired” and “status unavailable.” A spinner with no status text is not enough.
7. Build the failure paths before launch
Test the interface against conditions that are normal in production but easy to overlook in a happy-path demo:
- quote expires while the wallet prompt is open;
- the selected route disappears or liquidity changes sharply;
- the wallet is on the wrong network;
- simulation fails or estimated fees change;
- the user rejects the signature;
- the transaction is submitted but not yet confirmed;
- the transaction confirms but off-chain fulfilment fails;
- the user retries and creates a duplicate request.
Every failure message should say what is known, what is uncertain and what the user can safely do next. Preserve transaction signatures and route details so support teams can investigate without asking users to repeat an action.
A compact pre-launch checklist
| Check | Pass condition |
|---|---|
| Data freshness | Quotes and liquidity show a timestamp and become unusable when stale. |
| Trade-size context | The interface recalculates impact for the actual input amount. |
| Terminology | Price impact, slippage tolerance and minimum received are separately explained. |
| Transaction preview | The user can inspect assets, destination, fees and authoritative identifiers before signing. |
| Status handling | Submitted, confirmed, failed, expired and unavailable states are visibly distinct. |
| Accessibility | Warnings use text and structure, not color alone, and remain readable on mobile. |
| Disclosure | Product facts, roadmap statements and market conditions are clearly separated. |
The takeaway
Low-liquidity safety is not solved by one red banner. It requires a chain of honest interface decisions: current data, size-aware estimates, separate risk concepts, a readable transaction preview and explicit confirmation states. When uncertainty remains, the safest product action is to say so and make cancellation easy.
For broader wallet hygiene before using unfamiliar Web3 applications, review the AirdropBuzz crypto safety checklist.
Sources and editorial note
- Original source: Designing a Utility-First Solana Product Ecosystem, ARMCP_Team on DEV Community.
- Companion source: Construire une utilité Web3 vérifiable avant de parler de croissance, ARMCP Technologie Web3.
- Uniswap Labs: What is price impact?
- Solana documentation: getTransaction
- Solana documentation: Actions and Blinks
This article is educational only and does not recommend buying, selling or interacting with any token. Market conditions can change between quote and execution.
