T3 Trades stays alive between harness turns through durable state, typed events, and bounded market data

These machines are persisted, versioned, and the only legal paths through trading state. A harness run may not invent transitions; the deterministic authority and execution services may only move a mission to a blocked terminal for a fixed reason. Hyperliquid exchange state, not a local cache, decides whether an execution record rests, fills, or fails.

The active loop expresses the continuing-mandate shape: analyse, publish strategy and watches, end the turn, wake on event, reassess, enter or decline, manage, close, and publish new watches. Any active state may exit to a terminal when the user, the provider, or a deterministic safety condition requires it.

Each wake-up produces at most one TradingHarnessRun. Only one run may own the mission decision lease at a time, so a second provider turn is never started while another is active. New events are still persisted and equivalent events coalesced; a follow-up run is considered only after the current run completes.

type TradingHarnessRun = {
  id: string;
  missionId: string;

  cause:
    | "mission_created"
    | "market_watch_triggered"
    | "scheduled_reassessment"
    | "order_updated"
    | "position_updated"
    | "user_message"
    | "mission_resumed";

  status:
    | "queued"
    | "starting"
    | "running"
    | "waiting_for_tool"
    | "completed"
    | "failed";

  startedAt?: number;
  completedAt?: number;
};

A watch moves active → triggered → consumed when a wake-up consumes it, or to cancelled, expired, or superseded from the active state. Watches are bound to a strategy version, so publishing a new strategy supersedes the watches of the prior version.

A triggered watch is consumed by exactly one run; a duplicate firing is dropped by the inbox deduplication key. Supersession is automatic when a new strategy version is published, so an obsolete watch can never wake a harness against stale intent.

Every typed action becomes an execution record that moves planned → validated → queued → signing → submitted → acknowledged, then to a live state of resting, partially_filled, or filled, and finally to a terminal of canceled, rejected, expired, or failed.

The harness ends a turn; the mission does not end. T3 evaluates simple typed watch predicates, persists and coalesces events, acquires a single decision lease, resumes the bound provider through the existing ProviderService, and hands the harness an authoritative snapshot. Complex interpretation stays a harness responsibility.

A MarketWatch is a simple condition the runtime can evaluate without judgment: a price crossing, a finalized candle close, an order update, a position update, or a scheduled reassessment. Anything that requires weighing evidence — regime, volume quality, structural invalidation — is harness responsibility and does not belong in a watch predicate.

type MarketWatch =
  | {
      type: "price_cross";
      market: "ETH";
      priceSource: "mark" | "mid";
      direction: "above" | "below";
      price: number;
    }
  | {
      type: "candle_close";
      market: "ETH";
      interval: TradingTimeframe;
      direction: "above" | "below";
      price: number;
    }
  | {
      type: "order_update";
      cloid: string;
    }
  | {
      type: "position_update";
      market: "ETH";
    }
  | {
      type: "scheduled_reassessment";
      runAt: number;
    };

When a run starts, the harness does not receive unbounded market data or a free-form prompt. It receives a TradingHarnessWakeup: the cause, the triggering watch or user message, and a fresh, versioned snapshot of market, account, active strategy, authority, and pending events. The runtime assembles the bounded context; the harness supplies the judgment.

type TradingHarnessWakeup = {
  missionId: string;
  harnessRunId: string;
  cause:
    | "market_watch_triggered"
    | "scheduled_reassessment"
    | "order_updated"
    | "position_updated"
    | "user_message"
    | "mission_resumed";

  occurredAt: number;
  triggeringWatch?: PersistedWatch;
  userMessage?: string;

  marketSnapshot: AgentMarketSnapshot;
  accountSnapshot: AgentAccountSnapshot;
  activeStrategy: MomentumStrategyState;
  authority: TradingAuthority;
  pendingEvents: TradingDomainEventSummary[];
  instruction: string;
};

The TradingTurnCoordinator is the single gate between an observed event and a started run. It verifies mission, provider, account, lease, and version state before doing anything, and it returns one of three outcomes so a caller can tell whether a run actually started, was queued behind an active one, or was blocked.

interface TradingTurnCoordinator {
  requestRun(input: HarnessRunRequest): Promise<
    | { status: "started"; harnessRunId: string }
    | { status: "queued_behind_active_run" }
    | { status: "blocked"; reason: string }
  >;
}

Between harness turns, T3 may observe and route facts. It may not generate new discretionary intent. A watch firing is routed through the evaluator, the inbox, the coordinator, and ProviderService before the harness sees it — and the harness may still decline.

1. Five-minute candle closes above threshold. The gateway finalizes the candle once, after its close time.
2. WatchEvaluator marks the watch triggered. The simple, deterministic predicate matches on the finalized close.
3. TradingEventInbox persists the event. It is keyed for deduplication and coalesced with any pending peers.
4. TradingTurnCoordinator acquires the lease. The seven pre-run checks pass; no other run owns the lease.
5. ProviderService resumes the bound session. The same provider, instance, and resume cursor as the original binding.
6. The harness receives a fresh snapshot. A bounded TradingHarnessWakeup, not a raw market stream.
7. The harness decides. To enter, decline, or revise strategy — and registers the next watches before ending the turn.

Because immediate downside protection lives at the exchange, the mission is not idle merely because the harness is asleep. The following continue without an active harness turn, because they were already placed or authorized, and T3 reconciles them and wakes the harness when interpretation is required.

T3 subscribes to order, fill, and clearinghouse updates and reconciles each against canonical Hyperliquid state. When interpretation is required — a partial fill that needs independent protection, a triggered stop, a funding swing — T3 wakes the bound harness with a fresh snapshot. Routine exchange-native bookkeeping does not require a turn.

The market-data gateway subscribes directly to every POC ETH candle interval plus BBO, active asset context, and the account streams that drive execution and reconciliation. Hyperliquid documents direct candle snapshot and WebSocket support for every POC interval — 1m, 3m, 5m, 15m, and 1h — so the gateway subscribes to those intervals directly rather than synthesizing longer candles locally.

The gateway is the only market-data path into trading state. It must distinguish snapshots from incremental updates, survive disconnects without duplicating records, and refresh canonical state through the Info API after reconnect rather than trusting replayed updates.

Hyperliquid supports all five POC intervals directly, so the gateway subscribes to each rather than deriving 3m or 1h candles locally. One tool response is bounded to 500 bars; the gateway may paginate historical requests within Hyperliquid's documented recent-candle availability, but it must not place an unbounded history into a harness turn. Computed features are derived from the bounded view, not shipped as raw streams.