x402 Ecosystem Adds WebTransport Probing and DID Resolution APIs

The x402 payment protocol is turning capability invocations between AI Agents into a measurable service. In the latest update, developers launched two new paid APIs: one for detecting whether a target website truly supports WebTransport, and another for unified querying of W3C Decentralized Identifier (DID) resolution status. Each request is priced at 0.0005 USDC and settled via the Base network — services like these are filling the "last mile" verification gap in the Agent toolchain.

Why WebTransport Needs a Dedicated Probing Tool

WebTransport (RFC 8441, RFC 9290, RFC 9221) is a bidirectional low-latency transport layer built on HTTP/3, and Google Meet-style real-time applications, the Cloudflare Realtime platform, and a growing number of A2A agent protocol stacks are built on top of it. The problem is that a website claiming HTTP/3 support does not mean it has actually exposed a WebTransport endpoint.

The newly launched /api/webtransport-probe?url=<URL> endpoint performs 8 audits: parsing h3 port declarations in the Alt-Svc header, sending an Extended CONNECT request with the :protocol=connect-udp pseudo-header, HEAD-probing 6 conventional paths to find session endpoints, validating whether endpoints are https, detecting the Supports-Transport-Webtransport response header, probing the SCITT endpoint, identifying client libraries in the HTML, and extracting the ECH config ID from Alt-Svc parameters.

The output includes webtransport_advertised, http3_drafts[], webtransport_endpoints[], connect_udp_endpoints[], and a webtransport_score rating from 0 to 100. The author's live test on cloudflare.com showed: Cloudflare advertised h3=":443"; ma=86400, but the score was 25, with the conclusion connect_udp_explicitly_disabled — it supports HTTP/3 but has not yet exposed a WebTransport endpoint. This case precisely illustrates the necessity of probing: transport-layer capabilities need to be verified item by item, not inferred from vendor marketing.

Interestingly, this endpoint forms a division of labor with the author's previously launched tools — the generic Alt-Svc check, QUIC handshake probing, and 0-RTT replay risk assessment — specifically covering the WebTransport protocol layer and endpoint discovery.

Alt-Svc Header and Protocol Negotiation: Alt-Svc (Alternative Services, RFC 7838) is an HTTP response header that tells the client that the same resource of the origin can be served via other endpoints or protocols. A common form is h3=":443"; ma=86400, indicating HTTP/3 is reachable on port 443 of the same host, with ma being the cache lifetime in seconds. Parsing the h3 port from Alt-Svc is the first step in determining whether the server "announces" HTTP/3, but an announcement does not mean a usable WebTransport session is open, so subsequent Extended CONNECT probing is still required.

Extended CONNECT and the :protocol Pseudo-Header: In HTTP/2 and HTTP/3, the CONNECT method can carry a :protocol pseudo-header via an extension mechanism (RFC 8441, RFC 9221), thereby establishing a bidirectional tunnel such as WebSocket or WebTransport within a single HTTP connection. When :protocol=connect-udp, it indicates a datagram stream carrying UDP semantics over HTTP/3, which is the key underlying capability of WebTransport. The probe endpoint actively sends such requests to directly verify whether the server actually handles the WebTransport handshake, rather than merely making a static announcement.

ECH (Encrypted Client Hello): ECH is a TLS 1.3 extension used to encrypt sensitive fields such as the SNI in the ClientHello, preventing intermediaries from snooping on the target domain being accessed. Its configuration is distributed in base64 form via DNS HTTPS records or the ech field in Alt-Svc parameters. Extracting the ECH config ID from Alt-Svc parameters can help assess whether the server has deployed encrypted SNI, serving as corroborating evidence of transport-layer privacy capabilities.

Fragmented DID Resolution Spurs a Unified Catalog API

The W3C DID Method Registry (December 2024 edition) lists 28 methods, but no public resolver currently covers them all uniformly. Universal Resolver mainly handles a few methods such as did:ion, did:web relies on /.well-known/did.json, did:plc goes through plc.directory, and ATProto has its own identity layer — for Agent applications that need to verify identities across methods, the integration cost is high.

/api/did-method-catalog?did=<DID> consolidates resolution for 13+ methods into a single call: did:web reads the well-known path; did:key is decoded offline via multibase and multicodec; did:plc queries the AT Protocol directory; did:webvh reads /.well-known/did.jsonl; did:ion goes through the Microsoft Sidetree interface; did:jwk directly decodes the base64url JWK; did:ethr queries the ERC1056 registry via public Ethereum RPC; and the remaining methods fall back to the DIF universal resolver.

Returned fields include per-method resolution_status, did_document_present, resolution_url, error messages, and, on successful resolution, the full DID document, registry_completeness, and a did_method_score from 0 to 100. For developers building cross-platform identity verification, this "one query, multiple fallbacks" pattern can significantly reduce adaptation code.

W3C DID and DID Documents: A Decentralized Identifier (DID) is a string identifier developed by the W3C, in the form did:method:identifier, where method specifies the resolution rules (e.g., did:web, did:key) and identifier is defined by that method itself. Each DID can be resolved into a DID Document, which contains public keys, verification methods, service endpoints, etc., and serves as the carrier for identity verification and key agreement. "Resolution" refers to the process of obtaining the DID Document and its metadata from a DID string.

multibase and multicodec: These are two companion encoding specifications. multicodec assigns a short prefix to different key or data formats (e.g., ed25519-pub corresponds to 0xed01), while multibase prepends a character to the encoded result to indicate the encoding used (e.g., z for base58btc). did:key works precisely by prefixing the public key per multicodec and then encoding it with multibase, so the public key can be fully reconstructed offline from a DID string without a network query — which is why the did:key branch in the unified catalog API performs "offline decoding."

Sidetree and ERC1056: Sidetree is a specification proposed by DIF for batch-anchoring DID state onto existing distributed ledgers (such as Bitcoin and Ethereum); did:ion is a Bitcoin-based Sidetree implementation. ERC1056 is the "lightweight identity" standard on Ethereum, mapping Ethereum addresses to DIDs and public keys via a smart contract; did:ethr relies on public RPC to read that contract's state. What both share is that resolution requires access to on-chain or indexing services, so a unified API must configure separate backends for each.

x402 Payment Model and API Design for the Agent Economy

Both endpoints are priced at 0.0005 USDC, settled via the x402 protocol on the Base network (eip155:8453), with USDC as the asset contract. The service provider claims it has run continuously for 165 cycles and opened 238 paid routes; the catalog is continuously updated via /.well-known/x402 and /openapi.json, and settlement is handled by pay.openfacilitator.io rather than a mock stub.

From a broader perspective, these micropayment APIs solve the problem of Agents automatically discovering and verifying external capabilities. When an AI Agent needs to determine whether a service supports a particular transport protocol or identity system, rather than embedding a large amount of probing logic, it is better to pay less than a cent to call a dedicated endpoint. This "verification-as-a-service" form may become a stable category of infrastructure in the Agent tooling ecosystem.

A caveat, however: the service addresses are currently hosted on a temporary trycloudflare.com domain, and the information comes from the project's own statements; actual availability and settlement stability still require independent verification.

x402 Protocol and HTTP 402: x402 is a micropayment protocol based on HTTP status code 402 (Payment Required). The idea is that the server returns payment requirements (amount, asset, network, payee address) in its response; the client completes an on-chain payment and then retries the request with payment credentials, and the server verifies and grants access. Because payment and request are negotiated within the same HTTP round trip, it is naturally suited to per-call API billing and makes it easy for AI Agents to complete the "pay—invoke" loop without human intervention, with no need to pre-register an account or sign a contract.

Base Network and eip155:8453: Base is an Ethereum Layer 2 built by Coinbase on the OP Stack, using an Optimistic Rollup. Transaction fees are denominated in ETH but far lower than on mainnet, making it suitable for extremely small payments like 0.0005 USDC. eip155:8453 is a CAIP-2 chain identifier, where eip155 denotes the EVM-compatible chain namespace and 8453 is the Base mainnet chain ID. Choosing an L2 as the settlement layer is the cost prerequisite that makes micropayments feasible.

/.well-known/x402 and the OpenAPI Catalog: /.well-known/ is a conventional path defined by RFC 8615 for hosting site-level metadata (such as /.well-known/did.json). The service provider publishes its paid route list and interface descriptions in /.well-known/x402 and /openapi.json, enabling Agents to automatically discover "what paid capabilities exist, how to invoke them, and at what price" — precisely the discovery mechanism Agents need to automatically call micropayment APIs.

Key Takeaways

• The WebTransport probe endpoint performs 8 protocol-layer audits; live testing found that Cloudflare advertises HTTP/3 but does not expose a WebTransport endpoint
• The DID catalog API uniformly resolves 13+ W3C DID methods, covering mainstream systems such as did:web, did:key, did:plc, and did:ion
• Both endpoints are priced via x402 at 0.0005 USDC micropayments, with a low barrier suitable for automatic Agent invocation
• Verification-as-a-service micropayment APIs are becoming an infrastructure form in the Agent toolchain, but service stability needs ongoing observation

One-line Summary

x402 micropayment APIs launch WebTransport probing and unified DID resolution as two Agent verification services

Paragraph Summary

The article introduces two paid APIs priced via the x402 protocol: the WebTransport probe endpoint performs 8 protocol-layer audits and can distinguish whether a site truly exposes a WebTransport endpoint — live testing showed that cloudflare.com advertises HTTP/3 but scores only 25 and does not expose WebTransport; the DID catalog API consolidates resolution of 13+ W3C DID methods into a single call, returning per-method status and scores, reducing the integration cost of cross-platform identity verification. Both endpoints settle at 0.0005 USDC via the Base network, supporting automatic Agent discovery and invocation, reflecting the "verification-as-a-service" micropayment infrastructure form. The author also notes that the service is hosted on a temporary domain and the information comes from the project's own statements, so stability still requires independent verification.