Voidly
Voidpay · the security boundary

Payment boundaries for the live marketplace.

Voidpay works with standard x402 (exact scheme, USDC on Base). Buyers review the current terms for the selected service and authorize payment to the quoted seller address.

use current payment terms

Read the selected listing and its current 402 response before authorizing payment. Those terms do not grant permission to spend. Do not send funds to retired addresses or contracts. The session staging and historical tests below have separate scope.

01 · recorded session tests

What the session tests checked.

These records cover the session rail’s grant binding. Current marketplace calls need their own payment and request checks; a token-transfer signature alone does not bind a marketplace service or request body.

one key · one job · every other lock is a different cut

The following record documents the session rail’s local fork rehearsal.

the published analysis

A published security analysis of live x402 deployments names four implementation-layer flaw classes, reaching, in the authors’ words, “resource-leakage ratios up to 100%” against the official Coinbase SDKs and a production deployment.

  • one payment reused on a different jobcross-resource substitution
  • the same payment counted twiceduplicate-settlement race
  • more money taken than was agreedallowance overdraft
  • the payment stopped from ever landingdenial of settlement

The recorded session tests used that analysis to select their attack cases.

Recorded session tests · 2026-08-21
a payment for a different jobcross-resource substitution
a second job, free
Refused
one unit short
the job, underpaid
Refused
the money pulled straight back out
the job, then a reversal
Refused
a different token than the one agreed
the job, in something worthless
Refused
two payment authorizations in one transactionduplicate-settlement race
one job, paid once, opened twice
Refused
a payment one confirmation too shallow
a job that was never finally paid for
Refused
a receipt belonging to some other transaction
somebody else's receipt, reused
Refused
a payment sent by someone other than the signer
a payment nobody signed for
Refused

The two amber rows answer a flaw class named in the analysis above, by its own name. The other six are ours.

87 checks · 87 passed · 8 bad payments refused. Every record published, with the name of the assertion that produced it.

Against the real USDC contract, on a private copy of the live network. No real money moved · 2026-08-21

The recorded local-fork test used a separate relayer to pay gas.

That test does not measure current user activity or establish a gas policy for every marketplace client.

02 · direct x402 payment

Payment goes to the seller.

For the direct x402 seller route, Voidpay does not hold buyer funds in a deposit balance or escrow. The current 402 response identifies the receiving address.

Direct transfer
The quoted payment goes from the buyer wallet to the seller address.
No deposit balance
This route does not hold buyer funds in a Voidpay balance or escrow.
Current terms
Review the network, asset, amount and recipient in the current 402 response.
Separate delivery
Settlement does not guarantee delivered quality or an automatic refund.
historical checkout context

OpenAI and Stripe launched checkout inside ChatGPT in September 2025. When it reached Shopify merchants in January 2026 they were reported to pay OpenAI a four percent fee on those sales. OpenAI pulled back on 4 March 2026.

“OpenAI is not the merchant of record in the Agentic Commerce Protocol.”

OpenAI, Agentic Commerce Protocol documentation

Legacy Voidpay v1 credit units are separate from the live x402 marketplace. They are not money and cannot be redeemed or converted.

03 · legacy pay-runtime gates

Separate containment status.

This panel reads the legacy pay-runtime health endpoint. It does not determine the availability of the live x402 marketplace at x402.voidly.ai.

legacy session release conditions
0 of 6 attested
  1. 01PRODUCTION SIGNING AUTHORITY IN HARDWAREProvisioned signing authority for the legacy session release. A mock test does not establish production provisioning.
  2. 02INDEPENDENT REVIEWReview of the legacy money path by an identified outside reviewer, with the reviewed scope recorded.
  3. 03REHEARSED ROLLBACKA timed, recorded rollback for the legacy session release.
  4. 04TESTNET CANARYA bounded testnet canary with an identified resource, price, quote lifetime, and independent observations.
  5. 05MAINNET CANARYAn approved, bounded mainnet canary for the legacy session release.
  6. 06RECONCILIATIONA canary receipt reconciled against its on-chain outcome.

A dark row does not establish that the legacy gate is satisfied. These rows do not report the x402 gateway’s release status.

04 · how to report

Tell us before you tell anybody else.

Email security@voidly.ai with impact, reproduction steps, the affected endpoint or release id, and a minimal safe proof. Remove secrets, sealed payloads and personal data.

the rules of engagement
  • 01Use only identities, briefs and browser profiles you control.
  • 02Do not degrade service, exfiltrate data, or reach another reader’s records.
  • 03Stop after proving the minimum impact, and report privately.
  • 04Never include vault material, capability material or raw sealed payloads.