Documentation
Saved & Deployed Strategies
Astral keeps private saved strategies, public publications, and active deployments as related but distinct records. Understanding the difference prevents accidental sharing or live operation.
Strategy states
| State | Meaning |
|---|---|
| In-session | Generated in a Terminal conversation and available to inspect or backtest. |
| Saved | Stored privately in your account library. |
| Published | Explicitly shared to Explore and a public profile. |
| Notifications only | Active signal monitoring with a notification profile and no tracked portfolio execution. |
| Astral Paper | Active simulated portfolio funded by a strategy allocation from an Astral Paper account. |
| Broker connected | Active against an eligible verified connected account for live order routing. |
| Paused or stopped | No longer operating normally; inspect the reason and any live broker state. |
Classic strategy order directions
The Classic Terminal strategy builder creates long-only strategies. Buy opens or adds to a long position; Sell reduces or closes that position. A sell does not open a short position. Short/cover orders and two-sided long/short strategies are not available through this builder, including on mobile web and in Paper mode.
If your request includes short entries, the assistant should explain the limitation before offering a clearly labeled long-only alternative. Review that alternative's entry and exit rules: it is not an equivalent implementation of a two-sided strategy.
Review a strategy
Strategy detail surfaces can show description, code, assets, timeframe, historical dates, metrics, equity, orders or trades, current execution mode, notification profile, capital, and health state. Availability differs between a historical saved result and an active deployment.
For notifications-only modes, portfolio metrics may be intentionally unavailable because no Astral paper or broker ledger is being tracked. Paper and broker metrics should identify their data source.
Reopen an in-session draft
Reopen the same Terminal conversation to continue a persisted build-only draft, including its assets, indicators, entry/exit rules and environment. On desktop, the code panel restores that draft even if you have not saved or backtested it. Once restoration completes, the full existing code appears together; it should not wait for the welcome template to erase or replay a typing animation. Newly authored code can still appear progressively while the assistant works. Mobile web uses a chat-first layout and does not expose the desktop code panel in this workflow; open the same conversation on desktop to review the full code. Check the rules and interval before continuing. If the desktop panel still shows the welcome template, reload the conversation and report its link if the problem persists; creating another account is unnecessary.
Reopening a draft does not save, publish, backtest or deploy it. Saved and active strategies keep their separate records and controls. Installed clients require a release containing this restoration behavior.
Change a draft's interval
In the same Terminal conversation, ask for the exact interval, for example: “Change this draft to 5m and keep its rules.” Classic strategies use one price timeframe. On releases containing the interval-edit repair, the draft environment and its price datasets update together while retaining the assets, indicators, rules and order protections. Supported intervals are 1m, 5m, 15m, 30m, 1h, 4h and 1d. Alternative-data selectors retain their existing configuration.
Desktop and mobile web use the same authoring operation; review the full code on desktop and check the chart's visible interval separately. Installed clients depend on their release. Editing or reopening a draft does not update a saved strategy or a running Paper or broker-connected deployment. A stale dataset label alone does not prove which interval executed. If the draft still contains conflicting intervals, report the conversation link, requested interval and device; saving or running it is not needed to diagnose the mismatch.
Copying and publishing
Copying an Explore strategy creates or associates your own saved version so you can inspect and modify it. It does not inherit the author’s suitability, account assumptions, or future changes. Run your own backtest.
Publishing requires public-profile context and makes the selected strategy visible to others. Private saved strategies remain private until an explicit publication action succeeds.
Copy a crypto strategy to Onchain
If your account can also use Astral Onchain, you can copy a Classic strategy that trades BTC, ETH or SOL into Onchain. The import is done in Onchain: open Strategies there and choose Import from Classic. The copy keeps the strategy's rules, indicators, interval and sizing, drops short entries, and must be backtested on Onchain before it can be deployed. Strategies on other coins, on stocks or on 4-hour bars can't be imported. Importing doesn't change the Classic strategy, its results or its deployments.
Stop, undeploy, and delete
Stopping a deployment prevents future Astral-side operation for that deployment. It does not necessarily close existing broker positions or cancel every broker-side order. Deleting or unsaving a private strategy is also separate from stopping a deployment or removing a publication.
Open Dashboard → Strategies, select the deployment, and use Stop. Review the available Stop & Undeploy or Liquidate & Stop action and its confirmation. An unavailable ownership or accounting check can prevent completion. Wait for the final lifecycle result and returned Paper allocation. Desktop and mobile web use the same checks; installed clients can depend on their release.
MCP's undeploy/confirmed Paper-stop tools are flat-only: they do not liquidate strategy holdings and accept no position-disposition parameter. If positions or reservations remain, use the Dashboard Stop workflow. A manual account sell is not a substitute for closing a strategy-owned position.
Recover after selling directly at the broker
For a real broker-connected deployment that is paused or liquidating, the Stop dialog (Dashboard → Strategies → select the deployment → Stop) can show I already sold this position at my broker. It is not offered for Paper deployments. Pause a running strategy first; the step appears only once the deployment is paused or liquidating.
- Expand that section only after you have sold the strategy's position directly at the broker.
- Read the explanation and check I confirm I sold the position directly at my broker and want to undeploy this strategy.
- Choose Verify external close & undeploy. Astral checks that the position is flat and no orders are pending before releasing the deployment; the saved strategy remains.
- If the deployment changed, close the dialog, refresh and review it again. If the request timed out, retry from the same dialog; it repeats the same confirmed request. An unverified close stays blocked.
This recovery does not place a sale. Missing sale prices and fees remain unverified in the strategy's performance history. On releases containing the November 7, 2026 alert update, an alert titled Your broker no longer holds this position (Astral's exit was rejected because the account no longer holds the quantity) points to this step.
A strategy is more than its code
The inspectable rule set is central, but a usable strategy also depends on its assets, bar size, historical range, capital assumptions, data availability, version, and intended execution mode. Two saved records with similar code can produce different results when any of those inputs differ.
Name saved versions so the difference is understandable later. A useful title or description records the market, interval, and major revision instead of only saying “final” or “new.”
Historical, paper, and connected results
| Result source | What it represents | What it cannot prove |
|---|---|---|
| Backtest | A historical simulation over selected data and assumptions. | Future performance or broker fill quality. |
| Astral Paper | Ongoing simulated activity with configured paper capital. | That live orders would fill at the same price or size. |
| Broker connected | Account and order state reported through the connected execution path. | That every value is instantaneous or free from broker restrictions. |
Never splice these sources into one continuous performance claim without labeling the transitions. A paper deployment beginning today does not inherit the backtest’s historical ledger, and a live account can include activity unrelated to one Astral strategy.
Strategy health and lifecycle events
An active label alone is not enough to prove normal operation. Review last evaluation time, current mode, notification profile, paper or broker account, health messages, and any pause reason. Common interruptions include access changes, expired broker authorization, rejected orders, insufficient funds, position-integrity conflicts, or unavailable data.
Daily execution progress
On releases containing the daily-execution progress update, open a deployed strategy's status details to review Last evaluation, Last strategy bar received, and Next evaluation expected. Waiting for data lists assets whose bars have not arrived for a complete evaluation. These details use the same status popup on desktop and mobile web; installed native releases require separate verification. Older deployments can have no progress record yet.
A completed evaluation can produce no trade signal: the rules may require cash, or no entry condition may match. An empty activity log or a single equity point does not, by itself, prove the strategy stopped. Activity events are not a log of every rule check, and a trade signal is not a confirmed fill.
For daily stocks, the expected evaluation follows exchange sessions, including holidays and early closes. Daily crypto bars complete at UTC midnight. A daily evaluation more than five minutes past its expected time is shown as degraded and not ready. Review missing data and contact support if progress remains overdue. A restart or fresh deployment completing warmup does not prove that the next scheduled rebalance will execute.
Historical data recovery rebuilds calculations without placing old missed trades. Execution ownership verification incomplete means Astral could not verify the current execution owner; it does not itself prove corrupt accounting. The deployment remains blocked until ownership and accounting verification succeed. This does not automatically resume a manually or durably paused run.
Recovering order history means Astral is replaying recorded order events after a restart or connection gap. It can appear on a flat Paper deployment and does not itself mean holdings are missing. New entries stay blocked during recovery. Order history recovery incomplete means that recovery failed or exceeded its time limit. Review the strategy's controls and contact support if it stays blocked. Successful replay clears its own hold; a separate position, price-source, or manual pause can still keep the strategy from trading.
Protection recovery
On releases containing the protection-recovery update, Astral blocks additional entries in a strategy and asset when an existing Astral-managed protected position lacks usable certified pricing during its market session. Other assets and strategies keep their own checks. Expected market closures are excluded. The guard leaves exits available, but an exit still needs a usable execution route and price; a stored stop alone does not prove it can currently evaluate.
Fresh certified observations can recover the price-source check. A separate historical gap, accounting mismatch, customer Pause, or subscription restriction can remain. A confirmed execution can also need reconciliation into the strategy's protection records; that recovery uses the recorded fill and does not make a second trade. Clearing that discrepancy does not automatically resume a customer pause or establish that a pending Liquidate & Stop has completed.
Protection on thinly traded crypto pairs
Stop-loss, take-profit and trailing-stop protection on a deployed crypto strategy (Astral Paper or broker-connected) is checked against each new trade in the pair. Some pairs trade only every few minutes. On releases containing the quiet-pair protection update, a quiet pair is not treated as a price-feed failure while Astral's crypto market feed is confirmed connected:
- No protected position: the strategy stays healthy however long the pair goes without trading. A new entry waits until the pair's latest trade is recent enough. How recent depends on how often that pair normally trades, never more than 15 minutes old.
- Protected position open: the latest trade stays the protection price for a limit based on how often the pair normally trades (at most 15 minutes, plus a short grace period). The next trade is checked as soon as it arrives. If the pair stays quiet past that limit, protection reports a failed price feed and the strategy is marked degraded. New entries stay blocked until the pair trades again and several consecutive trades confirm the price.
- Market feed disconnected: the standard price-feed failure workflow applies within a minute or a few minutes, depending on the pair, whether or not it is trading.
After a service restart Astral measures each pair's recent trading from market history, which normally takes about a minute. Until a pair is measured, the standard limits apply: an entry needs a trade from the last 15 seconds, and an open position reports a failed feed after 45 seconds without a trade (a few minutes for some sparse pairs). Stocks, forex and commodities keep their standard limits.
When you deploy a strategy that protects a crypto pair which recently went more than 15 minutes without a trade, Astral shows a warning naming the pair. The strategy still deploys. While it holds that pair, expect occasional degraded notices during quiet stretches and entries that wait for a recent trade.
When you revise a strategy, confirm whether you are editing a draft, saving a new version, or replacing the record associated with a deployment. Do not assume an active deployment automatically adopts changes made elsewhere.
Before deleting anything
Trace the relationships first: private saved record, public publication, Terminal session, backtest, and deployment. Deleting one record may remove a convenient route back to the logic while leaving other records or live broker state intact. Export or record anything you need for audit before removal.