Deployment status (August 2026): FarmDash ACP V2 is implemented but configuration-gated. It must not be described as a live production payment feature until the required database migrations, evaluator configuration, Base RPC verification, cron schedule, readiness checks, and production review are complete.
Direct answer: FarmDash's Virtuals ACP design separates the customer's ACP client wallet from FarmDash's evaluator. The customer retains the client signer, reviews each spend-capable action locally, and funds ACP escrow directly. FarmDash receives signed commitments and onchain job references—not the customer's private key. Its evaluator may assess and settle only jobs already bound to the signed tender.
Zero custody is an authority boundary
Zero custody is more than a promise not to store seed phrases. The architecture must not give FarmDash the authority to create or fund a customer's jobs in the first place.
| Capability | Customer-owned ACP client | FarmDash ACP evaluator |
|---|---|---|
| Review the tender and payment limit | Yes | No |
| Sign tender approval | Yes, locally | No |
| Create and fund ACP jobs | Yes, with local approval | No |
| Read a bound job and its evidence | Yes | Yes |
| Apply consensus and simulation rules | No | Yes |
| Complete or reject a verified bound job | No | Yes |
| Spend from the customer wallet | Yes, through the customer's signer | No |
The customer runs FarmDashAcpConnector in a customer-controlled process. A FarmDash session, API key, or evaluator signature is never a substitute for the customer's ACP signer.
Why a shared signer is not acceptable
A shared server-side customer signer would turn an application credential into a potential payment rail. It would create cross-tenant blast radius, unclear attribution, and a custody-like obligation. FarmDash instead operates only a separately registered evaluator signer with a deliberately narrower role: it cannot create customer jobs, fund customer escrow, change the provider set, or raise the customer's cap.
The customer's normal DeFi wallet remains a separate authority. A positive ACP verdict is evidence for a tender; it is not permission to swap, bridge, stake, deposit, or trade from another wallet.
What the customer approves
FarmDash creates a non-spendable tender before any ACP job exists. The customer should review and sign the exact EIP-712 payload returned by FarmDash—not a reconstructed payload or a generic approval message.
The signed commitment binds at least:
- the tender identifier and task commitment hash;
- the authoritative simulation ID;
- the named specialist providers and FarmDash evaluator;
- expected output and gas context;
- a maximum aggregate payment in raw Base USDC units;
- a nonce, expiry, chain ID, and signing domain.
{
"primaryType": "AcpTenderApproval",
"domain": { "name": "FarmDash", "version": "1", "chainId": 8453 },
"message": {
"tenderId": "fdat_example",
"taskCommitment": "0x...",
"simulationId": "fdsim_example",
"evaluator": "0x...",
"maxPaymentUnits": "2000000",
"nonce": "1234567890123",
"expiresAt": "2026-08-03T22:00:00.000Z"
}
}
EIP-712 standardizes structured signing and domain separation, but it does not provide replay protection by itself. FarmDash must still enforce exact-payload matching, signer identity, expiration, nonce uniqueness, and tender state.
Smart-wallet verification and data minimization
Externally owned accounts can be verified through signature recovery. Smart-contract wallets require contract-based validation: ERC-1271 defines isValidSignature(hash, signature) and its expected magic return value. FarmDash therefore requires a trusted HTTPS Base RPC and fails closed on RPC failure, malformed responses, timeouts, or chain mismatch.
FarmDash may retain audit evidence needed to verify a tender: public client address, commitment hash, simulation ID, approved provider and evaluator addresses, cap, nonce, signature, job IDs, structured verdicts, evaluation state, transaction hashes, and canonical receipts. It must never retain customer private keys, seed phrases, wallet exports, or local connector secrets.
How the tender stays bounded
The customer-owned connector follows this sequence:
- Request a draft tender and display its commitment, simulation, providers, evaluator, cap, nonce, and expiry.
- Obtain the customer's local typed-data signature.
- Create and fund each committed ACP job only after explicit local approval.
- Bind the onchain jobs to the tender.
- Submit the required specialist deliverables and request evaluation.
- Display submitted, confirmed, failed, or reconciliation-required settlement status.
Each of the three specialists addresses a different risk domain: Solidity and contract behavior, DeFi economics, and external sentiment or incident signals. Two eligible safe verdicts can satisfy the consensus threshold, but never bypass a fresh simulation, identity verification, evidence validation, or budget check.
The cap is always compared as integer Base USDC units:
1 USDC = 1000000 units
1.25 USDC = 1250000 units
Floating-point values are inappropriate for payment authorization. FarmDash checks the aggregate payment across all bound jobs against the customer-approved maximum.
Fail-closed conditions
The safe outcome when a critical control fails is no settlement. Examples include an unconfigured evaluator, expired or replayed approval, provider or evaluator mismatch, unknown job, malformed deliverable, stale or failed simulation, budget excess, receipt conflict, or ambiguous chain state. A submitted transaction is not a completed tender; completion requires a canonical successful Base receipt.
Production activation checklist
Before describing ACP V2 as live, the release owner should verify:
- the required Supabase ACP migrations and state constraints are applied;
- the evaluator is separately registered and its address, ID, and signer are server-only configuration;
- trusted Base RPC and ERC-1271 validation are enabled;
- customer-side signer approval and explicit job funding remain mandatory;
- nonce, idempotency, durable settlement leasing, and reconciliation records are functioning;
- cron authentication and the settlement schedule are configured;
- readiness checks, receipt verification, logs, and alerting have been reviewed in production.
Frequently asked questions
Does FarmDash ever receive my ACP private key?
No. The customer ACP signer remains in the customer-controlled connector process and must never be transmitted to FarmDash.
Can FarmDash withdraw from my wallet or raise the payment cap?
No. The evaluator cannot spend from the customer's wallet, create customer jobs, or alter the exact cap in the signed tender. A higher cap requires a new approval.
Does two-of-three consensus guarantee a safe or profitable transaction?
No. Consensus reduces reliance on one specialist. It does not remove market, liquidity, smart-contract, model, or execution risk, and it remains subordinate to deterministic simulation and policy gates.
What happens when Base RPC verification or receipt confirmation is unavailable?
The workflow should fail closed or enter reconciliation. It must not infer signature validity or report a settlement as complete without a verified canonical receipt.
Related FarmDash guides
- 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