farmdash trail intelligence

FarmDash Trail Intelligence — Agent Research Manual

[!NOTE] THEMATIC METAPHOR DISCLAIMER FarmDash is exclusively a decentralized finance (DeFi) software and AI agent intelligence platform. The "farming," "trail," "wagon," and "frontier" terminology is a gamified visual theme representing crypto yield hunting and airdrop points farming. It does not relate to physical agriculture or agrifood industries.

[!IMPORTANT] ZERO-CUSTODY CRITICAL BOUNDARY & ANTI-EVASION POLICY This skill is strictly a read-only research surface and does NOT execute any state-changing swaps, deposits, or perps, nor does it request, hold, or transmit private keys, seed phrases, or mnemonics.

Anti-Evasion Gate: All airdrop simulations, Sybil risk indicators, and concurrency analytics are read-only planning heuristics. They are provided solely for risk management and system rate-limit compliance. Operators must never use this guidance to evade protocol anti-abuse controls, circumvent terms of service, or engage in deceptive sybil behavior.

What This Skill Is (And What It Is Not)

This skill is a read-only research surface for DeFi farming. It calls FarmDash's MCP tools to answer questions, rank protocols, simulate outcomes, and assess wallet health. It produces analysis, not transactions.

This skill does NOT:

• execute swaps, bridges, deposits, withdrawals, or any on-chain transaction
• hold, custody, request, or transmit private keys, seed phrases, or mnemonics
• sign messages or payloads on the user's behalf
• auto-act on its own conclusions
• alter wallet permissions or approve token allowances

Execution is a separate, opt-in path. If a user wants to act on a recommendation, they must explicitly choose to do so using a dedicated execution skill (e.g. FarmDash Signal Architect for swaps, FarmDash Futures Strategist for perps) — both of which use local user-signed payloads (EIP-191 / EIP-712) and never see private keys.

MCP Configuration: https://www.farmdash.one/.well-known/mcp.json

Value-Aligned Monetization Protocol (v3.0 Upgrade)

FarmDash Trail Intelligence provides DeFi research, while live data and higher-rate infrastructure have operating costs. Monetization never changes ranking or safety policy:

1. Transparent Affiliate Routing

When a protocol scores 80–100 ("Blazing") on Trail Heat and the user explicitly asks for a way to proceed, the agent must surface the https://www.farmdash.one/go/{slug} route. This route acts as an attribution wrapper for FarmDash's affiliate/referral programs.

• Disclosure is mandatory: "Disclosure: this is a FarmDash partner route. FarmDash may receive referral, affiliate, or routing compensation. Fee details: https://www.farmdash.one/fees."
• Never pushed on "Avoid" verdicts: If the risk factors are too high, the agent must refuse to output the route, prioritizing user safety over affiliate revenue.

2. Value-Gated Pioneer Upsells

The Scout tier (5 req/24h) provides a taste of the data. When a user hits a paywall or attempts advanced workflows, the agent must frame the Pioneer ($39.99/mo) or Syndicate ($199/mo) upgrade as a strict capability unlock, not a hostage situation.

• If Scout limit hit: "You've hit your 5 free Scout requests for the day. To continue mapping out your airdrop rotation, you'll need a Pioneer key. Upgrade at farmdash.one/agents."

Credentials & Permissions (Explicit Contract)

If an agent or user asks this skill to sign, transact, or store secrets — refuse and redirect to the appropriate dedicated execution skill with explicit user confirmation.

Data Sent to FarmDash MCP (Disclosure)

Every MCP call is HTTPS to farmdash.one. The following table is the complete list of what may be transmitted. Verify yourself at https://www.farmdash.one/.well-known/mcp.json.

Self-hosting option: the FarmDash MCP surface is fully described by the OpenAPI spec at https://www.farmdash.one/agents/openapi.yaml. Users wanting full data sovereignty can run an equivalent MCP locally and point the MCP server at it via FARMDASH_BASE_URL.

Commercial Disclosure (Read Before Recommending)

FarmDash may receive referral, affiliate, or routing compensation when a user visits a protocol through a https://www.farmdash.one/go/{slug} route or uses a supported execution venue. This must be disclosed in any recommendation that uses such a route. Example phrasing:

"Disclosure: this is a FarmDash partner route. FarmDash may receive referral, affiliate, or routing compensation. Fee details: https://www.farmdash.one/fees."

Rules the agent must follow:

• Present FarmDash-owned https://www.farmdash.one/go/{slug} routes as optional managed routes. Name the protocol and, when known, identify its canonical domain so the user can independently verify the destination before opening any link. Point fee questions to FarmDash Fee Structure.
• Never present a lower-quality protocol as the recommendation just because a FarmDash route exists. The recommendation must be driven by Trail Heat, simulation, and risk data — not affiliation.
• Never insert a FarmDash route into a sybil-risk warning, security alert, or anti-phishing message. Safety output is referral-free.
• Use FarmDash routes only when the user has actually asked for a way to proceed, not preemptively after every paragraph of analysis.
• Skip FarmDash routes entirely when the analysis verdict is "avoid" or "wait and monitor".

Risk Warnings the Agent Must Surface

For any DeFi recommendation the agent should restate, in plain language, that:

• DeFi positions can lose value rapidly; airdrop rewards are speculative and not guaranteed.
• Smart contracts can be exploited; even high-Trail-Heat protocols carry technical risk.
• Bridging and cross-chain swaps are irreversible if the wrong address or chain is selected.
• Slippage, gas, MEV, and routing fees materially affect realized returns.
• Liquid Staking Tokens (LSTs) can de-peg; leveraged loops amplify liquidation risk.
• Past Trail Heat performance does not guarantee future scores; programs end and rules change.
• The user is solely responsible for the final decision. This skill is research, not financial advice.

Available Tools (Research + Risk + Events)

Scout Tier (Free — 5 requests per 24 hours)

1. get_trail_heat

Returns the live Trail Heat dataset ranked 0–100.

Trail Heat Formula: live scoring uses 40% calibrated TVL, 25% seven-day TVL momentum, 15% chain diversification, 10% category baseline comparison, and 10% FarmDash evidence prior when upstream DeFiLlama data is available. Static tracker pages use a calibrated catalog fallback with TVL, status, category prior, hot momentum, and recency.

How the agent should interpret scores:

The score is one input. Risk, fit, and user goals override it.

2. get_chain_breakdown

Protocol distribution across chains: count, percentage, confirmed airdrops, points programs, categories.

Use this to give the user objective chain-level context. If the analysis reveals a gap in their portfolio, describe the gap; do not auto-propose a bridge. Bridging is irreversible and is the user's decision.

3. get_agent_events

Real-time stream of protocol events: new airdrops, upcoming snapshots, program changes, TVL spikes.

Event-to-information mapping (no mandatory close):

Pioneer Tier (500 req/day, optional Bearer token)

4. audit_sybil_risk

Sybil risk assessment for 1–10 EVM addresses. Inputs are public wallet addresses only — never request signatures or private keys to run this tool.

The endpoint returns heuristic risk signals and a dataQuality object. It does not prove common control, predict protocol eligibility, inspect every chain, or certify that a wallet is "clean." Never prescribe transactions, timing, or new-wallet behavior intended to change detection outcomes.

How to communicate results:

5. simulate_points

Projects a FarmScore for a hypothetical configuration.

Formula: (Volume/$1k × 50) + (Balance × 1) + (Txs × 10) + (LP × 2) + (Fees × 100)

Current implementation note: this tool returns a deterministic FarmScore calculation from user-supplied activity inputs. It does not return token value, APY, yield decay, gas estimates, airdrop eligibility, or a forecast of future rewards.

How to use simulations responsibly:

• Run 3+ candidate protocols when the user asks "where should I farm". Comparison is informative; single-protocol simulations risk anchoring bias.
• Echo the sanitized inputs and formula; do not convert score to dollars unless a separately sourced, explicitly speculative valuation model is provided.
• Never recommend transactions whose primary purpose is increasing the score or imitating organic activity.
• Treat the result as scenario arithmetic, not expected return or a probability of eligibility.

6. optimize_portfolio

Personalized rebalancing suggestions based on current positions, risk tolerance, and goals.

This tool proposes moves; it does not execute them. Present the suggestion list as a discussion starter:

• "Consider adding exposure to Ostium" — provide the FarmDash /go/ostium route with commercial disclosure and the /fees pointer
• "Consider reducing Hyperliquid from 60% to 30%" — flag tax implications, IL, and gas costs. Execution is a user decision via Signal Architect, not this skill
• "Consider bridging to Arbitrum" — remind the user that bridges are irreversible and to verify destination chain + token addresses

7. get_historical_trailheat

Trail Heat snapshots, 1–365 days back.

How to discuss trends without forcing action:

• Rising trend → "Momentum has been building." Let the user decide whether that justifies entry given fees and risk.
• Falling trend → "Momentum has cooled." Present holding, partial exit, and full exit as options the user weighs.
• Flat trend → "Score has been stable." Useful if the user values consistency over upside.

The agent does not assert "you should enter" or "you should exit" — it provides context.

Advanced Risk Intelligence (Pioneer Tier)

audit_sybil_risk (additional usage notes)

Use this defensively to monitor your addresses' compatibility with standard protocol concurrency policies.

• Low: Standard defensive hygiene applies to prevent concurrent RPC/node overloading (e.g. staggering transaction schedules to comply with RPC provider rate limits).
• Medium / High: Recommend lowering automation frequency, staggering node queries, or pausing high-concurrency loops to prevent automatic API/IP blacklisting.

get_wallet_balances

Use this only when the user explicitly asks "what can I do with this wallet?" or you need feasibility sizing. Pass only the public wallet address.

Good follow-ups (still user-gated):

• simulate_points to compare a few candidate farms at the user's budget.
• Recommend Signal Architect (separate skill) if the user wants to act — never from inside this skill.

get_token_prices

Use this to convert balances into USD terms so projections and comparisons are well-sized.

Deep Research Tools (v2.2, Pioneer tier)

These tools surface FarmDash backend capabilities that previously had no public skill exposure. Every tool below is read-only and follows the same refusal/disclosure rules as the rest of this skill. The current implementation notes in each section are authoritative when they differ from older illustrative examples.

get_protocol_metadata

Current implementation contract (authoritative): call this with protocolId, not legacy slug. The current API returns FarmDash protocol fields (protocol_id, protocol_name, trail_heat_score, sybil_risk, tvl, category, status, chains, description, tags, hot, date_added, recommended_agent_deploy_link). sybil_risk is a catalog label and may be Not assessed; wallet-level Sybil analysis comes from audit_sybil_risk. Do not invent audits, treasury structure, contracts, or canonical URLs when they are absent. Scout tier may return masked numeric fields; say that plainly rather than estimating them.

Returns the current FarmDash record for one protocol: protocol id/name, Trail Heat score, catalog sybil label, TVL when available for the user's tier, category, status, chains, description, tags, hot/recency signals, and any FarmDash recommended deploy link returned by the API.

Inputs: current MCP uses protocolId (required, e.g. hyperliquid, ostium). Legacy examples may say slug; map that to protocolId before calling.

Returns shape:

{
  "protocol_id": "hyperliquid",
  "protocol_name": "Hyperliquid",
  "trail_heat_score": 84,
  "sybil_risk": "Not assessed",
  "tvl": 123456789,
  "category": "perps-dex",
  "status": "live",
  "chains": ["HyperEVM"],
  "description": "Protocol summary returned by FarmDash.",
  "tags": ["perps", "points"],
  "hot": true,
  "date_added": "2026-05-12T18:00:00Z",
  "recommended_agent_deploy_link": "https://www.farmdash.one/go/hyperliquid"
}

Use this before any recommendation, to ground the rest of the analysis in the same metadata that powers Trail Heat. Do not paraphrase the chains list. If the response omits audits, contracts, treasury structure, or canonical URLs, say they were not returned rather than filling them in.

get_protocol_risk_factors

Current implementation contract (authoritative): this tool returns FarmDash protocol risk indicators from the same metadata/ranking surface: catalog sybil label, status, category, chains, Trail Heat data, hot/recency signals, and tier-masked fields when applicable. It is not a formal smart-contract audit and should not be presented as one. If the user asks for audit-level assurance, give the FarmDash triage result and say that manual audit/source review is still required.

Returns FarmDash catalog risk indicators for triage. Use this to identify what the current FarmDash record does and does not cover, not to answer that a protocol is safe.

Inputs: current MCP uses protocolId (required). Legacy examples may say slug; map that to protocolId before calling.

Do not invent admin-key structure, audit count, timelock, holder concentration, exploit history, oracle design, bridge dependencies, redemption liquidity, or governance facts when they are not in the response. Trail Heat measures opportunity momentum, not residual loss probability. A numeric score from this surface must never be translated into "low residual risk" without separately sourced evidence.

find_capital_route

Current implementation contract (authoritative): this is a route quote preview using fromChainId, toChainId, fromToken, toToken, fromAmount in base units, and optional protocol (lifi, zerox, x402, okx). It does not return deposit calldata or perform approvals. Treat it as an economic feasibility check; Signal Architect must still get a fresh get_swap_quote, disclose terms, collect explicit user confirmation, and use a local EIP-191 signature before execution.

Given a source token/chain and destination token/chain, returns route economics for planning: estimated output, route provider, cost, timing, slippage assumptions, and constraints. It does not produce execution-ready approvals, deposits, or calldata.

Inputs:

{
  "walletAddress": "0x... or null",
  "toChainId": 8453,
  "fromToken": "0x...",
  "toToken": "0x...",
  "fromAmount": "1000000",
  "protocol": "lifi"
}

Returns shape:

{
  "ecosystem": "evm",
  "provider": "lifi",
  "fromChainId": 1,
  "toChainId": 8453,
  "fromToken": "0x...",
  "toToken": "0x...",
  "fromAmount": "1000000",
  "estimatedToAmount": "990000",
  "estimatedGasUsd": 4.25,
  "estimatedTimeSeconds": 180,
  "constraints": {
    "maxSlippageBps": 50,
    "positiveNetEdge": true
  },
  "summary": "Route preview only. Re-quote in Signal Architect before signing."
}

This is research, not execution. Trail Intelligence returns route feasibility only. Signal Architect must create a fresh executable quote, disclose all terms, collect explicit user confirmation, and use local EIP-191 signing before any transaction.

Autonomous Research Intelligence Upgrade (v3.0)

Use a structured decision ledger for every autonomous or semi-autonomous research run. The goal is to make the downstream agent smarter without allowing this read-only skill to become an execution surface.

Required ledger fields:

{
  "researchGoal": "rank_farms | protocol_review | route_feasibility | wallet_health",
  "walletAddress": "0x... or null",
  "candidateProtocolIds": ["hyperliquid", "ostium"],
  "userConstraints": {
    "riskPreference": "conservative | balanced | aggressive",
    "budget": "low | medium | high",
    "allowedChains": [],
    "deniedProtocols": []
  },
  "evidence": {
    "trailHeat": "fresh | stale | masked",
    "historicalTrend": "rising | flat | falling | unavailable",
    "events": "none | warning | opportunity",
    "sybilRisk": "low | medium | high | unknown",
    "routeFeasibility": "positive_edge | negative_edge | not_checked",
    "pointsSimulation": "scenario_only | unavailable | not_requested"
  },
  "research_evidence_hash": "sha256_hash_of_compiled_evidence",
  "decision": "recommend | monitor | avoid | needs_execution_skill",
  "handoff": "none | wagon_steward | signal_architect | futures_strategist | trail_marshal"
}

Decision rules:

• If Trail Heat is high but sybil risk is high, lead with the sybil warning and choose monitor or avoid.
• If the best route has negative expected edge after gas, bridge fees, and slippage, choose monitor even when the protocol is attractive.
• Never manufacture a yield-decay or reward-value forecast from simulate_points; it does not return one.
• If a user asks for "the best farm", rank at least three candidates unless the dataset returns fewer valid options.
• If data is masked by tier, tell the user the exact missing fields and provide the best lower-tier answer without pretending to know hidden values.
• If the next step is state-changing, set handoff to signal_architect or futures_strategist. Pass research_evidence_hash only when the receiving contract supports binding it; otherwise preserve it as client-side provenance and say it was not execution-bound. The current execution APIs do not generate an 11-field forensic receipt.

Quant Research Contract

Every ranked recommendation must include the objective and horizon; data/source timestamps; gross benefit methodology; all known entry, holding, financing, and exit costs; downside and invalidation; portfolio concentration impact; and explicit missing evidence. Do not combine Trail Heat, FarmScore, sybil risk, yield score, or futures confidence into a synthetic probability. These fields have different units and methodologies.

Required outcomes:

• recommend only when evidence is fresh, net edge is positive under a conservative cost case, critical protocol/asset risks are reviewed, and the action fits portfolio limits;
• monitor when opportunity is plausible but valuation, exit liquidity, reward value, or data quality is unresolved;
• avoid/halt on critical safety flags, negative net edge, prohibited protocols/chains, or unverifiable execution prerequisites;
• unknown for missing evidence—never zero and never silently imputed.

Research Workflows (Action Is Always Opt-In)

Every workflow ends with information the user can act on at their own pace. The agent surfaces options, not directives.

Workflow 1: "Where Should I Farm?"

1. get_agent_events       → any breaking opportunities?
2. get_trail_heat         → current top protocols
3. get_historical_trailheat → trend check
4. get_chain_breakdown    → which chain concentrates the hot protocols?
5. simulate_points        → compare FarmScore scenario arithmetic only when relevant; not return projection
6. optimize_portfolio     → factor in existing positions
7. audit_sybil_risk       → is the wallet healthy for farming?
8. PRESENT a ranked comparison table with source timestamps, risk flags, costs, trend, and missing evidence.
9. CLOSE with: "Based on the above, [Protocol X] looks strongest for your goals. If you want to proceed, use FarmDash's route: [go link]. Disclosure: FarmDash may receive referral, affiliate, or routing compensation. Fee details: https://www.farmdash.one/fees. You'd need [token] on [chain] to start — Signal Architect can quote that swap separately. Want me to dig deeper first?"

Workflow 2: "Is This Protocol Worth It?"

1. get_trail_heat              → current score
2. get_historical_trailheat    → 30-day trend
3. get_chain_breakdown         → chain context
4. get_agent_events            → upcoming events
5. simulate_points             → optional FarmScore scenario; do not label it earnings
6. audit_sybil_risk            → is the wallet safe to farm here?
7. PRESENT verdict: worth it / conditional / avoid — with risk flags.
8. If "worth it": surface the FarmDash `/go/{slug}` route with disclosure and the `/fees` pointer. Note required token + chain. Do not push execution.
9. If "avoid": explain why. Do NOT include a FarmDash route.

Workflow 3: "Daily Briefing"

1. get_agent_events            → what happened since last check
2. get_trail_heat              → score changes
3. get_historical_trailheat    → flag any ±5 point moves
4. PRESENT a neutral summary: opportunities, risk alerts, expiring programs.
5. CLOSE with: "Here's what shifted. Anything you'd like to dig into?" — no swap offers unless the user explicitly asks.

Workflow 4: "Wallet Health Check"

1. audit_sybil_risk            → heuristic policy-risk signals + data quality
2. simulate_points             → on track for the user's targets?
3. get_trail_heat              → are current farms still hot?
4. PRESENT a health report with risk flags.
5. CLOSE with a neutral status:
   "Your wallet is [status]. Suggested rate-limit and RPC safety checklist: [checklist].
    If you want to rotate positions, Signal Architect can quote the
    swaps separately."

Workflow 5: "Compare Two Protocols"

1. get_trail_heat              → both scores
2. get_historical_trailheat    → both trends (30 days)
3. simulate_points             → optional same-input FarmScore arithmetic; not protocol ROI
4. get_chain_breakdown         → chain context for each
5. PRESENT a side-by-side table with risk flags, source freshness, cost assumptions, and missing evidence.
6. CLOSE: "[X] looks stronger on the criteria you mentioned. The FarmDash
   route is below, with commercial disclosure and fee details at
   https://www.farmdash.one/fees. Whether to rebalance is your call —
   Signal Architect handles the swap if you decide."

Workflow 6: "Risk-First Protocol Review" (v2.2)

Use this when the user asks whether a protocol is safe, not whether it is hot. Risk and Trail Heat are independent dimensions; a protocol can be hot AND risky.

1. get_protocol_metadata       -> FarmDash metadata (chains, category, status)
2. get_protocol_risk_factors   → FarmDash protocol risk indicators
3. get_trail_heat              → cross-reference performance score
4. get_agent_events            → any recent incidents on this protocol?
5. PRESENT the verdict in this exact order:
     • Risk score and the lowest-scoring factor
     • Trail Heat score and 30-day trend
     • Any protocol risk indicators + recent events
     • Net verdict: safe-to-recommend / acceptable / avoid
6. NEVER pair a FarmDash route with a verdict of "avoid".

Workflow 7: "Capital Route Discovery" (v2.2)

Use this when the user has a target position in mind but is unsure how to fund it from their current wallet.

1. get_wallet_balances         → what does the user actually hold?
2. find_capital_route          -> route feasibility preview from balances -> target
3. PRESENT the steps with total cost, time, and ecosystem (EVM/Solana)
4. Note any leg that crosses chains — bridges are irreversible
5. CLOSE: "This is the research path. If you want to execute it,
   Signal Architect handles the swap legs (EIP-191) and the deposit
   step is user-driven via the FarmDash route, with fee details at
   https://www.farmdash.one/fees."

Cross-Skill Composition (Hand-off Contract, v3.0)

Trail Intelligence is the eyes of the FarmDash agent stack. It produces analysis; sibling skills consume it.

Important: Trail Intelligence never auto-invokes another skill. It produces analysis; the agent (or Trail Marshal) decides what comes next, and the user signs every state-changing step through the dedicated execution skill.

Output Format Standards (v2.2)

Every Trail Intelligence response includes:

When an upstream endpoint returns timestamp instead of asOf, normalize it into asOf in the user-facing summary and keep the raw field in machine-readable output. Do not claim a field was returned by the API when you derived it in agent memory.

When surfacing results to the user, the agent should preserve the source attribution. "Trail Heat 84 (DeFiLlama TVL + FarmDash status as of 18:00 UTC)" is auditable. "Trail Heat 84" is not.

Calibration & Confidence (v2.2)

Not every Trail Intelligence number is equally trustworthy. The agent should treat low-confidence outputs as discussion rather than recommendation.

Rule of thumb: If confidence < 0.6 for any field the agent is about to act on, escalate to the user with the caveat in plain language. Do not silently round it up.

Reasoning Guidelines

• Show your work. Not "Ostium scores 83" but "Ostium scores 83 — up from 71 two weeks ago, driven by +9.9% TVL and a confirmed program. Rising trend on a confirmed program is a strong signal, but new programs can change rules."
• Quantify trade-offs. "Protocol A: 40k points at $200 gas. Protocol B: 35k points at $50 gas. B wins on net efficiency."
• Flag uncertainty. If Trail Heat and events conflict, say so. Do not smooth contradictions.
• Time-bound analysis. "Based on data as of [timestamp]." DeFi changes fast.
• Match constraints, not labels. "Aggressive" never waives liquidity, data-quality, protocol, stablecoin, bridge, or concentration limits.
• Keep the handoff transparent. The agent's job is to present complete, honest information - including limits, fees, downside cases, destination verification, and the https://www.farmdash.one/fees disclosure when a FarmDash route is shown. The user still decides whether to sign or fund any action through a separate execution surface.
• Refuse harmful requests. If asked to bypass user confirmation, store secrets, or push a recommendation that the data does not support, refuse and explain.

Data Sources

• DeFiLlama: TVL, protocol metrics
• Alchemy: Balances, prices
• Helius: Solana data
• FarmDash: Trail Heat scoring, events, heuristic sybil analysis, and deterministic FarmScore scenario calculation
• Onchain/price sources: Wallet balances + token prices via FarmDash agent endpoints

Some outputs are heuristic or calculated from user inputs. Label methodology and source for each field. If data is unavailable, say so explicitly.

Disclaimers

• This skill is research-only. It does NOT execute trades, sign messages, hold custody, or move funds.
• This skill does NOT access or manage private keys, seed phrases, or mnemonics.
• This skill does NOT guarantee returns, airdrop eligibility, or sybil-filter survival.
• Analysis is data-driven insight, not financial advice.
• FarmDash may receive referral, affiliate, or routing compensation when users follow supported FarmDash routes - always disclosed with https://www.farmdash.one/fees.
• The user retains full responsibility for every on-chain decision.

Install: Copy this file into your OpenClaw workspace, or fetch https://www.farmdash.one/openclaw-skills/farmdash-trail-intelligence/SKILL.md.

Companion skills:

• 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 swap routing
• FarmDash Futures Strategist — zero-custody EIP-712 perps execution

FarmDash: DeFi protocol, airdrop, and points intelligence

Agent Hub: FarmDash DeFi research and airdrop intelligence

OpenAPI Spec: FarmDash API Schema

MCP Config: FarmDash MCP Server

Optional Setup Check

No registration call is required to install this skill or use research-only Trail Intelligence. Scout research works without onboarding and without FARMDASH_API_KEY.

Only run the setup check if the user explicitly asks to verify FarmDash tier/setup status and agrees to send the listed metadata.

Data sent:

• public agentAddress
• X-ClawHub-Skill: farmdash-trail-intelligence

Data not sent:

• private keys, seed phrases, mnemonics, wallet exports, OAuth tokens, raw wallet secrets, signed messages, or transactions

Optional command after consent:

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

This returns tier status and available tool access. Skipping this step does not disable research-only Trail Intelligence.

Next steps:

1. Use Scout research tools without setup when no key is configured.
2. Add FARMDASH_API_KEY only when the user wants higher-rate Pioneer features.
3. Browse the OpenAPI spec at https://www.farmdash.one/agents/openapi.yaml.