hive-intelligence 1.1.4 → 1.4.0

package/agent-skills/packs/hive-defi-research/SKILL.md

@@ -1,42 +1,128 @@
 ---
 name: hive-defi-research
-description: Use this skill for DeFi protocol and chain research covering TVL, fees, revenue, yields, stablecoins, bridges, protocol slugs, and chain-level DeFi metrics. Use it for current protocol comparisons and freshness-sensitive DeFi analysis.
+description: Use this skill when the user asks about DeFi protocol metrics — TVL, fees, revenue, yields, APY, stablecoin supply, bridge volume, or chain-level DeFi totals — or wants protocols compared ("Aave vs Compound", "top protocols by TVL", "best stablecoin yields"). Use it whenever the answer needs current protocol-level numbers. For token prices and venue data use hive-market-research; for a specific pool's depth use hive-dex-pool-analysis.
 license: MIT
 metadata:
   package: "@hiveintelligence/agent-skills"
   category: "defi"
   requires_network: "true"
-version: 1.0.0
+version: 1.4.0
 ---
 
 # hive-defi-research — DeFi Protocol Analysis
 
-Use this skill for protocol, TVL, fees, yield, stablecoin, bridge, or chain
-DeFi questions.
+Answer protocol, TVL, fee, revenue, yield, stablecoin, bridge, and chain-level
+DeFi questions with like-for-like, timestamped metrics.
 
-## Task toolset
+## Task toolset and identifiers
 
-Use `defi_protocol_analysis`.
+Toolset: `defi_protocol_analysis`. Read
+`hive://toolsets/defi_protocol_analysis` before execution; it is authoritative
+for the current output schema, material-call budget, phases, fallback
+condition, and stop conditions.
 
-Required identifiers: protocol name or chain.
+- Required: protocol name/slug or chain.
+- Optional: time window, metric type, yield pool, stablecoin, bridge.
 
-## Procedure
+Ask for a protocol slug, or choose a provider-supported slug only when the
+user clearly named the protocol.
+
+Before choosing endpoints, select exactly one matching entry from the exact
+workflow's routes[]. Follow its ordered steps, use a fallback only under that
+step's published condition, stop at four material calls, and preserve the
+selected route_id in the typed result. The broad coverageCatalog is discovery
+coverage, not an execution plan.
 
-Read `references/workflow.md` when the request needs protocol comparison,
-metric normalization, timestamp caveats, or a structured DeFi report.
+## Procedure
 
 1. Resolve the protocol slug or chain name.
-2. Pull TVL, fee/revenue, yield, bridge, stablecoin, or chain metrics depending
-   on the user question.
-3. Compare protocols only with like-for-like metrics and timestamps.
-4. State if a metric is unavailable or stale.
+2. Call `search_tools` for protocol, TVL, fee/revenue, yield, stablecoin,
+   bridge, or chain-metric capabilities.
+3. Call `get_api_endpoint_schema` for each endpoint before calling it.
+4. Pull only the metrics the question needs.
+5. Compare protocols only with like-for-like metrics and timestamps, and
+   state when a metric is unavailable or stale.
+
+## Bounded calls
+
+- Limit protocol lists and yield pools.
+- Avoid comparing TVL snapshots from different dates without a caveat.
+- Mark missing fee/yield/stablecoin metrics instead of omitting them.
+
+## Worked example
+
+User: "Compare Aave and Compound — TVL and fees, which one actually earns
+more?"
+
+1. `search_tools` → `{"query": "protocol tvl fees revenue defi", "limit": 5}`
+2. `get_api_endpoint_schema` for the protocol-metric endpoints returned, then
+   `invoke_api_endpoint` once per protocol slug with schema-valid arguments.
+3. Normalize: same metric definitions, same window, same timestamps.
+4. Summarize the comparison in a table, with provider and `fetched_at` per
+   metric, using the report template.
+
+## Report template
+
+```markdown
+## Summary
+[Protocol or chain DeFi read in one or two sentences.]
 
-## Example
+## Calls made
+- Toolset: defi_protocol_analysis
+- Endpoint(s): [exact endpoint names]
+- Identifiers: [protocol slugs, chains, metric filters]
 
-For "compare Aave and Compound", run protocol-level TVL and fee/yield checks for
-each, then summarize differences in a table.
+## Evidence
+- TVL: [value + as-of]
+- Fees/revenue: [value + window]
+- Yields/stablecoins/bridges: [if requested]
+- Provenance: [provider, fetched_at, observed_at/cache_age_ms, runtime status per call]
+
+## Caveats
+[Unavailable metrics, stale snapshots, methodology differences.]
+
+## Next action
+[Compare peers, inspect a yield pool, or add token/pool diligence — only if needed.]
+```
+
+## Gotchas
+
+- TVL, revenue, and fees answer different questions — do not substitute one
+  for another.
+- High APY without liquidity/risk context is not a recommendation.
+- Provider methodology can differ across chains and protocols.
+
+## Evidence receipt (required)
+
+End every Hive-backed answer with a compact receipt built from the `_hive`
+object on each material tool response:
+
+- `provider`, `tool`, `fetched_at`, `observed_at`, `cache_age_ms`, and `runtime_status`
+- `receipt_id`, `receipt_version`, server/build version, and SHA-256 input/result
+  digests when present (self-checks, not signatures)
+- `source`, `cache_status`, `truncated`, and any warnings
+- canonical chain/entity identifiers plus block, slot, transaction, or query ids
+  present in provider data
+- material provider disagreements and how they were handled
+- checks that were unavailable, gated, stale, truncated, or intentionally not run
+- a `claims[]` citation from each material statement to exact receipt IDs
+- one `coverage[]` entry for every canonical evidence phase, with each gap explained
+
+Never turn missing evidence into a clean result, silently merge conflicting
+provider values, or omit a degraded/fallback call from the receipt.
+`observed_at` is Hive's first-observation/original cache-population time, and
+`cache_age_ms: 0` only means newly retrieved by Hive. Use provider time, block,
+slot, transaction, or candle close for source recency; if absent, mark it
+unknown. Run `validate_task_result` before presenting the typed workflow result;
+it checks structure but cannot authenticate an invented receipt.
 
 ## Runtime status handling
 
-Treat unreliable or temporarily unavailable DeFi endpoints as `degraded`.
-Do not silently omit a metric; mark it unavailable with the runtime status.
+Treat unreliable or temporarily unavailable DeFi endpoints as `degraded`. Do
+not silently omit a metric; mark it unavailable with the runtime status.
+
+## Hand-offs
+
+- Token price/market questions → `hive-market-research`.
+- One pool's depth and trades → `hive-dex-pool-analysis`.
+- Protocol token risk → `hive-token-diligence` or `hive-security-risk`.

package/agent-skills/packs/hive-defi-research/evals/evals.json

@@ -3,13 +3,15 @@
   "evals": [
     {
       "id": 1,
-      "prompt": "Compare Aave and Compound by current TVL, fees, and yield context.",
-      "expected_output": "Uses defi_protocol_analysis, resolves protocol slugs, fetches like-for-like metrics with timestamps, and marks missing/stale data.",
+      "prompt": "Compare Aave and Compound by current TVL and fees.",
+      "expected_output": "Uses defi_protocol_analysis, resolves protocol slugs, fetches like-for-like metrics with timestamps, marks missing/stale data, and ends with a runtime evidence receipt.",
       "files": [],
       "assertions": [
         "Chooses defi_protocol_analysis.",
+        "Selects protocol_economics for the comparison and stays within its four-call budget.",
         "Normalizes metrics and timestamps.",
-        "Caveats missing or stale metrics."
+        "Caveats missing or stale metrics.",
+        "Includes receipt ids and provider disagreements."
       ]
     },
     {
@@ -19,6 +21,7 @@
       "files": [],
       "assertions": [
         "Uses chain-level DeFi workflow.",
+        "Selects chain_protocol_landscape and does not fan out across every listed protocol.",
         "Bounds the result list.",
         "Reports provider and freshness."
       ]

package/agent-skills/packs/hive-defi-research/evals/triggers.json

@@ -0,0 +1,50 @@
+[
+  {
+    "query": "compare aave and compound tvl and fees — which one actually earns more",
+    "should_trigger": true
+  },
+  {
+    "query": "top defi protocols on arbitrum by tvl right now",
+    "should_trigger": true
+  },
+  {
+    "query": "best stablecoin yields at the moment and how sketchy are they",
+    "should_trigger": true
+  },
+  {
+    "query": "is curve's revenue growing or shrinking this quarter",
+    "should_trigger": true
+  },
+  {
+    "query": "how much bridge volume went between ethereum and base this month",
+    "should_trigger": true
+  },
+  {
+    "query": "which chains are gaining defi tvl the fastest",
+    "should_trigger": true
+  },
+  {
+    "query": "whats the price of CRV",
+    "should_trigger": false
+  },
+  {
+    "query": "how deep is the curve 3pool, recent swaps?",
+    "should_trigger": false
+  },
+  {
+    "query": "is the AAVE token itself safe? holders, liquidity?",
+    "should_trigger": false
+  },
+  {
+    "query": "explain how lending protocols work",
+    "should_trigger": false
+  },
+  {
+    "query": "watch aave tvl and alert me on a 10% drop",
+    "should_trigger": false
+  },
+  {
+    "query": "what does the aave treasury wallet hold",
+    "should_trigger": false
+  }
+]

package/agent-skills/packs/hive-dex-pool-analysis/SKILL.md

@@ -1,41 +1,131 @@
 ---
 name: hive-dex-pool-analysis
-description: Use this skill for on-chain DEX and pool analysis covering pools, pairs, swaps, liquidity, trades, OHLCV, trending pools, and token-level DEX flow. Use exact chain, pair, pool, or token identifiers before selecting tools.
+description: Use this skill when the user asks about a DEX pool or trading pair — liquidity depth, recent swaps/trades, OHLCV candles, trending pools, fee tiers, or token-level DEX flow on a chain — including "how deep is the X/Y pool", "what's trading on Uniswap", or a pasted pair address. For CEX prices, order books, and funding use hive-market-research; for whole-token diligence use hive-token-diligence.
 license: MIT
 metadata:
   package: "@hiveintelligence/agent-skills"
   category: "dex"
   requires_network: "true"
-version: 1.0.0
+version: 1.4.0
 ---
 
 # hive-dex-pool-analysis — DEX And Pool Analysis
 
-Use this skill for pool, pair, swap, liquidity, DEX trend, or token flow
-questions.
+Analyze on-chain DEX pools and pairs: liquidity, swaps, OHLCV, trends, and
+token-level DEX flow, keeping pool-level and token-level facts clearly
+separate.
 
-## Task toolset
+## Task toolset and identifiers
 
-Use `onchain_dex_pool_analysis`.
+Toolset: `onchain_dex_pool_analysis`. Read
+`hive://toolsets/onchain_dex_pool_analysis` before execution; it is
+authoritative for the current output schema, material-call budget, phases,
+fallback condition, and stop conditions.
 
-Required identifiers: chain and pair address or token contract.
+- Required: chain/network plus pair/pool address, token contract, or both
+  token sides.
+- Optional: DEX name, time window, candle interval, trade direction.
+
+If the user gives only one token, search candidate pools and prefer the pool
+most relevant by liquidity/volume — and say which pool you chose, because the
+same pair can have several pools with different fee tiers.
+
+Before choosing endpoints, select exactly one matching entry from the exact
+workflow's routes[]. Follow its ordered steps, use a fallback only under that
+step's published condition, stop at four material calls, and preserve the
+selected route_id in the typed result. The broad coverageCatalog is discovery
+coverage, not an execution plan.
 
 ## Procedure
 
-Read `references/workflow.md` when the request needs pool/pair resolution,
-liquidity context, trade-flow comparison, or a structured DEX report.
+1. Resolve chain and pool/pair/token identifiers.
+2. Call `search_tools` for pair search, pool info, liquidity, trades, OHLCV,
+   and trending-pool capabilities.
+3. Call `get_api_endpoint_schema` for each endpoint before calling it.
+4. Start with pool/pair metadata and liquidity; add trades/OHLCV for flow or
+   trend questions.
+5. Report liquidity depth, recent flow, and data freshness.
+
+## Bounded calls
+
+- Limit trade lists and candle counts.
+- Do not infer token-wide liquidity from one pool without saying so.
+- Keep pool-level and token-level metrics separate.
+
+## Worked example
+
+User: "How deep is the main PEPE/WETH pool on Ethereum, and which way has
+flow gone today?"
+
+1. `search_tools` → `{"query": "dex pair search pool liquidity trades ethereum", "limit": 5}`
+2. Resolve candidate pools for PEPE
+   (0x6982508145454Ce325dDbE47a25d4ec3d2311933), pick the deepest PEPE/WETH
+   pool, and state the choice.
+3. `get_api_endpoint_schema` then `invoke_api_endpoint` for pool info,
+   liquidity, and a bounded trade list (explicit limit, today's window).
+4. Report depth, net flow direction, and freshness with the template below.
+
+## Report template
+
+```markdown
+## Summary
+[Pool/liquidity/trade-flow read in one or two sentences.]
 
-1. Resolve the chain and pair/token identifier.
-2. Pull pool info, liquidity, trades, OHLCV, and pair stats only as needed.
-3. Distinguish pool-level facts from token-level facts.
-4. Report liquidity depth, recent flow, and data freshness.
+## Calls made
+- Toolset: onchain_dex_pool_analysis
+- Endpoint(s): [exact endpoint names]
+- Identifiers: [chain, pair/pool/token addresses]
 
-## Example
+## Evidence
+- Liquidity: [depth, fee tier, venue]
+- Flow: [trades, volume, OHLCV in window]
+- Provenance: [provider, fetched_at, observed_at/cache_age_ms, runtime status per call]
 
-If the user provides only a token contract, first search for relevant pools or
-pairs, then choose the pool with the most relevant liquidity/volume.
+## Caveats
+[Missing pools, stale candles, thin liquidity, degraded provider.]
+
+## Next action
+[Compare pools, widen time window, or add token diligence — only if needed.]
+```
+
+## Gotchas
+
+- The same token pair can have multiple pools with different fee tiers and
+  liquidity.
+- Trending pools are not necessarily safe or liquid.
+- OHLCV data can be unavailable even when pair metadata exists.
+
+## Evidence receipt (required)
+
+End every Hive-backed answer with a compact receipt built from the `_hive`
+object on each material tool response:
+
+- `provider`, `tool`, `fetched_at`, `observed_at`, `cache_age_ms`, and `runtime_status`
+- `receipt_id`, `receipt_version`, server/build version, and SHA-256 input/result
+  digests when present (self-checks, not signatures)
+- `source`, `cache_status`, `truncated`, and any warnings
+- canonical chain/entity identifiers plus block, slot, transaction, or query ids
+  present in provider data
+- material provider disagreements and how they were handled
+- checks that were unavailable, gated, stale, truncated, or intentionally not run
+- a `claims[]` citation from each material statement to exact receipt IDs
+- one `coverage[]` entry for every canonical evidence phase, with each gap explained
+
+Never turn missing evidence into a clean result, silently merge conflicting
+provider values, or omit a degraded/fallback call from the receipt.
+`observed_at` is Hive's first-observation/original cache-population time, and
+`cache_age_ms: 0` only means newly retrieved by Hive. Use provider time, block,
+slot, transaction, or candle close for source recency; if absent, mark it
+unknown. Run `validate_task_result` before presenting the typed workflow result;
+it checks structure but cannot authenticate an invented receipt.
 
 ## Runtime status handling
 
 If a DEX/pool endpoint is `degraded`, fall back to pair search or token-pool
 tools and state which exact metric is missing.
+
+## Hand-offs
+
+- CEX prices, order books, funding, derivatives → `hive-market-research`.
+- Whole-token diligence (holders, risk, metadata) → `hive-token-diligence`.
+- Pool-token purchase risk → `hive-security-risk`.

package/agent-skills/packs/hive-dex-pool-analysis/evals/evals.json

@@ -3,13 +3,15 @@
   "evals": [
     {
       "id": 1,
-      "prompt": "Analyze the main Uniswap pool for this token and summarize liquidity and recent flow.",
-      "expected_output": "Uses onchain_dex_pool_analysis, resolves chain/token/pool, fetches bounded pool/liquidity/trade data, and separates pool facts from token facts.",
+      "prompt": "Analyze the main Uniswap pool for PEPE (0x6982508145454Ce325dDbE47a25d4ec3d2311933) on Ethereum and summarize liquidity and recent flow.",
+      "expected_output": "Uses onchain_dex_pool_analysis, resolves chain/token/pool, fetches bounded pool/liquidity/trade data, separates pool facts from token facts, and ends with a runtime evidence receipt.",
       "files": [],
       "assertions": [
         "Chooses onchain_dex_pool_analysis.",
+        "Selects pool_quality or pool_activity from routes[] and preserves route_id.",
         "Resolves pool or asks for enough identifiers.",
-        "Caveats pool-specific liquidity."
+        "Caveats pool-specific liquidity.",
+        "Includes receipt ids and source freshness."
       ]
     },
     {

package/agent-skills/packs/hive-dex-pool-analysis/evals/triggers.json

@@ -0,0 +1,50 @@
+[
+  {
+    "query": "how deep is the main PEPE/WETH pool and which way has flow gone today",
+    "should_trigger": true
+  },
+  {
+    "query": "show me trending pools on base right now",
+    "should_trigger": true
+  },
+  {
+    "query": "get OHLCV for pair 0x… on arbitrum, 1h candles",
+    "should_trigger": true
+  },
+  {
+    "query": "which pool has the most real liquidity for token 0x6982508145454Ce325dDbE47a25d4ec3d2311933",
+    "should_trigger": true
+  },
+  {
+    "query": "recent swaps on this pool — any whale sized trades?",
+    "should_trigger": true
+  },
+  {
+    "query": "compare the 0.05% and 0.3% fee tier pools for this pair",
+    "should_trigger": true
+  },
+  {
+    "query": "whats the price of PEPE right now",
+    "should_trigger": false
+  },
+  {
+    "query": "is this pool's token a honeypot",
+    "should_trigger": false
+  },
+  {
+    "query": "top protocols by TVL on base",
+    "should_trigger": false
+  },
+  {
+    "query": "explain impermanent loss to me",
+    "should_trigger": false
+  },
+  {
+    "query": "check the SOL order book on kraken",
+    "should_trigger": false
+  },
+  {
+    "query": "what LP positions does this wallet hold",
+    "should_trigger": false
+  }
+]

package/agent-skills/packs/hive-market-research/SKILL.md

@@ -1,45 +1,154 @@
 ---
 name: hive-market-research
-description: Use this skill for live crypto market research including prices, liquidity, exchange data, OHLC candles, order books, tickers, funding rates, derivatives, and trading context. Use it whenever the user needs current market data or venue-specific market evidence.
+description: Use this skill for any live crypto market question — prices, 24h moves, liquidity, exchange/venue data, OHLC candles, order books, tickers, funding rates, derivatives, trading context — even casual asks like "what's BTC at" or "is ETH pumping". Use it whenever the answer needs current market numbers instead of memory. For on-chain pool depth and DEX trades use hive-dex-pool-analysis; for protocol TVL/fees/yields use hive-defi-research.
 license: MIT
 metadata:
   package: "@hiveintelligence/agent-skills"
   category: "market"
   requires_network: "true"
-version: 1.0.0
+version: 1.4.0
 ---
 
 # hive-market-research — Market Research
 
-Use this skill for live price, liquidity, exchange, OHLC, order book,
-derivatives, or trading-context questions.
+Answer live price, liquidity, exchange, OHLC, order-book, derivatives, and
+trading-context questions with sourced, timestamped market data.
 
-## Task toolset
+## Task toolset and identifiers
 
-Use `market_research`.
+Toolset: `market_research`. Read `hive://toolsets/market_research` before
+execution; it is authoritative for the current output schema, material-call
+budget, phases, fallback condition, and stop conditions.
 
-Required identifiers: token symbol or contract, plus chain or exchange id when
-the request is venue-specific.
+For tokenized real-world-asset perps (stock/pre-IPO/ETF/index/commodity/FX
+perps — funding, rollover carry, cross-venue markets), route to
+`rwa_perp_analysis` instead and read `hive://toolsets/rwa_perp_analysis`; its
+rows carry `funding_mechanism` (a `funding_plus_borrow` rollover is never
+sign-comparable with a funding transfer), `is_delisted`, and
+`is_price_suspect` fields that must be respected in the answer.
+
+- Required: asset (token id, symbol, or contract address) and quote currency
+  (usually `usd`).
+- Venue/exchange id when the request is order-book, ticker, or derivatives
+  specific.
+- Time window and candle interval for OHLC or trend questions.
+
+Ask for missing venue or chain details when the choice changes the answer. For
+general price questions, choose a broad market-data tool and state the source.
+
+Before choosing endpoints, select exactly one matching entry from the exact
+workflow's routes[]. Follow its ordered steps, use a fallback only under that
+step's published condition, stop at four material calls, and preserve the
+selected route_id in the typed result. The broad coverageCatalog is discovery
+coverage, not an execution plan.
 
 ## Procedure
 
-Read `references/workflow.md` when the request needs multi-step market
-analysis, venue selection, freshness comparison, or a provenance-aware report
-template.
+1. Resolve ambiguous symbols first — call `search_tools` with the asset and
+   intent.
+2. Call `get_api_endpoint_schema` for each market endpoint before calling it.
+3. Prefer focused calls: price, ticker, OHLC, order book, or funding data —
+   not everything at once.
+4. For derivatives questions, include funding/open-interest context when
+   available.
+5. For Hyperliquid perp questions, filter discovery to `Hyperliquid`, inspect
+   the typed endpoint schema, and bound time-series calls by time range and
+   pagination limits. Continue from the returned timestamp when a funding
+   scan reports an incomplete range.
+6. Return freshness with every number, and avoid trading conclusions without
+   liquidity context.
+
+## Bounded calls
+
+- Use small limits for candles and order-book depth unless the user asks for
+  more.
+- Avoid fetching all exchanges or all markets for a single-asset question.
+- Bound Hyperliquid funding scans with an explicit time range, `max_points`,
+  and `max_pages`. Treat `pointCount` as the range total only when
+  `pointCountIsTotal` is true; otherwise continue from `range.nextStartTime`
+  and de-duplicate the inclusive boundary.
+- Do not compare data from different timestamps without saying so.
+
+## Worked example
+
+User: "What's the BTC funding picture across exchanges right now — anything
+crowded?"
+
+1. `search_tools` → `{"query": "funding rates derivatives bitcoin exchanges", "limit": 5}`
+2. `get_api_endpoint_schema` for the funding-rate endpoint returned, then
+   `invoke_api_endpoint` with schema-valid arguments and a bounded venue list.
+3. Report per-venue funding with the provider timestamp when present. Treat
+   `observed_at` as Hive first-observation time and `fetched_at` as retrieval
+   completion; flag source recency as unknown when no provider time exists,
+   and flag stale or degraded venues,
+   and avoid a directional trade call unless asked.
+
+If the user says "check the order book" without naming a venue, ask which
+exchange — order-book liquidity is venue-specific.
+
+## Report template
 
-1. Resolve ambiguous symbols with `search_tools`.
-2. Inspect schemas for exact market tools before execution.
-3. Prefer focused calls for price, ticker, OHLC, order book, or funding data.
-4. Return freshness and avoid trading conclusions without liquidity context.
+```markdown
+## Summary
+[Current market read in one sentence.]
 
-## Example
+## Calls made
+- Toolset: market_research
+- Endpoint(s): [exact endpoint names]
+- Identifiers: [asset, venue, interval, quote]
 
-Ask for the exchange id if the user says "check the order book" without naming
-a venue. Use `binance`, `kraken`, or another explicit exchange id only when the
-user provided it or asked you to choose a fixture.
+## Evidence
+- [Key metrics: price, volume, depth, funding — with venue and provider]
+- Freshness: [Hive observed_at/cache_age_ms plus provider timestamps or candle closes; fetched_at is retrieval completion; source recency unknown if provider time is absent]
+
+## Caveats
+[Stale data, missing venue, fallback, degraded provider, thin liquidity.]
+
+## Next action
+[Deeper venue, time-window, or liquidity drilldown — only if needed.]
+```
+
+## Gotchas
+
+- Symbols collide. Prefer contract addresses, provider ids, or venue ids over
+  bare tickers.
+- Order-book liquidity is venue-specific; do not generalize it to the full
+  market.
+- Market data can be fresh but still incomplete if a venue/provider is
+  degraded.
+
+## Evidence receipt (required)
+
+End every Hive-backed answer with a compact receipt built from the `_hive`
+object on each material tool response:
+
+- `provider`, `tool`, `fetched_at`, `observed_at`, `cache_age_ms`, and `runtime_status`
+- `receipt_id`, `receipt_version`, server/build version, and SHA-256 input/result
+  digests when present (self-checks, not signatures)
+- `source`, `cache_status`, `truncated`, and any warnings
+- canonical chain/entity identifiers plus block, slot, transaction, or query ids
+  present in provider data
+- material provider disagreements and how they were handled
+- checks that were unavailable, gated, stale, truncated, or intentionally not run
+- a `claims[]` citation from each material statement to exact receipt IDs
+- one `coverage[]` entry for every canonical evidence phase, with each gap explained
+
+Never turn missing evidence into a clean result, silently merge conflicting
+provider values, or omit a degraded/fallback call from the receipt.
+`observed_at` is Hive's first-observation/original cache-population time, and
+`cache_age_ms: 0` only means newly retrieved by Hive. Use provider time, block,
+slot, transaction, or candle close for source recency; if absent, mark it
+unknown. Run `validate_task_result` before presenting the typed workflow result;
+it checks structure but cannot authenticate an invented receipt.
 
 ## Runtime status handling
 
-Report `ok`, `missing_key`, `plan_required`, `rate_limited`, `degraded`, or
-`failing` per tool/provider. If a venue endpoint is degraded, fall back to
+Report `ok`, `invalid_input`, `missing_key`, `plan_required`, `rate_limited`,
+`degraded`, or `failing` per tool/provider. If a venue endpoint is degraded, fall back to
 another public market-data endpoint and state the substitution.
+
+## Hand-offs
+
+- On-chain pool depth, swaps, OHLCV per pool → `hive-dex-pool-analysis`.
+- Protocol TVL, fees, revenue, yields → `hive-defi-research`.
+- "Is this token safe" rather than "what's the price" → `hive-token-diligence`.

package/agent-skills/packs/hive-market-research/evals/evals.json

@@ -4,12 +4,14 @@
     {
       "id": 1,
       "prompt": "What's the live BTC price, recent liquidity context, and source freshness?",
-      "expected_output": "Routes to market_research, resolves BTC to a provider-supported id, inspects schemas, makes bounded price/liquidity calls, and reports provider/freshness/runtime status.",
+      "expected_output": "Routes to market_research, resolves BTC to a provider-supported id, inspects schemas, makes bounded price/liquidity calls, and ends with a runtime evidence receipt.",
       "files": [],
       "assertions": [
         "Chooses market_research.",
+        "Selects spot_snapshot or derivatives_positioning from routes[] and follows its ordered calls instead of the coverage catalog.",
         "Uses schema lookup before execution.",
-        "Reports provider and freshness."
+        "Reports provider and freshness.",
+        "Includes receipt ids and cache/fallback status."
       ]
     },
     {
@@ -22,6 +24,17 @@
         "Bounds order book depth.",
         "Caveats venue-specific liquidity."
       ]
+    },
+    {
+      "id": 3,
+      "prompt": "Pull eighteen months of BTC funding history from Hyperliquid and tell me whether the returned series covers the full range.",
+      "expected_output": "Routes to market_research, discovers the typed Hyperliquid funding endpoint, inspects its schema, uses a bounded time range and pagination controls, and checks completion/continuation metadata before calling the point count a total.",
+      "files": [],
+      "assertions": [
+        "Filters discovery to Hyperliquid and uses the typed provider tool.",
+        "Bounds the scan with time and pagination arguments.",
+        "Checks pointCountIsTotal or range.complete and reports any continuation."
+      ]
     }
   ]
 }