The Autonomous Wagon: Designing Zero-Custody DeFi Agents with FarmDash

A production architecture for DeFi agents using FarmDash: evidence ingestion, capability checks, policy, simulation, explicit authority, execution adapters, receipt verification, reconciliation, and kill switches.

TLDR: A production DeFi agent is not “an LLM with a private key.” It is a control system. The safe pipeline is discover → verify evidence → read live capability state → apply policy → simulate where authoritative simulation exists → obtain the route-specific authority → execute through a trusted adapter → verify receipt/finality → reconcile economic effects → audit. FarmDash supplies machine-readable intelligence and control primitives; the live status contract determines which execution stages are actually enabled. Raw customer private keys should remain outside FarmDash.

Capability	Canonical status
spot.USER_SIGNED	operational
spot.BOUNDED_AUTONOMOUS	operational
futures.USER_SIGNED	operational
futures.BOUNDED_AUTONOMOUS	operational
solana.USER_SIGNED	operational
solana.BOUNDED_AUTONOMOUS	operational
ERC4337_SERVER_SUBMISSION	preparation_only
GENERIC_SERVER_INTENT_EXECUTION	preparation_only
MEE	preparation_only
ACP	deployment_prerequisite

Read canonical readiness and live deployment/request gates before execution. These rows are conditional capability contracts, not funded-production proof. USER_SIGNED requires fresh human authorization. Bounded execution requires a separate revocable domain policy and customer-agent-local signature per action, plus exact identity, scope, validity, simulation/research, risk/budget and replay checks. Commercial access cannot supply signing authority; FarmDash never receives the customer key.

What Makes an Agent Production-Grade?

A useful DeFi agent must solve more than decision generation.

It needs to answer:

Is the underlying data fresh?
Is this capability actually enabled?
What authority does this action require?
What is the maximum permitted value?
Which token/venue/chain is allowed?
Did the exact prepared action pass simulation?
Who signs?
Who broadcasts?
Did the transaction finalize?
Did balances change as expected?
Can the operator stop or revoke the system?

If any of those answers is implicit, the architecture is not finished.

The FarmDash Control Loop

Use a staged loop rather than a monolithic “trade” function:

INTELLIGENCE
    ↓
EVIDENCE + FRESHNESS
    ↓
PLAN
    ↓
POLICY / RISK
    ↓
AUTHORITATIVE SIMULATION (when available)
    ↓
AUTHORITY
    ↓
TRUSTED EXECUTION ADAPTER
    ↓
RECEIPT + FINALITY
    ↓
ECONOMIC RECONCILIATION
    ↓
AUDIT / LEARN

Each boundary should be independently testable.

1. Intelligence: What Is the Agent Looking At?

FarmDash can expose protocol research, Trail Heat, wallet context, quotes, market data, and other structured inputs through REST/OpenAPI, MCP, SDK, and OpenClaw surfaces.

The agent should preserve:

source;
timestamp;
freshness;
confidence;
live/cached/estimated state;
request ID;
protocol/chain identity.

A high Trail Heat score is a research-prioritization signal. It is not wallet authority.

2. Capability: Is the Requested Action Actually Live?

Before a state-changing workflow, read:

GET /api/v1/agent/status

A tool can exist in MCP or an SDK while its runtime capability is:

read-only;
preview;
preparation-only;
session-bound;
server-verified;
provider-gated;
operator-paused;
unavailable.

Treat status as operational truth.

This prevents an agent from confusing “the method exists” with “production execution is enabled.”

3. Policy: What Is the Agent Allowed to Do?

Policy belongs outside the language model.

A practical policy envelope can include:

allowed chains;
allowed assets;
allowed protocols/adapters;
maximum value per action;
cumulative daily value;
maximum slippage;
leverage ceiling;
minimum health factor;
minimum data freshness;
minimum liquidity;
denylisted destinations;
required human approval above a threshold;
session expiry;
emergency pause state.

The LLM can propose. The policy engine decides whether the proposal is admissible.

4. Simulation: What Would This Exact Action Do?

Where FarmDash exposes an authoritative simulation, simulate the exact action that may later be signed.

A useful simulation record should bind:

action/intent ID;
chain;
signer;
exact prepared payload or transaction fingerprint;
provider;
estimated gas/fees;
expected asset deltas;
price impact;
validity window;
failure/revert information.

Simulation is evidence, not permission.

A successful simulation can become stale as state changes.

5. Authority: Who Is Permitted to Sign?

Do not collapse access credentials and wallet authority.

A FarmDash API key can grant commercial capacity. It should not become a wallet-signing key.

Current and future workflows can use different authority models:

Supervised authority

A human or customer-controlled wallet signs each bounded action.

This is appropriate when the operator wants transaction-by-transaction control.

Bounded standing authority

The bounded preparation architecture uses a separate explicit owner-signed policy, not a generic session or venue delegation alone. Where runtime status permits future dispatch, it must enforce:

scope;
chains;
assets;
adapters;
spend/value caps;
leverage and health limits;
expiry;
revocation;
pause/kill switch;
replay protection.

That is still not “give FarmDash the private key.”

Until the live capability contract explicitly enables such a mode for a route, do not claim it exists merely because the architecture supports the concept.

6. Execution: Use Trusted Adapters

Execution should go through a narrowly defined adapter rather than arbitrary LLM-generated calldata.

The adapter should enforce:

expected chain;
expected target;
expected function or transaction family;
expected token/value;
approved provider;
slippage/value bounds;
nonce/idempotency rules;
no hidden permission expansion.

For compatibility EVM swaps, FarmDash prepares the exact transaction after the required quote, simulation, and authorization checks; the customer-controlled wallet or execution client decides whether to sign and broadcast it.

Other venue-specific workflows have their own authority and submission models. Read status rather than generalizing from the compatibility path.

7. Receipt and Finality

“Submitted” is not “settled.”

Track at least:

prepared
→ signed
→ submitted
→ confirmed
→ finalized
→ reconciled

The exact finality rule is chain-specific.

A receipt verifier should obtain authoritative chain evidence instead of trusting a caller-supplied “success” flag.

8. Economic Reconciliation

A successful receipt still needs economic interpretation.

Reconcile:

principal sent;
asset received;
network fees;
provider/routing fees;
FarmDash fees;
bridge fees;
account rent where relevant;
collateral/debt changes;
residual balances;
unexplained deltas.

If an unexplained economic delta remains, the agent should not mark the lifecycle cleanly complete.

OpenClaw, Hermes, and Other Agent Runtimes

FarmDash should not require one cognitive framework.

OpenClaw

Useful when you want versioned skills, explicit tool boundaries, and inspectable workflow instructions.

Hermes

Useful as an external orchestration/runtime environment when its policies, credentials, and logs are configured safely.

Claude, Eliza, LangChain, custom agents

Any runtime that can:

consume the machine contracts;
preserve typed state;
respect policy;
obtain route-specific authority;
distinguish preparation from settlement;

can integrate.

The security boundary belongs in deterministic systems, not in a model-brand assumption.

MCP and REST

The external source mirror was re-synchronized and now carries full parity with the canonical MCP subset: 35/35 mirrored skill files byte-equal, the full registered toolset from tools/list, and a standalone build. An earlier October 5, 2026 observation found that mirror behind the canonical catalog (missing get_execution_authority, get_payments_bootstrap, request_execution_delegation, register_execution_delegation, revoke_execution_authority, prepare_autonomous_swap, confirm_autonomous_swap, and release_autonomous_reservation); that observation is superseded and retained as history only. @farmdash/mcp-server is still not published on npm (registry metadata returned 404), and official MCP Registry lookups still find no matching publication — those publication gaps remain open. Always read the installed tools/list rather than assuming manifest parity. No external mirror sync or publication is implied.

MCP discovery is useful for:

schema discovery;
tool invocation;
local agent clients such as Claude Desktop.

REST/OpenAPI is useful for:

direct server-to-server integrations;
deterministic typed clients;
custom orchestration.

Both surfaces should describe the same product state.

The npm package name @farmdash/mcp-server should not be described as publicly installable until npm registry readback confirms publication.

Payment Is Not Authority

x402 can unlock an eligible API operation.

It does not:

choose a wallet action;
sign a transaction;
delegate a session;
broadcast;
prove settlement.

Likewise, a Pioneer or Syndicate subscription changes commercial capacity, not wallet authority.

Keep the payment state machine separate from the execution state machine.

Idempotency and Ambiguous Failures

Financial retries require stricter semantics than ordinary web requests.

For each mutation record:

idempotency key if supported;
request ID;
intended economic action;
state before request;
state after response;
authoritative recovery query.

If a connection dies after sending a request, do not automatically submit the mutation again.

First determine whether the original action was accepted, prepared, submitted, or settled.

Signer Architecture

Avoid placing a raw private key inside an LLM process.

Safer signer designs include:

hardware wallet;
hardware-backed or managed KMS/HSM signer;
audited smart-account/session-key infrastructure;
dedicated signing service with strict policy;
local wallet provider controlled by the user.

The signer should receive a bounded, policy-approved request—not arbitrary natural-language instructions.

Kill Switches and Revocation

A serious autonomous system needs an emergency path independent of the model.

The kill switch should be able to:

prevent new actions;
invalidate or revoke active delegated/session authority where supported;
stop new transaction preparation/submission;
preserve audit state;
require explicit recovery before resuming.

Do not assume that revoking ERC-20 allowances alone halts every authority path. Sessions, venue API authorities, smart accounts, and pending transactions can require different revocation mechanics.

Canary Deployment

Do not define a universal dollar amount or 72-hour ritual as if it proves safety.

A canary should be small relative to the operator's risk budget and designed to exercise the exact production path.

Verify:

provider/RPC failure behavior;
nonce/idempotency behavior;
policy rejection;
simulation freshness;
signer binding;
receipt verification;
finality handling;
accounting/reconciliation;
kill switch;
recovery after restart.

A canary that does not test failure paths is just a small trade.

Observability

Keep an append-only operational record of:

input evidence;
model recommendation;
deterministic policy result;
simulation;
authority used;
prepared action fingerprint;
submitted transaction/order identifier;
receipt/finality;
economic reconciliation;
manual override;
pause/revocation.

This lets an operator answer not only “what did the agent do?” but “what evidence and authority made that action permissible?”

What Should the Agent Do When Data Is Bad?

Fail conservatively.

Examples:

stale quote → re-quote;
missing verifier → stop at preparation;
provider unavailable → surface typed degraded state;
stale wallet state → refresh;
ambiguous mutation result → query authoritative state;
policy violation → refuse;
unexpected receipt delta → reconcile before continuing.

Do not substitute a fabricated zero, synthetic live value, or optimistic “probably succeeded.”

Frequently Asked Questions

Does FarmDash hold an agent's private key?

Raw customer private keys are not part of the FarmDash public integration contract. Signing remains customer-controlled or explicitly delegated according to the live capability's authority model.

Does installing the MCP server make an agent autonomous?

No. MCP exposes tools and schemas. Autonomy requires an explicitly configured authority model plus policy, risk controls, provider readiness, and settlement verification.

Can the model decide its own spending limit?

It can propose a policy change. Deterministic control code and the authorized operator should govern whether the limit changes.

Is simulation enough to make a trade safe?

No. Simulation reduces uncertainty under a specific state. Prices, balances, approvals, liquidity, and chain conditions can change before submission.

What happens when an RPC or provider fails?

The correct behavior is a typed degraded/unavailable state, a bounded fallback if one is explicitly supported, or a stop. Do not replace missing live evidence with invented data.

Is fully autonomous execution the same as custody?

Not necessarily. A bounded session/delegation can permit autonomous actions without disclosing a raw private key, but its scope, limits, revocation, and supported route must be explicit.