Extensions

Solvador advertises its protocol extensions in the extensions array of GET /supported. Clients and resource servers opt in per payment by echoing an extension in the payment payload.

eip2612GasSponsoring

Permit2-based flows (upto, and exact for tokens without EIP-3009) require a one-time on-chain approval from the payer to the canonical Permit2 contract. For permit()-capable tokens such as USDC, Solvador sponsors that approval — the payer’s onboarding is fully gasless, with no native token needed on any chain.

payment-identifier

Settle idempotency. Include an id in your payment payload and Solvador guarantees at-most-once settlement for it:

• Same id, same payment — the cached settle response is replayed verbatim. No second on-chain transaction, no additional quota consumed.
• Same id, different payment — the request is rejected with 409 Conflict.
• Malformed id (or missing where the payload declares one is required) — 400 Bad Request.
• A failed settle releases the id, so a retry with the same id re-executes rather than replaying the failure.

Identifiers are scoped to your API key — different Solvador accounts never collide.

Bazaar (resource discovery)

The Bazaar is an open catalog of x402-payable resources. When a payment payload echoes the bazaar extension, Solvador catalogs the resource once the payment verifies — a resource can only enter the catalog behind a valid payment, which keeps spam out by construction. Successful settles refresh the catalog entry.

The outcome of a cataloging attempt is reported in the EXTENSION-RESPONSES response header of /verify and /settle. The catalog itself is public — query it at GET /discovery/resources and GET /discovery/search.

Builder codes (ERC-8021)

Solvador can stamp an ERC-8021 builder-code suffix onto settlement calldata for on-chain attribution, including codes supplied by the resource server and the client alongside its own. Attribution is additive metadata only — it never changes settlement semantics.