Check before you pay, prove after you pay

nsgoods + SafeGate for x402 agent payments

An agent that pays an x402 endpoint has two open questions. Before the payment: who exactly am I paying, and is that wallet on a sanctions list? After the payment: was this payment bound to my request, can it be replayed, and what actually happened next?

nsgoods answers the first. SafeGate answers the second. The two stay independent: nsgoods never touches the merchant payment, and SafeGate never rewrites the nsgoods verdict.

Step 1. Before you pay: screen the payee (nsgoods)

Two ways, both 0.01 USDC per call over x402 on Base or Solana, no account, no API key. Invalid input is rejected with a 400 and no charge.

You have the endpoint URL. nsgoods reads the endpoint's own 402 quote, extracts every payTo and screens each one against the OFAC, UN, EU and UK lists.

GET https://sanctions.nsgoods.org/screen-url?url=<x402 endpoint URL>

You have the wallet address. Same four lists, each reported separately with its own version date. Pass your own request_id and it is echoed inside the signed body, which is what lets the next step reference this exact verdict.

GET https://sanctions.nsgoods.org/screen-multi?address=<payTo>&request_id=<your id>

Every response is signed with EIP-191 by 0x57fF0F084Cba33e6761503f90eEF0Da9F159350c. Free signed previews: /screen-url/preview, /screen-multi/preview. Full spec: https://sanctions.nsgoods.org/openapi.json

Step 2. Keep the verdict exactly as received

Store the response bytes unchanged. Their SHA-256 and the request_id are how the verdict is referenced later. Changing any byte changes the SHA-256, and modifying the signed verdict data invalidates the signature.

Step 3. Pay, then prove (SafeGate)

SafeGate binds the payment to the exact request, enforces single consume so it cannot be replayed, observes what happened next and returns a signed CommerceProof with an explicit assurance level (CLAIMED, OBSERVED, VALIDATED, THIRD PARTY ATTESTED). Its evidence can reference the nsgoods verdict by hash and request id.

POST https://safegate-nsgoods-paid-pilot.vercel.app/api/x402-commerce-evidence-session

0.07 USDC per call over x402 on Base mainnet. Body: the commerce transaction hash, payer, merchant and exact USDC amount, plus optionally the original signed nsgoods /screen-multi response from Step 1, exactly as kept in Step 2 and base64 encoded, in nsgoods_verdict_base64. The spec also explains the payment recovery key. Returns a signed CommerceProof with explicit assurance; in the September run the assurance was OBSERVED with commerce_verified=false, meaning SafeGate observed the payment and evidence but did not independently verify merchant fulfilment. Spec: https://safegate-nsgoods-paid-pilot.vercel.app/openapi.json · Developer portal: https://api.safegatelabs.xyz/

It already ran, with real USDC

On 25 September 2026, one self funded run on Base mainnet: 0.01 USDC to nsgoods for the screen, 0.07 USDC SafeGate fee, a separate merchant payment, a signed CommerceProof. Afterwards both sides checked the retained verdict: same bytes, same signer, same request id.

Case study: https://safegate-nsgoods-case-study.vercel.app/

What this does not claim

• A clean screen is negative evidence: the address was not on the named lists at their stated version dates. It is not a safety rating and not legal advice.
• SafeGate states its assurance level explicitly and does not silently upgrade OBSERVED to VALIDATED.
• The September run was self funded. It proves the path works, not that a customer has paid for it yet.

Contact

nsgoods: nikos@nsgoods.org · https://x402.nsgoods.org

SafeGate: https://safegatelabs.xyz/ · X @nurexenlabs