Virtuals ACP V2 Security: Consensus and Receipt Settlement

How FarmDash secures customer-owned Virtuals ACP jobs with verified providers, committed evidence, simulation, Base payment caps, and receipt finality.

Deployment status (August 2026): FarmDash ACP V2 is implemented but configuration-gated. It is not a live production payment feature until the migration, provider-registry, evaluator, Base RPC, scheduler, finality, readiness, and human go-live checks pass.

Direct answer: FarmDash uses a customer-owned Virtuals ACP client to create and fund specialist jobs, while a separately registered FarmDash evaluator verifies those jobs. The V2 workflow binds provider selection, privacy disclosures, simulation evidence, economic policy, payment cap, and evaluator identity into one exact approval. FarmDash does not receive the customer's private key and does not report settlement as complete until canonical Base receipts are confirmed.

What ACP V2 changes

The original version of this guide described FarmDash's V1 tender path. New integrations must use the allowlisted V2 workflow. V1 creation is disabled by default and exists only as a controlled compatibility path.

V2 adds controls that cannot be reconstructed after approval:

an authoritative, expiring provider plan from the FarmDash readiness registry;
a local secret scan and an explicit disclosure manifest before task plaintext reaches providers;
immutable hashes for the provider plan, disclosure manifest, evidence snapshot, economic policy, and task commitment;
an exact EIP-712 V2 approval signed by the customer ACP wallet;
durable, cap-aware funding reservations made only after local approval;
V2 specialist verdicts bound to the same role, task, simulation, and evidence;
canonical receipt and confirmation checks for funding and evaluator settlement.

For the complete request-to-receipt sequence, see Virtuals ACP V2 Job Lifecycle: From Provider Selection to Confirmed Base Receipt.

The authority model

Role	Controls	Cannot do
Customer-owned ACP client	Reviews the plan, signs the exact approval locally, creates jobs, and funds escrow	Force FarmDash to accept substituted providers, stale evidence, or an over-cap tender
FarmDash ACP evaluator	Reads bound evidence, applies consensus and simulation gates, and completes or rejects verified jobs	Create customer jobs, fund escrow, alter the signed cap, or spend from the customer wallet
Specialist providers	Analyze the disclosed task and return role-specific V2 evidence	Change the tender, evaluator, payment cap, or the other providers

The customer runs FarmDashAcpConnector in a customer-controlled process with its own registered ACP wallet and signer. A FarmDash session or API key authenticates an API request; it is not a substitute for the wallet's payment authority.

The current V2 lifecycle

POST /api/v1/agent/virtuals-acp exposes the V2 coordination actions. The customer connector remains the only component allowed to submit spend-capable wallet calls.

select_provider_plan_v2 selects three eligible providers from current registry, identity, stake, and readiness observations.
The connector scans the task locally, computes its commitment, and prepares the disclosure categories the customer will approve.
prepare_tender_v2 captures authoritative FarmDash evidence and returns a non-spendable draft plus exact typed data.
authorize_tender_v2 verifies the customer's exact signature, nonce, expiry, provider plan, evidence window, and tenant/session ownership.
The customer connector creates the specialist jobs locally; bind_job verifies each onchain client, provider, evaluator, role, status, and expiry.
After the customer approves each funding call locally, reserve_funding_v2 atomically reserves the exact job amount under the signed aggregate cap.
The connector submits funding from the customer wallet and calls record_funding_submission_v2 with the resulting Base transaction hashes.
The funding finality worker confirms canonical successful receipts before evaluation becomes eligible.
Specialists submit farmdash_acp_specialist_verdict/v2 deliverables. evaluate_tender validates every binding, the funding ledger, evidence, consensus, and the deterministic FarmDash gate.
The evaluator completes or rejects only the bound jobs. Settlement remains pending until its own Base receipt checks pass; ambiguous terminal state stops for reconciliation.

sequenceDiagram
    participant C as Customer connector
    participant F as FarmDash API
    participant P as ACP providers
    participant B as Virtuals ACP on Base

    C->>F: Select verified provider plan
    C->>C: Secret scan and disclosure approval
    C->>F: Prepare non-spendable V2 tender
    F-->>C: Evidence and exact EIP-712 payload
    C->>C: Review and sign locally
    C->>F: Authorize exact tender
    C->>B: Create specialist jobs
    C->>F: Bind verified job references
    C->>C: Approve exact funding calls
    C->>F: Reserve exact amounts under cap
    C->>B: Submit customer-owned funding
    C->>F: Record Base transaction hashes
    P->>B: Submit V2 specialist verdicts
    C->>F: Evaluate tender
    F->>F: Evidence + consensus + simulation gates
    F->>B: Complete or reject bound jobs
    F->>F: Confirm canonical Base receipts

Consensus is evidence, not spending authority

Each provider fills a distinct role: Solidity auditor, DeFi economist, or sentiment analyst. A two-of-three safe result can satisfy the specialist consensus threshold, but it cannot override a failed deterministic control.

FarmDash rejects or stops a tender when, for example, evidence is stale, a provider or evaluator does not match, a structured deliverable is malformed, a high-severity finding blocks approval, the payment ledger exceeds the signed maximum, receipt finality is missing, or the authoritative simulation gate fails.

A positive ACP evaluation is also not authorization for a separate swap, bridge, deposit, stake, or trade. Any DeFi execution needs its own current quote, simulation, policy decision, wallet approval, transaction submission, and receipt lifecycle.

Privacy and evidence binding

FarmDash stores a SHA-256 task commitment rather than the original task plaintext. Before sending the task to providers, the local connector blocks common secrets and records only approved disclosure categories. An override requires a reason commitment and explicit customer approval; detected secret values must never be sent to FarmDash.

The V2 approval binds the task commitment to the approved disclosure manifest, evidence snapshot, provider plan, economic policy, evaluator, maximum Base USDC payment, nonce, and expiry. EIP-712 provides structured signing and domain separation, but the standard does not supply replay protection. FarmDash therefore enforces nonce consumption, expiry, state transitions, and exact-payload matching. Smart-contract wallet signatures are checked through ERC-1271 using trusted Base RPC.

Deployment truth

Production activation requires the repository's ACP migrations in order, including the original tender controls and the V2 evidence, registry, funding, evaluation, finality, nonce, provider-selection, and concurrency hardening through migrations 044 and 045. Both migration verifiers must pass before enablement.

FarmDash's committed Vercel Hobby configuration currently schedules both /api/cron/settle-acp-tenders and /api/cron/acp-funding-finality once daily. A faster schedule requires an approved Vercel Pro or external scheduler authenticated with CRON_SECRET. The public site must not claim five-minute settlement while the deployed schedule is daily.

ACP V2 must remain disabled unless every readiness declaration reflects a tested production prerequisite, the Base RPC reports chain 8453, canonical Base USDC and contract configuration are verified, scheduler heartbeats and logs are clean, and a human release owner approves go-live.

Frequently asked questions

Does FarmDash control the customer ACP wallet?

No. The client wallet and signer remain in the customer-controlled connector. FarmDash operates a separate evaluator with narrower, job-bound authority.

Can an API session create or fund an ACP job?

No. A session authenticates coordination requests. Job creation and funding require explicit local approval and the customer's ACP signer.

Does two-of-three consensus guarantee safety or profit?

No. It reduces dependence on one provider. It does not eliminate smart-contract, liquidity, market, model, or execution risk, and it cannot bypass deterministic FarmDash controls.

Is a submitted transaction a completed settlement?

No. Submission is pending. Completion requires a canonical successful receipt with the required confirmations. Uncertain state enters reconciliation instead of being blindly retried.