Logging x402 MCP Calls Without Storing Wallet Signatures
Skavio x402 MCP is a live developer-facing MCP and x402 v2 verification product for native Circle USDC, public chain inspection and conditional Base USDC payment challenges. The logging design problem is not to capture everything. It is to reconstruct what the client requested, what the server returned and which payment state was actually observed - without turning private wallet material into an application artifact. Tool discovery is not a paid invocation, and a signed payment challenge is not independently settled revenue.
Start with an event model, not a wallet dump
A support-friendly x402 log works more like a state machine than a packet capture. Discovery asks which tools exist. A tool invocation is a separate action. A payment challenge is another stage, and verification against public chain data is another. A returned tool result is not automatically an accounting event. Treat each stage as a separate event with its own evidence, and document the event names your team uses.
- Discovery event: record that a client requested tool discovery and whether discovery returned. Do not count it as a paid tool invocation.
- Invocation event: log the MCP tool name from the published documentation and an opaque attempt ID generated by your server. Do not infer success from the request alone.
- Challenge event: record payment-challenge state as its own event. Do not label it revenue, an invoice or a completed payment.
- Verification event: keep x402 v2 verification and public-chain inspection outcomes separate from the tool's business result. An observed verification fact does not by itself establish invoice or tax treatment.
- Result event: record that a result was returned or that an error occurred, using a non-secret result reference. Keep payment reconciliation outside the tool-result log.
The minimum useful record
The most useful support log is compact and referenceable. It should take an engineer from a user report to one attempt, then to a non-secret result reference and, where relevant, a verified payment fact. The template below is an editorial recommendation, not a Skavio-mandated schema. Confirm exact tool names, request fields, status behavior and client handling in the published x402 MCP documentation.
- Use an opaque attempt ID generated by your server, plus a parent request ID when one request fans out into several calls.
- Log the MCP tool name exactly as documented, the event stage and a trusted server timestamp.
- Use a structured error category and a short redacted message. Avoid free-text blobs that mix transport, payment and business errors.
- Keep a pointer to the stored result or evidence record rather than copying the full payload into application logs.
- For payment support only, record network, token, recipient and amount when those facts were verified and are necessary to investigate. Label them as observed facts, not conclusions about settlement.
- Keep discovery and paid-invocation counters separate. A dashboard that mixes them will overstate paid activity.
Never let secrets become log fields
Redaction needs a deny-by-default list because logs travel. They get indexed, copied into tickets, attached to incident reports and replayed in support conversations. The safest wallet secret is the one the application never writes in the first place. A scrubber can help after the fact, but it should not be the only barrier.
- Exclude seed phrases, private keys, raw wallet signatures, signed payloads and authorization headers.
- Exclude the full MCP client wallet configuration. Do not assume a later cleanup job will remove it reliably.
- Do not paste complete request or response bodies into a log line when they may contain signed material. Log a safe subset plus a non-secret reference.
- Do not use a fragment of a signature as a correlation ID. Use your own opaque identifier.
- Restrict access to payment-related logs to support staff who need that context. Redaction is a data-minimization practice, not a compliance certification.
Reconcile errors and payment evidence without false certainty
x402 integrations span client behavior, MCP transport, payment challenges and public-chain inspection. A single "failed" status is not enough. An API failure does not by itself determine whether a payment challenge was presented or verified. Those are separate states to reconcile, and the log should expose uncertainty rather than fill gaps with optimistic defaults.
- Use explicit values such as unobserved, unverified or pending review when your system does not know. Do not leave a blank field that downstream code treats as success.
- Never mark a customer sale, an invoice or settled revenue from a challenge signature, a transaction hash or a log entry alone. Those artifacts may help an investigation; they are not accounting conclusions.
- When a tool result is returned, check its association with the original attempt ID and request context before passing it downstream.
- For support, ask for the attempt ID and non-secret context. Do not ask users to send seed phrases, private keys or raw signatures.
- Document your field meanings and use the published x402 documentation as the source for tool schemas, status codes and client behavior.