Skip to content
EN

← Return to Guides

Developer elizaagentssignal architect

Build a Safer Eliza DeFi Swap Agent with FarmDash

Integrate Eliza with FarmDash Signal Architect using firm quotes, mandatory simulation, bounded EIP-191 authorization, customer-controlled broadcasting, and receipt confirmation.

By FarmDash Pioneers · Published 2026-02-26 · Updated 2026-10-05

TLDR: A safe Eliza swap integration should not give the language model a raw private key and should not jump directly from “swap this” to broadcast. FarmDash's compatibility EVM lifecycle is firm quote → mandatory simulation → exact EIP-191 authorization → transaction payload → customer-controlled broadcast → server-verified confirmation. LI.FI and Relay are the active routing providers; 0x remains operator-paused, and x402 is payment/access infrastructure rather than a swap venue.

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 Problem Does Signal Architect Solve?

An agent framework such as Eliza is good at interpreting intent, coordinating tools, and explaining results. It should not have to learn every router's schema, invent security rules, or infer whether a quote is safe to execute.

Signal Architect gives the agent a narrower contract:

  • normalize swap parameters;
  • obtain a provider-neutral estimate or a firm wallet-bound quote;
  • run the required FarmDash simulation;
  • collect an authorization bound to the exact swap request;
  • receive the exact transaction payload;
  • let the customer-controlled signer decide whether to broadcast;
  • verify the resulting chain evidence separately.

The critical design principle is:

The model chooses tools; the wallet controls authority.

What Are the Live Compatibility Swap Tools?

The current MCP/tool contract exposes this compatibility path:

Tool API route Purpose
get_swap_quote /api/v1/agent/quote-intent for a firm quote Create/reuse a wallet-bound quote intent when an idempotency key is supplied
simulate_swap_execution /api/v1/simulate Run the mandatory compatibility simulation
execute_swap /api/agents/swap Validate the signed, simulated request and return exact transaction calldata
confirm_swap /api/agents/confirm Verify canonical-chain receipt and committed fee evidence after the customer broadcasts

Use /api/v1/agent/status before the workflow. Tool names are not permission.

Research Quote vs. Firm Quote

get_swap_quote has two materially different modes.

Research estimate

Without an idempotencyKey, the tool can return a provider-neutral market estimate without creating a firm execution intent.

Use this for:

  • UI previews;
  • strategy comparisons;
  • rough cost estimation;
  • deciding whether a route deserves deeper work.

Do not treat it as executable.

Firm wallet-bound quote

With:

  • idempotencyKey;
  • real walletAddress;
  • destination address;
  • slippage;
  • token and chain inputs;

FarmDash creates or reuses a firm single-provider quote intent from an active provider and returns the intent identifier required for simulation.

The same idempotency key is important because an agent retry should not silently create a second economic action.

Which Routers Are Active?

The compatibility layer currently selects between LI.FI and Relay when the route is compatible.

  • 0x is configured but operator-paused.
  • x402 is not a router.
  • The agent may request lifi or relay explicitly where supported.
  • Automatic selection should never be described as a guarantee of the globally best possible market price.

The useful value proposition is normalized routing plus FarmDash's lifecycle controls—not an unprovable “best price” promise.

How Should an Eliza Action Be Structured?

Treat the Eliza action as an orchestrator, not a signer.

A production design has four components:

  1. Intent parser — converts the user's request into typed swap fields.
  2. FarmDash client — calls quote, simulation, and execution-preparation endpoints.
  3. Signer interface — asks an external customer-controlled wallet to sign the exact authorization and later the returned transaction.
  4. Receipt verifier — confirms the chain outcome and FarmDash fee event.

Do not store a raw EVM_PRIVATE_KEY in a general LLM runtime just to make the demo shorter.

A Safer TypeScript Skeleton

The following example intentionally models the wallet as an injected signer interface.

type Address = `0x${string}`;

interface SwapIntent {
  fromChainId: number;
  toChainId: number;
  fromToken: Address;
  toToken: Address;
  fromAmount: string;      // base-unit integer string
  walletAddress: Address;
  toAddress: Address;
  slippage: number;
  idempotencyKey: string;
}

interface WalletAuthority {
  address: Address;

  // Signs only the exact FarmDash authorization message shown to the user.
  signMessage(message: string): Promise<`0x${string}`>;

  // Broadcasts only after the caller has inspected the returned tx payload.
  sendTransaction(tx: {
    to: Address;
    data: `0x${string}`;
    value?: string;
    chainId: number;
  }): Promise<`0x${string}`>;
}

The Eliza action receives a WalletAuthority; it should not construct one from an environment private key inside the action.

Step 1: Check Capability Status

Before a swap:

GET /api/v1/agent/status

Verify that the compatibility EVM swap capability is available for the requested route.

If status reports:

  • unavailable;
  • provider degraded;
  • unsupported chain;
  • required verifier missing;
  • tier/payment requirement;

stop or degrade gracefully.

Step 2: Create a Firm Quote Intent

Conceptually:

const quote = await farmdash.getSwapQuote({
  fromChainId,
  toChainId,
  fromToken,
  toToken,
  fromAmount,
  walletAddress: wallet.address,
  toAddress: wallet.address,
  slippage: 0.5,
  idempotencyKey,
});

The important output is the wallet-bound intent identifier used by simulation.

The idempotency key should be stable for the same intended economic action and new for a genuinely new action.

Step 3: Simulate the Exact Intent

const simulation = await farmdash.simulateSwapExecution({
  intentId: quote.simulationRequirements.intent_id,
  walletAddress: wallet.address,
});

Do not proceed merely because a quote exists.

If simulation fails or expires, obtain the correct fresh state instead of force-retrying a stale payload.

Step 4: Build and Display the EIP-191 Authorization

The compatibility message binds:

v1:FARMDASH_SWAP:
{fromChainId}:
{toChainId}:
{fromToken}:
{toToken}:
{fromAmount}:
{agentAddress}:
{toAddress}:
{nonce}

Before signing, show the user or governing policy:

  • source chain;
  • destination chain;
  • source token;
  • destination token;
  • amount;
  • destination wallet;
  • slippage;
  • selected provider;
  • FarmDash fee;
  • quote/simulation freshness.

The signature authorizes this bounded request. It is not a general wallet delegation.

Step 5: Ask FarmDash for the Exact Transaction Payload

Call execute_swap with:

  • the same swap fields;
  • agentAddress;
  • toAddress;
  • fresh nonce;
  • EIP-191 signature;
  • successful simulationId;
  • intent ID when present;
  • the same slippage/provider constraints.

FarmDash validates the signed, simulated request and returns the transaction payload.

Despite the tool name, FarmDash does not broadcast the compatibility transaction.

That naming distinction is important for agent logs and UI copy.

Step 6: Broadcast Outside FarmDash

The customer-controlled wallet inspects and signs the returned transaction.

const txHash = await wallet.sendTransaction(txPayload);

A good wallet layer should still enforce:

  • correct chain;
  • expected destination contract;
  • maximum value;
  • token approvals;
  • expected calldata family;
  • user/policy confirmation.

The LLM should never rewrite the calldata between FarmDash preparation and signing.

Step 7: Confirm and Reconcile

Broadcasting is not the final state.

Use confirm_swap after the required chain evidence exists. The confirmation route is session-bound and verifies more than a caller-supplied hash: it checks the canonical receipt and the committed fee asset, payer, recipient, amount, and finality requirements.

Then reconcile:

  • source-token decrease;
  • destination-token increase;
  • network gas;
  • protocol/routing fees;
  • FarmDash fee;
  • bridge effects if cross-chain;
  • unexplained residuals.

A transaction receipt and an economic outcome are related but not identical facts.

What Should the Eliza Tool Return?

Avoid:

“Swap executed successfully.”

immediately after FarmDash returns calldata.

Use state-specific language:

After quote

“Firm quote created; no transaction has been signed or broadcast.”

After simulation

“The exact quote intent passed the current simulation gate. Wallet authorization is still required.”

After FarmDash preparation

“FarmDash validated the authorization and returned the transaction payload. Your wallet has not broadcast it yet.”

After wallet broadcast

“Transaction submitted as 0x…; awaiting required confirmation/finality.”

After confirmation

“Canonical receipt verified. Reconciliation shows the expected asset and fee changes.”

This prevents the agent from collapsing five lifecycle states into one word.

What About API Keys?

API access and wallet authority are separate.

Scout-capable routes can be used without a paid bearer token within the published quota. Pioneer/Syndicate tokens provide commercial API capacity.

An API key does not replace:

  • the swap EIP-191 authorization;
  • the wallet transaction signature;
  • session credentials required by confirm_swap.

Do not market “no API keys required” as if FarmDash had no access-control system at all.

How Does x402 Fit In?

x402 can pay for eligible API access or overage.

It does not:

  • sign the swap;
  • select a liquidity pool by itself;
  • authorize the wallet;
  • broadcast the transaction;
  • prove settlement.

Keep payment state and swap state separate in your Eliza memory/state machine.

What Should Happen on Retries?

Retries are dangerous when an endpoint is non-idempotent.

Recommended policy:

  • reuse the same idempotencyKey for the same firm quote intent;
  • do not automatically replay execute_swap after an ambiguous client/network failure without first checking state;
  • never broadcast the same prepared transaction twice unless the wallet/chain semantics make that safe and intentional;
  • use receipt/status checks before deciding that an operation needs to be repeated.

Agent frameworks tend to retry tool failures. Financial tools need narrower retry rules than ordinary web requests.

What About Generic FarmDashIntent Execution?

Do not assume that the generic lifecycle is production execution just because the tools exist.

The MCP capability contract can mark generic policy/simulation/execution stages as preparation-only or blocked when authoritative verifiers are not configured.

For the compatibility EVM swap path described in this guide, use the explicit quote → simulation → bounded authorization → transaction-payload flow whose current runtime state is exposed by /api/v1/agent/status.

Why Use FarmDash Instead of Calling a Router Directly?

FarmDash's value is not “we always have the best price.”

It is the control layer around execution:

  • normalized provider contracts;
  • firm quote idempotency;
  • provider-status truth;
  • mandatory simulation for the compatibility path;
  • bounded authorization;
  • explicit fee disclosure;
  • typed errors;
  • agent-readable capability status;
  • receipt confirmation;
  • separation between commercial payment and wallet authority.

A sophisticated agent can integrate LI.FI or Relay directly. FarmDash is useful when you want a consistent safety and evidence contract around those underlying venues.

Frequently Asked Questions

Does the Eliza agent need my private key?

It needs access to a signer to perform an authorized wallet action, but the safer design is an external wallet/signer interface rather than injecting a raw private key into the language-model runtime.

Does execute_swap broadcast the transaction?

No. On the compatibility EVM path it validates the signed simulated request and returns exact transaction calldata. The customer-controlled wallet or execution client broadcasts it.

Is 0x an active fallback?

Not currently. It is configured but operator-paused. Use live status for future changes.

Is x402 a swap router?

No. It is the payment/access layer.

Does a successful simulation guarantee execution?

No. State can change, quotes can expire, wallet signing can be rejected, and a broadcast transaction can still fail. Simulation is a required gate, not a guarantee.

Related Guides

Continue researching