Hi — I found switchboard while looking at agent-payment infrastructure where agents can pay each other over HTTP/402, x402, escrow, gas-budgeted transactions, or high-volume A2A payment wires.
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 switchboard’s x402 middleware, X-PAYMENT verification, AgentEscrow contract, nonce manager, gas budgets, ZAP binary wire, payment protocol, on-chain records, tests, or future settlement-receipt work. The receipt only proves a narrow claim:
a specific signer signed a specific claim, and the signed claim has not been altered.
switchboard seemed relevant because it provides programmable payments for AI agents: HTTP 402 middleware, x402 payment proofs, on-chain escrow, timeout/challenge/refund flows, gas budgets, nonce management, binary PaymentOffer/PaymentProof transport, and a roadmap item around multi-party micropayments and settlement-receipt format.
A BoundaryAttest receipt could potentially bind selected events like:
- payer / provider / agent reference;
- paid endpoint or service reference;
- x402
accepts[] envelope hash;
- X-PAYMENT / payment proof reference;
- request digest;
- response/result digest;
- escrow request ID / contract / chain reference;
- timeout / challenge / refund / confirm status reference;
- gas budget decision reference;
- nonce manager result reference;
- ZAP PaymentOffer / PaymentProof digest;
- settlement receipt or MPP session reference, if applicable;
- optional
authorization_ref, if a separate approval/consent basis exists;
- status, such as payment-required, proof-verified, budget-refused, nonce-accepted, escrow-created, confirmed, refunded, challenged, fulfilled, failed, exported, or handed off;
- timestamp/event ID;
- signer/public key ID.
The strongest use case would be when a paid agent call, escrow state, payment proof, gas-budget decision, MPP settlement record, ZAP payment exchange, buyer/seller support packet, accounting handoff, or dispute artifact leaves the switchboard runtime, and another agent, provider, payer, reviewer, or future audit trail should not have to fully trust a screenshot, copied JSON, local server log, or chain explorer link alone.
BoundaryAttest would not prove the payment was legally sufficient, the work was correct, settlement was final beyond the referenced payment system, the buyer consented, the provider fulfilled the task, the gas policy was wise, or the runtime was uncompromised. It would only prove that a specific claim about a selected payment/escrow/request/result/handoff was signed and has not been altered after export.
Does this kind of portable signed receipt fit anything you imagine around switchboard, especially around x402 paid routes, AgentEscrow state, gas-budget refusals, nonce decisions, ZAP payment proofs, MPP settlement receipts, or buyer/seller dispute handoffs? Or are the current x402 proof, on-chain records, escrow events, and application logs enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn whether signed receipts are useful around agent-payment evidence that leaves the original payment/runtime context.
Hi — I found switchboard while looking at agent-payment infrastructure where agents can pay each other over HTTP/402, x402, escrow, gas-budgeted transactions, or high-volume A2A payment wires.
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 switchboard’s x402 middleware, X-PAYMENT verification, AgentEscrow contract, nonce manager, gas budgets, ZAP binary wire, payment protocol, on-chain records, tests, or future settlement-receipt work. The receipt only proves a narrow claim:
switchboard seemed relevant because it provides programmable payments for AI agents: HTTP 402 middleware, x402 payment proofs, on-chain escrow, timeout/challenge/refund flows, gas budgets, nonce management, binary PaymentOffer/PaymentProof transport, and a roadmap item around multi-party micropayments and settlement-receipt format.
A BoundaryAttest receipt could potentially bind selected events like:
accepts[]envelope hash;authorization_ref, if a separate approval/consent basis exists;The strongest use case would be when a paid agent call, escrow state, payment proof, gas-budget decision, MPP settlement record, ZAP payment exchange, buyer/seller support packet, accounting handoff, or dispute artifact leaves the switchboard runtime, and another agent, provider, payer, reviewer, or future audit trail should not have to fully trust a screenshot, copied JSON, local server log, or chain explorer link alone.
BoundaryAttest would not prove the payment was legally sufficient, the work was correct, settlement was final beyond the referenced payment system, the buyer consented, the provider fulfilled the task, the gas policy was wise, or the runtime was uncompromised. It would only prove that a specific claim about a selected payment/escrow/request/result/handoff was signed and has not been altered after export.
Does this kind of portable signed receipt fit anything you imagine around switchboard, especially around x402 paid routes, AgentEscrow state, gas-budget refusals, nonce decisions, ZAP payment proofs, MPP settlement receipts, or buyer/seller dispute handoffs? Or are the current x402 proof, on-chain records, escrow events, and application logs enough for the current scope?
No pressure if it is not relevant — I’m mainly trying to learn whether signed receipts are useful around agent-payment evidence that leaves the original payment/runtime context.