Token research and data

Research begins with the network and token address. Use the token returned by discovery or exact mint search rather than assuming that a display ticker identifies one asset.

Research an asset in the app

1. Use the top search or open Tokens, choose a list, and filter by chain when useful.
2. Select the asset and inspect its chart, statistics and token activity. For a Solana token, Who holds it in the token info shows at a glance how concentrated ownership is; the risk-details button beside the chart statistics shows the same figures under Ownership.
3. In Chat, ask a focused question such as “Explain this token's last hour of activity and cite your sources.” For a holder comparison, first confirm that the assistant actually retrieved the ownership snapshot; an aggregate listing count is not a holder breakdown.
4. Open cited links or Feed reports to inspect the underlying evidence. A report's captured price move is historical; ask for a current snapshot to learn what happened afterward.

The agent can discover live web/news and X research tools, read supported documents, search market episodes, and analyze returned datasets. Available data tools are account- and release-dependent. It must distinguish measured data from an author's claim and retain the source's date.

Read risk and holder information

Crash-risk categories estimate a kind of price decline; they do not certify a token as safe or identify fraud. A missing risk score is unknown, not low risk. Holder counts, top-holder share, wallet activity and observed liquidity answer different questions. A large holder is not automatically the developer or an insider. Values and rankings change over time.

The first-hour buyers' sold/bought ratio compares cumulative sold quantity with bought quantity for that cohort. It can exceed 1 (for example, 1.35); it is not a percentage of initial holdings. Do not clamp it to 100% or interpret it as a bounded ownership share.

Holder snapshot availability

Who holds it

For a Solana token, the token info shows Who holds it: a ring chart of who holds the token's circulating supply. On desktop it sits in Token info below the Tokens list, after the trading activity; use Expand token info if minimized. Token info grows to show the activity and the chart in full, leaving room for a few token rows above; it scrolls only on short screens or after you drag it smaller. On mobile, open the token's chart and read the About tab. The ring has:

• a red slice, Pool its creator controls or Pool one wallet controls, for a PumpSwap or Raydium pool whose LP tokens one wallet holds. That wallet can withdraw the pool's tokens and the SOL or other token paired with them at any time, the usual way a rug pull happens, so the pool counts as that wallet's holding. Hover the row for the wallet, the pool and its share of the LP;
• one grey slice for the other known liquidity pools: pools whose LP is burned (as pump.fun does when a coin graduates), held by a program such as a lock, or spread across many holders, and Meteora and Orca pools, whose ownership isn't checked. A single pool is labelled with its name (for example PumpSwap pool, Raydium pool or Meteora pool); a token in several pools, such as its own pool plus pools pairing it with other tokens, shows Liquidity pools (N) with their combined share. Hover the row to list each pool and whether its LP is burned or held by a program;
• a colored slice for each of the 10 largest holders. The legend lists Holder 1 to Holder 5 with a shortened wallet address, and groups the rest (usually Holders 6–10) into one row and one color;
• Everyone else, the rest of the circulating supply.

Circulating supply leaves out tokens still unsold in the token's own launch curve (a pump.fun bonding curve, a Meteora launch curve or a Raydium LaunchLab curve): nobody holds them yet. When at least 1% is unsold, a line under the title reads, for example, Of circulating supply · 42.5% is unsold in the launch curve, and every percentage in the chart is a share of the rest.

The center shows Top 10, the share of circulating supply held by the 10 largest holders, a controlled pool counting as its wallet's. Hover a slice or legend row, or focus a legend row with the keyboard, to show that row's share in the center. The header shows the holder count, marked approx. when the scan was approximate. Beside the title, a tag reads Concentrated when the top 10 holders own more than 30% of circulating supply or any one holder (including a wallet through a pool it controls) owns more than 10%. Otherwise it reads Risky pool when the token's crash risk reports unsafe pools (most recent trading in a PumpSwap pool of a token that didn't launch on pump.fun; such pools are usually drained within a day), and Well spread if not. Hovering the tag states the rule. The tag is a fixed rule of thumb about holdings, not a safety check or a recommendation. One large colored slice means one wallet holds much of the supply; many small slices and a large Everyone else mean ownership is spread out. The snapshot time is in Risk details → Data notes.

If pools can't be identified at that moment, the chart says Pools couldn't be identified right now, so a large slice may be a pool rather than a holder, pools are counted as holders, and only the Risky pool tag can show. Only listed launchpads and pool programs are recognized; other program accounts, such as multisig vaults, appear as holders. A wallet that can withdraw a Meteora or Orca pool is not detected. Wallets controlled by one person count separately, so a holder spreading tokens across many wallets looks more spread out than it is. Tokens too widely held to rank show This token has too many holders to rank here. The chart is not shown for non-Solana tokens.

Risk details → Ownership shows Top 10 holders, Largest holder, Pools one wallet can withdraw, Unsold in launch curve, Liquidity pool (the other identified pools) and the holder count from the same snapshot, with the same circulating-supply figures as the chart. If pools aren't identified, the totals are shares of total supply and include program and pool accounts. Data notes shows its snapshot time. A wallet is not automatically a person, developer or insider. These balances are not reconstructed by adding buys and subtracting sells.

In Chat, ask for a current holder breakdown using the exact Solana token address. The assistant can retrieve the same balance snapshot: top wallets with balances and supply percentages, holder count and top-10 concentration. It returns 10 wallets by default and up to 100 on request. The holder count covers all observed nonzero owners; the returned ranking is only the largest wallets. Top-10 concentration is calculated from the full snapshot even if fewer than ten rows are requested. Balances are grouped by owner before ranking, and include program and pool accounts. Known liquidity pools and launchpad bonding curves are labelled by name. The assistant can also report unsold launch supply, which pools one wallet can withdraw and the top-10 and largest-holder shares of circulating supply, matching Who holds it.

Ask the assistant to include the snapshot time and whether it is stale or approximate. A stale result is the last available observation. An approximate scan can span multiple blockchain slots, so the rows and supply are not guaranteed to be one atomic observation. If data is loading or unavailable, wait for the stated retry interval; missing data is not zero holders. Full holder-size cohorts and developer/insider labels are not supplied by this breakdown. Launch allocation describes the first three seconds after creation; recent buying and selling describe flows. Neither establishes current balances.

For “the newest Pump.fun graduate,” the assistant orders the published Graduated list by recorded graduation time and identifies the newest among those entries, with the list's observation time. Missing graduation times cannot establish newest status. The list does not cover every token on-chain; custom screening can select by migration age within its recorded coverage. Current ownership snapshots cannot be used as historical strategy inputs.

The current Terminal keeps the full Holders table tab hidden while network coverage is incomplete. Use Chat for the returned wallet rows, or Who holds it and Risk details → Ownership for concentration.

Certified holder balance snapshots are not currently available for Base and other non-Solana networks. In particular, a Base Doppler token can have a working chart but unavailable holder data. An unavailable-network response is not zero holders and does not establish an empty ownership distribution. Retrying cannot add an unsupported network's snapshot coverage.

Loading or a failed refresh is separate from unavailable network coverage. Read the displayed snapshot time and any last-available or error notice; missing ownership data stays unknown. The same data boundaries apply on desktop and mobile web in Paper and Real money, subject to the installed release. Viewing ownership does not change a strategy or authorize a trade.

Available context

Crypto indexes and token activity

In Terminal, open Tokens → Crypto and select a currency pair such as ABTUSD or BTCUSD. The Token info panel below the list follows the selected chart. If it is minimized, use Expand token info. The panel shows market details without the extra price-index explanation or routine loading/update text. Pool buy/sell counts, directional volume and unique-trader counts are unavailable, not zero; a price index does not identify a particular network, token contract or pool.

The live quote updates independently of optional market details. A slow details request should not hide an available quote; if the quote stream has no value, the price remains unavailable rather than being invented. A stalled optional read stops after about ten seconds while active. Recovery messages remain visible: Market details unavailable or No additional market details were returned for this pair offers Retry market details. Retry rereads the selected pair; it does not enable a provider or add pool coverage. Do not infer pool counts or a volume split from a market price, market cap or aggregate volume.

For supported token activity, select the exact network-qualified token from another Tokens list or search by its network/address. The activity panel shows the selected window without an auto-refresh/timestamp footer. Hover its info/retry icon to read the source, scope and update time; the same details are available in the control's accessible description. Indexed-market and single-pool observations are different scopes. The app does not choose a representative wrapped token or pool for a currency index. Perpetual details are a separate venue-contract view. The index explanation and recovery apply on desktop/mobile web and in Paper/Real mode; installed native clients can differ until updated.

For a network-qualified token, the activity panel first reads Astral's stored trades of that token across indexed markets. Its 5M, 1H, 4H and 1D windows count buy and sell transactions (a transaction counts once per side), sum buy and sell volume in USD and count distinct buying and selling wallets. They end at the latest stored minute, normally one to two minutes behind live trading; the panel shows that time and refreshes about every ten seconds while it is visible. When Astral has no stored trades of the token or cannot answer, the panel shows one pool's activity from GeckoTerminal, which can include 6H, or from DexScreener, which has transaction counts and total volume only. Loading unique trader counts… and Unique trader counts delayed · retrying automatically (and the same notices for the buy/sell volume split) mean a source with those values will be asked again; Unique trader counts aren't available for this token means the remaining sources do not provide them. A window that includes minutes Astral did not store completely, such as 1D for a day after a data gap, shows — with Unique trader counts for this timeframe aren't available yet: those values are unknown, not zero. If no source answers, the panel reports that trading activity isn't available right now and keeps retrying; Retry asks again at once.

Risk-details loading and freshness

For Solana tokens, open the risk-details button beside the chart statistics to see Crash risk, Ownership, Token controls, and Market activity. Crash risk, holder information (ownership and token controls), and market activity load independently on desktop and mobile, in both Paper and Real mode.

• Crash risk reads a published five-minute score. The score time is shown; a score more than ten minutes old carries an age notice. Older saved scores can lack factor explanations while still having a valid score. The mobile chart's About summary keeps this compact: severity, probability score and four bars, with no factor list or explanatory paragraphs. Score time, stale and refresh information remain in its accessible description/tooltip; the risk-details view retains the fuller context. Unavailable and not-scored values remain unknown rather than zero.
• Token controls show the mint/freeze authorities and supported transfer extensions returned by the mint read. Revoked means an authority was explicitly absent; missing control data is Unavailable, not revoked or safe.
• Market activity displays stored observations while background refreshes run. Volume can be available even when a new token has insufficient history for a 24-hour price-change baseline. Pool transaction counts cover measured pools.
• Data notes lists the holder, liquidity, volume-window and pool-activity timestamps. Volume observations older than ten minutes and liquidity/pool-activity observations older than thirty minutes become unavailable until refreshed.

A failed risk or market request stops loading and shows a retry notice. Market snapshots are checked every fifteen seconds while the chart is mounted; crash risk retries on its one-minute refresh cycle. An unavailable field is not a zero, and one unavailable section does not mean the others failed.

An actively traded token can have an unavailable crash-risk score when shared source history is incomplete or corrected scoring inputs are still being prepared. This can affect several tokens at once; it does not mean there were no trades or that the tokens have low risk. Check the score time and Data notes rather than substituting a chart price or trading volume for a risk estimate. Recovery depends on source availability, so there is no guaranteed completion time; contact support if it persists.

The trade ticket's Crash risk disclosure can show the same published score as Tokens while refreshing risk details. It keeps the newest matching scored observation and shows its time in a compact line with Refresh unavailable or Over 10 min old when applicable. The ticket omits factor lists and longer explanations. Token-name loading does not need to finish before risk can load for the exact contract. See ticket crash-risk checks.

Other research context

• Charts show the price history available for the selected token and interval.
• Market statistics can include market cap, price, liquidity, volume and transaction counts.
• Token activity can break down buys, sells, volume and traders across supported time windows.
• Holder views can show wallet positions and supply distribution where returned.

Coverage, refresh intervals and available fields vary by source and token. A missing field is unavailable, not zero. Market cap, traded volume and liquidity describe different things and should not be substituted for one another.

Verified feed ranges describe data coverage, not a promise of a price observation for every token. A token can have no stored observations at or after a scheduled entry even within those ranges. Ask for history of the exact network/address and interval. An empty result does not establish zero value, executable liquidity or the absence of all on-chain activity. Qualified launch facts and price coverage are separate requirements.

For a launch-dependent screening plan, an explicit-date coverage check also checks unavailable launch days throughout the plan's launch-history dependency window. A migration-age limit does not bound the token's creation age. If launch facts are unavailable, the dates do not fit; the explanation names the missing days and dependency window, says that retrying will not add them, and offers only dates inside the checked span whose launch facts are complete (never price-only alternatives as qualified dates). If no such dates exist, it says so instead of offering any. Fully automatic dates for these screens start after such days when a qualified window remains, so the default test can be shorter than usual. Read the current launch floor and readiness from the returned evidence, not a fixed start date. This checks the supplied screening plan, not every additional data expression in a strategy. Historical repair and choosing different dates remain separate actions; your explicit dates and eligibility rules are unchanged.

Discovery and token lifecycle

Discovery offers the networks and scopes currently returned by the product. Trending uses the ranking described by the selector; it should not be interpreted as a prediction. New tokens and bonding-curve or graduated tokens can have different history and chart availability.

Search can return usable identities with a partial result when a source or optional metadata lookup times out. Unavailable enrichment does not mean the token is absent. Confirm the network/address and retry missing information separately. Search-result positions describe the current response page; provider ranks, market cap and similar names do not establish canonical identity.

Creation dates and observed history

Ask the agent to distinguish verified token creation from a provider-reported date, catalog first-seen time and first observed trade. Search's created_at is supplied only with validated on-chain creation evidence. reported_created_at is an unverified source claim; first_observed_trade_at describes retained observations, not necessarily the token's first-ever trade. A provider date is not automatically a listing or ingestion date either when its meaning is undocumented.

The reported date's source can be unspecified, even when the token row names a current data provider. Identity, ranking and dates can come from different observations; the current provider does not prove who supplied an older timestamp. Astral names that timestamp's source only when evidence is tied to the same reported date. A named source is still not verified on-chain creation.

Earlier candles can show that a reported creation date needs investigation, but Astral must not replace it with the earliest candle to make dates agree. Conflicting creation evidence remains explicitly unverified/conflicted, with the original evidence retained. Ask for the exact network/address, timestamp source and transaction evidence when available. Missing launch evidence and limited historical retention remain separate from chart availability. These research meanings are the same on desktop/mobile web and in Paper/Real money; no history or strategy is rewritten.

A strategy can pick its tokens from one of the Tokens lists, for example "trade the top 10 Robinhood Chain tokens on Trending that are rising". It uses each list as it was published a minute before every decision, limited to the strategy's one network, so the order matches what the list showed then, including later changes to how a list is ranked. Trending and Top cover every on-chain network; New, Graduated, Bonding, Growing holders, Broader ownership and Fresh traction are Solana only; Perps covers Hyperliquid. Crypto is a fixed set of price indexes rather than a ranked list: a strategy can screen those pairs directly, in backtests only for now.

List membership and rank do not establish safety or liquidity. A list-ranked strategy still needs a supported activity filter, such as a suitable trading-volume floor, alongside its other entry conditions.

Research is not an execution quote

Check timestamps and source information before comparing values. A chart price does not guarantee the price of a live transaction. Liquidity and activity do not establish that a token is safe or that an order can fill.

Holder concentration is descriptive context. It does not by itself identify insiders, prove wallet ownership, or guarantee detection of abusive activity.

Turning observations into a strategy

Ask which inputs are supported by the strategy engine. Discovery lists are recorded as they were published, so a strategy can rank by them in backtests within the recorded period. Displayed holder or liquidity data is not otherwise available for historical signal evaluation. Avoid using present-day observations as if they were known at the time of a backtest.

See Backtesting and Markets for coverage and simulation boundaries.