Ballast · invited beta

Ballast trading logic

0.4.23-beta: runner profit lock (Trade rules version 2)

Reviewed per mode in System (Trade rules, version 2). A mode that accepted the 0.4.20 rules (version 1) keeps them unchanged until it accepts version 2.

• Profit lock (volatility runners only). With c the average cost when the

runner armed (captured cost_px) and peak the highest price seen, the lock floor is c + 0.5 × (peak − c) (RUNNER_LOCK_SHARE). It only rises and is not shown while the peak is at or below cost.

• Tightening trail. Peak gain g = (peak / c − 1) × 100. The trail in use

is min(captured trail, max(1.5, 0.5 × g)) (RUNNER_MIN_TRAIL_PCT, RUNNER_TRAIL_GAIN_SHARE).

• Stop. max(previous stop, captured floor, lock floor, peak × (1 − trail/100));

it never falls. Worked example (synthetic, from the 2026-09-30 report): cost 0.26421, peak 0.27706, captured trail 9.15% → trail 2.43%, lock 0.270635, stop about 2.4% above cost where the version 1 stop stayed at the 0.26554 floor.

• Scope. Accepting version 2 extends the lock to every volatility runner of

that mode, including runners armed under version 1; a runner that has used the lock records its terms and keeps them. Consolidation runners are unchanged. A market sale can fill below the line; a tighter line can exit before a renewed rally.

• Accepting can sell at the next cycle. The new line is computed from the

persisted peak, so a runner whose price is already at or below it is sold at the next cycle (cost 100, peak 110, price 104: 100.5 → 105). crypto_runner.acceptance_preview lists each armed runner's line now/after and a would-sell flag (read-only, latest snapshot bid) in System and the update window before acceptance.

• Rollback. 0.4.22 reads only version 1 as accepted, so rolling back after

accepting version 2 returns that mode to the pre-0.4.20 rules until 0.4.22's rules are accepted again. Captured runner stops stay (they only rise).

Also in 0.4.23: the loss-limit skip note names the positions without a live price (after hours, stock trades waiting for the market are named as such), and the Core sleeve skips quietly while a LIVE Core buy for the current account awaits its broker check (one warning alert once the hold is older than a day). The loss limit still is not evaluated while any open position lacks a live price, which after hours includes every open stock Trade; stops and exits keep running.

0.4.22-beta: the Agentic account is the capital

LIVE capital (anchor.account_total) = Agentic cash + stock positions + stock Core + parked anchor. Crypto (bought with individual-account funds) is excluded. state.crypto_backing_usd = max(crypto buys − sells, cost of crypto still held) + crypto buys awaiting a fill. state.agentic_free subtracts it from cash and buying power for every buyer (entries, Core sleeve, T-bill parking), so that Agentic cash stays as cash. Paper mode is unchanged (its cash pool pays for crypto).

0.4.20-beta: per-trade Core keep, volatility runners and trade-owned sales

Reviewed per mode in System (Trade rules). Until accepted, the 0.4.19 rules below apply unchanged.

• Retention (crypto Trade positions). Acceptance requires the mode's

enabled conviction policy. A confirmed profitable sale adds k × (sold × (fill − average cost) − fees) to the position's retention budget, and the budget is retained as Core, where k is the position's captured conviction share (or the mode's enabled percentage for older positions), capped at (100 − TAX_RESERVE_PCT)%. Stock positions and positions that captured the opt-in v1 retention policy keep their rule. The retained quantity is that value divided by the fill price, further bounded by the unsold remainder and CORE_KEEP_MAX_PCT of the position. There is no account-wide profit-pool gate. Stops, losing sales, partial and clamped fills retain nothing.

• Runner. At the first scale-out, a crypto position captures a volatility

profile: trail clamp(ATR × 1.0, 3%, 10%) from the peak, floor average cost × 1.005. The runner sells at max(floor, peak × (1 − trail)); the stop only rises. The peak-age profit stop and the return-to-target floor do not apply to this runner. Hard stops and owner closes do.

• Sale bound (always, since 0.4.20). A live crypto sale is at most

min(position buys − position sells − Core retained from the position, symbol ledger − Core, broker balance − Core). Owner reserves are retired.

0.4.19-beta: reviewed capital sharing and conviction Core

The optional conviction policy is saved separately for PAPER and LIVE. Until accepted in a mode, its existing entry allocation and retained-asset rules continue. After acceptance, the crypto engine checks each coin's entry rules independently, then shares the permitted cash/exposure budget among qualifying coins. Relative dip depth measured against the coin's ATR and spread changes weights by a bounded amount. It is a priority estimate, not a return forecast. One eligible coin can use its allowed room. Existing durable order holds still block repeat execution; this policy does not alter exit checks or stop-loss cooldowns. A profit exit can be followed by a new qualifying dip entry in the same cycle.

For positions opened after review, the engine captures the conviction score and the operator's saved multiplier of the otherwise allowed profit-funded retained-asset share. Sample settings are 0%, 0%, 20%, 50%, 75% for one through five stars. The values can be edited in System, independently by mode. Existing positions retain their captured policy. The separate configured after-tax net realized-profit allocation to the Core sleeve remains in effect when positive; losses may offset gains. A low-conviction asset can send cash profit to that sleeve while retaining no units of that traded asset. Core sleeve purchases may wait for minimum amounts and market conditions. Trading principal, unconfirmed fills and losing trades do not fund retained asset units. The operator must review a positive Core cash setting before enabling the new policy. AI output can propose settings but cannot save them.

This document describes the configured engine behavior. It does not recommend assets or settings. Shipped settings are labeled SAMPLE CONFIGURATION; inspect the saved values and capital plan in System before activation.

See GUIDE.md (GUIDE.md) for operation and ARCHITECTURE.md (ARCHITECTURE.md) for the code layout. Local rules depend on a running process, usable data and broker access. A planned order or a displayed threshold is not a guaranteed fill.

0.4.15-beta Core and trade settlement repair

Core inventory documents exact rounded-fill settlement, protected retained units, terminal dust, revision-bound crypto close requests, and historical-repair limits. Equity hard stops precede armed profit targets; this repairs exit precedence without introducing a new stop width or runner policy. Crypto market data documents the HYPE alias, explicit data blockers, mode-separated references and broker-priced exits during a chart outage. These source changes are not installed or published.

Consolidation-aware crypto runners (0.4.2)

System offers explicit versioned acceptance separately for paper and live mode. The first-sale percentage and hard stop remain. An unarmed position must be at least 48 hours old and collect 12 observed hours within one ATR below target and above average cost during the previous 72 hours. Observations start upon enabling. Gaps over ten minutes earn no time; cost/target changes reset evidence. Existing classic runners are never loosened retroactively.

A qualified target crossing captures 1x ATR, rising linearly to 2x at 48 observed hours, capped at 10%. The remaining runner uses a floor 0.5% above average cost; its stop is the maximum of that floor, its previous stop and peak minus captured width. Target floor, peak-age squeeze and confirmed-top shortcut no longer override this qualified policy. Hard stops and manual exits retain precedence. Without qualification the classic policy applies. The daily-bar backtest does not model this observation-dependent rule. No improvement in returns is claimed.

Crypto confirmations and historical repair (0.4.2)

Submission retains the v1 route and existing execution account. V2 order/holdings reads name that same account explicitly. Confirmation requires exact broker ID, client reference, symbol, side and account plus finite terminal execution details. Crypto ledger settlement is atomic; uncertainty stays visible on the Bot page and blocks duplicate orders. Legacy settling holds still need manual review. Historical estimate correction is a separate maintenance action using exact execution proof, complete local links, a verified backup and stale-plan rejection. Ambiguous ownership is never guessed. Installing does not rewrite history.

Accounts, sessions and price references

Equities use the selected Robinhood Agentic account. Crypto uses separate Robinhood Crypto credentials and the associated individual crypto account. An equity account selection does not select or restrict the crypto account. Finance can display additional accounts for review.

The main equity cycle's regular-session check is weekdays, 09:30–16:00 Eastern. It does not implement a complete exchange-holiday calendar. The out-of-session path evaluates enabled crypto and can refresh equity marks or record deferred equity entry candidates. An overnight quote does not mean the engine places equity orders around the clock. Broker eligibility and session restrictions still apply.

The engine uses recorded prices near a rolling 24-hour reference where available. Source day-change values or other fallback references may be used when sufficient local history is missing. It is not always an observation exactly 24 hours old. Inspect quote timestamps and decision details.

Entry rules

Optional core target allocation (schema 1)

Finance's core target editor stores separate PAPER/LIVE plans. Existing installs retain the previous yield-biased selection until explicit mode-specific acceptance. Settings schema 3 creates no target policy automatically. Equity targets must sum to 100%, with at most 20 tickers and two decimal places. Core crypto allocation is not supported by this equity-sleeve editor.

Within the existing authorized core budget, the selector computes each asset's dollar deficit against its target share of selected sleeve value plus that budget. It buys the largest deficit, capped by the deficit and rounded down to cents. Sub-dollar deficits defer. Price movement and incremental purchases mean actual weights can differ from targets. This replaces yield-biased selection only for an accepted plan; funding, reserves, daily limits and exposure caps still apply.

No balancing sales occur. Removed/zero-target holdings remain, consuming the core ceiling; the calculation concerns the bot's mode-specific core ledger, not all connected-account holdings. Missing/non-finite prices for any selected or retained core asset block new core purchases rather than redistribute weights. Invalid policy versions block core buys; existing exits remain available. The capital-plan review hash includes the policy so a target change invalidates a prior review.

Restoring the previous method is explicit and mode-specific. It removes that mode's target policy, not positions or trades, and resumes the shared core symbol list and existing yield-selection rules. Asset settings do not constitute ticker verification, a backtest or optimization.

A watchlist symbol's tier chooses a configuration group for dip triggers, take-profit levels and related management rules. Tiers are not quality or safety ratings. Conviction is an operator input that can change priority and size, not evidence of suitability.

Entry planning considers the price-change trigger, available position slots, per-name and allocation limits, cash/reserve requirements, order limits, spread/chase/cooldown checks and other configured gates. Additional legs and pyramiding have their own conditions. Equity and crypto positions have separate asset-specific limits, while shared funding and daily-buy controls can still constrain both.

Deferred equity candidates recorded outside the regular session must pass their expiry and price checks as well as current entry gates. A stored candidate is not a promise of an order at the next open.

Regime, sizing and entry judgment

Market-regime, trend, volatility and conviction inputs can adjust configured entry thresholds, leg sizes and exit parameters. These are rule inputs; their labels do not establish future market direction or protect against all adverse moves.

The entry news-judgment function can return proceed or skip. It does not choose the trading account or override deterministic size limits. Configured rule-only symbols do not request paid AI judgment. Other covered live entries require a usable paid judgment result; a missing key, exhausted or unavailable autonomous budget, or request failure skips those entries. Paper mode without a key can skip the judgment step.

The current LIVE activation separately requires an Anthropic API key. Optional research also consumes API usage. Review recorded usage estimates and autonomous budget controls; there is no fixed cost per day or per trade.

Exits, partial sales and retained core

Partial profit exits and retained core holdings are deliberate strategy features. Their behavior depends on the current scale-out, keep, activation and exit settings; there is no universal one-third keep or fixed exit fraction.

A position may sell an initial tranche at its configured target, leave a managed remainder with a floor/trailing rule, and retain a configured quantity in the core ledger. Hard-stop, time-based and operator-close paths have different conditions. Core retention and an actively managed remainder are different states; inspect the position and core records when reviewing them.

Trailing rules can follow recorded peaks and tighten with elapsed time or regime changes. A floor is an order-decision threshold, not a guarantee that an eventual fill occurs there. Gaps, spreads, unavailable quotes, rejected orders or a stopped process can prevent the intended outcome.

The entry order cap does not cap protective exits. Minimum-net-profit checks apply to relevant profit-taking paths; stop and operator-close paths can bypass those checks. That makes them eligible for submission, not guaranteed to execute. A dashboard close request is processed by a subsequent eligible cycle rather than synchronously closing the broker position.

Crypto ownership and reserves

Crypto may share its connected account with holdings outside the bot's strategy. Sell sizing uses the bot's ownership ledger, core keeps, quantity increments and declared long-term reserves. Where usable broker balances are available, reserve checks provide an additional constraint.

These checks depend on correct order accounting and account data. They are not proof that every holding is reconciled or that an unconfirmed response represents a completed fill. Review broker orders and balances alongside the local ledger. Deliberately retained core remains a configured part of the strategy; it is not the same thing as assuming an unconfirmed sale completed.

Capital allocation

The capital plan includes several distinct paths:

• Trading cash and reserves: available funding is reduced by configured

cash floors, reserve accounting, unsettled amounts and other allocations.

• Base core deployment: when enabled, purchases can use principal until

the configured base target is reached, subject to the other limits.

• Profit-funded core purchases: a separate allocation can fund core

purchases from recorded realized results after the configured accounting.

• Core keeps: configured partial exits can retain holdings in kind.
• Reserve parking: enabled parking can move reserve cash into the

configured instrument and later release it. It can transact independently of a watchlist entry or prior realized profit.

The core symbol list is separate from the trading watchlist. A core activation threshold on profit-funded purchases does not universally disable principal deployment. Review the full plan rather than assuming the sleeve is funded only by profits.

Tax reserves and yield estimates are internal planning values. They do not pay taxes, establish a tax liability, guarantee distributions or guarantee a return. Changing this documentation does not change the configured allocation policy or sample defaults.

Circuit breakers, STOP and missing data

A daily or weekly circuit-breaker trip records a buying halt. Entries, adds and core buys are blocked while the engine continues exit and stop evaluation, subject to its required data and broker access. The operator reviews and releases the breaker through the dashboard.

The STOP file has a different effect: it prevents subsequent automated cycles, including exits. It does not interrupt an active cycle or cancel an order already sent. Stopping the scheduler or closing the terminal also prevents later local evaluation.

Incomplete portfolio data pauses new purchases and reserve adjustments. The UI marks account values unavailable or stale rather than substituting a zero balance. Protective exit evaluation continues where usable position quotes and broker access remain available. Missing marks also prevent drawdown arithmetic from treating unknown holdings as worthless.

Research, simulation and activation

Finance options boards, Strategies, Ideas, Sports and Predictions are research surfaces. The Finance options review/place endpoints refuse execution. Research results do not automatically authorize live orders or bets.

Paper trading uses simulated fills, and equity quotes can be synthetic without broker access. Shadow-paper behavior and daily-bar backtesting also differ from live execution. Read each simulation's limitations and the displayed backtest disclaimer.

The go-live checklist is advisory. LIVE activation requires current setup checks, capital-plan review and typed GO LIVE. A checklist or paper result does not validate broker settlement or crash recovery. Inspect account identity, holdings, orders and reconciliation before activation.

Future-position profit retention (0.4.15-beta candidate)

System > Build core holdings from future trade profits offers an opt-in versioned policy, independently saved for PAPER and LIVE, with equity/crypto percentages and optional per-asset overrides. It starts disabled, preserving the legacy method. Saving requires mode-specific typed confirmation that permanent core is excluded from automatic stops and trading exits. Turning it off affects only new positions; it does not sell accumulated core or rewrite open trades.

The selected share, tax reserve, core-income fraction and position ceiling are captured at the first filled entry that creates a position. Added legs use that position's policy. Old positions have no enabled snapshot and retain legacy behavior. Config schema remains unchanged: this is a separate opt-in schema v1, not a silent migration of existing percentage meanings.

The new share applies after tax reserve and core-income allocation, before the legacy cash-growth step. Example only: of $100 confirmed profit after execution costs, 30% tax reserve leaves $70; 50% income allocation leaves $35. A 40% retained share budgets $14 of the traded asset and leaves $21 liquid. Current shipped legacy settings retain $8.75 for ETH/BTC/index ETFs, $4.375 for other crypto and $2.625 for single stocks under the same assumptions. These are illustrative settings, not the owner's verified live configuration or a return forecast.

Planning reserves a bounded share quantity. Settlement recalculates from the exact recorded confirmed sell quantity and effective price, subtracting reported fees. It banks only shares still in the trading position, within the captured ceiling and existing profit-cover pool; the transferred shares retain their cost basis. The per-position budget tracks earned funding minus market value banked. First scale-out and final runner sales can each contribute without spending the same budget twice. If fees or slippage reduce funding, the unallocated remainder stays open under ordinary exits. Partial fills do not trigger a transfer. Losses, hard stops, time stops and explicit owner closes create no core. Dust does not silently graduate principal under this policy.

Crypto effective execution prices include spread; the existing execution adapter does not independently itemize all provider fees. Separate fees are deducted if reported. Paper costs/fills are simulated. No claim is made that the legacy backtester models this captured policy; use the isolated paper engine to inspect it. The research-only shadow sampler retains its prior reporting method.

Position budgets and core state remain separate for paper/live. Background paper staging includes only paper policy and state; live records cannot be published by that worker. Live activation is not authorized by this implementation task.

0.4.17 local assistant and profit-exit review

0.4.18 equity and crypto review

Version 2 peak protection covers equity and crypto Trade positions with explicit per-mode acceptance and optional existing-position capture. Core stays protected. Captured v1 crypto stops remain active during review. Equity bar confirmation requires fresh venue timestamps; session gaps reset evidence. Supported session hours still govern equity exits. Age includes downtime and may tighten stops on resumption. Protective final exits bypass the minimum-profit hold after a gap. System includes OpenAI key/billing steps and refreshes saved connection status. Installation does not start the bot or send an API request.