Know the request.
Inspect the terms. Keep the receipt.

The idea

A request can have terms before it has a payment.

Imagine asking a service to perform a task. Before paying, you need to know what you are buying, its cost, the currency and network, who receives the payment, and when the offer expires. A payment challenge supplies conditions to inspect; it is not itself a charge or a result.

1. Discover a service and choose one documented operation.
2. Check its exact input fields and current availability.
3. Inspect any payment challenge and the permission required before an actual payment.
4. If an explicitly approved supported payment proceeds, retain the resulting operation or receipt identifier and verify the outcome.

Do not interpret a 402 response as “the work succeeded.” Invalid requests may be rejected before a payment challenge, and a configured or documented operation can still be unavailable.

Availability

One catalog, different evidence and permissions.

The generated V2 catalog contains 76 operations: 74 priced and 2 free. Those are catalog counts, not a count of independently verified production services.

• Public discovery: read the operation list, schemas, release identity and limits without a wallet.
• Local evaluation: run documented real handlers and durable receipts with deliberately synthetic payment/provider dependencies. Synthetic settlement is not a live paid transaction.
• Provider-dependent operations: inspect individual operation status and response evidence. An unavailable dependency has no invented success example.
• V3 payments: disabled. Source review and a working local example do not open a production funds gate.

Inspect operation-by-operation status, read exact request and response contracts, and browse the generated operation reference. The current advertised live lane is Base-only V2; do not infer paid Solana or cross-chain execution from a catalog entry.

For builders

Start without secrets or real settlement.

Begin with the selected source and the prerequisites in the developer Quickstart. Then follow the separate local x402 evaluation guide, which gives the exact setup, requests, expected responses and recovery commands. That HTTP example is different from the consent register/revoke SDK example; both need their own result checks.

A terminal is the application where you run commands. This first command only reads public discovery; it does not sign, submit a transaction or authorize payment.

curl --fail --silent --show-error https://theloopbreaker.com/.well-known/x402.json

Expected result: a JSON discovery document containing operation and release information, not an HTML login page or a receipt for paid work. If it fails, keep the HTTP status and error; restore connectivity or inspect service health. Do not send money or share a private key to make a discovery read succeed.

Before implementing a write operation, read its current schema and status, validate input, inspect the quote, obtain the required authorization, simulate where supported, submit through the documented path, keep durable identifiers, and poll the documented status route. The SDK/API integration index and OpenAPI document are references, not proof that every declared operation is live.

When a request is interrupted

An unknown result is not a reason to pay twice.

Keep the operation or receipt identifier, original payment authorization, explicit idempotency key, method, resource and exact request body. “Idempotency” means the server can recognize the same logical request rather than perform it twice. Use the documented lookup and retry procedure to recover the original outcome.

Do not replace a payment authorization with a new payment merely because the connection dropped. Where HTTP authorization signatures or nonces are required, they must still be fresh per attempt; that does not mean authorizing a second charge. A durable-storage outage must fail closed, not fall back to an unverifiable success response.

The local guide demonstrates retained receipts, polling, retries and failure handling. A browser metadata inspection record is not this receipt, and a 402 challenge is not either one. Avoid publishing raw authorizations or sensitive request bodies when asking for help.

For AI agents

Discovery first. Explicit permission before action.

Start with agent discovery, the agent index, and the copyable read-only brief. Vaultfire’s MCP endpoint exposes five read-only tools; it does not sign, pay, execute V3 transactions, or grant authority over someone’s funds.

Use an operation’s schema and actual status, not a remembered endpoint or an example from another release. Report unavailable or disabled operations honestly and stop at the permission boundary. If your client cannot connect to remote MCP, read the public documents directly rather than inventing a successful tool call.

Return to the complete Vaultfire index, or choose a safe Quickstart path.