Terminology and Conventions

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in .

Layer Zero

The pre-negotiation capability advertisement layer: the mechanism by which a requester agent discovers which settlement protocols, trust credentials, and verification formats a provider agent supports, before any payment intent or negotiation message is created.

MCP Model Card

A structured, machine-readable capability declaration document attached to an MCP server, declaring the server's capabilities, constraints, provenance, and quality metadata. As defined in the MCP Model Card Specification v1.0 (Di Maio, W3C AI Knowledge Representation Community Group, 2026; stable URL forthcoming).

Agent commerce stack

The combination of VCAP, AIVS, ATEP, and VCAP-AP2-Binding as a unified protocol suite for agent-to-agent financial transactions.

Capability advertisement gap

The absence of a standardized mechanism for an agent to declare its supported payment protocols, trust tier, and verification preferences to a prospective requester before negotiation begins.

Architectural Overview

The four drafts form a coherent vertical stack. Each layer addresses a distinct problem in agent-to-agent commerce:

 +---------------------------------------------------------+
 | VCAP-AP2 BINDING (integration layer) |
 | Connects VCAP settlement to AP2 PaymentIntent schema |
 +---------------------------------------------------------+
 | ATEP (reputation layer) |
 | Portable trust credential from append-only exec logs |
 +---------------------------------------------------------+
 | VCAP (settlement layer) |
 | 7-phase escrow state machine, timeout, idempotency |
 +---------------------------------------------------------+
 | AIVS (proof layer) |
 | SHA-256 hash-chained audit log, Ed25519 signature |
 +---------------------------------------------------------+
 | LAYER ZERO [NOT SPECIFIED] |
 | Pre-negotiation capability advertisement |
 | "Does this agent support VCAP? What tier? Which proofs?"|
 +---------------------------------------------------------+
 | MCP / A2A / Agent Protocol (transport layer) |
 | Discovery, messaging, tool invocation |
 +---------------------------------------------------------+
 

The conceptual separation is sound and the individual layer specifications are technically substantive. The problem this Note addresses is not within any layer but between the transport layer (MCP, A2A , Agent Protocol) and the settlement layer (VCAP). That gap is what we term [=Layer Zero=].

VCAP: Settlement Layer Assessment

The VCAP specification makes a precise and verifiable contribution to the AP2 v0.1 gap identified in its problem statement. AP2 v0.1 defines captureType: "escrow_release" with releaseCondition: "delivery-confirmation" but leaves the transition trigger, confirmation format, verifier identity, timeout behavior, and cryptographic binding unspecified. VCAP answers all five questions with implementable precision.

The escrow state machine is well-specified: the HELD to RELEASED or REFUNDED transition uses an atomic compare-and-swap operation to prevent double-release; timeout requires the escrow to remain HELD pending human review rather than auto-releasing or auto-refunding; and idempotency is required on delivery, escrow transitions, and verification callbacks.

The verification callback that triggers fund release uses HMAC-SHA256 with a pre-shared symmetric secret, not the Ed25519 keys established in AIVS and used for agent identity in ATEP. A compromise of the shared secret enables fabrication of payment-triggering callbacks without any valid AIVS proof bundle, bypassing the entire proof layer. Agent identity binding via Ed25519 is marked OPTIONAL in VCAP Section 5.4. For a payment-triggering message, this SHOULD be REQUIRED.

The auto_approve boolean in verification hints, if set to true, skips automated verification and allows provider self-attestation. No conditions are specified for when this field may or may not be set. In an adversarial context, a provider agent can always set auto_approve: true and receive payment without independent verification. This field MUST be gated to TRUSTED tier agents at minimum, and the restriction MUST be stated normatively.

VCAP describes verification engines as independent third parties, but the only known reference implementation has SwarmSync.AI acting as both marketplace and verifier via Conduit . A vendor-neutral protocol requires a verifier registration mechanism and conflict-of-interest rules. These are absent.

AIVS: Proof Layer Assessment

AIVS is technically the strongest of the four drafts. The hash chain specification is fully deterministic, the verification algorithm is reproducible, and the self-contained verify.py using only Python 3 stdlib is an excellent portability design. The security section is notably candid:

"AIVS does not prove that the recorded inputs/outputs actually occurred. A malicious agent could fabricate actions and produce a valid chain."

This candor is valuable and should be preserved and amplified in any revision.

The hash chain includes seven fields per row but excludes inputs_json and outputs_json. Output truncation is explicitly permitted and does not affect chain validity. This means a valid chain can exist where the actual content of what the agent produced has been replaced or omitted. For a proof format used to trigger escrow release, the content of deliverables SHOULD be cryptographically bound, not merely the action sequence metadata.

The Ed25519 session signature is optional. An unsigned AIVS bundle proves only internal chain consistency -- any party can generate a valid unsigned bundle from scratch. When AIVS is used as VCAP proof-of-delivery, the signature MUST be required.

AIVS situates itself relative to IETF SCITT , W3C VC 2.0 , and Certificate Transparency. Actual SCITT integration would require COSE signing (RFC 9052), which is not specified here. This is a natural extension point for a future revision and would significantly strengthen the standards lineage.

ATEP: Reputation Layer Assessment

ATEP addresses a genuine and underspecified problem: the absence of portable, fraud-resistant agent reputation credentials across marketplaces. The append-only log requirement, monotonic trust tier promotion, and W3C Verifiable Credentials wrapper are architecturally correct design choices.

The portability claim contains a structural problem. When an agent transfers a passport from Platform A to Platform B, Platform B is advised to treat imported statistics as advisory rather than authoritative, and may require a local probation period before honoring the imported tier. If every platform discounts imported trust, cross-platform portability is illusory in practice. The spec acknowledges this without resolving it. Resolving it requires an independent trust anchor -- precisely the role that W3C DID and SCITT could serve.

The passport is signed with HMAC-SHA256 using an issuer key, while the VC wrapper example uses Ed25519Signature2020. For a credential claiming to be "verifiable," the core signing mechanism should use the same asymmetric cryptography as the VC wrapper, not a symmetric HMAC that requires the verifier to hold the issuer's secret.

Trust tier thresholds (10, 50, 200 sessions) are low enough to be gamed by orchestrated self-dealing within a single marketplace. An operator running both requester and provider agents can reach TRUSTED tier -- unlocking financial operations with optional verification -- through mutual session farming. Rate limiting and cross-platform corroboration requirements are not specified.

VCAP-AP2 Binding: Integration Layer Assessment

The AP2 binding is the most strategically significant document in the suite for the purposes of this Technical Note. It specifies precisely how the VCAP verification result triggers an AP2 PaymentIntent state transition from authorized to captured, defines the vcap.verification_proof evidence type for the AP2 evidence array, and introduces three webhook event schemas for the VCAP verification lifecycle.

The dual-signature settlement concept is the most coherent security statement in the entire suite: AP2's VDC signature proves the buyer authorized the payment; VCAP's proof signature proves delivery was independently verified; both must be valid for settlement to proceed.

The ATEP passport is embedded as a credential type inside AP2's participant objects:

{
 "participants": {
 "seller": {
 "credentials": [
 { "type": "ap2.vdc.agent_identity", ... },
 { "type": "atep.passport.summary",
 "trust_tier": "VERIFIED",
 "total_sessions": 127,
 "success_rate": 0.94,
 "issuer": "swarmsync.ai",
 "signature": "..." }
 ]
 }
 }
}
 

This is where the [=capability advertisement gap=] becomes most visible. The AP2 binding assumes the seller's credentials are already present in the PaymentIntent when it is created. It specifies how trust modulates payment parameters during a transaction. It does not specify how a requester agent discovers whether a provider supports VCAP, what tier they hold, or where their passport endpoint is -- before creating any payment intent at all.

The trust-adjusted escrow table permits TRUSTED tier agents to use self-attestation with verification described as optional. This same vulnerability appears in VCAP and the AP2 binding. It should be flagged consistently: TRUSTED tier is currently reachable through session farming, making this the highest-risk permissive clause in the stack.

Characterizing the Gap

The VCAP specification positions itself as "a settlement layer that complements agent-to-agent communication protocols (such as Google A2A or the Agent Protocol)." The AP2 binding assumes that when a requester agent creates a PaymentIntent, it already knows:

• that the provider agent supports VCAP settlement;
• what verification engines the provider accepts;
• which ATEP trust tier the provider holds and which platform issued it;
• where the provider's passport endpoint is located; and
• which proof formats (AIVS full bundle, AIVS-Micro, or other) constitute valid delivery confirmation.

Neither A2A , the Agent Protocol, nor MCP currently specifies how an agent advertises payment protocol capabilities. An MCP-exposed provider agent has no standard mechanism to declare to a connecting requester:

"I support VCAP settlement. My ATEP trust tier is VERIFIED, issued by platform X. My passport endpoint is at this URL. I accept AIVS full bundle as proof format. My Ed25519 public key is this value. My preferred verification engine is browser automation."

Without that declaration, the requester agent cannot evaluate whether VCAP-based payment is viable before initiating a task. This forces out-of-band credential exchange, hardcoded assumptions about provider capabilities, or trust in a marketplace intermediary's representation of the provider -- all of which reintroduce exactly the vendor lock-in the VCAP suite claims to eliminate.

More critically: in a pipeline where TRUSTED tier agents can receive payment with optional verification and reduced escrow, the ability to misrepresent capability credentials at the pre-transaction discovery stage is the highest-value attack surface in the entire stack. A malicious agent claiming TRUSTED tier capabilities before any VCAP machinery is engaged can extract favorable escrow terms that the rest of the protocol then treats as legitimate.

MCP Model Card as Layer Zero

The MCP Model Card Specification v1.0 (Di Maio, W3C AI Knowledge Representation Community Group, 2026; stable URL forthcoming), developed through the W3C AI Knowledge Representation Community Group, provides the pre-transaction capability advertisement layer that the agent commerce stack assumes but does not specify. An MCP model card is a structured, machine-readable document attached to an MCP server that declares the server's capabilities, constraints, provenance, and quality metadata. It is readable by a requester agent before any negotiation or task assignment begins.

A commerce_capabilities extension to the MCP Model Card schema would provide the Layer Zero declaration. The proposed extension requires three fields:

settlement_protocols

An array declaring which payment settlement specifications the agent supports, including version identifiers. Example values: "vcap:1.0", "ap2:0.1+vcap".

trust_credentials

A block containing the agent's ATEP passport endpoint URL, current trust tier, issuing platform, issuer signature, and credential freshness timestamp. This provides the information that the AP2 binding embeds in the PaymentIntent participant block, but makes it available for inspection before the PaymentIntent is created.

verification_acceptance

An object specifying which proof formats and verification engines the agent will accept as delivery confirmation: AIVS full bundle, AIVS-Micro, LLM evaluation, human review, or composite.

A requester agent reading this model card before negotiation can determine from a single document lookup whether VCAP settlement is viable, what tier-adjusted escrow terms to expect, and whether the provider's trust credentials are fresh enough to rely on. This eliminates the attack surface created by credential misrepresentation at the pre-transaction stage.

The proposed JSON structure for the extension is:

{
 "mcp_model_card_version": "1.0",
 "commerce_capabilities": {
 "settlement_protocols": ["vcap:1.0", "ap2:0.1+vcap"],
 "trust_credentials": {
 "atep_passport_endpoint": "https://example-marketplace.ai/agents/{id}/passport/public",
 "trust_tier": "VERIFIED",
 "issuer_platform": "example-marketplace.ai",
 "issuer_signature": "...",
 "credential_issued_at": "2026-03-14T12:00:00Z",
 "credential_expires_at": "2026-03-15T12:00:00Z"
 },
 "verification_acceptance": {
 "proof_formats": ["aivs_bundle:1.0", "aivs_micro:1.0"],
 "verification_engines": ["browser_automation", "llm_eval"],
 "ed25519_public_key": "..."
 }
 }
}
 

This extension is additive and non-breaking. Agents that do not support VCAP simply omit the commerce_capabilities field. Agents that do support it provide a machine-readable declaration that is verifiable against the ATEP passport endpoint before any transaction begins.

Security Properties of the Layer Zero Extension

Single-Author IETF Submissions with Proprietary Reference Implementations

All four drafts are authored solely by SwarmSync.AI. All reference implementations point to SwarmSync's proprietary NestJS codebase. The ATEP badge namespace reserves unprefixed types for the "standard" while all provided examples use swarmsync:-prefixed identifiers. The verifier in the VCAP model is functionally the same entity as the marketplace in the only known deployment.

These are not disqualifying conditions for a first-submission individual draft. They are, however, conditions that must change for the drafts to function as genuine open standards rather than proprietary infrastructure described in RFC format.

This pattern is consistent with the premature commercialization concern documented in WebMCP Technical Note 4 (Di Maio, W3C AI-KR-CG, 2026; stable URL forthcoming), where web-mcp.net began selling compliance tools against an empty security section of the WebMCP spec. In both cases, a commercial actor has structured standards activity to consolidate ecosystem control. Community vigilance is appropriate.

Namespace and Registry Governance

Three registries implied by the Stone drafts currently have no governance structure:

• ATEP badge namespace: Who adds types to the standard set? What is the process for registering a platform-prefixed badge type with a neutral authority?
• VCAP verifier registry: Who can register as an independent verification engine? How is independence from the marketplace established and maintained?
• VCAP action type registry (Appendix A of VCAP): The action vocabulary is presented as exhaustive for browser automation, with no extension process defined for other agent types.

Without governance for these registries, de facto control rests with SwarmSync.AI as the sole author and implementor. The W3C AI-KR-CG has established precedent for multi-stakeholder registry governance in the agentic AI space and is positioned to propose a neutral governance framework for these registries.

Cryptographic Consistency Across the Stack

The four drafts use three different signing mechanisms without stated rationale:

A coherent security design would use Ed25519 consistently throughout the stack for all authentication and proof purposes, and treat HMAC as an explicitly acknowledged fallback for constrained environments only. The current inconsistency means the strongest security guarantees can be bypassed at the most critical points: payment release and reputation transfer.

R1: Extend MCP Model Card Specification with commerce_capabilities

The MCP Model Card Specification (Di Maio, W3C AI-KR-CG, 2026) SHOULD be extended with a commerce_capabilities section providing the Layer Zero declaration schema described in . Draft text SHOULD be circulated to the WebMCP community list and the W3C AI-KR-CG mailing list before the next community call.

R2: Initiate Liaison with AP2 Working Group

The W3C AI-KR-CG SHOULD initiate formal liaison with the AP2 working group to identify the pre-transaction capability advertisement gap as a priority interoperability issue, with MCP model cards proposed as a candidate solution alongside any AP2-native mechanism.

R3: Invite Stone Drafts to W3C AI-KR-CG Community Call

The Stone IETF drafts SHOULD be invited to present at a W3C AI-KR-CG community call, with the specific agenda of:

• discussing multi-stakeholder governance for the ATEP badge namespace and VCAP verifier registry;
• addressing the Ed25519 vs HMAC inconsistency as a priority revision item;
• identifying co-authors from outside SwarmSync.AI to broaden the draft's community basis.

R4: Issue Technical Comment on Cryptographic Consistency

A formal technical comment SHOULD be submitted to the IETF draft authors requesting that Ed25519 signing be elevated from OPTIONAL to REQUIRED for all payment-triggering messages (VCAP verification callback) and all portable credential issuance (ATEP passport signing), consistent with the approach already taken in AIVS and the ATEP VC wrapper.

R5: Issue Technical Comment on auto_approve Gating

A formal technical comment SHOULD be submitted requesting that the auto_approve field in VCAP service delivery be constrained by a normative MUST NOT clause for agents below TRUSTED tier, and that TRUSTED tier itself be strengthened against session farming via rate limiting or cross-platform corroboration requirements.