x402 Protocol Adds Two New AI Agent Paid Endpoints: SVCB Resolution and CSP Replay

Endpoint 1: Deep SVCB Record Resolution

The newly launched /api/svcb-record-parse endpoint focuses on DNS-layer SVCB (Service Binding) and HTTPSSVC record resolution, following the RFC 9460 and RFC 9461 standards. It queries 11 conventional _<port>._<proto>.<domain> endpoints, retrieving data via Cloudflare DoH using record types type=64 and type=65.

The resolver covers all standard SvcParamKey values defined in RFC 9460 §6, including alpn, port, ipv4hint, ipv6hint, ech (Encrypted Client Hello), dohpath, ohttp, mandatory, and more. The returned result includes a 0–100 svcb_score rating (A–F) that comprehensively evaluates ECH support, HTTP/3 capability, ALPN breadth, and the configuration of mandatory keys.

This endpoint complements the existing TLS-layer ECH probing endpoint—the latter reads ECHConfig directly from TLS extensions, while the new endpoint resolves SVCB records from the DNS layer, together covering different layers of the technology stack.

SVCB (Service Binding) records are a relatively new DNS resource record type, defined in RFC 9460, used to bind a domain name with service connection parameters (such as supported protocols, ports, IP hints, encryption methods, etc.), enabling clients to learn server capabilities before establishing a connection. HTTPSSVC (type 65) is a dedicated variant of SVCB specifically for HTTPS services, allowing domains to declare support for features like HTTP/3 and ECH at the DNS layer, thereby reducing connection establishment round trips. Unlike traditional A/AAAA records that only provide IP addresses, SVCB/HTTPS records carry "how to connect" metadata and are an important part of modern web protocol stack optimization.

DoH (DNS over HTTPS) is a protocol that encapsulates DNS queries within HTTPS requests to improve DNS query privacy and resistance to interference. Cloudflare DoH provides standard JSON and wireformat interfaces, supporting queries for any record type via the type parameter, where type=64 corresponds to SVCB and type=65 to HTTPS. Developers can obtain these records through HTTP interfaces without building their own DNS resolvers.

ECH (Encrypted Client Hello) is a TLS 1.3 extension mechanism used to encrypt the SNI (Server Name Indication) field in ClientHello, preventing network intermediaries from snooping on the specific domain a user is visiting. ECHConfig is configuration data delivered by the server via DNS HTTPS records or TLS extensions, which the client uses to encrypt the handshake. The ech parameter in SVCB records is precisely the field carrying ECHConfig, so resolving SVCB records from the DNS layer can determine whether a domain has deployed ECH.

ALPN (Application-Layer Protocol Negotiation) is a TLS extension used to negotiate application-layer protocols (such as h2, http/1.1) during the handshake phase. In SVCB records, the alpn parameter declares the list of protocols supported by the server, allowing the client to select the optimal protocol. The port parameter in SVCB can specify a non-default port, ipv4hint/ipv6hint provide IP address hints to reduce additional DNS queries, dohpath declares the path of a DoH service, ohttp points to an Oblivious HTTP relay configuration, and mandatory lists the critical parameter keys that the client must understand, otherwise the entire record should be ignored. Together these parameters form a declarative description of server capabilities.

Endpoint 2: CSP Violation Report Replay

The /api/csp-violation-replay endpoint addresses another practical problem: verifying the reachability and acceptance of CSP (Content Security Policy) violation report endpoints. It crawls the target page, extracts CSP headers, meta CSP, Reporting-Endpoints headers, and report-uri/report-to configurations, then replays four violation scenarios against each declared endpoint.

The four scenarios are script_violation, style_violation, connect_violation, and img_violation. Each POST carries a real application/csp-report payload, including fields such as blockedURL, disposition, and effectiveDirective. The result of each probe is classified and recorded, such as accepted, queued, auth_required, rejected_bad_request, endpoint_missing, rate_limited, or fetch_error.

The final csp_replay_score is composed of four parts: reachability ratio (30 points), acceptance ratio (30 points), simultaneous configuration of both legacy and Reporting API (20 points), and acceptance rate of at least 50% for each scenario (20 points). Compared with the existing single endpoint acceptance check endpoint, this new endpoint achieves true end-to-end round-trip verification.

CSP (Content Security Policy) is a security mechanism declared via HTTP response headers or meta tags, used to restrict which resources a page can load (scripts, styles, images, connections, etc.), thereby mitigating injection attacks such as XSS. When page behavior violates the policy, the browser sends a violation report to the developer-declared report endpoint. There are two reporting mechanisms: the traditional way is the report-uri directive in the CSP header, sending JSON in application/csp-report format; the new standard is the Reporting API, which declares endpoints via the Reporting-Endpoints header and uses the report-to directive, with reports in application/reports+json format. The two mechanisms differ in both payload structure and endpoint declaration, and many sites configure both for compatibility across browsers.

CSP violation report endpoints themselves are also an attack surface: if an endpoint is unreachable, rejects requests, or lacks authentication, security monitoring fails. Therefore, verifying the reachability and acceptance of report endpoints is critical for security operations. Replay probing constructs real violation payloads and POSTs them to the endpoint, simulating browser behavior, and can uncover configuration errors, excessive authentication requirements, overly strict rate limiting, and other issues.

Continuous Expansion of the Micropayment Ecosystem

The service's paid endpoint directory has now reached 244 endpoints, all settled via pay.openfacilitator.io on the Base mainnet using USDC (eip155:8453). Invocation follows the x402 protocol—requests without a signed X-PAYMENT header return a 402 status code.

For AI Agents that need to query DNS SVCB records or perform cross-directive CSP replay probes, the value of these two endpoints lies in eliminating the engineering cost of building DoH pipelines and writing report formats. The service's discovery document is located at the /.well-known/x402 path, allowing Agents to automatically discover available endpoints.

From a broader perspective, such highly specialized paid endpoints reflect a key characteristic of the AI Agent economy: Agents are willing to pay for atomic services that save engineering complexity, and micropayment protocols make transactions of a few cents per call economically viable. The scale of 244 endpoints also indicates that this model is attracting continuous service supply.

The x402 protocol is a machine payment protocol based on the HTTP 402 status code, proposed by Coinbase, designed to enable AI Agents and automated programs to complete pay-per-call API invocations with extremely low friction. Its core flow is: when a client first requests without payment credentials, the server returns 402 along with payment requirements (price, currency, chain, receiving address); the client constructs and signs a payment payload, places it in the X-PAYMENT request header, and retries; the server verifies and provides the service. x402 supports on-chain stablecoin settlement, making microtransactions at the $0.0005 level economically viable and avoiding the fee thresholds of traditional payment channels. Base is an Ethereum Layer 2 network built by Coinbase, known for low transaction costs; USDC is its widely used USD stablecoin, and eip155:8453 is the CAIP-2 chain identifier for the Base mainnet.