Question: signed receipts for selected x402 payment-header / paid-result handoffs?

Hi — I found MetaMask/mcp-x402 while looking at MCP tools where agents can create x402 payment headers and use them to access paid HTTP resources.

I’m building BoundaryAttest, a small open-source project for portable signed receipts around selected claims, actions, artifacts, or handoffs that cross trust boundaries:

https://github.com/cullenmeyers/BoundaryAttest

The idea is not to replace MetaMask wallet behavior, private-key custody, x402 payment-header creation, X-PAYMENT semantics, facilitator/server verification, MCP tool responses, or normal client/server logs. The receipt only proves a narrow claim:

> a specific signer signed a specific claim, and the signed claim has not been altered.

For an x402 payment-header MCP flow, a BoundaryAttest receipt could potentially bind selected evidence like:

- MCP server/tool reference;
- payment request digest;
- generated payment-header digest, without exposing private keys;
- payer/account reference, where safe;
- x402 payment/settlement reference;
- paid endpoint reference;
- response/result hash;
- optional authorization_ref, if there is a separate consent/approval artifact;
- status, such as header-created, paid, fulfilled, refused, failed, exported, or handed off;
- timestamp/event ID;
- signer/public key ID.

The strongest use case would be after a payment header is used to obtain a paid result and that result is passed to another agent, user, service, report, or audit/debugging trail. The recipient should not have to fully trust a screenshot, copied JSON, wallet-local state, or transient MCP transcript.

BoundaryAttest would not prove the user intended the payment, the payment was wise, the endpoint result was correct, the service fulfilled fairly, the wallet was uncompromised, or the runtime was safe. It would only prove that a selected claim about a payment-header/action/result handoff was signed and has not been altered.

Does this kind of portable signed receipt fit anything you imagine around mcp-x402, especially around payment-header creation, payment references, paid-result artifacts, or downstream handoffs? Or are the current x402/payment/MCP records enough for the current experimental scope?

No pressure if it is not relevant — I’m mainly trying to learn whether signed receipts are useful where MCP tools create payment headers for agent-paid HTTP access.

No files, tests, or entry points are named. Start by reviewing the repository's MCP server scope and its x402 header creation behavior, then determine whether portable signed receipts belong in the experimental project; done requires a maintainer decision and a concrete, scoped requirement.

Written by the indexing model from the issue text.