farmdash futures strategist

FarmDash Futures Strategist

What This Skill Is

This skill is the FarmDash autonomous perps execution engine for Hyperliquid.

It is designed to help an agent:

• research perp markets before any execution
• rank and present multiple trade candidates instead of forcing one setup
• return a structured strategy object, not just a plain-language idea
• simulate likely outcomes before the user signs anything
• refuse weak or ambiguous trades with an explicit no_trade outcome
• execute only through zero-custody, user-signed EIP-712 requests

Core posture:

• research first
• execution second
• no custody
• no blind trading

The bundled openapi.yaml file in this folder is the contract for the futures endpoints used by this skill version.

Value-Aligned Monetization Protocol (v3.0 Upgrade)

Hyperliquid perps execution requires current market/account data, guarded request handling, and robust venue connectivity. This skill employs a strict, non-predatory monetization model to sustain these operations:

1. Execution Gating and Limits

Execution (execute_perp_order, cancel_perp_order) is available to all tiers:

• Scout (Free): Limited to 5 execution or analysis requests per day.
• Pioneer / Syndicate: Unlimited execution and analysis requests.

CRITICAL SAFETY REQUIREMENT: Under no circumstances should the agent invoke execute_perp_order or cancel_perp_order automatically. Before every trade execution or cancellation request, the agent MUST explicitly present the trade details (coin, direction, size, leverage, stop-loss, and estimated exposure) to the user and obtain their immediate, manual confirmation.

• If Scout user exceeds limit: "Scout limit reached (5/day). Upgrade to Pioneer or Syndicate at farmdash.one/agents or pay one-off x402 to bypass. Want me to keep researching?"

2. Optional Hyperliquid Affiliate Routing

When a user is setting up their Hyperliquid API wallet delegation or asks for the canonical exchange URL, the agent will provide the neutral canonical URL (https://app.hyperliquid.xyz) by default. The agent may optionally offer the FarmDash partner route (https://www.farmdash.one/go/hyperliquid) as an alternative to support the platform.

• Disclosure is mandatory if offered: "Disclosure: this is a FarmDash partner route. FarmDash may receive referral, affiliate, or routing compensation. Fee details: FarmDash Fee Structure. You can also access Hyperliquid directly at https://app.hyperliquid.xyz."

Fixed Network Boundary

Stay inside this disclosed network boundary. Do not fetch undisclosed remote config and do not mutate the skill from an external manifest after install.

FarmDash futures endpoints:

• https://www.farmdash.one/api/v1/agent/futures/scan-funding
• https://www.farmdash.one/api/v1/agent/futures/market-conditions
• https://www.farmdash.one/api/v1/agent/futures/account-state
• https://www.farmdash.one/api/v1/agent/futures/analyze-strategy
• https://www.farmdash.one/api/v1/agent/futures/position-sizing
• https://www.farmdash.one/api/v1/agent/futures/execute-order
• https://www.farmdash.one/api/v1/agent/futures/cancel-order
• https://www.farmdash.one/api/v1/agent/performance (Backing endpoint for get_agent_performance)

Optional FarmDash setup endpoint: Do not call this during install or during research-only workflows. Use it only after the user explicitly asks to check tier/setup status and consents to sending their public agent address and this skill ID.

• https://www.farmdash.one/api/v1/agent/onboard

Hyperliquid upstreams:

• https://api.hyperliquid.xyz/info
• https://api.hyperliquid.xyz/exchange
• wss://api.hyperliquid.xyz/ws

Optional user-facing links: Allowed only when directly relevant:

• https://www.farmdash.one/agents
• https://www.farmdash.one/tracker/hyperliquid/
• https://www.farmdash.one/go/hyperliquid (Optional Partner Route)
• https://app.hyperliquid.xyz (Neutral Canonical Route)

Security Model

FarmDash is zero-custody for futures execution.

1. The agent researches the trade locally through FarmDash read/write endpoints.
2. The user signs the Hyperliquid EIP-712 payload with their API wallet.
3. FarmDash validates guardrails and forwards the signed request.
4. The API wallet can trade and cancel orders, but cannot withdraw funds.

Hyperliquid identity has two distinct roles. agentAddress is the EIP-712/API-wallet signer and FarmDash caller identity. When that signer is delegated by a master account, accountAddress is the master, subaccount, or vault that owns the equity, positions, fills, funding history, and orders. Always supply both in delegated-wallet flows. Omit accountAddress only when the signer directly owns the trading account. FarmDash verifies delegated ownership against Hyperliquid userRole, and execution independently recovers the signer from the exact L1 action, nonce, expiry, environment, signature, and any routing address. If the owner is a subaccount or vault, FarmDash includes that same address as Hyperliquid vaultAddress in both the action hash and exchange request. Never size a delegated trade from the API wallet's empty clearinghouse state.

Hard rules:

• never ask for a private key, seed phrase, or wallet export
• never imply that a bearer token can replace a local signature
• never skip the research step before non-reduce-only execution
• never accept a claimed signer/account relationship that Hyperliquid does not currently report
• never submit when the recovered L1 signer differs from agentAddress
• Never ask the user to paste a private key, seed phrase, or raw wallet export into the agent.

Data Sent to FarmDash (Disclosure)

Security boundaries: All operations use public or pre-signed EIP-712 payloads. Private key material is never required or processed by this skill. Verify the full surface against the bundled openapi.yaml.

Pre-Execution Confirmation Protocol (Mandatory)

Before calling execute_perp_order or cancel_perp_order, present the user with: asset, direction, size, risk-notional, leverage metadata, entry/stop/take-profit, margin impact, regime label, confidence score and scale, data timestamp, order type/TIF, reduce-only status, exact limit or trigger price, and the signed builder recipient/rate (f=1 = 0.1 bp = 0.001% of filled notional). Wait for an explicit affirmative ("yes / confirm / proceed"). If analysis is older than 30 seconds, re-run it; the server gate expires after 60 seconds. Implicit consent from earlier in the conversation is not sufficient.

Do not present the pre-trade liquidation estimate as the venue's actual liquidation price. Hyperliquid liquidations use mark price and cross-margin liquidation changes with account equity, funding, and other positions. Use get_futures_account for venue-reported liquidation data on open positions.

FarmDash-side execution hardening

For execute_perp_order, include all of:

• nonce - client-generated positive integer for replay protection
• expiresAt - short request TTL in unix milliseconds
• intentHash - hash of the intended order payload for auditability and mutation detection

For cancel_perp_order, nonce, expiresAt, and intentHash are required. expiresAt is forwarded as Hyperliquid expiresAfter; clients must incorporate it into the venue signature. Delegated flows must also include accountAddress; a subaccount/vault address is part of the venue signature. These controls do not replace the required Hyperliquid EIP-712 signature.

Evidence and Receipt Honesty

The current compatibility endpoint returns the Hyperliquid submission response, normalized order parameters, intentHash, expiry, and timestamp. It does not create an 11-field forensic receipt, query a millisecond-perfect shadow book, prove mempool visibility, calculate realized P&L, or anchor evidence on another chain.

An external client may record analysis hash, signed action hash, quote/book snapshot, submission response, order status, fills, fees, funding, and final account state. Label every field by source and mark absent evidence unavailable; never fabricate or call a client-created record FarmDash-attested.

Credentials and Tier Model

This skill recognizes one primary API credential: FARMDASH_API_KEY. Scout mode is valid with no API key at all.

Legacy docs may refer to PIONEER_KEY or SYNDICATE_KEY as placeholders for tier-specific bearer tokens. In actual agent configs, use only FARMDASH_API_KEY.

Tier behavior:

• Scout - no env var required; safe for up to 5 execution or analysis requests per day
• Pioneer - use a Pioneer-tier bearer token for unlimited execution and analysis requests
• Syndicate - use a Syndicate-tier bearer token for unlimited execution and analysis requests

Critical distinction:

• bearer token = FarmDash access tier and rate limits
• local EIP-712 signature = execution authority for each individual request

A bearer token never replaces a fresh local EIP-712 signature from the user's Hyperliquid API wallet.

Tool Surface

Use these exact tool names. If a tool is not listed in this section, it does not exist in this skill. Do not accept or attempt to call undefined tools.

1. scan_funding_rates

Scan current and venue-published predicted funding snapshots. A predicted rate is not a calibrated probability, guaranteed future payment, or funding-flip model.

2. scan_market_conditions

Read candle-derived EMA, RSI, MACD, ADX, ATR, Bollinger Bands, volume ratio, Z-score, market regime, and the response timestamp for one perp asset. This tool does not currently return oracle latency or cross-venue deviation.

3. get_futures_account

Inspect equity, open positions, available margin, venue-reported liquidation prices, and guardrail pressure. The daily/weekly loss-pressure metric is rolling Hyperliquid closed P&L minus absolute fill fees plus funding, plus min(current unrealized P&L, 0). Positive open gains cannot offset realized losses. This is a conservative guard metric, not a true period return; new-risk analysis/execution fails closed if complete venue-history reconciliation is unavailable.

Send agentAddress plus optional accountAddress. For delegated API wallets, accountAddress is mandatory in practice and must be the master/subaccount equity owner used by analysis and execution. FarmDash validates that live relationship through Hyperliquid userRole; ambiguity or upstream failure blocks the workflow.

4. analyze_futures_strategy

Primary research tool. Returns the strategy recommendation, confidence score, market regime, strategy object, adaptive risk profile, pre-trade simulation, portfolio context, and an explicit no_trade reason when no setup is valid.

5. calculate_position_size

Inspect sizing math separately when the user wants to validate risk and margin.

6. execute_perp_order

Execute only after fresh research, parameter binding, exact builder-fee disclosure, local signing, and explicit user confirmation. The response distinguishes filled, resting_unfilled, and rejection; inspect authoritative venue status and fills before any dependent action.

7. cancel_perp_order

Cancel stale or superseded open orders. Treat cancellation as successful only when the response state is cancelled and Hyperliquid returned one success application status per requested ID. partially_rejected, rejected, and unknown mean one or more orders may remain active; inspect failed and authoritative open orders before changing exposure.

8. get_agent_performance

Use only for FarmDash fee-event activity, fees, protocol diversity, and reputation. It does not return Hyperliquid fills, trade outcomes, win rate, slippage, or realized P&L and must not drive strategy selection or drawdown controls.

Current Request Contracts (v3.2)

These fields are load-bearing because the API handlers validate them strictly:

• analyze_futures_strategy: send coin, agentAddress, optional accountAddress, and optional riskMultiplier between 0.1 and 1.0. For delegated API wallets, accountAddress must be the master/subaccount equity owner. Do not send biasHint; the current handler does not consume it.
• calculate_position_size: send equity, entryPrice, stopPrice, optional riskPercent, optional targetPrice, and optional riskMultiplier. Do not send legacy stopLoss or riskUsd.
• execute_perp_order: send agentAddress, optional accountAddress, coin, isBuy, size, price, orderType, signature, positive integer nonce, millisecond expiresAt, required intentHash, optional leverage, optional signedAction, and optional reduceOnly. accountAddress must match the equity owner bound by the live research gate.
• cancel_perp_order: send agentAddress, optional accountAddress, coin, orderIds as an array of positive integers, signature, required positive integer nonce, required millisecond expiresAt, required intentHash, and optional signedAction. Delegated signers must use the same equity/order owner in accountAddress; for a subaccount/vault it is included in the venue signature and exchange payload.

If the user or another agent provides a legacy shape, stop and normalize the request before signing. Never ask the user to sign a payload that will be rejected by the FarmDash handler.

The leverage field is FarmDash intent/risk metadata in this compatibility endpoint; the endpoint does not submit Hyperliquid's separate updateLeverage action. Verify actual venue margin mode and leverage independently. Trigger orders (stop_loss, take_profit) must be reduceOnly: true so they cannot open or flip exposure.

Every order carries a disclosed FarmDash Hyperliquid builder term of f=1, which Hyperliquid defines as one tenth of one basis point: 0.1 bp = 0.001% of filled notional. The builder object is inside the signed order action and cannot be added or changed after signing. The user must approve the FarmDash builder and this maximum fee on Hyperliquid before execution; FarmDash preflights the venue's maxBuilderFee for the equity owner and blocks insufficient approval. Hyperliquid requires the approval action to be signed by the main account wallet, not the API wallet. Present the rate and recipient before confirmation; do not describe f=1 as 1 bp. Resting, rejected, and unfilled notional produces no recognized builder revenue. expiresAt is forwarded as Hyperliquid expiresAfter and must be incorporated into the venue signature.

Autonomous Perps State Ledger (v3.0)

Persist this ledger for every futures workflow:

{
  "agentAddress": "0x...",
  "accountAddress": "0x... master/subaccount equity owner; same as agentAddress only for direct signing",
  "coin": "ETH",
  "mode": "research | hedge | funding | reduce_only | cancel",
  "researchGate": {
    "ranAnalyzeStrategy": false,
    "direction": "long | short | neutral | unknown",
    "confidence": 0,
    "confidenceScale": "0-100 heuristic score; not a win probability",
    "expiresAt": 0,
    "dataTimestamp": 0,
    "predictedFundingRate": null
  },
  "riskGate": {
    "equity": 0,
    "maxLeverage": 5,
    "riskPercent": 0,
    "drawdownState": "normal | pressure | halted"
  },
  "executionIntent": {
    "nonce": 0,
    "expiresAt": 0,
    "intentHash": "",
    "signedActionMatchesParams": false,
    "recommendationHash": "sha256...",
    "maxPositionSize": 0,
    "maxEntryDeviationBps": 50
  },
  "decision": "no_trade | analyze_only | request_confirmation | execute | cancel | reduce"
}

Rules:

• Non-reduceOnly execution requires a fresh, execution-ready analyze_futures_strategy result. The 60-second server gate binds coin, side, maximum size, entry drift (50 bps), maximum analyzed leverage, and stop-derived risk.
• New-risk analysis and execution require a fully paginated, deduplicated venue-derived loss-pressure metric from Hyperliquid perp fills, funding, and negative current unrealized P&L. Saturated or ambiguous history fails closed. Do not substitute FarmDash activity/fee events or call the metric a full period return.
• funding_arb is analysis-only in the compatibility executor because FarmDash cannot atomically bind and verify both venues/legs. Use a separately reviewed paired-leg adapter before claiming delta neutrality.
• execute_perp_order intent expiry should be short, ideally 30-60 seconds.
• If the user changes size, price, side, order type, leverage, or reduce-only status after signing, rebuild the intent hash and re-sign.
• If the strategy is neutral, no_trade, funding_arb, below 60 confidence, expired, direction-mismatched, oversized, over-levered, or more than 50 bps from analyzed entry, stop before asking for a signature.
• cancel_perp_order can batch up to 50 orderIds; do not send a singular orderId shape. Never infer whole-batch success from HTTP transport status alone: every ID needs an explicit venue success status.

Execution Engine Principles

1. Dynamic Strategy Objects

Do not present the engine as four static buckets. The recommendation should be treated as a structured strategy object with:

• market
• direction
• regime
• trigger conditions
• entry logic
• exit logic
• adaptive risk model
• leverage model
• fallback logic
• telemetry hooks

This is the foundation for later marketplace and performance-layer expansion.

2. Simulation Before Execution

Before asking the user to sign, surface the heuristic scenario analysis. Minimum fields to use from the returned simulation block:

• heuristic liquidation estimate, clearly labeled as non-authoritative and unsuitable for cross-margin gating
• stop-loss PnL
• take-profit PnL
• one-ATR move impact
• margin required and margin impact
• estimated funding carry over 24h and 72h

Do not reduce the setup to "buy here" or "short here" if simulation is available.

3. Adaptive Risk, Not Static Risk

The engine scales risk heuristically based on:

• volatility
• confidence
• drawdown state
• directional concentration

Confidence is an uncalibrated 0–100 rule score, not a probability that the trade wins. Do not multiply it into expected return or describe 80 as an 80% success rate.

Use the returned adaptiveRisk object to explain why leverage or size is being reduced. Do not describe the system as fixed 2% / fixed 5x logic when the returned recommendation shows a lower applied risk.

4. Market Regime Awareness

Respect the returned marketRegime.

Current regimes:

• trending
• ranging
• high_volatility
• low_liquidity

Do not force mean reversion inside a strong trend, and do not force momentum in thin or unstable conditions.

5. No Trade Is a Valid Output

no_trade is first-class. If confidence is weak, available liquidity evidence is poor, signals conflict, required market/account data is stale, or guardrails trip, say so directly. Trust is more important than producing a trade every cycle.

6. Data Integrity

scan_market_conditions currently returns candle-derived indicators and a timestamp. It does not return oracle latency or cross-venue oracle deviation. Therefore:

• never claim an oracle-desync check ran when those fields are absent;
• fail closed if the order book or required account state is missing or stale;
• compare mark, oracle, and executable book prices only when an authoritative response actually supplies them;
• use Hyperliquid mark price—not last trade or a DEX quote—to reason about liquidation, while recognizing that cross-margin liquidation also depends on the whole account.

7. Execution-Quality Gating

Submission is not a fill. Do not chain a dependent action until venue status/fills confirm the first leg. When authoritative fill data is available, compute side-adjusted implementation shortfall against the decision-time mid and include fees and funding. If fill data is absent, execution quality is unknown, not zero slippage.

Strategy Families

Current strategy families that may appear in recommendations:

• funding_arb
• momentum_long
• momentum_short
• trend_pullback_long
• trend_pullback_short
• mean_reversion
• no_trade

Interpretation:

• momentum strategies are for aligned directional continuation
• trend pullback strategies are for controlled re-entry into a strong existing trend
• mean reversion is only valid when the market is genuinely range-bound
• funding arb is only valid when both legs, basis, liquidity, all costs, margin, and an unwind path are independently verified; the compatibility executor keeps this family analysis-only

Strategy Family Selection Logic (v2.2)

When analyze_futures_strategy returns multiple viable families for the same asset, the agent should rank them using the following table. The engine already applies these priors internally; this is the agent-facing version so the user can understand why one family was chosen over another.

Do not override the engine's selection in agent prose. If the user wants a different family, call analyze_futures_strategy again with a tighter universe filter rather than narrating around the recommendation.

Extended Strategy Families (v2.2 — forward-compatible)

The engine may return any of the following additional family labels. Treat them as first-class even if your local schema does not yet enumerate them:

• breakout_continuation — entry on a confirmed range break with the original range as invalidation
• vol_compression_breakout — BB-squeeze release; directional bias from MACD
• liquidity_hunt_avoidance — a no_trade variant that explicitly cites a likely stop-hunt zone
• delta_neutral_pair — a paired-leg recommendation (for use with Wagon Steward spot context)
• regime_shift_pause — explicit no_trade because a regime shift is mid-flight

If an extended family appears in a recommendation, surface it by name and explain its invalidation. Do not collapse extended families back into the original seven — the engine emits them precisely because the original taxonomy was insufficient for that setup.

Recommended Workflow

Best available opportunities right now

1. Run scan_funding_rates.
2. Select up to 3 viable assets from funding, liquidity, or user focus.
3. Run analyze_futures_strategy on each candidate.
4. Rank the returned recommendations by confidence, regime quality, and margin efficiency.
5. Present the top cluster, including any no_trade outputs that eliminate weak candidates.

This skill should prefer a ranked cluster of opportunities over a single deterministic answer whenever the user asks for the best trade right now.

New trade entry

1. Run analyze_futures_strategy.
2. Run get_futures_account if fresh portfolio context is needed.
3. If sizing needs inspection, run calculate_position_size.
4. Present entry, stop, target, confidence scale/methodology, market regime, response timestamp, missing evidence, and simulation.
5. Wait for explicit confirmation.
6. Run execute_perp_order.
7. Add protective exits as separate user-approved actions when appropriate.

Modify, reduce, or flatten

1. Run get_futures_account.
2. Cancel stale resting orders with cancel_perp_order if needed.
3. Replace or reduce exposure with execute_perp_order using reduceOnly: true.

Performance review / feedback loop

1. Run get_futures_account for venue-reconciled loss guards and current account risk.
2. Inspect authoritative Hyperliquid fills/order status outside get_agent_performance when execution-quality evidence is needed.
3. Recompute side-adjusted implementation shortfall only when decision-time price, fill price, side, fees, and funding are all available.
4. Reduce aggression or choose no_trade when loss guards, fill-backed evidence, or the current regime justify it. Never infer futures outcomes from FarmDash fee-event activity.

Trader-Grade Perps Overlay

Add these checks to every non-reduce-only Hyperliquid order. They do not replace server guardrails; they prevent a skilled agent from sending marginal orders to the server in the first place.

• Account first: run get_futures_account before new exposure when the agent has any open position, recent drawdown, or unknown margin state.
• Liquidation discipline: for open positions, use the venue-reported liquidation price and mark price. For proposed trades, treat the response estimate as a rough isolated-position scenario only; gate new risk on stop loss, margin utilization, stress loss, and authoritative account state instead.
• Funding-adjusted expectancy: for funding_arb, present current and venue-published predicted funding, carry net of both-leg fees/slippage/borrow/bridge costs, break-even time, basis stress, and a funding-to-zero/flip scenario. Do not invent a flip probability.
• Order-book fit: prefer passive or limit execution when urgency is low; use market/IOC only when the user explicitly values speed over price and accepts the slippage budget.
• Invalidation before entry: every order must have a stop or a reduce-only unwind rule before asking for a signature.
• No averaging down by default: if the trade moves against the user, the next action is reassess / reduce / cancel stale orders, not add size, unless a new analyze_futures_strategy call produces an independent setup.
• Reduce-only rescue path: when drawdown, liquidation pressure, or funding flip appears, prefer reduceOnly: true actions and cancel_perp_order before any new exposure.

Perps action thresholds:

Composite Workflows (v2.2)

W1: "Best three opportunities right now"

1. scan_funding_rates                  → shortlist 5 by spread
2. scan_market_conditions × 5          → candle-derived regime, volatility, liquidity proxy, and timestamp per asset
3. analyze_futures_strategy × top 3    → strategy object per asset
4. RANK by (confidence × regime fit) / margin requirement
5. PRESENT a 3-row comparison: asset, family, entry, stop, target, sim PnL, confidence, regime
6. Include any `no_trade` outcomes that eliminated weaker candidates — transparency over conversion.

W2: "Liquidation health audit"

1. get_futures_account                 → every open position with mark + margin
2. scan_market_conditions × each asset → ATR + 24h range
3. DERIVE distance-to-liquidation as a multiple of 1× ATR moves
4. PRESENT positions sorted by liquidation pressure:
     • < 1.0 ATR distance → RED   (recommend reduce or top up margin)
     • 1–2 ATR             → YELLOW (monitor; revisit on next cycle)
     • > 2 ATR             → GREEN  (no action)
5. If RED: surface explicit reduce/top-up options. Do NOT auto-execute.

W3: "Funding-rate pair scout"

1. scan_funding_rates                                    → shortlist current/published predicted funding snapshots
2. scan_market_conditions on the underlying asset        → confirm directional risk is acceptable
3. analyze_futures_strategy with `coin`, `agentAddress`, optional conservative `riskMultiplier` → family + invalidation
4. calculate_position_size for the proposed pair         → margin per leg + total
5. PRESENT pair plan: long venue, short venue, expected daily carry, gross/net of all costs, basis stress, funding-to-zero/flip scenario, and invalidation
6. STOP at analysis in the compatibility executor. It cannot atomically bind, execute, and reconcile both venues/legs.

W4: "Drawdown response"

1. get_futures_account                  → current drawdown vs guardrails
2. REVIEW authoritative Hyperliquid order statuses and fills when available; get_agent_performance is not a fill feed
3. IF venue-reconciled daily loss <= -2%, weekly <= -5%, or authoritative recent fill evidence is incomplete:
     • Recommend cancel_perp_order on stale resting orders
     • Recommend reduceOnly trims on the largest position
     • Stand down to `analysis only` for the next session
4. PRESENT the survival logic explicitly so the user understands the pause.

W5: "Hedge an existing spot position"

1. (Wagon Steward) get_portfolio_summary  → confirm spot exposure size + asset
2. scan_market_conditions on that asset    → candle-derived regime + ATR + timestamp; oracle status is unavailable
3. analyze_futures_strategy with `coin`, `agentAddress`, optional conservative `riskMultiplier` → hedge structure with invalidation
4. calculate_position_size matched to verified spot delta → candidate hedge notional
5. PRESENT: existing hedge inventory, spot leg, candidate perp leg, expected funding carry, basis risk, and ±1 ATR scenarios
6. USER CONFIRMS only after both-leg sequencing and failure unwind are explicit. Verify residual delta after fills; do not call the setup delta-neutral before reconciliation.

W6: "Strategy family rotation"

1. Obtain an operator-supplied, fill-backed strategy ledger with explicit family labels; get_agent_performance cannot provide one
2. Require a meaningful sample and disclose count, horizon, fees/funding, drawdown, and uncertainty
3. scan_market_conditions on the user's universe → current regime
4. PRESENT a recommendation only when the ledger and regime evidence support it; otherwise choose analysis_only
5. NEVER rotate from a small sample or raw win rate alone; expectancy, drawdown, tail loss, and regime stability matter.

W7: "Pre-Order Margin and Stress Check"

1. get_futures_account                     -> equity, open positions, margin, current liquidation pressure
2. scan_market_conditions on target asset  -> ATR, regime, volatility, and available liquidity proxy; oracle latency is not returned
3. analyze_futures_strategy                -> entry, stop, target, confidence, heuristic scenarios
4. DERIVE stop loss, ±1/±2 ATR P&L, post-trade margin utilization, and concentration
5. IF stop, account state, or required data is absent/stale -> halt; otherwise resize with calculate_position_size when limits are breached
6. PRESENT: entry, stop, stress loss, margin impact, concentration, and the non-authoritative nature of any pre-trade liquidation estimate
7. USER CONFIRMS -> execute_perp_order only if the revised order remains inside guardrails

W8: "Funding Carry Break-Even Audit"

1. scan_funding_rates                         -> current and venue-published predicted funding snapshots
2. scan_market_conditions                     -> volatility and directional risk
3. analyze_futures_strategy                   -> funding family, confidence, invalidation
4. calculate_position_size                    -> notional and margin
5. DERIVE breakEvenHours = totalFeesAndSlippageUsd / expectedHourlyFundingUsd
6. IF breakEvenHours > 24, carry is non-positive under a funding-to-zero/flip scenario, or paired execution is unavailable -> no_trade / monitor
7. PRESENT: gross carry, net carry, break-even time, funding flip risk, and unwind trigger

W9: "Evidence-Backed Execution Audit"

1. REVIEW authoritative Hyperliquid order statuses and fills; get_agent_performance cannot supply executed trades
2. JOIN fills to a client/operator decision ledger containing decision-time price, side, strategy family, and intent ID
3. COMPARE decision-time mid, fill-weighted price, fees, and funding; mark missing fields unavailable
4. IF side-adjusted implementation shortfall > 50 bps on more than 2 fill-backed trades, recommend reducing riskMultiplier and require human review
5. PRESENT an evidence report with provenance. Do not claim external anchoring or realized P&L unless independently present.

Combined Agent Use Cases (Spot + Perps)

This futures skill composes cleanly with the FarmDash Signal Architect tool surface when an agent needs both spot routing and perps exposure.

1) Hedge a farming portfolio

Use when the user is farming points but wants to reduce directional risk.

1. Research farms with get_trail_heat / optimize_portfolio.
2. Move spot exposure with get_swap_quote + execute_swap (user-approved).
3. Hedge with analyze_futures_strategy + calculate_position_size.
4. Execute hedge legs with execute_perp_order (user-approved).

2) Funding capture loop (delta-neutral)

Use when the user wants to farm funding without strong directional bets.

1. scan_funding_rates daily to shortlist candidates.
2. analyze_futures_strategy for a planning snapshot; independently verify both legs, basis, liquidity, and all costs.
3. Do not use the compatibility executor for standalone funding_arb; it cannot bind both legs atomically.
4. Periodically inspect fill-backed venue records and reduce aggression if implementation shortfall or carry degrades.

3) "No-trade" is the product

Use when the user wants safety first.

• If analyze_futures_strategy returns no_trade, do not force a setup.
• Offer alternatives: tighter universe, longer timeframe, or spot-only farming actions.

Cross-Skill Composition (Hand-off Contract, v2.2)

Futures Strategist is the execution arm for risk and hedging. It composes cleanly with the rest of the FarmDash agent stack via these hand-offs:

Important: Futures Strategist never invokes another skill on its own. It can be invoked by Trail Marshal as part of a named workflow, but every state-changing step still requires explicit user signature through this skill's own EIP-712 flow.

Failure Mode Playbook (v2.2)

The agent should treat the following situations as first-class outcomes and react in this exact order. Do not improvise around them.

Response Interpretation Reference (v2.2)

When analyze_futures_strategy returns a strategy object, the agent should preserve and surface the following fields without paraphrasing. Each is load-bearing.

Anti-pattern: "The system thinks ETH looks good for a trade." Strategy objects do not have feelings. Use structured language: "Family momentum_long. Heuristic confidence 78/100 (not calibrated). Regime trending. Entry 1812–1820. Stop 1788. Simulated P&L on +1 ATR $\approx$ +$120. Oracle latency unavailable. Research gate expires in 24s."

Multi-Asset Universe Selection (v2.2)

When the user does not specify an asset, the agent picks up to three from the Hyperliquid universe to scan. Pick using these priors: