Strategy Reference

Astral strategies are structured, rule-based specifications generated and revised through chat. The code view is the inspectable representation used by backtesting and deployment workflows; review it before saving or operating a strategy.

Current authoring contract

The editable Astral Strategy source is authoritative. Compiled JSON is internal; users review source in the read-only Code panel and request changes in Chat. New calculations use expressions. Pine imports, custom scripted indicators and scripted strategy dependencies are currently disabled.

The agent uses versioned authoring references for exact syntax, function signatures and validation. A static product guide is not a substitute for those contracts. A validation error must be corrected and the final revision retested; a nearby supported operation must not silently replace the user's requested rule.

The current product covers supported on-chain tokens, crypto USD indices for research, and Hyperliquid perps. Stocks, forex, commodities and prediction markets are unavailable in the current agent workflow. Supported strategy bar sizes are 1m, 5m, 15m, 30m, 1h and 1d, subject to exact asset coverage; do not assume a 4h option from an older guide. A 4h strategy is rejected at validation and is not silently replaced; ask for 1h or 1d instead. Hyperliquid perps backtest on 1m, 5m, 15m, 1h and 1d only (no 30m).

Core structure

Price data and common functions

Strategies can reference open, high, low, close, and volume for configured assets. Strategy, chart-indicator and alert formulas use the same functions (stored-data inputs such as volume_usd are separate):

• Indicators: SMA, EMA, RSI, ATR, MACD_LINE, MACD_SIGNAL, MACD_HIST, BB_UPPER, BB_MIDDLE, BB_LOWER, STOCH_K and STOCH_D.
• Rolling values: MIN, MAX, STDEV, ZSCORE, LAG, PCT_CHANGE, ROC and DIFF.
• Math: LOG, EXP, ABS, SQRT and CLAMP, plus arithmetic, comparisons and and/or/not.
• Events and time: CROSS_ABOVE, CROSS_BELOW, BARS_SINCE, VALUE_WHEN, PIVOT_HIGH, PIVOT_LOW, HOUR, MINUTE, DAY_OF_WEEK, ISTIMESTAMP and IS_BETWEEN_TIMESTAMPS.

There is no VWAP, SUM or IF function, and strategies reject conditional selection (a if condition else b). A rolling sum over N bars can be written exactly as SMA(x, N) * N. A session-anchored VWAP is not available in strategies, chart formulas or alerts; the chart's built-in VWMA indicator, SMA(close * volume, N) / SMA(volume, N), is a rolling volume-weighted average over N bars, which is a different calculation.

Function availability and signatures are validated by the current strategy schema. If generated code fails validation, ask Astral to correct it rather than manually guessing at an unsupported signature.

Actions, sizing, and risk

Backtests can model long and short actions where supported by the strategy engine. Position sizing can use a percentage of equity, fixed dollars, or fixed shares. If you don't choose a size, Astral uses 100% of equity for one fixed token, 20% of equity per pick for a screen that holds one token at a time (the rest stays in cash), and splits equity equally when several positions can be open together, such as 33% each for a top-three strategy. Ask for a specific size, including all in, to use a different one. In two-week replays of the screens users built on Astral, one token at 100% re-picked all day ended near $0 in most runs, because small losses per pick compound at full size. Rules may include take-profit, stop-loss, or trailing-stop instructions.

Perp shorts are a backtest feature. For a Hyperliquid perp you name, ask for a short entry with a matching cover (close) rule. The backtest simulates it at 1x cross margin with fees, Hyperliquid's hourly funding (a short receives positive funding and pays negative funding) and liquidation. Strategies have no leverage setting yet (manual Paper perps are a separate, manual-only feature), and perp strategies cannot be deployed live or to Paper, so a short backtest does not mean the strategy can run. A ranked collection with a top_n above 1 requires per-trade rules, which support long spot trades only. Such perp baskets are unavailable for both long and short entries; use the supported ordinary-rule contract rather than treating a basket as equivalent.

Live execution can be narrower than backtest expressiveness. Check the selected token, account, permissions, interval, order type and available mode. A successful backtest does not establish live execution support.

Specification fields

On-chain screens and event data

Supported screening plans can combine stored price/volume windows, trade counts, distinct wallets, wallet-specific or creator flows, token age, launch holdings, migration/bonding state, Solana crash-risk metrics and market cap. Market cap is the token's market cap as the data provider reports it (the value the chart's MCap view shows), from its latest minute with one in the hour before the decision, refreshed every 5 minutes; it covers on-chain tokens, not perps or the crypto network, and a token without one is skipped by a market-cap filter. Use it to pick tokens by size, for example only tokens worth $1M–$500M. Provider caps can be wrong for copycat or thinly traded tokens, so combine it with a volume minimum. On every network, market cap history starts on October 2, 2026; a market-cap filter picks nothing on earlier dates, so backtests that use it should start on or after that date. Each metric has its own chain coverage and historical window. Research panels may display additional fields that cannot drive historical strategy rules.

For Pump.fun tokens, minutes_since_migration is the number of minutes since the token left the bonding curve, for example “only tokens within 30 minutes of migrating”. It is unknown while the token is still on the curve and for tokens that migrated more than 30 days earlier, and an unknown value never qualifies. It uses only what was known at the time of each decision.

The strategy interval sets how often a dynamic screen re-evaluates; the metric lookback is a separate setting. If you don't choose an interval for a screen, the agent uses 1 hour: re-picking every few minutes switches tokens many times a day. Name an interval, such as 5 minutes, to use it instead. The chosen token and an existing holding can differ. State the exit/rotation rule rather than assuming every new screen result instantly replaces all holdings.

Crash risk estimates the chance of a large price decline, not fraud. Historical “Crash risk eased to Low” means the score met its recovery condition after a severe warning; it does not prove the token's price recovered. Missing scores are unknown. A collapsed token can have low estimated risk of a further halving, so the agent's default Solana filter also excludes already-collapsed tokens.

New Solana screens also skip tokens worth less than $1M by default (market_cap_usd at least 1,000,000), and the agent tells you it added the filter. In two-week replays of the screens users built on Astral (late September to early November 2026), this floor cut the runs that ended near $0 from 71% to 54%, and Pump.fun tokens less than a day old lost about 8% per hour on average whatever a screen ranked them by. Ask the agent to remove the filter or use a lower one. If you ask for new launches or micro caps, it keeps that universe and repeats this warning. Strategies saved before this default keep their screens until you revise them.

Astral has no token category such as "memecoin". When you ask for memecoins or tokens similar to one, the agent limits the screen to tokens worth $1M to $500M or proposes a list of specific tokens for you to confirm, and says which it used. It limits the screen to recent Pump.fun launches only when you ask for launches. It keeps stablecoins, wrapped coins such as wSOL or cbBTC and other large tokens out of the list. A list of named tokens only ever picks from those tokens.

Timestamped trade/event data must use what was available at evaluation time. On 1-minute bars, stored-data inputs (such as volume_usd, trade counts or buyer flows) are read through the previous minute: the decision at 12:05 sees data through 12:04, in backtests and live alike, because a minute's stored data is published about a minute after it ends. On 5-minute and longer bars each decision reads data through its own bar. A public news report or research metric is not automatically an executable signal. Ask the agent to verify the exact event contract and stored coverage before building around it.

Strategies can't trigger on news or sentiment, such as "buy when someone says something on the news". The agent can search news for research, and it can offer a price or volume rule instead. To follow someone's trading, such as "sell when he sells", give the agent the wallet addresses to watch (up to 1,000). A rule can then react to those wallets' buys or sells of a token, for example closing when they sell more than $10,000 of it within an hour. For a Pump.fun token, it can also watch the token's creator wallet. Astral doesn't know who owns a wallet, so you have to supply the addresses. Only those wallets' on-chain swaps count. Transfers, exchange deposits and private sales aren't seen.

Skipping tokens Astral can't trade

New on-chain screens skip tokens Astral knows it can't trade, before ranking, so the next tradeable token takes the slot. Without this, a live buy of such a token is refused and its slot waits in cash. These are the tokens Discover hides from Trending and Top: tokens that trade only on exchanges or pool types Astral doesn't route through, tokens still on their Pump.fun bonding curve, and tokens Astral refuses for issuer controls, transfer fees or similar token features.

• Today's verdicts, in backtests too. A backtest shows what you could trade now, not what was tradeable at each past moment. A token that has since graduated from its bonding curve can be picked on dates when it was still on the curve, and a token that has since lost support is skipped on every date. Screens pick up new verdicts about once an hour.
• Unchecked tokens stay candidates. Astral checks the tokens Discover considers for its lists. A token that was never checked can still be picked, and every live order is still checked before it is placed.
• Not a liquidity check. A supported pool can still hold too little money to sell into. Keep a trading-volume floor in the screen.
• On by default for new screens. The agent adds it (trade_support='exclude-unsupported') and tells you. Ask it to turn it off (trade_support='none') to research every token. Strategies saved before this setting keep their screens unchanged until you revise them. Perps and crypto-pair screens don't use it.

Ranked screens: size limits and re-entry

A ranked screen returns at most 10 tokens per decision (top_n from 1 to 10). A strategy also has bounded numbers of candidate and holding tokens and of per-token calculations; if a plan is too large, validation says so and asks you to reduce top_n, the open-trade cap or the calculations. These limits are not currently configurable.

Each token the screen selects becomes its own independent trade with its own exit, protection and sizing. Entry and re-entry follow these rules:

• Entry trigger. By default (rising_edge) a token is bought when its entry condition turns from false to true, not on every bar it stays true. each_bar tries to buy on every bar the condition is true.
• Open-trade cap. max_open_trades (1 to 100; by default the screen's size) limits concurrent trades; when a rule takes every ranked token it defaults to the screen's size, otherwise to 1. When it is reached, a qualifying token is skipped. Under the default trigger a skipped token is not retried until its condition turns false and true again, or the token leaves the ranked list and returns. Use each_bar if you want it bought as soon as a slot opens.
• The same token again. A token you already hold in a rule is not bought a second time unless allow_same_asset is on. After its trade closes, it can be bought again when the trigger fires.
• A held token that drops off the list. By default (until_exit) it is kept until its own exit. rotate sells it when it leaves the selected set and buys the new pick with the proceeds of that sale. Only the first buy uses the strategy's position size: every later pick gets what the previous sale returned, so after losses the amount traded shrinks, it is not topped up from the rest of the account, and a backtest's equity can fall quickly and then stay flat.

There is no setting to buy each token only once ever, and no open-ended portfolio that grows with every token that ever qualified. Ask for a bounded set (a top-N screen with an open-trade cap) instead.

A timed profit exit can combine time since the first entry fill with a return condition, for example selling once held for 30 minutes if the gain covers estimated round-trip costs. This is not a timer measuring how long the trade has stayed continuously in profit; that duration is not currently exposed to strategy rules. An explicit continuous-profit request needs that limitation explained, rather than silently replacing it with holding time. The per-trade return field measures price return, so a cost-aware exit needs an estimated cost buffer. Decisions use completed strategy bars, and a triggered exit is not a confirmed sale or a guaranteed positive realized return. Review the estimated cost threshold, stop and fill model. After a confirmed exit, fresh qualifying signals can open another trade; default edge-triggered entry does not force an immediate rebuy of an unchanged signal. Rank changes and profit exits are separate holding policies.

Previous-minute reversal research

A previous-minute loser rotation compares percentage returns over the last completed minute and chooses the lowest return. Use synchronized, available observations and a deterministic tie rule. The smallest gainer still ranks last when all candidates rose; requiring a negative return is an additional filter, not part of that basic ranking.

For a fixed BTC/ETH/SOL comparison, define one selected holding and the transition when the weakest changes. This differs from adding a position on every minute or running three independent entry rules without comparing the assets. Orders must follow the decision and the selected fill model; do not assume an earlier price was available after observing the completed minute. Missing or stale observations need an explicit policy rather than silently comparing different minutes. For network-token screens, keep the existing eligible universe and supported filters before ranking; a token-local bounce rule applies to the shortlist afterwards.

Previous-minute reversal and its bounce-confirmation variant are two of the blue-chip research ideas. The other blue-chip ideas use candle turns, range rebounds, selloff recoveries or relative strength. The separate network-token starters retain profit-taking themes and do not inherit this ranking or the 1m interval. These are research hypotheses. Stops, estimated costs, a cash filter or a profit exit change the tested rules and need their own evaluation. A cash filter can reduce exposure during a decline but cannot establish positive bear-market returns. A zero-cost index-price simulation does not establish an executable edge or wallet tradeability. Do not apply an earlier version's return to a changed version. The starter messages do not fix sizing, profit targets or a holding period.

What screens cannot filter on yet

These are not accepted as strategy filters or rankings, and Astral does not silently substitute another metric: LP lock or burn, mint or ownership controls, honeypot checks, liquidity stability, pool liquidity, total holder count and holder trend. Some of them can appear as optional facts in previews, but a preview fact cannot gate entries. A backtest would need what was true at each past moment, and that history is not stored for these yet. Skipping tokens Astral can't trade (above) does remove tokens Astral currently refuses for issuer controls, but by today's verdict, not as a filter you can set or rank by.

Closest supported alternatives you can ask for:

• Solana crash risk: rug_risk_level at or below 1, together with the default already-collapsed-token filter.
• Market cap as a size filter, for example at least $1M (the default floor) or $1M to $500M.
• A trading-volume floor over a stated window, so the token has enough activity to exit.
• Distinct buyers or new buyers over a window as a participation signal (not total holders).
• For Pump.fun tokens, curve_sol and bonding progress to describe how much has been put into the curve.

These alternatives measure something different from the unavailable metric. Say so in the strategy description rather than presenting them as equivalent.

Session ranges, such as the Asian session

There is no SESSION_HIGH or SESSION_LOW function. A clock-bounded range is built from existing pieces: sample a rolling maximum or minimum, exactly as long as the session, at the session's last bar. The result holds that session's value until the next session ends.

For the Asian session (00:00 to 08:00 UTC) on 15-minute bars, set the engine timezone to UTC. The session is 32 bars and its last bar is stamped 07:45, which is minute 465 of the day:

• High: VALUE_WHEN(HOUR() * 60 + MINUTE() == 465, MAX(BTCUSD.high, 32))
• Low: VALUE_WHEN(HOUR() * 60 + MINUTE() == 465, MIN(BTCUSD.low, 32))

Backtest and live evaluation give the same values, equal to the plain high and low of each 00:00 to 07:45 window. Things to know:

• It is unknown until the first session ends, and during a session it still shows the previous session's range, not the one in progress.
• The window length is counted in bars, so it must equal the session length divided by the bar size. If the data has missing bars inside a session, the window reaches back before the session start.
• Change the minute value, the bar count and the timezone for other sessions, bar sizes or exchanges; clock functions use the strategy engine timezone, including daylight-saving changes.

Time zones of clock functions

HOUR(), MINUTE() and DAY_OF_WEEK() read the bar's time in a time zone that depends on where the formula runs:

• Strategies: the strategy's engine timezone, UTC unless the strategy sets another one.
• Chart indicators and alerts: New York time (America/New_York, with daylight saving). These formulas have no time-zone setting.

So HOUR() == 14 matches 14:00 UTC in a default strategy but 14:00 New York time (18:00 or 19:00 UTC) on a chart or in an alert. To reproduce a UTC strategy's clock rule on a chart or in an alert, convert the hour to New York time and remember that the offset changes with daylight saving.

A clock time inside ISTIMESTAMP, such as ISTIMESTAMP("09:30"), is always New York time, in strategies too, whatever the engine timezone. Use HOUR() and MINUTE() for a clock rule in a strategy's own timezone.

Validation checklist

1. Confirm every asset and its intended asset class.
2. Confirm the bar size and historical period.
3. Read each entry and exit condition.
4. Check how multiple conditions are combined.
5. Review size, capital, and maximum exposure assumptions.
6. Review stop, target, and trailing behavior.
7. Check that live deployment restrictions are compatible before selecting a live mode.