§16 · The 7 concepts that must not collapse

Distinct quantities the harness, T3, and Hyperliquid each own part of

Authority
ConceptDefinitionOwner
Allocated capitalUser-authorized capital pool the mission may draw from.User
Deployed marginCollateral supporting the current position.Hyperliquid
Gross notionalAbsolute market exposure.Hyperliquid
Planned riskEstimated mission loss if an entry fills and the stop later executes.Authority
Paid trading costsAll fees already charged to the mission, including fees on still-open positions.Hyperliquid
Realized mission resultClosed PnL plus net funding minus all paid trading fees.T3 server
Reserved open riskEstimated remaining loss represented by open positions and pending entries.Authority

Allocated capital, deployed margin, gross notional, planned risk, and realized mission result are not interchangeable. A position can have large gross notional, small deployed margin, and zero planned risk all at once.

§16.1 · Default cumulative-loss model

A hard mission-loss budget measured from mission start

Authority

For the POC, maximumCumulativeLossUsd is a hard mission-loss budget measured from mission start. Positive PnL does not enlarge this budget. For a $1,000 mandate:

maximumCumulativeLossUsd$100Hard mission-loss ceiling.
maximumPlannedRiskPerPositionUsd$20Per-position planned-loss ceiling.
Fallback taker-fee reserve5 bps / sideOnly when user-specific rate is unreadable or stale.
Stop slippage reserve25 bpsOf protected notional.

Use the current Hyperliquid userFees response when available. The 5-bps fallback applies only when the user-specific rate cannot be read or is stale.

§16.2 · Accounting equations

How realized losses, open risk, and pending entries consume the budget

Authority
realizedMissionResultUsd
    = closedPnlUsd
    + netFundingUsd
    - allPaidTradingFeesUsd

realizedLossUsedUsd
    = max(0, -realizedMissionResultUsd)

openPositionRiskUsd
    = max(0, estimatedLossFromWeightedEntryToStopUsd)
    + estimatedUnpaidExitFeeUsd
    + stopSlippageReserveUsd

pendingEntryRiskUsd
    = plannedLossAtStopUsd
    + estimatedEntryFeeUsd
    + estimatedExitFeeUsd
    + stopSlippageReserveUsd

lossBudgetUsedUsd
    = realizedLossUsedUsd
    + sum(openPositionRiskUsd)
    + sum(pendingEntryRiskUsd)

remainingCumulativeLossUsd
    = max(0, maximumCumulativeLossUsd - lossBudgetUsedUsd)
Paid fees are not double-counted. Paid entry fees are included in realizedMissionResultUsd; they must not also be reserved as unpaid open-position fees. A queued-but-unfilled entry reserves both estimated entry and exit fees; a filled position reserves only the fees that have not yet been paid.
Profits reduce realized loss, never the ceiling. Realized profits may reduce realizedLossUsedUsd back toward zero, but they never increase maximumCumulativeLossUsd above the user-authorized amount.

§16.3 · Position-increase validation

The full checklist before any position-increasing action is signed

Authority
Reserve before signing; reconcile after every state change. Reserve risk before an entry is signed. Reconcile the reservation after rejection, cancellation, partial fill, stop replacement, funding, fee updates, reduction, or realized close.

§16.4 · Loss-budget exhaustion

When remainingCumulativeLossUsd reaches zero or below

Authority

When remainingCumulativeLossUsd reaches zero or becomes negative after reconciliation:

  1. Cancel all mission-owned position-increasing orders.
  2. Block new entries, scale-ins, reversals, and re-entry.
  3. Preserve valid reduce-only protection.
  4. Permit only protection improvement, cancellation of increasing orders, reduction, close, and revocation.
  5. Set the mission to blocked with reason cumulative_loss_limit.
  6. Notify the user and expose the remaining position and protection state.
Budget does not force an immediate market close while valid protection exists. Reaching the budget does not by itself force an immediate market close while valid protection exists. If protection is absent or cannot be confirmed, the deterministic emergency-close path applies.
No auto-resume. A mission does not automatically resume after reservations fall or PnL improves. The user must explicitly resume or modify authority, after which T3 revalidates the full account and risk state.
A stop is not a guaranteed maximum loss. Gaps, slippage, partial fills, liquidation behavior, and exchange behavior can produce a worse result than the reservation.

Related: see Hyperliquid protection invariant for the exchange-native reduce-only stop path, and Tools for the typed execution surface the harness validates against.