Saved and deployed strategies

In your private Profile → Strategies → Deployed / Saved, strategies use the same table styling as Positions and Orders. Wider profiles align Strategy, P/L, Trades, Win rate and Updated with sortable headings; mobile shows labeled facts and retains Filters → Sort. Search and filters stay within the selected library. Profile rows have no trailing arrow or menu icons. Press a tracked row for strategy details, then use its detail-view actions and deployment controls for eligible Terminal, deployment and publication actions, with their existing review. Signals-only rows open a management view with their supported controls and unavailable-performance explanation. Missing or pending results show —, rather than a confirmed zero. See profile strategy rows for source, timestamp and sorting meanings.

A saved strategy is a reusable version of rules. A backtest is one simulation of a version. A deployment is an operating instance in an available mode. These are separate records and actions.

Saved and deployed lists show the strategy's name. An older record with a missing or blank name is labeled Untitled strategy, including when searching the list, rather than a blank row or internal strategy number. This display fallback does not rename the saved rules or change a deployment. The same naming applies on desktop/mobile web and in Paper/Real money; installed clients can differ by release.

Save a strategy

1. From the current strategy/result, choose Save, or ask the assistant to save the final tested strategy with a specific name.
2. In Save Strategy, enter Strategy Name and an optional Description. The name field allows up to 44 characters.
3. Check the listed assets and choose Save to open Confirm Save.
4. Review the strategy details and choose Confirm Save. Use Edit to correct them, or Cancel to leave the form.
5. Wait for the success state and choose Done. Open Strategies from Terminal's left rail to find it again. A failed save offers retry; do not assume the record exists from the first click alone.

An existing saved strategy can update its saved record. Check its identity before overwriting. To keep the saved version and also save your edited revision, use Save as new copy instead; see Strategy workflow. A description change does not rewrite the strategy's logic; ask the assistant to edit the source for rule changes.

Find and reopen saved work

Open Strategies, use its search/filter controls, and click the strategy's name or row to open its details modal. This applies to Saved and tracked Deployed strategies; alerts-only rows keep their existing controls. ⋮ → Details also opens the modal. To open a chart workspace, choose ⋮ → View in terminal: Saved opens the saved code and any existing backtest results; Deployed opens the tracked deployment's Live view. Opening from Saved does not start a backtest or switch to Live, even if that strategy also has a deployment. If it has no saved result, inspect its code and the existing empty-results state. Viewing code, editing its name/details, deploying and deleting remain available through the existing controls. Deleting never stops a strategy: on the chart (SAVED → DELETE, Remove Saved Strategy), in Strategies, on the Dashboard or through the assistant, a strategy that is deployed stays saved and running, and a Strategy is running notice says "Stop it first, then delete it." On your desktop profile, Private → Strategies opens your own library and Published → Strategies shows your public strategies. An Explore bookmark is a separate library entry, so a private saved strategy need not appear in Explore's Saved list.

Opening Saved replaces the previous workspace's price charts with the strategy's recorded chart targets. Explicitly saved indicators keep their exact asset, interval and immutable version or complete formula. Remaining declared assets open at the saved engine interval, within your chart limits; a recorded chart interval takes priority for an asset that already has a saved target. An empty study list stays empty even when the strategy's price charts open. The app does not reconstruct studies from strategy rules or assign a missing indicator target to the first asset. For a rotating strategy without fixed assets, the app uses actual coins recorded in its saved result: ending/open positions first, then recent trades, then recorded token selections. These price charts use the saved engine interval (or the recorded result interval when needed), preserve exact token identities and respect your chart limit. A screen name is not a coin. If no asset was recorded, the chart area says No asset chart selected; use + to choose one or ask for an exact asset and interval. Opening does not rerun the token screen or backtest, and price history can still be unavailable for a particular coin. Shared-strategy imports retain their own saved-snapshot behavior.

If Saved indicator could not be restored appears, inspect the error. A legacy attachment missing its asset or interval needs an explicit plotting request; it is not automatically reconstructed from the strategy. For an unavailable chart or calculation, retry after that exact chart/data is available. Source, original results and deployment state are unaffected. These boundaries apply on desktop and mobile web in both trading modes.

Review strategy analysis

On desktop, open a tracked strategy's details from Strategies → Deployed, then choose Analysis when its deployment equity history is available. Saved strategies with retained backtest results offer analysis for that saved result. The full Analysis view has four tabs. Native mobile strategy sheets instead use the inline Analytics → Metrics / Charts / Trade log sections described under Mobile strategy sheets. The full Analysis tabs have separate content:

• Returns & risk (Returns on mobile): available portfolio performance and risk metrics, plus Result context with starting/ending portfolio values, the chart time zone and the available evaluation-bar or equity-observation count.
• Trades: trade statistics and consecutive results.
• Charts: time-based entry/P&L charts and holding-time analysis. Chart times use UTC. On mobile, Group by hour/weekday/month changes the entry grouping; Net / Pre-fee and $ / % change the P&L display.
• Trade Log: a separate searchable history of the available position records. In the strategy details modal, the log uses the remaining height; scroll inside the list for more rows. Selecting a chart bar opens matching rows in this tab; selecting a holding-time point highlights its row here. Charts do not repeat in this tab. There is no Run details tab; the useful run information remains in Result context.

In the strategy details modal, scroll inside the Returns, Trades, or Charts content area to reach its lower sections. The top tabs stay visible, including after switching back from Trade Log.

Deployed performance summaries and filled orders do not supply full completed-position history. If no position records are available, Trade history unavailable explains the missing charts and log while the available summary metrics and result context remain. Available position records stay visible without partial-history banners in any tab. These rows and chart totals may cover less history than the summary metrics; the absence of a banner does not establish complete history. Inspect recorded orders in the deployment's details. An order is not necessarily a completed position, and missing history does not mean zero trades or zero profit. No trades recorded yet is reserved for a result with known empty position history. Analysis does not recover missing records by pairing orders or borrowing saved backtest trades.

These analysis views are read-only on desktop and mobile web in both Paper and Real money. Installed clients can differ by release. Opening a tab does not rerun a backtest, submit an order or change a deployment.

Mobile strategy sheets

On mobile web and in the compact browser shell, tapping a Profile strategy name or row opens its detail sheet over Profile. A published strategy attached to a post opens above that post's page. Neither automatically opens Terminal. Explicit View in Terminal or Fork actions still open the editor/conversation.

The return sits above the chart; the strategy identity and Analytics / Feed tabs sit below it. The bottom chart-view control switches between strategy performance and market Candles. Recorded candles keep their result's exact market, interval and history period, with the result's simulated fills marked where available (Simulated fills hides them). Choose Chart market for multi-asset results. Missing periods/history are unavailable rather than replaced with current prices; use Retry candles after a failed read. Replay inspects the recorded result without revising it. Deployment and stop controls keep their existing eligibility, account/mode checks and review. Closing returns to the original page and filters.

In Analytics, choose Metrics, Charts, or Trade log. Metrics includes the performance grid, Risk, Trade results and the Backtest period/portfolio values; deployments use their live period/values instead. Expand Performance details for methodology, metric availability and observation times. Analysis filters sets chart grouping (Hour, Weekday or Month), Net/Pre-fee profit and Dollars/Percent, with entries grouped in UTC. Selecting a chart bar or holding-time point opens the filtered or selected trade in Trade log. Missing individual trade history stays unavailable even if summary figures exist. Switching to Feed and back retains the selected Analytics section. Deployed sheets also show the available execution status and lifecycle events; their performance uses live deployment data, not the saved backtest.

Your saved strategy shows its updated date beneath the name; a deployed strategy shows its execution mode. The equity chart stays mounted when you switch to candles. Open the top-right Open actions menu → Compare a market to add a comparison. For a deployed strategy, the bottom Order History button opens its orders and allocation, even when there are no orders yet; Back to strategy details returns to the same chart. Stop and other lifecycle controls are in Open actions menu, with their existing review and confirmations. Saved strategies retain Deploy in the bottom dock.

Switching between candles and strategy performance brings the chart back into view if you have scrolled into Analytics. A strategy that selects tokens dynamically can use exact markets recorded in its trades or orders, even without a fixed asset list. Recorded backtest candles use the result's bar interval when available; missing history still offers Retry candles rather than substituting current prices.

The chart-view button is hidden when no alternate chart is available. Horizontal swipes do not switch the selected strategy or sheet view. Use the explicit tabs, actions and back controls; close the sheet to choose another strategy. Dragging the sheet down to dismiss it still works.

The compact footer sits above the bottom edge with a fade behind its actions; the candle/performance button has a blurred background. For multi-asset candles, tap Chart market to open a picker sheet. It shows the selected market and exact market IDs. Tap another market to close the picker and load that market's recorded candles; dismissing the picker keeps the current market and strategy sheet open.

Deploy a saved strategy

1. Choose Deploy from its details or completed backtest.
2. Inspect the selected Paper or real wallet/account and the strategy's current source. The workspace trading mode affects new deployments; existing deployments retain their accounts.
3. Set the capital/allocation offered by the form and review available funds beneath the amount. For real-wallet deployments, the disabled action shows Minimum $… until the amount meets the strategy's sizing minimum, then returns to Deploy Strategy when ready. There is no separate minimum hint or Real money tag; Paper retains its Paper indicator. Other invalid amounts and wallet problems still show their relevant messages. Capital assigned elsewhere may not be available here. When the real wallet can't run what the strategy trades, such as a perp while perps strategies are off, a price index like XRPUSD with no on-chain version, or tokens on another network, the form says why under Can't deploy and Deploy Strategy stays disabled, with the same reason Explore shows. In Paper, these checks still happen at confirmation.
4. Select delivery settings if offered. A notifications-only deployment sends signals rather than placing trades.
5. Continue to Confirm Deployment. This single confirmation shows the strategy, mode, capital, notifications, symbols and timeframe, together with a short trading notice and any offered Trading fee and Network fees rows. There is no separate fee-details section or further confirmation step. Edit returns to the amount and notification settings. Opening this review or closing it without confirming submits nothing.
6. Read the action label before confirming: the wallet flow normally uses Confirm Deployment; funding-shortfall variants explicitly describe moving funds or adding money by card and deploying. Other eligible modes may show Confirm Alerts or Confirm Paper. This action submits directly, without another confirmation popup or step. Wait for the deployment status, then inspect it under Strategies. A deployment request or card payment alone is not confirmation that the strategy is running.

You can also ask the assistant in Chat to prepare a deployment, for example "Deploy Canary cbBTC Base with $3.50." It opens this same review with the amount filled in, starting at step 2. The wallet follows the strategy's network: Solana, or your EVM wallet for Base and other EVM chains. The mode is your current Real money or Paper trading mode, which you change in Settings → Wallets. Check them and the amount, then confirm yourself; the assistant cannot confirm, choose the wallet or switch the mode. It does not open a review for a strategy that is already deployed; manage that one from Dashboard. Closing the review before you confirm deploys nothing.

Coins on the real wallet and the $1 minimum

A strategy built on a coin's price trades that coin on your real wallet: a Solana (SOL) strategy buys and sells SOL itself with USDC, a Bitcoin (BTC) strategy buys and sells cbBTC, Coinbase's wrapped Bitcoin, and an Ether (ETH) strategy buys and sells whETH, Wormhole's wrapped Ether on Solana. A strategy trades on one network: when its other tokens are on Base, BTC trades as cbBTC on Base and ETH as WETH on Base (SOL trades on Solana only). You don't choose a token; the strategy's chart, signals and backtests keep using the coin's price. Astral pays the network fee on these trades, so a SOL strategy needs only USDC to deploy, and its position is exactly the SOL it bought. Stop-loss and take-profit on these strategies trigger on the price the coin actually trades at on-chain (SOL, cbBTC, whETH or WETH), which can differ slightly from the coin's price index the strategy reads. New buys of cbBTC, whETH or WETH pause while the token trades more than 1% away from the coin's price; selling stays available. Paper runs SOL, BTC and ETH strategies too, filling at the coin's price.

Solana doesn't let a wallet keep a balance between 0 and 0.00065 SOL. When a SOL strategy's sale would leave less than that, it sells all of the strategy's SOL where it can; otherwise, for example when the rest is your own SOL, the sale is skipped and the strategy shows "The last SOL sale was skipped because it would have left less than 0.00065 SOL in your wallet…". Adding a little SOL to your wallet lets the next sale go through.

Coins the wallet has no strategy version of yet, such as XRP or Cardano, can't run on the real wallet or in Paper. On the real wallet, the deploy form says so before you continue, for example "Trades XRPUSD, a price index with no on-chain version the Astral Wallet can trade.", and Deploy Strategy stays disabled. In Paper, deploying one stops at Confirm Deployment with "XRP strategies can't run in Paper yet." You can still backtest them. The assistant tells you this when it builds such a strategy, explains why, and offers to use an on-chain token for that coin instead, if one trades; it keeps the coin you asked for unless you agree.

Each strategy buy on the real wallet must be at least $1. The disabled action in Deploy Strategy shows the smallest amount your strategy's sizing needs, with 10% extra so fees from the first buys don't push later buys under $1: a strategy that buys 2% of its money each time needs at least $55, not $50. Enter at least that amount to continue to Confirm Deployment. If losses later shrink a buy below $1, that buy is skipped and the strategy shows "The last trade was below the $1 minimum."

Confirm and monitor in Terminal

After a confirmed deployment from a backtest in the current Terminal session, the existing flow opens that deployment's Live view without starting another run. The chart has a compact Live / Backtest toggle. On desktop, hover Live for the strategy name, Paper · Simulated money, Real money, or an unconfirmed account mode; the same details are available to screen readers. On touch, open the deployment's details under Strategies → Deployed. Broker-mode execution alone does not establish real money: Paper wallets can use that execution mode too. If you changed sessions during submission, inspect Strategies → Deployed instead of assuming the new chat is the deployed view. A failed live-data connection is not a failed deployment or a reason to submit it again.

On the Dashboard, in Strategies → Deployed, click the strategy's name or its row to open its details modal, or use ⋮ → Details; in the Terminal's Strategies panel the name or row opens the Live workspace instead. Choose ⋮ → View in terminal to open the existing Live chart workspace. In the details modal, Edit and ⋮ → View in terminal close the modal and open that deployment's Live view; they never load it into the chat you already had open. These shortcuts apply to deployments with tracked performance; alerts-only rows keep their existing controls. On desktop, opening or switching chart workspaces preserves your Chat sidebar state. Use the existing Chat panel toggle to collapse or reopen it yourself. On mobile web, View in terminal opens the fullscreen strategy chart.

Returning to the same deployment reopens its last monitoring session recorded in this browser for the signed-in user and strategy run, after checking that the session still belongs to that strategy. The normal session restore brings back its saved charts, intervals and recorded chart attachments; it does not infer studies from strategy rules. A session repurposed for another strategy is left intact and a fresh monitoring workspace opens instead. Missing live charts are initialized again. A different browser, cleared browser storage or a new strategy run can need a fresh workspace. If session restoration fails, use its displayed recovery controls; the app does not silently discard the saved workspace and replace it.

Monitoring shortcuts recorded before the chart-restoration fix initialize a clean Live workspace once. Their original server sessions remain available in chat history.

A fresh workspace picks charts once: open positions first, then the most recently traded assets, then the assets named in the strategy and its saved chart targets, up to five charts or your plan's chart limit if that is lower. Saved targets keep their recorded intervals and studies; new position assets use the deployment's engine interval. If a rotating deployment has no current positions, fills or fixed chart targets, recorded coins from its saved backtest provide price-chart context; those charts are not evidence of current holdings. The first actual live position or fill replaces that fallback once. If there is no recorded coin either, Waiting for the first position appears inside the price-chart area until the first asset is recorded. Later trades do not rearrange the chosen charts. Add, remove or change charts as usual. Opening the deployment does not pause, resume or change it. Use Publish in the Live view to share the strategy, as from Dashboard → Publish.

Hover Live to read the deployment status: Starting strategy…, Connecting to live data…, Monitoring for the next signal, Active · trading blocked, Paused, or a waiting/unavailable state. A confirmed deployment does not mean warmup, trade readiness or its first fill has completed. Starting strategy… counts warmup bars loaded of those needed, such as 0 / 26 bars. While the strategy is active, the status also gives the last price bar its run recorded, or no price bar received yet during warmup. A last price bar well behind the current time means live data for the strategy has stopped: warmup cannot finish and no new signal is evaluated until data resumes. A strategy on a quiet on-chain token warms up from the token's most recent traded minutes, looking back up to a week. If the token hasn't traded that often, the status shows Waiting for price history with the traded bars found so far, such as 41 / 220 bars. The strategy checks again every 10 minutes and starts by itself once there are enough; it places no orders while it waits. In Strategies → Deployed, such a strategy shows Waiting for price history instead of Active, and an active strategy whose trading is blocked shows Needs attention. Blocked states show their recorded reason; missing performance remains unavailable, not a zero return. You can also ask the assistant why a deployed strategy hasn't traded; it reads the same warmup progress, last price bar, health and blocking reasons. When live data is unavailable, Reconnect appears with the error in the performance chart and retries data, not deployment. Live / Backtest switches between the deployment's live view and the backtest saved with the strategy, however you opened it (Strategies, View in terminal, a link or the chat it was deployed from); Backtest is disabled only when the strategy has no saved backtest. Switching does not resume or redeploy a strategy. Asking the assistant to build, edit or backtest a strategy in that chat leaves the live view, so the Backtest tab shows the new work; the deployment keeps running and stays under Strategies → Deployed. If the strategy is undeployed while its live view is open, the view closes with a notice.

The Live view's performance history and metrics are recorded at each completed bar of the strategy's interval, such as every minute for a 1m strategy, and include open positions at that bar's closing price. The performance chart has one point per completed bar. A trade the strategy places at a bar close appears at that close, including its fill price and fees, even though it fills a few seconds later; a take-profit or stop-loss fill, a liquidation that keeps the strategy deployed, or a transfer appears with the next bar close. The chart starts at the deployment time; after Stop it ends at the stop time with the final value. Between bar closes, open positions are re-priced from the live price: Earnings and Total return move with the price, without a small Live badge beside the values, and the Allocation bar shows Open P&L, the open positions' gain or loss against their entry price. Hover a position in the bar for its own Open P&L and whether it is priced at the Live price or the Last bar close (used when no live price is available). These live figures are provisional: the next bar close records the stored value, which can differ slightly. The Deployed list, your profile's deployed rows and strategy details also include live estimates without a small Live badge when tracked accounting and fresh quotes are available. Quotes expire after 15 seconds without another update and clear on a connection, account or saved-snapshot change; recorded values are used until the next fresh quote. The performance chart, drawdown, Sharpe and other ratios keep stored bar values. Trades counts filled buy/sell orders, including both entries and exits. Pending and canceled orders are excluded. Win rate and Mean position P&L continue to use the server's completed-position population. The strategy list's headline Return is a percentage and sorts by percentage. Historical selections keep historical metrics.

The Pause button, with its small two-bar pause icon and visible label, sits in the performance chart’s top-left action group while the Live view is shown: it reads the deployment's current controls, asks you to confirm, and then shows Paused once the pause is confirmed. Resume, stop and liquidation stay under Strategies → Deployed, which also offers Pause, using the deployment's available controls and confirmation. The toggle itself only switches the performance view. Pause blocks new entries and requests cancellation of pending entry orders while the strategy stays deployed and existing positions, exits and protection remain managed. It does not liquidate holdings or undo transactions already submitted. If an action's result is uncertain, check the deployment's current state before requesting it again. These boundaries apply on desktop/mobile web and for Paper/real deployments; installed native clients can differ until updated.

If a mode is absent, check the strategy's assets, account permissions, current capabilities and displayed error. Current wallet-first navigation does not offer new brokerage onboarding. A backtest or published strategy may use a market that the current account cannot execute.

Inspect the test window, methodology, completed positions and commission/slippage assumptions in the backtest results before deploying. The deployment review keeps these separate from the deployment details and does not repeat a Backtest evidence block. A short sample, missing evidence or zero simulated costs does not establish reliable performance or real trading costs. Compare the results with the actual trading terms in the Confirm Deployment review. Desktop and mobile web use this same review flow in Paper and real-wallet modes.

Price-feed warnings and recovery

For an Onchain deployment, Waiting for this token's price feed means the price source needed for protection is unavailable, automatic recovery is pending, and no held position is affected for that token. This is a warning in the app, with no email or SMS; its matching recovery also stays in-app. The assistant's automatic activity review stays quiet for this routine warning. A token trading infrequently alone does not establish a feed failure.

Open Strategies → Deployed and inspect the affected strategy's status and recorded reason. When protection-feed checks are enforced, affected new entries wait for the source. In a monitoring-only configuration, the warning alone does not block entries; use the deployment's current readiness state rather than assuming it is paused. Astral rechecks the source automatically, and every other enforced readiness check still applies. Repeatedly redeploying, adding funds or dismissing the notification does not repair the feed. If the warning persists or the details say action is required, contact support with the strategy, token and event time.

If a held position's protection is affected, holdings are unknown, or recovery requires an operator, the event remains critical and can use configured email/SMS channels. A later held-position failure is not muted just because an earlier empty-position warning was quiet. Read the actual event and holdings; a recovery message is not proof that an order filled or that every protection issue is cleared. Older notifications can retain the classification recorded when they were created, so check their event time and current strategy status.

These server-side rules apply to eligible Paper and Real money deployments on desktop and mobile web. Paper uses simulated positions; it does not establish real-wallet execution. Installed clients can display different wording until updated. See Alerts & Notifications for delivery context.

Return from a deployment to a draft

When you ask the assistant to build, edit or backtest the current chat's draft, Terminal switches its source, result and Save/Deploy controls to that draft together. This also applies when you reopen a deployment's workspace and rerun a draft without editing it. The previous strategy's Saved or Deployed state does not belong to the draft. The draft view is remembered for a normal reload of that chat; reopening the deployment explicitly still opens its monitoring view. These display changes do not pause, stop or alter the deployment in Paper or Real money.

On desktop, a completed chat run's Results card selects that exact result and leaves the previous deployment view. An older run remains inspectable without borrowing a newer draft's source or action controls. On mobile, Results opens the separate recorded-results view; Back to chat closes it. Asking to build or rerun the draft switches the mobile Terminal's source and controls too. Installed clients can differ until updated.

The deployment's Live / Backtest toggle is different: it keeps the deployment selected and shows its own saved backtest. Late results from another chat and restoration of background work do not change an intentionally selected saved view. If Could not remember this view appears, the draft is open but reloading may restore the saved view; reconnect, then run or edit the draft again before reloading.

Strategies with independent trades and token screens

Independent-trade strategies track each entry's own quantity and exit rules, even when multiple trades hold the same token. They can deploy to eligible real wallets/brokers as well as Paper; stored token screens and stored-data inputs are not paper-only either. Select the workspace mode before deploying and review the account and capital in Confirm Deployment on desktop or mobile.

Account permissions, funding and asset/provider compatibility still apply. Real dynamic-token screens currently execute Solana tokens; Paper can simulate stored spot tokens on other supported chains. Independent trades use long spot positions and bars of one minute or longer. Dynamic perpetual screens remain backtest-only.

A trade's exit requests only its remaining filled quantity, including when another trade owns a small balance of the same token. It does not sweep that other balance to meet a minimum sale. Token precision, minimum sizes and available liquidity can leave a remainder unsold. A rejected or expired exit is not a completed sale: the exit condition stays latched and the remaining quantity can be retried. A rejected entry releases its slot; a new entry still follows the strategy's entry-trigger rules.

Protection starts from each trade's confirmed entry fills. Targets calculated on entry fill do not imply tick-by-tick monitoring: trade-rule protection evaluates completed bars, with closed one-minute observations between longer decisions where supported. These are not resting broker orders. While an entry or exit swap is still being placed, the trade waits for its result before acting again. A submitted order or an armed target is not proof of an exit fill.

After an interruption, Astral reconciles saved trade ownership, protection state and confirmed order outcomes before resuming. A matching holding balance alone does not establish that protection is active. Missing protection or trailing-stop history is not rebuilt from a current price; trade-rule execution stays held until the saved protection and ownership can be reconciled. Check the strategy's orders and holdings and contact support before resuming; do not clear the hold just because balances match.

Confirmed strategy liquidation sales reduce those same trade quantities and protection lots. Liquidate & Stop is complete only after the positions are confirmed flat and the strategy is undeployed. These execution rules apply across desktop and mobile; Paper results do not establish that a real-wallet exit has completed.

If you see Instance-managed trade rules deploy to Astral Paper, that backend is still enforcing the earlier paper-only restriction. Retrying the same request will not change it; the updated backend must be released first. Other deployment errors can still identify an unsupported asset, account or execution route.

For eligible real-wallet deployments, Astral uses available funds on the strategy's execution network and funds only its shortfall from other eligible Cash. Preparing cash… shows while funding is underway. It checks the credited balance again before allocating capital and starting the deployment. Later strategy signals use its local allocation. Where durable funding is enabled, interrupted transfers can be resumed from Cash; after closing the deployment flow, return and review deployment again. A completed funding operation alone does not mean the strategy is running. Hyperliquid strategy capital has separate requirements; spot-wallet deployment funding does not establish perps strategy support.

Recover a reviewed Base deployment

When the separately gated flow is offered for an existing saved Base strategy, Confirm cash funding also names the strategy, allocation and notification channels. Review Maximum Cash used, funding cost and the individual routes before Confirm funding. For automatic funding, current bounded permissions avoid another owner-permission signature; setup or renewal still requires explicit consent. Relay routes can still request transfer signatures. The deployment request stays bound to that strategy revision, wallet account and allocation for 15 minutes.

While the deployment screen stays open, Astral waits for verified funding and repeats normal deployment checks before allocating cash and creating the run. Terminal submits that same reviewed request, not a separate deployment after the funds arrive. Retrying after a lost response keeps the original review and returns its deployment receipt; an unavailable or expired review does not silently save a replacement strategy or start another run. If you close it, transfers can finish; activation waits for an explicit action. In Cash, Ready to deploy → Deploy strategy resumes the original reviewed request. Verify completion under Strategies. These review-identity boundaries apply on desktop and mobile web; they do not enable this gated flow for other accounts or modes.

Cancel deployment stops a reviewed request that has not deployed. Confirmed transfers can still finish. Unlike a bound manual buy, deployment funding leaves arrived cash unassigned and available until allocation succeeds; another spend can make the deployment underfunded. A changed strategy, expired or canceled review, account restriction, changed trading mode or failed admission requires another review. Arrived cash stays in the wallet. This recovery is for existing saved Base strategies; other networks, publication copies and conditional orders retain their displayed flow. It does not enable Hyperliquid strategies.

Solana token balance checks

Real-money Solana strategies verify wallet token balances, including a balance of zero, before trading a token for the first time. You do not need to buy that token manually first. This check records custody; existing holdings are not assigned to the strategy. Static strategy tokens are prepared during deployment. An already-running strategy or a newly selected token repeats missing setup before an eligible fresh signal is admitted.

If the Solana network can't confirm those balances while you deploy, Deployment failed says your wallet's token balances couldn't be confirmed and the strategy wasn't deployed. No strategy run or allocation is created; deploy again. If it says the balances couldn't be verified and that keeps happening, report it rather than redeploying repeatedly.

If a signal cannot become an order, inspect Active · trading blocked and its recorded reason in the Live view. A completed warmup or allocated cash does not prove a trade was submitted. A wallet-token balance verification failure requires a successful blockchain check; adding funds, waiting for more warmup bars, or buying the token manually is not its prescribed recovery. Astral retries eligible signals through the normal checks. Canceled and expired signals stay canceled or expired, and a fresh admitted trade clears only this admission warning. Other funding, data, protection and pause checks still apply.

These checks apply to real Solana wallet strategies on desktop and mobile web. Paper simulation does not establish a real-wallet fill. Installed clients can display different status wording until updated. This describes the matched release; see Troubleshooting if your release still shows ready after a failed trade.

Solana deployment fees and gas

The shared Solana fee policy is development-only and rollout-controlled. Only when the Confirm Deployment review actually displays this policy does a new strategy use 0.5% with a $0.02 quote-time minimum on each ordinary successful buy or sell. The review shows Trading fee and Network fees beside the deployment summary. Rates round up to 0.01% steps; the sell fee follows actual proceeds. See the order fee examples.

The reduced minimum for eligible low-value manual full-position market sells does not change automated strategy fees or authorize selling strategy-owned tokens from the manual ticket.

This schedule is pinned to the new deployment. Each strategy order receives its rate and bounded gas allowance when quoted, without prompting for each signal. Astral pays eligible network fees and new deployment funding allocates only USDC, not a separate SOL reserve. The strategy still spends only its own allocated assets. Account-deposit allowances, funding ownership, asset eligibility and protection-readiness checks remain in effect. A buy can be refused when the allowance for new token accounts is used up.

An unavailable sponsor, stale fee-price reference or unaffordable network bid can delay an ordinary order until its deadline; it does not authorize additional fees, greater slippage or execution of a stale signal. Protective exits retain their separately approved fees and safety budgets. No minimum fee guarantees profit or a fill in all network conditions.

Existing deployments keep their earlier terms and may still require SOL. Pausing/resuming does not silently adopt the new schedule or transfer its old reserve away. A new policy requires a new reviewed deployment. If pricing changes before confirmation completes, review the updated schedule and confirm again; the server checks the reviewed version before allocation. Paper, EVM, perps and historical backtest cost assumptions are unchanged: compare the backtest results with the displayed live fee schedule. Desktop and mobile use the same single confirmation review.

Stop, pause or remove a strategy

Open Strategies → Deployed, choose Undeploy from the strategy's Open actions menu, and read the review carefully. Astral picks the review from the deployment's current positions:

• Stop & Undeploy is offered when the deployment has no open positions, including one that never traded. Confirm Stop; the saved strategy remains available.
• Liquidate & Stop blocks new entries and attempts protected exits of strategy-owned positions. It stays deployed until flatness is confirmed, then undeploys. Follow the progress and inspect remaining positions/orders if an exit fails or remains pending.
• Pause/resume controls, where offered, affect processing according to their confirmation. They are not a promise that all positions close.
• Delete removes the selected saved record after confirmation and can be blocked by dependencies. A strategy that is still deployed is never stopped by Delete: it is refused with Strategy is running ("Stop it first, then delete it") and keeps running. Stop it as above, then delete it. Removing a library entry or bookmark is not a liquidation.
• Publications follow the deployment. If you published the strategy, deleting it unpublishes it, and so does its deployment ending (your Stop, Liquidate & Stop finishing, or Astral or staff stopping it) once nothing of it is still deployed. Its public page and Explore listing go away, as with Unpublish. People who bought in are sold out when the deployment stops, as before. A published strategy you never deployed stays published; to share it again after a stop, publish it again.

An exit filling does not immediately finish Liquidate & Stop: the operation can remain in progress while Astral checks remaining holdings and orders. Follow that same stop request until completion is confirmed, rather than starting another sale because a fill arrived first. This applies to Paper and real deployments on desktop and mobile web.

The stop action is state-dependent. Do not describe every stop as “leave positions open” or every removal as “sell everything.” Other manual holdings and independently working orders must be checked separately.

Both reviews confirm with Stop. Astral has no option to stop a deployment and keep its positions; the one exception is a wallet token that can't be sold (see When a wallet token can't be sold). To keep holding them under the strategy's management, use Pause, which blocks new entries and keeps exits and protection running.

When a wallet token can't be sold

On an Astral Wallet deployment that trades Solana tokens, Liquidate & Stop sells each token through a supported trading route. A token can become unsellable after the strategy bought it in two ways:

• No supported route: for example, the pool it was bought through loses its liquidity and its only remaining pool is one Astral does not trade yet, such as a PumpSwap pool with holder rewards.
• Worth less than the minimum fee: when the deployment uses the shared Solana fee policy, each strategy sale has a $0.02 minimum fee. When the whole position would sell for that or less (for example, a token that has fallen more than 99%), Astral does not place the sale.

Astral tries a failed sale up to three times. When a sale fails for either reason, the stop leaves that token in your wallet as your own holding and finishes: nothing is sold, the strategy records the position as closed with no proceeds, and the rest of the stop continues as usual. The stop confirmation says the strategy stopped and that a token was left in your wallet, and you also receive a notification. The tokens then show in your wallet like any other holding, and you can sell them yourself later if a supported route appears. A low-value holding can often be sold right away with a Market, 100% sell, which has a much smaller minimum fee (see Sell or close a spot holding).

• A position with its own stop-loss or take-profit is not released this way. Its stop stays in progress, and Astral notifies you if completion is not confirmed within an hour.
• If every attempt fails for another reason, the stop reports that it failed. Choose Stop again to retry.
• Paper deployments and other wallet networks are unchanged.

A stop that takes longer than the dialog waits can still finish in the background. If the dialog closes before confirming, check the strategy's status and choose Stop again to remove a deployment that has finished liquidating.

Ask the assistant to stop a strategy

In Terminal chat, ask the assistant to stop a deployed strategy by name. It opens the same review as Strategies → Deployed on your screen, picked from the deployment's current positions: Stop & Undeploy when it holds nothing, including one that never traded, or Liquidate & Stop when it holds positions, which sells them through protected exits. Nothing changes until you choose Stop; Cancel leaves the strategy running, and the assistant can't confirm for you.

If you ask to stop a strategy but keep its tokens, the assistant explains that Astral has no such option before opening anything, and suggests Pause to keep the positions managed. It opens the Liquidate & Stop review only if you still want to stop. The review opens in your open Terminal on web; installed native clients can differ until updated.

Full-position exits and Kraken dust

For an exit intended to sell the whole position, use a full-position close action. A sell sized as a percentage of strategy equity remains a partial, dollar-sized sell. Review the exit before redeploying; deployment does not rewrite its sizing rules.

The October 20, 2026 production hotfix supports eligible existing funded Kraken/SnapTrade deployments. After a full-position close with an actual exit fill, Astral can release a verified USD-quoted crypto remainder worth at most $0.10 from strategy management. It first checks holdings, orders, ownership and a fresh price. The coin remains in the broker account as an unmanaged holding; no additional sale is invented. Larger, unsupported or unverified remainders can still block completion.

Recover after selling directly at a legacy broker

For an eligible real broker-executed deployment that is paused or liquidating, the stop dialog can show I already sold this position at my broker. This is not offered for Paper or ordinary wallet deployments.

1. Expand that section only after you have sold the position directly at the broker.
2. Read the explanation and check I confirm I sold the position directly at my broker and want to undeploy this strategy.
3. 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.
4. If the deployment changed, close the dialog, refresh and review it again. If the request timed out, the original dialog can retry the same confirmed request. An unverified close remains blocked.

Missing sale prices and fees remain unverified in performance history. This recovery does not place a sale or make new brokerage onboarding available.

Saved work

Keep meaningful names and notes for token identity, interval and assumptions. Save a version before changing rules. Check that an imported or community strategy uses supported on-chain assets and data.

Deployment

Review the modes available to your account and strategy. Paper uses simulated funds; eligible live activity requires a supported account and authorization. Verify allocation and permissions before confirming.

Ongoing activity

Inspect the latest state and events. Different views can reflect different timestamps or sources. Do not infer a confirmed transaction solely from a notification or chart marker.

Funded deployment equity is maintained independently of viewing the chart or running new rules. Pausing evaluation can leave positions exposed, so their value can still change. Cash-only deployments need no trade to build history. See Dashboard and monitoring for saved history, corrections, timestamps and recovery states.

Removing or stopping

Check dependencies before deleting saved work. Liquidate & Stop attempts exits but is not complete until flatness and undeployment are confirmed. Check other holdings, orders and wallet permissions independently.

See Strategy workflow and Plans and limits.