farmdash futures strategist

Security

Adaptive Hyperliquid perps execution engine for OpenClaw. Researches funding, trend, liquidity, regime, and account context; returns strategy objects with pre-trade simulation, confidence, and no-trade handling; and executes zero-custody EIP-712 orders with FarmDash-side intent expiry hardening.

Install

openclaw skills install 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.

Fixed Network Boundary

Stay inside this disclosed network boundary.

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

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

Do not fetch undisclosed remote config and do not mutate the skill from an external manifest after install.


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.

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 ask the user to paste a private key, seed phrase, or raw wallet export into the agent.

Data Sent to FarmDash (Disclosure)

The skill transmits only the data needed to research and route a perps order: public wallet address, Hyperliquid asset symbols, sizes, leverage parameters, signed EIP-712 payload bytes, optional Bearer key, and required nonce / expiresAt / intentHash integrity fields for execution. It never transmits private keys, seed phrases, mnemonics, raw wallet exports, OAuth tokens, or PII. The Hyperliquid API wallet is permission-scoped to trading and cancellation only — it cannot withdraw funds. 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, leverage, entry/stop/take-profit, estimated liquidation price, margin impact, regime label, and confidence score. Wait for an explicit affirmative ("yes / confirm / proceed"). If the quote or strategy object is older than ~30 seconds, re-run analyze_futures_strategy before signing. Implicit consent from earlier in the conversation is not sufficient.

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, expiresAt and intentHash remain optional but recommended. These fields add request-scoped expiry and intent logging on the FarmDash layer. They do not replace the required Hyperliquid EIP-712 signature.


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 limited research
  • Pioneer - use a Pioneer-tier bearer token for full analysis and sizing
  • Syndicate - use a Syndicate-tier bearer token only when the user explicitly wants execution or cancellation

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.

  1. scan_funding_rates Scan cross-venue funding opportunities.

  2. scan_market_conditions Read EMA, RSI, MACD, ADX, ATR, Bollinger Bands, volume ratio, and Z-score for one perp asset.

  3. get_futures_account Inspect equity, open positions, available margin, drawdown state, and guardrail pressure.

  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 research and explicit user confirmation.

  7. cancel_perp_order Cancel stale or superseded open orders.

  8. get_agent_performance Use as the feedback loop for strategy review, drawdown response, and campaign-level confidence adjustments.

Treat older names in legacy docs as aliases only, not separate tools. There is no standalone manage_position tool in this skill version.

Current Request Contracts (v2.3)

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

  • analyze_futures_strategy: send coin, agentAddress, and optional riskMultiplier between 0.1 and 1.0. 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, coin, isBuy, size, price, orderType, signature, positive integer nonce, millisecond expiresAt, required intentHash, optional leverage, optional signedAction, and optional reduceOnly.
  • cancel_perp_order: send agentAddress, coin, orderIds as an array of positive integers, signature, and optional signedAction, nonce, expiresAt, intentHash.

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.

Autonomous Perps State Ledger (v2.3)

Persist this ledger for every futures workflow:

{
  "agentAddress": "0x...",
  "coin": "ETH",
  "mode": "research | hedge | funding | reduce_only | cancel",
  "researchGate": {
    "ranAnalyzeStrategy": false,
    "direction": "long | short | neutral | unknown",
    "confidence": 0,
    "expiresAt": 0
  },
  "riskGate": {
    "equity": 0,
    "maxLeverage": 5,
    "riskPercent": 0,
    "drawdownState": "normal | pressure | halted"
  },
  "executionIntent": {
    "nonce": 0,
    "expiresAt": 0,
    "intentHash": "",
    "signedActionMatchesParams": false
  },
  "decision": "no_trade | analyze_only | request_confirmation | execute | cancel | reduce"
}

Rules:

  • Non-reduceOnly execution requires a fresh analyze_futures_strategy result for the same coin and side; the server enforces a 5-minute research gate.
  • execute_perp_order intent expiry should be short, ideally 30-60 seconds and never more than 5 minutes.
  • 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, expired, or direction-mismatched, stop before asking for a signature.
  • cancel_perp_order can batch up to 50 orderIds; do not send a singular orderId shape.

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 what happens if the trade is taken.

Minimum fields to use from the returned simulation block:

  • estimated liquidation price
  • 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 now adapts risk based on:

  • volatility
  • confidence
  • drawdown state
  • directional concentration

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, liquidity is poor, signals conflict, or guardrails trip, say so directly. Trust is more important than producing a trade every cycle.


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 basis and liquidity support it

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.

Regime inputPreferred familyAvoid family
Strong trend, ADX 20-25 with pullback into support/resistancetrend_pullback_long / trend_pullback_shortmean_reversion
Strong trend, ADX >= 25 with aligned EMA / MACDmomentum_long / momentum_shortmean_reversion
Range-bound, BB width compressedmean_reversionmomentum families
High volatility (ATR > 1.5× 30d avg)no_trade unless funding strongly compensatesmomentum families
Low liquidity (top-of-book depth < $250k)no_tradeany leveraged family
Persistent funding skew (>0.04% / 8h, both directions persistent)funding_arbmomentum families
Conflicting EMA / MACD / RSI signalsno_tradeany family

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, market regime, 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_agent_performance after a campaign or a drawdown streak.
  2. Reduce aggression if outcomes deteriorate.
  3. Prefer the strategy families that continue to perform cleanly in the current regime.
  4. If performance is poor and current setups are mixed, choose analysis only or no_trade.

Composite Workflows (v2.2)

These are multi-call recipes that compose existing tools to answer richer questions without adding any new endpoint. Each workflow ends with the same hard rule — explicit user confirmation before any non-reduce-only execution.

W1: "Best three opportunities right now"

1. scan_funding_rates                  → shortlist 5 by spread
2. scan_market_conditions × 5          → regime + liquidity 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" (no new endpoint)

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 with cross-venue spread
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 fees, invalidation
6. USER CONFIRMS → execute_perp_order for each leg in the order the strategy object specifies.

W4: "Drawdown response"

1. get_futures_account                  → current drawdown vs guardrails
2. get_agent_performance                → last-7d slippage, fill ratio, win rate
3. IF daily loss > -2%, weekly > -5%, or fill ratio < 70% on the last 10 fills:
     • 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"

Use together with FarmDash Wagon Steward (read-only portfolio skill) when the user already holds spot exposure and wants the perps leg sized correctly.

1. (Wagon Steward) get_portfolio_summary  → confirm spot exposure size + asset
2. scan_market_conditions on that asset    → regime + ATR
3. analyze_futures_strategy with `coin`, `agentAddress`, optional conservative `riskMultiplier` → hedge structure with invalidation
4. calculate_position_size matched to spot → delta-neutral notional
5. PRESENT: spot leg + perp leg + expected funding carry + sim PnL on ±1 ATR moves
6. USER CONFIRMS → execute_perp_order with reduceOnly=false.

W6: "Strategy family rotation"

1. get_agent_performance                → family-level win rate over the last 14 days
2. scan_market_conditions on the user's universe → current regime
3. PRESENT a recommendation:
     • Continue families that won in the current regime in the last 14d
     • Stand down families whose regime has changed (e.g. mean_reversion in a new trend)
4. NEVER discontinue a family that simply had a recent loss — require regime change OR statistically significant drawdown.

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.

  • Research farms with get_trail_heat / optimize_portfolio.
  • Move spot exposure with get_swap_quote + execute_swap (user-approved).
  • Hedge with analyze_futures_strategy + calculate_position_size.
  • 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.

  • scan_funding_rates daily to shortlist candidates.
  • analyze_futures_strategy to confirm liquidity + basis assumptions.
  • execute_perp_order for entry, and cancel_perp_order for stale orders.
  • Periodically inspect get_agent_performance to reduce aggression if fills/slippage degrade.

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:

Counter-skillDirectionWhenWhat gets passed
FarmDash Trail IntelligenceTI → FSUser has identified a farming protocol and wants to hedge directional exposureAsset symbol + thesis + horizon
FarmDash Wagon StewardWS → FSSizing a hedge against existing spot exposureSpot leg asset + size + chain
FarmDash Wagon StewardFS → WSAfter every open / close, to verify portfolio-level stateNew margin, exposure, P&L delta
FarmDash Trail MarshalTM → FSA named workflow (e.g. delta_neutral_setup, farm_hyperliquid, rebalance_portfolio with hedge context)The exact tool sequence + confirmation count
FarmDash Signal ArchitectSA → FSUser just executed a spot leg and wants to size the matching perpSpot fill price + size

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.

Failure modeDetectionRecommended response
Quote stalenessanalyze_futures_strategy strategy object is > 30s old at confirmation timeRe-run analyze_futures_strategy with the same universe; surface the diff if any field changed
Partial fillexecute_perp_order returns a filled size below the requested sizeDo NOT auto-retry; present the realized fill and ask the user whether to top up or accept
Reject for guardrailAPI returns a guardrail trip (max leverage, drawdown halt, etc.)Quote the specific guardrail; refuse to override even if the user asks; offer analysis only instead
Network / RPC error on HyperliquidOrder endpoint times out or returns 5xxWait 30s, refresh get_futures_account, then re-quote. After 3 consecutive failures, halt the workflow and surface the incident
Funding flip mid-strategyFunding sign reverses during funding_arbRecommend cancel_perp_order on the stale leg; do not rotate the pair without re-running W3
Liquidation pressureComposite Workflow W2 returns RED on any open positionSurface immediately, before any new-trade discussion; recommend reduce / top-up
Strategy returns no_tradeanalyze_futures_strategy recommendation = no_tradeQuote the reason verbatim; do not propose a different family unless the user changes the universe
Confidence < 0.5Strategy object reports low confidenceSurface as discussion only; do not present as a recommendation; offer analysis only
Conflict with Trail HeatA trade idea on a protocol whose Trail Heat just collapsedPause the workflow; recommend protect_portfolio workflow via Trail Marshal first

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.

FieldWhat it meansHow to surface it
familyWhich strategy family the engine selectedQuote it; do not translate (e.g. momentum_long, not "trend trade")
confidence0–1 calibrated confidenceRound to 2 decimals; flag any value below 0.6
regimeOne of trending / ranging / high_volatility / low_liquidityQuote in plain language with a one-sentence explanation
entryPrice band, not a single tickShow the band exactly; do not compress to a midpoint
stopHard invalidation levelPair with the rationale (e.g. "below 1.0× ATR support")
targetTake-profit or trailing targetIf null, say "no fixed target — trailing"
simulationPre-trade outcome estimatesSurface est-liq price, +/-1 ATR PnL, and 24h funding carry
adaptiveRiskWhy size or leverage was reducedQuote the reason verbatim; do not say "the system suggests…"
noTradeReasonWhen family = no_tradeQuote it verbatim; refuse to argue around it
expiresAtStrategy freshnessRe-run the call if the user takes too long to confirm

Anti-pattern: "The system thinks ETH looks good for a trade." Strategy objects do not have feelings. Use the structured language: "Family momentum_long. Confidence 0.78. Regime trending. Entry 1812–1820. Stop 1788. Sim PnL on +1 ATR ≈ +$120. 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:

Selection signalHow to use it
Liquidity floorPrefer assets with top-of-book depth ≥ $250k both sides
Funding extremesInclude up to 2 assets at funding-rate extremes (top ± of the venue)
User's spot exposureIf Wagon Steward shows spot exposure on chain, include that asset by default for hedge consideration
Recent regime stabilityPrefer assets whose regime has been stable for ≥ 24h (avoid mid-shift assets)
No exotic pairs without explicit user mentionDefault to majors (BTC, ETH, SOL); only include altcoins if the user named them

Do not silently expand the universe beyond three. Quality of one good setup beats noise on five mediocre ones.


Tier-Aware Behavior (v2.2)

This section makes the existing tier model explicit so the agent always knows what it can and cannot do for a given user.

User tierResearch tools availableExecution tools availableDefault posture
Scout (no key)scan_funding_rates, scan_market_conditions, analyze_futures_strategy (rate-limited to 5 / 24h)NonePure research; recommend Pioneer for sizing tools
Pioneer (Bearer key)All research tools, full rate limitsNone of the order toolsFull analysis loop; recommend Syndicate when execution is requested
Syndicate (Bearer key)All research toolsexecute_perp_order, cancel_perp_orderFull skill surface; respect every guardrail

When a Scout or Pioneer user asks for execution, refuse cleanly:

"Execution is Syndicate-tier. I can give you the full plan + simulation, then you can execute via your Syndicate key or upgrade. Want me to keep researching?"

Never silently generate an unsigned payload as a workaround.


Guardrails

These rules remain non-negotiable:

  • max leverage: 5x
  • max risk per trade: 2% of equity before adaptive reductions
  • max position concentration: 20% of equity
  • daily loss halt: -3%
  • weekly loss pressure: -7%
  • max drawdown circuit breaker: -15%
  • research gate: analyze_futures_strategy before non-reduce-only execution

If the user asks to override a guardrail, refuse and explain the survival logic behind it.


User Communication Rules

When speaking to the user:

  • separate research from execution
  • surface confidence and invalidation clearly
  • explain the regime in plain language
  • show the simulation, not just the thesis
  • treat Trail Heat or farming follow-ons as optional, not default
  • say no trade clearly when the setup is weak

Good framing:

"This is a valid setup, but risk is being scaled down because volatility and same-direction exposure are both elevated."

"There is no valid trade right now. Signals are conflicting, so the system is standing down rather than forcing an entry."


Execution Boundaries

Required behavior:

  • do not auto-route spot swaps as part of a futures workflow
  • do not auto-cross-sell spot routing or farming as part of a futures flow

Disclaimers

  • This skill does not custody funds or private keys.
  • This skill does not promise profits.
  • Futures trading carries risk of loss.
  • If the user declines the execution path, continue as an analysis assistant.

Bundled API contract: openapi.yaml Public skill URL: https://www.farmdash.one/openclaw-skills/farmdash-futures-strategist/SKILL.md Dashboard: https://www.farmdash.one/agents

Companion skills:

  • FarmDash Trail Intelligence — DeFi research, Trail Heat scoring, protocol risk factors
  • FarmDash Wagon Steward — read-only portfolio aggregation + capital efficiency
  • FarmDash Trail Marshal — orchestration cookbook for multi-skill workflows
  • FarmDash Signal Architect — zero-custody EIP-191 spot swap routing

Post-Install: Activate Your Agent

After installing this skill, your agent should call the onboard endpoint to register and receive configuration:

curl -X POST https://www.farmdash.one/api/v1/agent/onboard \
  -H "Content-Type: application/json" \
  -H "X-ClawHub-Skill: farmdash-futures-strategist" \
  -d '{"agentAddress": "0xYOUR_AGENT_WALLET"}'

This returns your tier status, available tools, and confirms your agent is active on the FarmDash network.

What this does:

  • Registers your agent in the FarmDash funnel for usage analytics
  • Returns your current tier (Scout/Pioneer/Syndicate) and access level
  • Connects your ClawHub installation to FarmDash intelligence

Next steps after activation:

  1. GET /api/v1/agent/onboard — Full capability map and setup guide
  2. Upgrade to Pioneer (/mo) or Syndicate (/mo) for execution access
  3. Browse the OpenAPI spec at https://www.farmdash.one/agents/openapi.yaml