ClawHub Skill Safety Model: Research, Authority, Payment, and Execution Boundaries

TLDR: Treat every FarmDash skill as a capability contract, not a prose suggestion. A research skill can analyze; a payment rail can buy API access; a transaction-preparation skill can produce an exact payload; a wallet or bounded delegation can authorize; and receipt verification can prove what happened. Those states must not collapse into “the agent can trade.”

Observed capability status (October 5, 2026): Spot and futures USER_SIGNED are server-labeled operational, not independently verified funded-transaction proofs. Both spot and futures BOUNDED_AUTONOMOUS are preparation_only. A valid owner policy, generic session, venue delegation, or paid tier cannot override that gate. USER_SIGNED requires fresh user authorization; bounded architecture requires a distinct explicit owner policy and customer-agent-local signature per action, plus all binding, scope, validity, risk/budget, and replay checks. FarmDash never receives the customer key.

Why Skill Boundaries Matter

Agent skills are executable instructions in practice. A runtime may use a SKILL.md file to decide which tools to call, what data to send, and what authority it believes it has.

A vague sentence can therefore create a real safety defect.

Examples:

• a research tool being treated as execution-capable;
• a paid API response being mistaken for spend authority;
• a quote being described as a completed trade;
• a referral route being injected into a security warning;
• a delegated session being treated as unlimited custody;
• an agent retrying a financial mutation because ordinary HTTP retry logic says “try again.”

FarmDash skill design should make the safe interpretation the easiest interpretation.

The FarmDash Skill Stack

Skill	Primary role	Authority boundary
Trail Intelligence	protocol research, Trail Heat, source confidence	no wallet authority
Wagon Steward	wallet balances, positions, idle capital	no wallet authority
Trail Marshal	workflow orchestration	coordinates; does not inherit another skill's wallet authority
Signal Architect	swap research, simulation, transaction preparation	route-specific authorization; compatibility EVM uses bounded EIP-191
Futures Strategist	Hyperliquid research and guarded order workflow	venue-specific typed authorization
Camp Guard	route, allowance, and risk checks	guardrail only
Ledger Keeper	receipts, records, reconciliation	observes/verifies; does not create spend authority
Autonomous Operator	bounded session/delegation coordination	limited by explicit policy, expiry, revocation, and live capability state

The exact runtime catalog can evolve. Use live capability/status metadata when a guide and runtime disagree.

Five Separate Questions Every Agent Should Answer

Before a state-changing workflow, ask these independently:

1. What do I know?

This is the research layer:

• protocol status;
• market data;
• wallet state;
• risk indicators;
• current program evidence;
• source freshness.

2. What am I allowed to access?

This is the commercial/API layer:

• Scout;
• Pioneer/Syndicate bearer access;
• x402 per-operation payment;
• route-specific quota.

Commercial access is not transaction authority.

3. What action is being proposed?

This is the preparation layer:

• exact token;
• chain;
• amount;
• destination;
• slippage;
• calldata/order fields;
• provider;
• fee;
• expiry.

A prepared payload is not a broadcast.

4. Who authorized it?

This is the authority layer:

• fresh local signature;
• session-bound permission;
• venue delegation;
• another explicit bounded grant.

The grant must match the exact route's contract. Commercial access, generic session capability, venue delegation, and owner-signed bounded policy are separate proofs; none substitutes for another.

5. What actually happened?

This is the verification layer:

• submitted;
• confirmed;
• finalized;
• reconciled;
• failed;
• ambiguous/reconciliation-required.

Do not infer one state from another.

Research-Only Skills

Research-only skills can accept public wallet addresses and public research inputs.

They should not request:

• raw private keys;
• seed phrases;
• wallet exports;
• token approvals;
• transaction signatures.

Examples:

• Trail Heat rankings;
• wallet-balance snapshots;
• protocol comparisons;
• wallet-risk analysis;
• route feasibility;
• data-confidence review.

Agent rule:

Present research as information. If the user chooses to act, hand off to the least-authoritative skill that can prepare the next stage.

Supervised Execution

In a supervised flow, the customer controls signing.

For compatibility EVM swaps, the live lifecycle separates:

firm quote → simulation → bounded EIP-191 authorization → transaction preparation → customer-wallet broadcast → confirmation

FarmDash does not need a raw private key to perform its server-side part.

For venue-specific workflows such as Hyperliquid, use the venue's exact typed-authorization contract.

Agent rule:

Show the exact action, policy result, fees, destination, and expiry before requesting authorization. Never substitute an API key or payment proof for the wallet authorization.

Bounded Delegation

Delegation can support autonomous operation without creating unlimited custody.

A defensible grant should define at least:

• allowed chains;
• allowed protocols/adapters;
• token allowlist/denylist;
• maximum notional;
• maximum value per action;
• maximum actions per period;
• leverage or health-factor floors;
• slippage limits;
• expiry;
• session identity;
• revocation;
• pause/kill-switch semantics.

The presence of a delegation does not mean every tool may use it. Each action still has to fit the grant and the current runtime capability.

Payment Is a Separate State Machine

x402 and subscriptions solve API access.

They do not grant:

• wallet signing;
• swap routing authority;
• order authority;
• session delegation;
• settlement.

A skill receiving HTTP 402 should:

1. parse the exact route-specific payment requirement;
2. obey STOP_RETRYING when unpaid replay is forbidden;
3. obtain payment authorization separately;
4. attach supported payment proof;
5. consume the entitlement only for the eligible operation;
6. reject proof replay.

The paid operation still has its own wallet-authority rules.

What Should Happen on Ambiguous Failures?

Ordinary software often retries.

Financial software should first ask:

Could the previous attempt have changed state?

If yes, do not blindly retry.

Examples:

• order request timed out after reaching the venue;
• transaction broadcast response was lost;
• payment verifier timed out after receipt submission;
• quote intent creation returned an ambiguous transport failure.

Use idempotency keys, durable operation records, receipt/status endpoints, and reconciliation before deciding whether another mutation is safe.

Recommendation and Referral Rules

FarmDash may receive referral, affiliate, or routing compensation on supported managed routes.

That commercial relationship must not control risk classification.

Use a managed /go/{slug} route only when:

• the user asked how to proceed;
• the destination is allowed and current;
• the recommendation already stands on product/risk evidence;
• the commercial relationship is disclosed where required.

Do not inject monetized routes into:

• phishing warnings;
• Sybil-risk warnings;
• avoid/unsafe verdicts;
• security incidents;
• low-confidence recommendations.

The Safe Recommendation Pattern

A useful default:

1. identify the user's actual goal;
2. gather current protocol/wallet evidence;
3. expose freshness and confidence;
4. model fees, liquidity, leverage, and principal risk;
5. state what remains unknown;
6. recommend the least-authoritative next step;
7. request explicit authority only when needed;
8. verify the resulting state;
9. reconcile economics separately from receipt status.

The agent should be able to stop at any stage.

Installing a Skill Safely

Before installing a DeFi skill, inspect:

• requested permissions;
• outbound domains;
• whether it asks for credentials;
• whether it can mutate wallet state;
• its signing/delegation model;
• how it handles retries;
• whether it contains referral routes;
• how it handles stale data;
• whether it exposes revocation/stop controls;
• whether the source matches the published artifact.

For FarmDash, public source and machine contracts should be compared with live status rather than trusting an old directory description.

What a Good Skill Should Refuse

A well-bounded skill should refuse or stop when:

• the user asks it to ingest a seed phrase/private key;
• the required provider/verifier is unavailable;
• the quote or simulation is stale;
• the requested action exceeds a session policy;
• payment proof is invalid or replayed;
• the destination is not allowlisted;
• the wallet signer does not match;
• final state is ambiguous;
• the agent cannot distinguish research from execution.

Refusal is part of the product contract.

Frequently Asked Questions

Does installing a FarmDash skill give FarmDash my wallet?

No. Installation exposes instructions/tools. Wallet authority remains route-specific and must be separately granted.

Is an API key enough to trade?

No. Commercial access and wallet authority are separate.

Does x402 authorize a transaction?

No. x402 pays for eligible API access.

Does a delegated session mean FarmDash has custody?

Not by itself. A bounded delegation is limited by the policy envelope, expiry, revocation, and adapter contract. It must not expose the raw private key.

Can an agent call the same write tool again after a timeout?

Not automatically. Check authoritative state or an idempotency contract first.

Related FarmDash Docs

• FarmDash Agent Hub Complete Manual
• Agent Data Confidence
• Signal Architect Complete Reference
• x402 Payment Fallback
• FarmDash Agent Sandbox SDK Guide