Overview & execution plan

01 / What exists

What T3 Code actually does today

T3 Code is a web interface and orchestration server for coding agents. Its useful contribution is the agent workflow—not a trading strategy.

Reuse from upstream

The proven agent-session foundation

Provider routingChoose a configured agent provider and model, then route the turn through one cross-provider service.
Threads and resumable sessionsPersist the provider binding and resume cursor so later turns return to the same conversation.
Typed orchestrationTurn requests, approvals, runtime events, and projections move through explicit contracts.
Event persistenceThe server records ordered orchestration events and maintains SQLite-backed read models.
Provider-scoped MCPA per-thread authenticated tool boundary already exists; upstream tools currently cover preview automation.
Operator visibilityThe React client renders messages, activities, approvals, plans, and session state over WebSocket.

Build for T3 Trades

The entire trading domain

Market truthHyperliquid metadata, candles, best bid/offer, orders, fills, positions, margin, fees, funding, and PnL.
Trading stateMission, authority, published strategy, watches, execution intents, risk reservations, and audit events.
Risk kernelHard checks for market, side, size, leverage, stop, price tolerance, exposure, stale state, and loss budget.
Signing and executionAn approved API wallet, nonce coordination, normalized order payloads, deterministic client order IDs, and testnet submission.
ReconciliationTreat exchange responses as provisional; confirm orders, fills, positions, and reduce-only protection from Hyperliquid state.
Mission runtimePersist simple watches, wake the bound harness on an event, prevent concurrent runs, and recover safely after restart.

The key distinction:

T3 Code’s “decider” governs projects, threads, messages, approvals, and checkpoints. It is not a market or trade decider. Likewise, its filesystem/command approval modes are not capital-risk controls.

02 / Target system

One loop, with judgment and authority kept separate

The harness may interpret the market and propose an action. Only deterministic server code may authorize, sign, and reconcile it.

1
User sets authority
Allocate capital, choose the provider, approve testnet access, and start one ETH momentum mission.
User
2
T3 binds the mission
Persist one mission, thread, provider instance, model, session/resume cursor, and authority version.
T3 server
3
Harness publishes a plan
Read a bounded market/account snapshot; publish thesis, conditions, sizing intent, invalidation, exits, and next watches.
Model judgment
4
T3 waits for an event
Persist simple price, candle-close, order, fill, position, or timer watches. A completed turn does not end the mission.
Deterministic
5
The same harness resumes
Coalesce the trigger with fresh exchange state. The harness may enter, decline, revise the plan, or register new watches.
Model judgment
6
T3 validates the intent
Reject stale versions, excessive exposure, invalid precision, missing stops, stale prices, duplicate execution, or exhausted loss budget.
Risk boundary
7
Hyperliquid executes
The approved API wallet signs a normalized testnet action. Hyperliquid returns per-order status and any immediate fill summary.
Exchange
8
T3 reconciles and loops
Query or subscribe to fills and clearinghouse state, confirm the actual position and independent reduce-only protection, update risk, persist the outcome, and publish the next wait.
Deterministic

03 / Strategy contract

The POC strategy is new work, not recovered T3 behavior

“Momentum” names a family. The first build still needs a published, inspectable contract for each mission and a repeatable acceptance scenario.

Model-assisted

ETH momentum mission

The harness selects one allowed mode and publishes its conclusion as structured state. It cannot enlarge user authority.

Market: ETH perpetual only, Hyperliquid testnet
Allowed modes: Breakout continuation, breakdown continuation, pullback continuation, or volatility expansion
Decision cadence: Final 1m, 3m, 5m, 15m, or 1h candles; timers; and account/order events. No tick-level or high-frequency promise.
Required publication: Direction, timeframes, evidence, entry conditions, order preference, intended notional, invalidation/stop, exit and re-entry conditions, and next watches
Entry rule: Enter only after the published conditions are observed on fresh data and the deterministic preview passes. A fired watch is not an order.
Sizing rule: The harness may request less, but the server caps leverage, gross notional, planned loss, cumulative mission loss, and available margin.
Exit rule: The harness may request reduction or close; every exit is reduce-only. Operator reduction, close, pause, and revoke bypass model availability.
Protection rule: Every position increase requires stop information. Actual filled size must receive confirmed exchange-native reduce-only protection.

Open before strategy conformance

Choose the reference signal fixture.

The architecture permits model judgment, but repeatable tests still need one frozen candle fixture with an expected plan, one rejected stale-plan case, one valid entry intent, and one deliberate no-trade result. Do not claim a specific indicator formula until that fixture is approved.

04 / Authority

Every participant gets one clear job

The safety boundary is easier to review when judgment, control, identity, and exchange truth are not mixed together.

Owner	May do	Must never do
User	Set/reduce authority; start, pause, reduce, close, or revoke	Depend on a model turn for emergency risk reduction
Harness	Interpret fresh state; publish strategy; request typed intents	See keys, sign payloads, call arbitrary exchange methods, or override limits
T3 server	Persist, schedule, validate, deduplicate, sign-coordinate, reconcile, and recover	Treat a submitted action as a fill or silently switch provider identity
Risk kernel	Block invalid/stale exposure and keep risk-reducing controls available	Permit a position increase without reserved risk and stop information
API wallet	Sign only supported Hyperliquid trading actions	Expose its private key or offer withdrawal/transfer tools to the harness
Hyperliquid	Own canonical metadata, orders, fills, positions, margin, funding, and PnL	Be replaced by optimistic local assumptions

05 / Execution plan

Build the risky boundary in dependency order

Nine reviewable phases, one per execution prompt (PROMPT-00 to PROMPT-08). A phase is complete only when its exit evidence exists; a UI mock or happy-path response is not enough.

0Foundation

Done
Fork and integration baseline
No dependency · PROMPT-00

Done 2026-07-30. 55dd016 stays this specification’s evidence and audit pin; the approved product baseline is a8e05cbb (v0.0.31), recorded in the fork’s docs/upstream/BASELINE.md under tag upstream-base/2026-07-29-a8e05cbb with fork identity, a seeded patch ledger, and a sync runbook validated by one rehearsal batch. POC scope frozen to one account, one active mission, ETH perpetual, testnet.

Exit evidenceReproducible build; full approved product-baseline SHA visible in UI and runtime; evidence pin recorded separately; no updater or release endpoint pointing at upstream.
1Contracts

Done
Trading domain and workspace
After 0 · PROMPT-01

Done as built 2026-07-30. Versioned contracts for account, authority, mission, momentum strategy, watches, events, and tools; migrations 035/036; POC authority defaults; immutable thread-bound harness binding; versioned strategy publishing with watch supersession; the two §14.3 tools on the shared MCP boundary; a read-only workspace shell. Execution, order, and position contracts moved to Phase 4; composer, timeline, and provider-derived binding to Phase 3.

Exit evidenceMigration round-trip; optimistic-version conflicts rejected; one ETH momentum mission renders mandate and strategy; a second active mission is rejected.
2Read path

Not started
Read-only Hyperliquid truth
After 1 · PROMPT-02

Implement testnet HTTP/WebSocket clients for metadata, candles, BBO, user state, open orders, fills, fees, funding, and reconnect recovery. Resolve ETH and precision from live metadata; never hard-code an asset index. Includes the testnet lab: recorded fixtures, an opt-in live smoke suite, and a dev mission bind for hands-on iteration.

Exit evidenceRecorded testnet fixtures; reconnect/backfill test; stale-data flags; master account—not API-wallet—used for account queries.
3Agent loop

Not started
Watches and harness wake-up
After 2 · PROMPT-03

The central architecture proof. Persisted typed watches, event inbox with dedupe and coalescing, the single decision lease, and same-provider session resume with a bounded fresh snapshot.

Exit evidenceStrategy version supersedes old watches; one trigger creates one turn; concurrent turns are rejected; the same provider instance/session resumes.
4Execution

Not started
Execution and reconciliation
After 2 + 3 · PROMPT-04

The risk kernel and the signing path together: reserve risk before signing, coordinate nonces, derive deterministic client order IDs, place normalized testnet actions, reconcile all status paths, and enforce the cumulative loss budget. Signs with an owner-approved interim testnet API wallet held in server config; Privy replaces it in Phase 6.

Exit evidenceRetry cannot duplicate an order; rejection releases risk; budget exhaustion blocks exposure while preserving protection; local position converges to canonical exchange state.
5Protection

Not started
Protection, deterministic controls, position management
After 4 · PROMPT-05

Mandatory stop on every increase, partial-fill protection fallback, protection replacement after scale-in, the deterministic pause / cancel entries / reduce / close / revoke buttons, and the bounded emergency close.

Exit evidenceProtection confirmed for actual canonical size; controls work while the model is unavailable; emergency close performs at most three bounded attempts.
6Onboarding

Not started
Privy onboarding and signer swap
After 4 + 5 · PROMPT-06

Privy login, user-owned master wallet, server-controlled execution wallet, and the one-time approveAgent registration so ordinary testnet signing works without per-order prompts. Swaps out the interim configured signer behind the unchanged execution boundary and revokes it. Administrative actions stay excluded from the autonomous surface.

Exit evidenceOne-time approval verified against canonical Hyperliquid state; no raw key reaches harness or client; ordinary signing works without another prompt; the interim agent is revoked.
7Conversation

Not started
Conversational modification
After 6 · PROMPT-07

Interpretation over the Phase 5 primitives, not a second execution path: versioned authority patches enforced immediately, unambiguous risk-reducing instructions mapped to deterministic controls, ambiguous exposure changes clarified before any change.

Exit evidenceAuthority patches apply to the next run; ambiguity blocks exposure change until resolved; conversational pause/resume/revoke reuse the deterministic primitives.
8Recovery

Not started
Recovery and per-provider conformance
After 1–7 · PROMPT-08

Startup and reconnection recovery, the agent-unavailable state without provider substitution, and the conformance matrix run independently for Codex, Claude, and OpenCode before each is enabled.

Exit evidenceRestart preserves protection and binding; failure never triggers silent provider substitution; each provider is enabled only after passing its matrix.

06 / POC acceptance

The proof is the complete loop, not one successful order

The POC passes when these outcomes are demonstrated together on Hyperliquid testnet.

01

Bound

One active mission stays attached to one T3 thread, provider instance, model, and resume state.

02

Resumable

The harness publishes a strategy and watches, ends its turn, and is resumed exactly once by a later event.

03

Constrained

An invalid or stale intent is rejected before signing with a specific, inspectable reason.

04

Idempotent

A retry or restart cannot create a duplicate order or spend the same risk reservation twice.

05

Protected

A partial or full fill is reconciled and the actual canonical position has confirmed reduce-only protection.

06

Recoverable

After server restart, exchange truth wins, state converges, and the original provider binding is preserved.

07

Controllable

Pause, cancel entries, reduce, close, and revoke work without waiting for the harness.

08

Repeatable

The frozen signal fixture produces the expected plan, valid intent, rejected intent, and no-trade case.

09

Conformant

A provider appears in the trading selector only after passing the conformance matrix independently; the full three-provider claim requires Codex, Claude, and OpenCode to each pass.

07 / Scope boundary

What this POC will not claim

Restraint is part of the proof. These exclusions keep the first system reviewable.

No production funds

Testnet only. Mainnet custody, policy, incident response, and operational controls are separate work.

No high-frequency trading

Agent startup, context restore, tool use, and exchange round trips are incompatible with latency-sensitive strategies.

No multiple missions

One account and one active autonomous mission avoid competing authority and cross-margin ambiguity.

No provider failover

If the bound provider is unavailable, new discretionary exposure stops. T3 does not silently transfer judgment.

No arbitrary signing

The harness gets typed trading intents—not raw private keys, signatures, transfers, withdrawals, or exchange payloads.

No guaranteed loss cap

Stops and reservations reduce risk; gaps, slippage, partial fills, liquidation, and exchange behavior can exceed estimates.

08 / Evidence

Claims are pinned to source

Upstream facts below refer to commit 55dd016. T3 Trades decisions are explicitly labeled as proposals.

Absence-audit method

We searched all 2,607 non-vendored tracked files at the pinned commit—source, documentation, configuration, and dependencies—for Hyperliquid, perps, market data, signals and indicators, position sizing, leverage, liquidation, funding, slippage, orders, stops, and take-profit logic. Incidental matches such as OAuth token exchange, merge strategy, and scroll momentum were not trading behavior.

T3 Code identity and flow

Provider and session boundary

Hyperliquid implementation rules

09 / Detailed specification

Continue into the engineering details

The overview defines the product boundary. These pages carry the deeper contracts, failure paths, and mock operator surfaces.

ArchitectureUpstream seams and service boundaries RuntimeWatches, wake-ups, turns, and lifecycle DomainMission, authority, and strategy records ToolsRead, publish, preview, and execution intents HyperliquidWallet, precision, orders, and protection RiskLoss budget and validation gates RecoveryReconciliation and restart behavior PromptsPhased implementation briefs