Shared contract

Intent in, typed action out

T3 server

One tool registry

The TradingToolRegistry provisions the same tool surface to every bound harness. There is no provider-specific tool set and no provider-specific exchange client.

Harness

Intent-level inputs

Tools describe what the harness wants to do, not how to encode it. Market, side, size, price, and stop intent are validated and normalized inside T3 before signing.

Boundary

No raw payloads

Neither the harness nor the client may supply arbitrary raw Hyperliquid payloads. Precision, nonces, cloids, signing, and reconciliation stay inside the deterministic execution boundary.

Delivery is the existing upstream MCP boundary, not a new mechanism. Upstream T3 already runs a first-party MCP server inside the T3 server process, mints a per-session bearer credential when ProviderService starts a provider session, and every provider adapter already injects that server into its harness as t3-code. Trading adds a toolkit and a trading capability to that boundary; it adds no MCP configuration of its own to any harness and no second transport.

14.1 · Market tools

Read canonical market state

Market tools

Hyperliquid

Freshness thresholds govern execution: stale BBO or account state blocks submission rather than silently degrading.

14.2 · Account tools

Read canonical account truth

Account tools

User

Account state is queried with the user-owned master-wallet address. The Privy-managed execution-wallet address signs actions; it is never used as account identity.

14.3 · Mission tools

Publish the strategy that governs every execution

Mission tools

Harness
Publishing is a versioned, side-effecting operation. trading_publish_momentum_strategy requires an expected current version and, on acceptance:
  • Increments the strategy version.
  • Supersedes obsolete watches bound to the previous version.
  • Updates the ordered UI projections.
  • Invalidates execution previews produced from older strategy versions.
A stale expected-version publish is rejected rather than silently overwriting current state.

Publish contract

Harness
// Every MomentumStrategyState field the harness authors.
// version and updatedAt are excluded: the server assigns both on
// acceptance, and the accepted version is always expectedVersion + 1.
type PublishMomentumStrategyBody =
  Omit<MomentumStrategyState, "version" | "updatedAt">;

type TradingPublishMomentumStrategyInput = {
  missionId: string;
  expectedVersion: number; // 0 before any publish
  strategy: PublishMomentumStrategyBody;
};

type TradingPublishMomentumStrategyResult =
  | {
      outcome: "accepted";
      strategy: MomentumStrategyState;
      strategyVersion: number;
      supersededWatchIds: string[];
    }
  | {
      outcome: "rejected";
      reason: "stale_strategy_version" | "mission_not_active";
      currentVersion: number; // so the harness can retry
    };

MomentumStrategyState is §10.5 on the Domain page. A rejection returns the version the server actually holds rather than an opaque error.

14.4 · Watch tools

Register the conditions that wake the harness

Watch tools

Harness

Watches are bound to a strategy version and remain simple, deterministic, typed, and inspectable. Complex interpretation stays a harness responsibility.

14.5 · Execution tools

Request typed exchange actions

Execution tools

Authority

Every execution tool runs through the same authority checks, nonce lane, cloid derivation, signing, and reconciliation path. Submission is never treated as execution; canonical Hyperliquid state is the only completion signal.

14.6 · Mission controls available to the harness

Harness-requested lifecycle controls

Mission controls

Harness

These controls let the harness wind a mission down within a turn. They follow the same path as the deterministic user controls below.

14.7 · Deterministic user-control API

Risk-reducing controls that never wait for a harness turn

User-control API

User

These typed RPC commands are invoked directly by workspace buttons and do not require a harness turn:

One control service, two entry points. Harness tools and direct user controls converge on the same TradingControlService, authority checks, execution service, and reconciliation path. The deterministic buttons bypass discretionary harness reasoning — never T3's safety boundary. Their availability does not depend on the bound harness being online.

Button behavior and loss-budget consequences are detailed on the Risk page; the bounded emergency-close procedure is §17.5 on the Hyperliquid page. Interactive control placement is shown on the UI concepts prototype.

Surface boundary

What the tool surface deliberately omits

Excluded

No administrative actions

The autonomous tool surface excludes approving or replacing an API wallet, withdrawals, transfers, builder-fee approval, arbitrary transaction signing, arbitrary message signing, and wallet export.

Identity

No raw wallet exposure

No raw private key reaches the harness. The Privy-managed execution wallet signs ordinary exchange actions under a named Hyperliquid agent; it is never reused after revocation.