Deployment status (August 2026): The FarmDash ACP V2 workflow is implemented and configuration-gated. It is not a live production payment feature until database, evaluator, RPC, cron, readiness, and production-observability prerequisites have passed.
Direct answer: FarmDash's Virtuals ACP upgrade replaces a shared-control model with a customer-owned commerce workflow. The customer controls the ACP client wallet, approves spend-capable actions locally, and funds escrow directly. FarmDash operates a separate evaluator that can assess only jobs explicitly bound to a signed tender.
What changed
| Earlier risk or ambiguity | Upgraded FarmDash control |
|---|---|
| A server-controlled signer could become a payment rail | The customer owns the ACP client wallet and signs locally |
| A generic session could be mistaken for wallet authority | The customer signs an exact EIP-712 tender approval |
| Jobs could be committed before full review | A tender starts as a non-spendable draft |
| Providers or evaluators could be substituted | FarmDash verifies the onchain client, provider, and evaluator against the tender |
| Agent agreement could be treated as sufficient proof | Fresh FarmDash simulation is a deterministic veto |
| Several valid jobs could exceed the intended total | The customer signs one aggregate Base USDC cap |
| Submission could be reported as completion | Completion requires a canonical successful receipt |
| Uncertain settlement could be retried blindly | Ambiguous state stops for reconciliation |
The role of Virtuals ACP and the role of FarmDash
Virtuals ACP is a framework for verifiable agent commerce. Its protocol model covers the agreement, transaction or escrow, and evaluation phases that make agent-to-agent work auditable. See Virtuals' ACP technical deep dive and ACP v2 primer for the protocol's own documentation.
FarmDash adds DeFi-specific controls around that commerce lifecycle:
- A fresh, authoritative FarmDash simulation is prepared for the proposed route.
- FarmDash creates a non-spendable tender containing the task commitment, providers, evaluator, simulation reference, and maximum payment.
- The customer reviews and signs the exact typed approval locally.
- The customer-owned connector creates and funds the committed ACP jobs.
- FarmDash verifies that each onchain job matches the signed tender.
- Specialists submit structured evidence.
- FarmDash checks consensus, simulation, identities, deliverables, and the aggregate cap.
- The evaluator completes or rejects only verified bound jobs.
- The system records a canonical Base receipt before reporting completion.
The upgraded authority model
| Role | Controls | Cannot do |
|---|---|---|
| Customer-owned ACP client | Reviews tender, chooses committed providers, signs locally, creates jobs, funds escrow | Force FarmDash to settle an invalid, unbound, or over-cap job |
| FarmDash ACP evaluator | Reads bound evidence, applies consensus and simulation controls, completes or rejects verified jobs | Create customer jobs, fund escrow, change the cap, or spend from the customer wallet |
This separation is intentional. A compromised FarmDash API should not gain the customer's ACP key. A compromised customer session should not gain unrestricted evaluator authority. A positive tender evaluation also does not authorize a separate DeFi transaction.
The tender lifecycle in practice
1. Simulate the exact route
The simulation records the route context, expected output, gas, applicable policy result, and freshness. A failed, stale, or materially changed simulation cannot support evaluation.
2. Create a draft and obtain typed approval
The draft commits to the task hash, simulation ID, specialist addresses, evaluator address, cap, nonce, and deadline before any spend occurs. EIP-712 makes those fields structured and domain-separated. It does not eliminate replay risk, so FarmDash also enforces nonce uniqueness, expiry, exact-payload matching, and tender state.
For contract wallets, FarmDash verifies the resulting signature through ERC-1271 over trusted Base RPC. A session token or API key is not wallet approval.
3. Create, fund, and bind jobs locally
After approval, the customer-owned connector creates one job per committed specialist and presents each spend-capable action locally. FarmDash then reads the onchain job and refuses to bind it unless the client, provider, evaluator, tender, role, and budget context match the signed commitment.
4. Verify evidence, consensus, and economics
The specialist roles are deliberately distinct:
- Solidity auditor: contract interaction, permissions, selectors, proxies, and technical execution risk.
- DeFi economist: liquidity, gas, slippage, incentives, dilution, and capital efficiency.
- Sentiment analyst: incidents, governance, withdrawal pressure, and external confidence signals.
Two eligible safe verdicts can meet the consensus threshold. They cannot override a failed or stale simulation, invalid evidence, provider/evaluator substitution, excessive output or gas deviation, or a cap violation.
5. Settle only after confirmation
The evaluator can complete or reject only jobs already bound to it. FarmDash uses durable settlement attempts and receipt checks to distinguish submitted, confirmed, failed, and reconciliation_required. A transaction broadcast is not proof of completion.
Budget and risk limits
The customer signs a maximum aggregate payment in integer Base USDC units:
1000000 = 1.00 USDC
1250000 = 1.25 USDC
2000000 = 2.00 USDC
FarmDash compares the sum of all bound job payments against that cap. The cap is an upper limit, not an instruction to spend the entire amount. This workflow does not guarantee profit, yield, points, airdrop eligibility, or safety from all protocol and market risk.
What remains configuration-gated
Before production activation, FarmDash must verify the ACP migrations, evaluator registration and server secrets, trusted Base RPC, customer-local signing, authenticated settlement cron, canonical receipt handling, idempotency, reconciliation procedures, and production monitoring. If the evaluator is not configured, the service should return acp_evaluator_unconfigured and perform no customer wallet action.
Frequently asked questions
Does the upgrade give FarmDash control of my Virtuals ACP wallet?
No. The customer owns the client wallet and local signer. FarmDash's separate evaluator has constrained, job-bound authority.
Can FarmDash create or fund ACP jobs for a customer?
No. The customer-owned connector creates and funds jobs after explicit local approval.
Does agent consensus authorize a DeFi trade?
No. Consensus is tender evidence. A DeFi transaction still requires its own current quote, simulation, policy checks, approval, wallet signature, and receipt lifecycle.
Why simulate after the agents agree?
Agent evidence can be stale or incomplete. A fresh deterministic simulation can veto a recommendation when output, gas, route, or execution conditions have changed.
What happens if a receipt cannot be confirmed?
The tender enters reconciliation rather than being reported as complete or blindly retried.
Related FarmDash guides
- Virtuals ACP V2 Job Lifecycle: From Provider Selection to Confirmed Base Receipt
- How FarmDash Uses Virtuals ACP Without Taking Custody
- Virtuals ACP: Customer-Owned Escrow, Consensus, and Receipt-Verified Settlement
- FarmDash Agent Hub Complete Manual
- FarmDash Agent Sandbox SDK Guide
- FarmDash Security
- FarmDash API Documentation