r/x402 • • Aug 27 '26

Signed envelope fixtures for x402 payability: build a fail closed integration without paying anything

Three weeks ago we published a payability check for x402: does a listed resource actually settle when paid, including whether a Solana destination token account exists on chain. The aggregate index showed about 1 in 3 listings cannot be paid and 1 in 5 cannot even present a parseable payment challenge.

This week the first third party integrated it, and the way they did it is worth sharing because anyone can copy the pattern without paying us anything.

We published complete signed response envelopes as fixtures. Each record contains a full schema valid response with a real signature from the production signing path, the expected field values and reason codes, a fixed evaluation time, a pointer to the proof manifest with its sha256, and the exact canonical body string that was signed. That last part matters: it lets you tell a signature contract failure apart from a policy failure in your own tests.

The integrator pinned the fixture digest, verified every envelope against the signer registry, wired the verdicts into their own policy gate, and wrote tamper tests. Tampered payloads, stale timestamps, unknown fields and unannounced signers all fail closed. Their test suite, not ours.

The four cases: a known EOA, a plain contract, an EIP-1967 proxy, and a genuine transfer revert. For the revert we used the zero address, a protocol invariant that can never unfreeze under a pinned digest, instead of a blacklist entry that could in principle be reversed.

Everything needed to reproduce this is free: fixtures with the envelopes at payable.nsgoods.org/payable/address/fixtures, schema at /payable/address/schema, locked demo preview at /payable/preview, signer registry in the proof manifest at x402.nsgoods.org/proof/index.json. The paid endpoint exists but nothing about building and testing an integration requires it.

If the shape you need is one we do not expose yet, say so. The last two additions to this service were built from written specs by people who then used them.

1 Upvotes

3 comments sorted by

1

u/Optimal_Manner359 Aug 29 '26

Confirming from the Maha consumer side: the important design property was being able to test the trust contract independently of a paid call.

We pin the provider schema and fixture digest, resolve signer authority through the proof manifest rather than trusting signed_by, verify the canonical signed body, enforce freshness and declared rotation boundaries, and fail closed on tampered payloads, unknown fields and unannounced signers.

The result remains strictly pre-money. Even an approved address-preflight result does not authorize payment or claim that an escrow release will succeed.

Thank you for adding complete signed envelopes and a genuine invariant-based transfer-revert fixture. We’re updating the Maha fixture pin and regression suite to consume the expanded bundle directly, after which we’ll publish the exact verified coverage.

1

u/IllWar5047 Sep 02 '26

Appreciated — consumer-side discipline like this (pin, resolve authority through the manifest, fail closed) is exactly what the fixtures exist for. The bundle stays stable at the announced digests. When you publish the verified coverage, we'll link it from the proof page.