VCAP: Verified Commerce for Agent Protocols

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

As AI agents proliferate, they increasingly need to transact with one another: hire other agents, delegate subtasks, and pay for completed work. Today there is no standard for: How an agent requests work and holds payment in escrow How a delivering agent proves the work was actually done How a verification engine independently confirms delivery How proof of verification cryptographically triggers fund release How timeouts and disputes are escalated to human review Each marketplace invents its own ad-hoc system, creating fragmentation and vendor lock-in. VCAP provides a vendor-neutral protocol that any marketplace, payment processor, or agent framework can implement.

VCAP relates to several existing protocols. The Agent Payments Protocol (AP2) defines payment intents that VCAP fulfills at the settlement layer. The Agent-to-Agent Protocol handles agent discovery and messaging; VCAP adds payment settlement on top.

│ │ │ │ │──── 2. FORWARD ─────────>│ │ │ │<─── 3. RESPOND ──────────│ │ │<─── 4. TERMS ───────────│ │ │ │──── 5. ACCEPT ─────────>│ │ │ │ │── 6. ESCROW_HOLD ───────>│ (funds reserved) │ │ │── 7. AGREEMENT_CREATED ─>│ │ │ │ │ │ │ │ [Provider works...] │ │ │ │ │ │ │ │<─── 8. DELIVER ──────────│ │ │ │──────────── 9. VERIFY ──────────────────────>│ │ │ │ │ │ │ [Verifier runs...] │ │ │ │ │ │ │ │<──────── 10. CALLBACK ──────────────────────│ │ │ │ │ │ │── 11a. ESCROW_RELEASE ──>│ (if VERIFIED) │ │ │── 11b. ESCROW_REFUND ───>│ (if FAILED) │ │<── 12. SETTLEMENT_RECEIPT│ │ │ ]]>

Sent by the requester to initiate a service request.

json

Sent by the provider to accept, reject, or counter the request.

json

Created by the marketplace when negotiation reaches ACCEPTED.

json

Sent by the provider to claim work completion.

json

Sent by the marketplace to the verifier engine.

json

Sent by the verifier back to the marketplace. This is the most critical message in the protocol -- it triggers escrow settlement.

json

The final state of the escrow after verification.

json

Transitions:

Concurrency Guard: The HELD -> RELEASED/REFUNDED transition MUST use an atomic compare-and-swap (CAS) operation to prevent double-release. Implementations SHOULD use database-level atomic updates:

sql

Transitions:

The proof_hash field in the Verification Callback MUST be computed as:

Where canonical_json serializes the proof bundle with: Object keys sorted alphabetically (recursive) No whitespace between tokens UTF-8 encoding No trailing newline

The proof_signature field MUST be computed as an Ed25519 signature over the canonical JSON serialization of the proof body:

Where: proof_body contains at minimum: { verification_id, negotiation_id, escrow_ref, passed, proof_hash, completed_at } verifier_private_key is the Ed25519 private key of the verifier; the corresponding public key MUST be registered with the marketplace prior to use The signature binds the proof to the specific escrow, preventing replay across different transactions Implementations MUST verify proof_signature using the registered Ed25519 public key before releasing escrow funds. Constant-time signature verification MUST be used.

For verifiers that record sequential actions (e.g., browser automation), the action log SHOULD be hash-chained:

The final hash_n SHOULD be included in the proof bundle. Modifying any past action immediately invalidates all subsequent hashes, providing tamper evidence.

When agent identity is cryptographically established (e.g., via Ed25519 key pairs), the proof bundle MAY include:

json Agent identity headers for HTTP transport:

X-Agent-Signature: . X-Agent-Platform: ]]>

A compliant VCAP verifier MUST: Accept a verification_request message Return a verification_callback message within the specified timeout_seconds Include a proof_hash computed per Section 5.1 Include a proof_signature computed per Section 5.2 Set passed to true only if the verification criteria are met 6. Include an action_log documenting all steps taken A compliant VCAP verifier SHOULD: Use hash-chained action logs per Section 5.3 Include extracted_content when applicable Provide human-readable failure_reason when passed=false

The verification_hints object in the delivery message tells the verifier what to check. Standard hint fields:

If a verification does not complete within timeout_seconds (default: 1800 seconds / 30 minutes): The marketplace MUST transition the verification to TIMEOUT status The escrow MUST remain in HELD status (funds are NOT auto-released or auto-refunded) The marketplace SHOULD create a manual review queue entry with status PENDING A human reviewer MUST make the final settlement decision

Implementations SHOULD run a periodic check (recommended: every 5 minutes) that:

When a verification is escalated to manual review, the reviewer has access to: The original service agreement and negotiation terms The provider's delivery artifacts Any partial verification results (action logs, extracted content) The escrow hold details The reviewer MUST produce a standard verification_callback message with: passed = true or passed = false action_log containing a single entry documenting the manual decision proof_hash and proof_signature computed normally

If the same provider submits delivery for the same escrow multiple times, the marketplace MUST return the existing verification result rather than creating a new one. This prevents: Double-release of escrow funds Duplicate verification jobs Replay attacks

The HELD -> RELEASED/REFUNDED transition MUST be atomic and idempotent. If two concurrent processes attempt to settle the same escrow, exactly one MUST succeed and the other MUST observe the already-settled state.

If a verifier sends the same callback multiple times (e.g., due to network retry), the marketplace MUST process only the first callback and acknowledge subsequent duplicates without re-settling the escrow.

The shared_secret used for proof_signature computation MUST: Be at least 32 bytes of cryptographically random data Be transmitted out-of-band (never in VCAP messages) Be rotated periodically (recommended: every 90 days) Be unique per marketplace-verifier pair

All VCAP messages MUST be transmitted over TLS 1.2 or later.

The marketplace MUST authenticate verification callbacks to prevent spoofing. Recommended mechanisms: Shared secret in HTTP header (e.g., X-Internal-Secret) Mutual TLS Webhook signature verification

All Ed25519 signature verifications MUST use constant-time comparison to prevent timing oracle attacks.

The proof_hash + proof_signature pair creates a dual-layer integrity check: proof_hash verifies the proof content was not tampered with proof_signature verifies the proof was generated by the authorized verifier Both MUST be stored alongside the escrow settlement record for post-hoc auditability.

json

Fees SHOULD be calculated at settlement time (not at escrow creation), because: The provider's subscription tier may change between escrow creation and settlement Partial completions may adjust the fee basis Fee disputes should reference the fee at settlement time

Implementations MAY add custom fields to any VCAP message using the metadata or custom objects. Standard VCAP processors MUST ignore unknown fields.

New verification engine types can be registered by publishing their: Supported verification_hints fields Action types they may include in action_log Any custom proof_bundle fields

VCAP is agnostic to the underlying payment rail. The escrow_hold and escrow_settlement messages use wallet identifiers that can map to: Internal platform wallets (balance-based) Stripe Connect accounts Cryptocurrency wallets (x402 protocol) Bank accounts via ACH/SEPA Any future payment method

A conformant implementation MUST: [ ] Generate and process all seven message types (Sections 3.1-3.7) [ ] Implement the negotiation state machine (Section 4.1) [ ] Implement the escrow state machine with atomic CAS transitions (Section 4.2) [ ] Implement the verification state machine (Section 4.3) [ ] Compute proof_hash per Section 5.1 [ ] Compute proof_signature per Section 5.2 [ ] Support delivery idempotency (Section 8.1) [ ] Support escrow idempotency (Section 8.2) [ ] Use constant-time comparison for Ed25519 signature verification (Section 9.4) [ ] Store proof_hash and proof_signature in settlement records (Section 9.5)

The reference implementation is available at: Repository: https://github.com/bkauto3/SwarmSync

These are the standard action types for browser-automation verifiers. Other verifier types may define their own action vocabularies.

Machine-readable JSON Schema definitions for all VCAP message types are available at:

The AI Visibility Verification Standard (AIVS) defines a proof bundle format (Ed25519 + SHA-256 hash chain) for AI browser scan verification. AIVS proof bundles are a valid VCAP proof format. When a VCAP verifier uses AIVS-compliant proof bundles: The proof_hash in the VCAP callback corresponds to the AIVS manifest hash The proof_signature corresponds to the AIVS session_sig.txt The action_log corresponds to the AIVS audit_log.jsonl The AIVS verify.py can independently validate the proof without VCAP infrastructure This layering means AIVS proofs are portable: they can be verified both within a VCAP settlement flow and independently by any party with the proof bundle file.

Section 5.2: Replaced HMAC-SHA256 proof signature with Ed25519 signature for consistency with the rest of the stack. proof_signature is now computed as Ed25519Sign(canonical_json(proof_body), verifier_private_key). The corresponding verifier public key MUST be pre-registered with the marketplace. Section 5.4: Updated agent identity signature description from HMAC-SHA256 to Ed25519 to match Section 5.2 and AIVS proof format. Section 5.4: Updated X-Agent-Signature HTTP header format from HMAC-SHA256 hex to Ed25519 base64url encoding. Section 9.4: Updated timing-safe comparison requirement from HMAC to Ed25519 verification. Section 11 (Implementer Checklist): Updated checklist item to reference Ed25519 verification. These changes eliminate the cryptographic inconsistency identified in W3C AI-KR-CG Technical Note AI-KR-CG-TR-2026-001, aligning all signature operations in the stack on Ed25519.

This document has no IANA actions.