Signal Architect Complete Reference: Quotes, Simulation, Authority, Payments, and Receipts

The current FarmDash Signal Architect contract: research estimates, firm quote intents, mandatory simulation, EIP-191 authorization, LI.FI/Relay routing, x402 access, zero-custody transaction preparation, and receipt verification.

TLDR: Signal Architect is a DeFi execution-control surface, not a custodial trading bot. The compatibility EVM lifecycle separates research estimate → firm wallet-bound quote → authoritative simulation → bounded EIP-191 authorization → exact transaction preparation → customer-controlled broadcast → server-verified confirmation. LI.FI and Relay are the active compatibility providers; 0x is operator-paused. x402 is API payment/access infrastructure, never a swap router. The live /api/v1/agent/status contract is authoritative when a guide, SDK, MCP catalog, or cached AI answer disagrees.

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 Is Signal Architect?

Signal Architect is FarmDash's agent-facing transaction-preparation and routing layer.

It exists because a language model should not have to infer:

which liquidity providers are currently enabled;
whether a quote is merely informational or firm;
whether the wallet and destination are bound;
whether the exact transaction was simulated;
what the FarmDash fee is;
what must be signed;
whether FarmDash or the wallet broadcasts;
whether a submitted transaction actually settled.

The product turns those distinctions into explicit states and machine-readable contracts.

The core principle is:

Research does not grant authority, preparation is not broadcast, and broadcast is not settlement.

What Is the Compatibility EVM Lifecycle?

The compatibility swap path is the most mature zero-custody flow and should be understood as a state machine.

STATUS
  ↓
RESEARCH ESTIMATE (optional)
  ↓
FIRM QUOTE INTENT
  ↓
PREREQUISITES / RE-QUOTE WHEN REQUIRED
  ↓
AUTHORITATIVE SIMULATION
  ↓
EIP-191 AUTHORIZATION
  ↓
TRANSACTION PREPARATION
  ↓
CUSTOMER WALLET BROADCAST
  ↓
CANONICAL RECEIPT / FINALITY
  ↓
FEE-EVENT CONFIRMATION + ECONOMIC RECONCILIATION

Skipping a stage changes the security meaning of the action.

Step 0: Read Live Capability Status

Before calling a write-capable surface:

GET /api/v1/agent/status

Use status to determine:

feature availability;
tier/access requirement;
whether a route is read-only, preparation-only, server-verified, or execution-capable;
provider readiness;
verifier readiness;
session/delegation requirements;
chain-specific support.

Do not infer readiness from an endpoint existing in OpenAPI or a tool appearing in MCP discovery.

Research Estimate vs. Firm Quote

FarmDash deliberately separates walletless exploration from execution-state creation.

Provider-neutral market estimate

A research estimate answers:

“What does this route roughly look like right now?”

It should not create provider execution state and should not be presented as executable.

Useful for:

compare-before-commit workflows;
route feasibility;
UI previews;
estimating fees and slippage;
deciding whether deeper execution work is justified.

Firm wallet-bound quote intent

Execution preparation begins with:

POST /api/v1/agent/quote-intent

A firm quote requires exact parameters including:

source chain;
destination chain;
source token;
destination token;
base-unit amount;
real wallet address;
destination address;
slippage;
stable idempotency key.

The idempotency key identifies the same intended economic action across safe retries.

Two different intent identifiers

A firm quote can expose two identifiers with different jobs:

the top-level quote/cache identity;
simulationRequirements.intent_id, which is the execution-simulation identity.

Do not substitute one for the other.

The simulation call must use the identifier the response explicitly designates for simulation.

Provider Prerequisites Are Part of the Quote Contract

A quote can reveal prerequisites that prevent immediate execution readiness.

Examples include:

ERC-20 allowance;
balance insufficiency;
provider-specific ordered steps;
a required re-quote after approval;
unsupported recipe steps;
route expiry.

If an approval is required, the customer-controlled wallet performs it. FarmDash should not silently convert a prerequisite into a completed execution state.

After an approval or other state-changing prerequisite, request a fresh firm quote so balance, allowance, route, and price assumptions are re-evaluated.

Mandatory Simulation

The compatibility path uses:

POST /api/v1/simulate

with the exact simulation intent and signing wallet.

The simulation binds execution to the prepared request and can report:

success/failure;
gas estimate;
output amount;
price impact where available;
MEV risk classification;
provider;
request/transaction fingerprints;
validity window;
revert reason.

A simulation result is time-sensitive evidence.

It is not:

a transaction;
a signature;
a broadcast;
a guarantee that state will remain unchanged;
proof that the user still wants to proceed.

If it expires or the underlying route changes, regenerate the appropriate state rather than treating the old simulation as permanent authorization.

How Does EIP-191 Authorization Work?

Compatibility swaps use a bounded message:

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

Canonicalization matters: lower-case the 0x-prefixed fields exactly as the current contract requires.

The signature proves authorization over that bounded request. It is not:

the wallet private key;
a blanket session grant;
a subscription credential;
permission to change the destination;
permission to change token/amount/chain;
proof of final settlement.

The nonce is short-lived to reduce replay risk.

What Does `execute_swap` Actually Do?

The compatibility endpoint:

POST /api/agents/swap

validates the signed, simulated request and returns exact transaction material.

Despite the tool name:

FarmDash does not broadcast the returned compatibility-swap transaction.

The customer-controlled wallet or execution client must:

inspect the prepared transaction;
verify chain, destination contract, value, and calldata policy;
sign locally;
broadcast through its own wallet/provider.

The state after FarmDash returns calldata is prepared, not “executed successfully.”

How Should the Wallet Validate the Prepared Transaction?

Before signing, enforce an independent wallet policy.

At minimum verify:

expected chain ID;
expected destination/target;
native value;
token approvals;
calldata family or allowlist;
user-visible amount;
slippage;
quote freshness;
maximum gas/value constraints;
no unexpected delegatecall or permission expansion where policy forbids it.

The LLM should never edit opaque calldata between FarmDash preparation and wallet signing.

Broadcast Is Not Confirmation

After the customer wallet broadcasts, it has a transaction hash.

That proves only that a submission occurred.

Possible later states include:

pending;
replaced;
dropped;
reverted;
confirmed;
finalized.

Agent copy should preserve those distinctions.

What Does `confirm_swap` Verify?

The confirmation surface:

POST /api/agents/confirm

is session-bound and server-verified.

It is designed to confirm settlement evidence for a FarmDash fee event associated with a compatibility swap the customer wallet has already broadcast.

It verifies more than “the caller gave us a hash.” The contract binds canonical-chain evidence to the expected:

fee event;
payer;
fee asset;
recipient;
amount;
required finality.

A previously confirmed fee event is not silently rebound to a different transaction.

This is the difference between caller assertion and authoritative verification.

Confirmation vs. Economic Reconciliation

Even a valid transaction receipt is not the complete accounting result.

Reconciliation should separately account for:

source-asset decrease;
destination-asset increase;
gas;
provider/routing fee;
FarmDash fee;
bridge fee;
protocol fee;
token-account/accounting effects;
residual or unexplained balance changes.

A good agent can say:

“The transaction is confirmed, and the observed economic effects match the authorized action within the expected fee/slippage envelope.”

That is stronger than merely saying “tx succeeded.”

How Does Provider Selection Work?

Current compatibility providers are:

LI.FI
Relay

0x is configured but operator-paused unless live status explicitly reports a later reinstatement.

x402 is never a provider.

Automatic selection

Automatic selection can compare healthy compatible providers inside the FarmDash routing universe and return the best supported executable result under the current route logic.

Phrase this precisely:

“Best route among the healthy compatible providers FarmDash evaluated.”

Do not phrase it as:

“Best price in all of DeFi.”

The latter is not provable.

Forced provider

Where supported, callers can request lifi or relay.

A forced provider should be deterministic. If it is unavailable, return a typed failure rather than silently swapping to another provider while pretending the caller's constraint was honored.

What Is x402?

x402 is FarmDash's machine-payment and API-access layer.

It is separate from:

liquidity routing;
wallet authorization;
swap settlement;
subscription entitlement.

When Scout quota is exhausted, an eligible route can return HTTP 402 with:

quota state;
reset time;
upgrade path;
route-specific payment requirement;
payment destination/token/network;
retry policy.

If the response says:

instruction: STOP_RETRYING
retry_same_request: false

the client must stop repeating the same unpaid request.

A valid x402 payment can unlock the eligible API operation under its route policy. It does not sign or settle a swap.

What Is the Current Commercial Access Model?

The source-of-truth commercial limits are currently:

Tier	Published API capacity	Primary use
Scout	30 requests / 24h	discovery and initial evaluation
Pioneer	1,500 / day	full research and wallet-aware workflows
Syndicate	50,000 / day	production/high-volume and advanced control tooling

The public default x402 overage is currently 0.01 USDC, while premium operations can publish different route-specific prices.

Hard-code as little of this as possible in external agents. Read the current 402/status response.

How Does the FarmDash Routing Fee Work?

The current combined routing-fee targets are:

Trade value	Combined target
under $10,000	50 bps
$10,000–$99,999	40 bps
$100,000–$999,999	35 bps
$1,000,000+	20 bps

For LI.FI, the known provider platform component is deducted from the combined target rather than stacked on top.

Gas, slippage, price impact, bridge/liquidity costs, and token mechanics remain separate economic effects.

Never tell a user “0.50% total cost” when the number is only the routing-fee target.

How Should Retries Work?

Financial retries require operation-specific semantics.

Safe retry candidates

A read or explicitly idempotent request can generally be retried according to its typed error contract.

Ambiguous mutations

Do not blindly replay a non-idempotent financial call after:

timeout;
connection reset;
client crash;
unknown server response;
partial provider completion.

First inspect authoritative state.

Firm quotes

Reuse the same idempotency key for the same intended economic action.

A new idempotency key should mean a genuinely new action, not “the HTTP request felt slow.”

What Is the Generic FarmDashIntent Lifecycle?

FarmDash also has a durable generic intent control plane.

Conceptually:

create
→ policy
→ simulate
→ approval
→ prepare
→ sign
→ submit
→ receipt
→ reconcile

However, tool presence does not prove that every generic transition is publicly trusted or live.

Where the authoritative policy/simulation/execution verifier is not configured, public callers must not self-attest results and have FarmDash treat them as trusted evidence.

Typical fail-closed states include:

policy evaluator unconfigured;
simulation verifier unconfigured;
execution verifier unconfigured.

The compatibility EVM swap lifecycle described earlier is a distinct, current route with its own simulation and authorization contract.

Do not mix the two state machines.

How Does Solana Fit In?

Solana support must be described per lifecycle stage.

FarmDash can have Solana:

protocol discovery;
wallet data;
quote surfaces;
preparation;
receipt verification;

without automatically having production parity for:

authoritative simulation;
signing;
broadcast;
settlement reconciliation.

The October 5, 2026 status labels Solana preview, with Jupiter firm_quote_ready=true, solana-rpc simulation, solana-message signing, customer-wallet broadcast, and a Solana receipt verifier. This is not general operational readiness or funded-transaction proof. Private submission is unsupported. Use live capability status for the current stage-specific state.

Do not write “FarmDash supports Solana execution” merely because a Solana helper or endpoint exists.

What Is Trail Heat?

Trail Heat is a research-prioritization heuristic, not an execution signal.

The live quantitative methodology uses:

Factor	Raw contribution
TVL scale	40
7-day momentum	25
chain diversification	15
category outperformance	10

The 90-point raw quantitative maximum is normalized to a 0–100 headline score.

Editorial notes remain separate metadata.

Agents should preserve:

methodology version;
data freshness;
confidence;
masked/preview state;
missing upstream fields.

A high score cannot authorize a trade.

What Should an Agent Say at Each Lifecycle State?

Use exact state language.

Estimate

“This is an informational market estimate. No provider execution state or wallet authorization exists.”

Firm quote

“A wallet-bound quote intent exists. It still requires prerequisites and simulation.”

Simulated

“The exact intent passed the current simulation gate. It has not been signed or broadcast.”

Authorized/prepared

“FarmDash validated the bounded authorization and returned the exact transaction payload. The customer wallet has not broadcast it yet.”

Submitted

“The wallet submitted transaction 0x… . Confirmation/finality is still pending.”

Confirmed

“Canonical receipt evidence passed the required confirmation contract.”

Reconciled

“Observed asset and fee changes match the authorized economic action within the expected envelope.”

This vocabulary is part of the product's safety model.

What Should Never Be Collapsed?

Keep these pairs distinct:

Do not collapse	Why
API key ↔ wallet authority	commercial access cannot become signing authority
x402 payment ↔ transaction payment	API access is not swap settlement
quote ↔ simulation	price discovery is not execution validation
simulation ↔ authorization	passing a check is not permission
authorization ↔ broadcast	a signature can authorize preparation without submitting
broadcast ↔ confirmation	a transaction can fail
confirmation ↔ reconciliation	receipt success does not explain every economic delta
MCP discovery ↔ capability readiness	tool listing is not runtime proof
EVM support ↔ Solana support	chain lifecycles have different prerequisites

Frequently Asked Questions

Does FarmDash hold user funds?

The compatibility flow is designed so FarmDash does not possess the customer's raw private key or broadcast the prepared transaction. Other venue/delegation workflows must be evaluated under their own explicit authority contract.

Does `execute_swap` mean the swap is executed?

No. It is a compatibility name for the server-side validation/preparation step that returns transaction material. The customer-controlled wallet decides whether to sign and broadcast.

Can I force 0x?

Not while the provider is operator-paused. Current compatibility provider input is LI.FI or Relay; use live status for future changes.

Is x402 a DEX or bridge?

No. It is API payment/access infrastructure.

Can an API key move funds?

A commercial bearer token is not general wallet authority. Wallet-affecting routes still require their route-specific authorization model.

Does a successful simulation guarantee profit or settlement?

No. It proves only that the simulated action passed under the tested state and assumptions at that time.

Which document is authoritative?

For operational readiness, use the live status endpoint and current OpenAPI/MCP contracts. Editorial guides explain the system but should not override runtime truth.