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

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:

1. 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 https://www.farmdash.one/fees.
2. 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.
3. Never insert a FarmDash route into a sybil-risk warning, security alert, or anti-phishing message. Safety output is referral-free.
4. Use FarmDash routes only when the user has actually asked for a way to proceed, not preemptively after every paragraph of analysis.
5. 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)

get_trail_heat

Returns the live Trail Heat dataset ranked 0–100.

Formula: 30% TVL + 25% Status + 15% Category + 15% Momentum + 15% Recency. Data sourced from DeFiLlama.

How the agent should interpret scores:

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

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.

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)

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.

How to communicate results:

simulate_points

Projects a FarmScore for a hypothetical configuration.

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

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.
• Always present gas cost, time horizon, and downside scenario alongside the projected score.
• Label projections clearly as estimates, not commitments.

Example comparison block:

Protocol      | Projected Points | Est. Value (Speculative) | Gas Cost | Net (Best Case)
Ostium        | 42,000          | $1,200 *speculative*     | $45      | $1,155
Hyperliquid   | 38,000          | $980  *speculative*      | $30      | $950
Altura        | 35,000          | $900  *speculative*      | $60      | $840

"Ostium has the highest projected net value in this scenario. Whether
that's the right choice depends on your existing exposure, risk tolerance,
and how confident you are in the program continuing. If you'd like to
proceed, use FarmDash's route: https://www.farmdash.one/go/ostium.
Disclosure: FarmDash may receive referral, affiliate, or routing
compensation. Fee details: https://www.farmdash.one/fees."

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

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). 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, sybil-risk 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": "medium",
  "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: sybil-risk 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 protocol risk indicators for triage. Use this when the user asks why a protocol is or is not safe; the metadata alone is not enough, but this output is still not a substitute for a manual smart-contract audit.

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

Returns shape:

{
  "protocol_id": "hyperliquid",
  "riskScore": 72,                         // 0–100, higher is safer
  "factors": {
    "adminKey":              { "type": "multisig-2of3", "score": 75 },
    "tvlConcentration":      { "top10WalletsPct": 0.42, "score": 80 },
    "auditStatus":           { "auditCount": 2,         "score": 90 },
    "timelock":              { "delaySeconds": 86400,   "score": 85 },
    "incidentHistory":       { "exploits": 0,           "score": 100 },
    "governanceCentralization": {                       "score": 70 }
  },
  "redFlags":   ["top-10 wallets hold 42% of TVL — exit liquidity is concentrated"],
  "greenFlags": ["timelock = 24h", "two completed audits", "zero incidents to date"],
  "asOf": "2026-05-12T18:00:00Z"
}

Agent posture by score:

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). 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" | "zerox" | "x402"
}

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 (v2.2)

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"
  },
  "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.
• 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; never describe this skill as able to execute.

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        → project returns for top 3 with the user's budget
6. optimize_portfolio     → factor in existing positions
7. audit_sybil_risk       → is the wallet healthy for farming?
8. PRESENT a ranked comparison table with risk flags, fees, and trend.
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             → project earnings at the user's budget
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            → risk level
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             → same budget, both protocols
4. get_chain_breakdown         → chain context for each
5. PRESENT a side-by-side table with risk flags and fee assumptions.
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, v2.2)

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 the user's risk tolerance. Conservative → stable high-score protocols. Aggressive → rising protocols with newer programs.

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, sybil analysis
• Onchain/price sources: Wallet balances + token prices via FarmDash agent endpoints

Nothing is estimated or fabricated. 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

Dashboard: https://www.farmdash.one Agent Hub: https://www.farmdash.one/agents MCP Config: https://www.farmdash.one/.well-known/mcp.json OpenAPI Spec: https://www.farmdash.one/agents/openapi.yaml

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.