How to Use Axiom Trade Pulse Filters for Token Research

01 / RESEARCH FUNNEL

Why Filters Matter

A fast token feed contains more markets than anyone can investigate properly. Filters reduce that workload by excluding records that do not match a research question. The question comes first: are you examining the newest pools, markets nearing a launch transition, or tokens with an established pool?

A filter does not improve the underlying token. It only changes what you see. Overly broad settings create noise; overly tight settings can hide relevant exceptions and encourage false confidence in arbitrary cut-offs.

02 / LIST CONTEXT

Understanding Pulse Categories and Token Lists

Axiom’s official Pulse documentation describes three token-stage lists: New Pairs, Final Stretch, and Migrated. The labels organise markets by launch progression; they should not be read as quality grades. The current interface may evolve, so check live wording before relying on this navigation.

• New Pairs: useful for investigating recently surfaced markets, with the highest uncertainty.
• Final Stretch: a launch-stage context, not a guarantee that migration will occur.
• Migrated: indicates a later pool stage in the documented workflow, not maturity or safety.

For a feature-level overview, see the main Axiom Pulse guide. This article focuses on the filtering process rather than duplicating the workspace description.

03 / DOCUMENTED FIELDS

Verified Filter Options in the Published Documentation

Axiom’s Pulse documentation describes filters based on token age, liquidity, market cap, volume, and transaction counts. Its Explore documentation also describes liquidity, volume, market-cap, transaction, DEX Paid, and top-10-holder percentage filters. Availability can differ by workspace and version, so do not assume every Explore control is present in Pulse.

04 / TIME AND ACTIVITY

Use Token Age and Activity Together

Age defines a research window. Very recent markets provide less history, so claims about demand and distribution are harder to assess. Older markets provide more observations but can still be illiquid or manipulated.

Pair age with transactions and volume. A burst of volume shortly after launch could reflect broad interest, one large trader, automated activity, or wash trading. Compare the number, size, and direction of trades, and examine whether activity persists across more than one short interval.

05 / EXECUTION CONTEXT

Liquidity and Volume Filtering

Liquidity relates to the assets available in a pool; volume measures past turnover. They are not interchangeable. A token can show substantial volume but limited current depth, making the next order vulnerable to price impact. Conversely, a pool can contain liquidity while seeing little real demand.

Use a liquidity floor only as a first screen, then inspect the pool and estimate how your hypothetical order compares with its depth. Review the fees guide because slippage, network costs, priority charges, and platform fees remain separate from the displayed token price.

06 / DISTRIBUTION CONTEXT

Holder Concentration and Risk Indicators

Where a holder-concentration field is available, a lower top-holder percentage can reduce one obvious concentration concern, but it cannot reveal beneficial ownership. One controller can split supply across wallets, while a pool or programme account can appear near the top for operational reasons.

Treat risk labels, paid-listing fields, social activity, and holder data as prompts for verification. Confirm the mint, inspect top accounts in an explorer, and review recent transfers. The security and risk guide explains why token risk remains distinct from platform legitimacy.

07 / CONSERVATIVE PROCESS

Build a Conservative Pulse Research Workflow

1. Choose the Pulse list that matches the launch stage you intend to study.
2. Set broad initial filters for age and liquidity, using only controls visible in the current interface.
3. Add volume and transaction context to remove inactive records—not to identify winners.
4. Compare the remaining tokens side by side; note outliers rather than ranking solely by one field.
5. Open each candidate and verify the exact mint and pool.
6. Review holder distribution, recent transactions, liquidity changes, and token-specific risk indicators where supported.
7. Estimate likely execution costs and decide whether unresolved uncertainty is acceptable.
8. Save or discard the candidate. No trade is a valid research outcome.

For broader orientation, use the Axiom beginner guide. For the preceding discovery process, read how to find new Solana tokens.

08 / EDUCATIONAL EXAMPLES

Hypothetical Filter Scenarios

Scenario A: activity without depth

Suppose Token A shows $80,000 of one-hour volume but only $12,000 of displayed liquidity. Instead of reading volume as confirmation, investigate trade sizes, current pool depth, and whether a modest order would move the price materially.

Scenario B: distribution without context

Suppose Token B shows 28% held by the largest visible group. Inspect which accounts make up that percentage. A pool address, deployer wallet, or several recently funded accounts changes the interpretation.

Scenario C: quiet but established

Suppose Token C is older and has reasonable liquidity but few recent transactions. That may not suit a search for active markets, yet it does not automatically mean the token is unsafe. The filter reflects the research question, not a universal grade.

09 / COMMON ERRORS

Common Pulse Filter Mistakes

• Copying someone else’s thresholds without knowing their objective or risk.
• Treating high volume as organic demand.
• Filtering by market cap without checking liquidity and supply context.
• Assuming a migrated or trending token has passed a safety review.
• Changing filters after seeing a desired ticker.
• Using holder percentages without identifying pools or programme accounts.
• Relying on stale screenshots when the live controls have changed.

10 / PRIMARY EVIDENCE

Sources and Method

• Axiom — Pulse ↗
• Axiom — Explore Tokens ↗
• Solana — Tokens ↗

Checked 19 October 2026. Exact fields are attributed to the workspace in which Axiom documents them. Specific presets, defaults, and live thresholds remain subject to interface verification; none were invented here.