verify[402]
live · block — Run free check
Menu

Tester kit · three slots · no wallet

Bring three intents.
I'll run them.

I'm opening three tester slots for teams whose agents sign payments. Send one intent you expect to pass, one you're unsure about, and one you think should be blocked. You get the raw verdict, the reason codes, and the checks that did not run — not a sales call.

Send the first intent Run one yourself first

Free and read-only. The public demo settles testnet payments only; analysis reads mainnet chain data. No wallet connection, no signup, no payment.

What you get

The raw verdict

PASS / CAUTION / BLOCK, the typed reasons, the checks that ran, and the notChecked list. No summary written by a model.

What you get

A receipt you can verify

A short-lived HMAC receipt bound to the exact intent and block, plus the verify endpoint. Change one field and the binding should fail.

What you get

A written answer

I reply with what the gate saw, where it disagreed with you, and what I will change. If a false PASS is reproducible, it gets fixed and credited — or kept anonymous.

The honest part

No applause

If the gate is not useful for your workflow, that is a valid result. I would rather hear it than have you run a demo you will never use.

The three intents

One pass. One unknown. One block.

Use something your agent would actually sign, not a test vector. Redact addresses and amounts if you need to. The samples below are starting points; the real value is your intent.

1 · A payment you expect to pass

A normal x402 payment on the testnet demo. Replace the payee and resource with your own, or send the shape and I will adapt it.

Payment intent 
POST /preflight
{
  "kind": "payment",
  "payment": {
    "scheme": "exact",
    "network": "eip155:84532",
    "asset": "0x036CbD53842c5426634e7929541eC2318f3dCF7e",
    "amount": "10000",
    "payTo": "0x1111111111111111111111111111111111111111",
    "resource": "https://your-service.example/endpoint"
  },
  "policy": {
    "maxAmountUsd": 0.25,
    "allowedResourceHosts": ["your-service.example"]
  }
}

2 · A payment you are unsure about

A real intent where the answer is not obvious: a new payee, a resource you have not bound before, a timeout near the edge, or an asset you have not used.

What makes a good “unsure” case 
Examples
- a seller that is new to you, with no payout manifest
- a resource URL on a host your policy does not name
- a payment near your cap, or with a short timeout
- a chain or asset you support but have not tested
- an intent where you expect CAUTION, not PASS or BLOCK

3 · An intent you think should be blocked

The adversarial case. An unlimited approval, a swapped payee, the wrong chain, a zero minimum output, or calldata you do not recognize.

Unlimited approval sample 
POST /preflight
{
  "kind": "transaction",
  "chainId": 8453,
  "to": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",
  "data": "0x095ea7b30000000000000000000000001111111111111111111111111111111111111111ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff",
  "value": "0",
  "policy": { "forbidUnlimitedApproval": true }
}

Expected: BLOCK with unlimited_approval. If it passes, that is the finding.

How to send

Two ways. Both are fine.

Public or private

GitHub issue

Open a tester feedback issue with the redacted intent, the verdict you got, and what you expected. This keeps the record public and easy to link.

Open a tester issue →

Private

Email

Send the intent JSON with anything sensitive redacted. No keys, seed phrases, or unredacted wallet data. I will reply from the project address.

Email the builder →

What I commit to

I reply within two business days. I publish an anonymized finding only with permission. I name you only if you ask. If the gate produces a reproducible false PASS, I fix it and say what changed. If I cannot reproduce it, I say that too.

What this is not

No wallet connection, no payment, no mainnet settlement, no token, no funding ask. The public demo uses Base Sepolia testnet USDC; analysis reads mainnet chain data. Do not send mainnet funds for this test. The gate is a check, not an audit, a guarantee, or financial advice.

If it fits

Three design-partner slots.

If the gate is useful, the next step is embedding it where the signing happens. I will do the first integration with you — the hook, the receipt check, and the fail-closed path — and write it up as a public case study only if you approve the details.

Ask about a design-partner slot See the MCP server

No payment, no exclusivity, no token, no equity. The free gate stays free.