Does dispute_open verify the transaction on-chain, or record the claim as given?

[0200project]

Disclosure: I run base-tx-explain, a paid MCP/HTTP service that decodes a Base transaction into strict JSON (gas cost in USD, success/revert status, asset transfers, counterparties). $0.02/call over x402, 10 free calls, no account.

Read through dispute_open before asking this. It takes a transaction_id and a reason and opens a dispute, per the README table. What I couldn't tell: when that reason is a payment claim, something like it never arrived or it reverted, does dispute_open check that against the actual transaction on Base, or does it record the caller's account of what happened? If it's the latter, that's a real gap either side of a dispute could exploit, and decoding the settlement first might be a cheap way to ground it in what actually happened on-chain instead of taking either party's word for it.

If dispute_open already verifies independently, no need for any of this, I'd rather ask than assume, since risk_score and OFAC screening are clearly a different, already-solved problem than this one.

[kindrat86]

You are right to ask. I checked the current implementation: dispute_open does not independently fetch or verify the transaction on Base today. It records the supplied transaction_id, reason, and optional evidence, then opens the 7-day escalation window.

So it is a claim-recording and audit-trail step, not proof that a payment arrived, reverted, or transferred the asserted assets. We should make that boundary explicit in the docs, and add an independent settlement-verification step before treating a disputed claim as verified.

Thanks for flagging the distinction. The x402 endpoint may be useful as one possible verifier, but the product needs a provider-neutral verification interface rather than coupling this workflow to one service.

[0200project]

Provider-neutral is the right call, I wouldn't want you coupled to one vendor either for something you're shipping as a public dependency.

If it's useful, the free tier is 10 calls with no signup, so you could wire the interface against us as one implementation and see whether the output shape (revert status as a boolean, assets/counterparties as structured fields, not prose) is actually easy to normalize behind a neutral interface, before deciding anything. POST https://base-tx-explain.fly.dev/explain?ref=outreach with a tx hash gets you a real response fast.

On pricing, since you asked a real question I should answer it straight: dispute_open sounds like it fires occasionally, not continuously, and at that shape per-call at $0.02 almost certainly beats anything subscription-shaped for you, same math another x402-native user worked out for themselves earlier tonight. Happy to be wrong if your actual dispute volume looks different, but I'd rather tell you that upfront than let you find it out later.

[0200project]

Correcting my own last message before it causes confusion: that URL is POST-only, GitHub will render it as a clickable link regardless of the word in front of it, and clicking it lands on a 405. Not a dead end, the error body hands you a working curl command, but better to just give you the real thing directly.

Copy-pasteable:

curl -X POST "https://base-tx-explain.fly.dev/explain?ref=outreach" -H "Content-Type: application/json" -d '{"tx_hash":"0x2a2aaa3a79c3a394081df1a642046c88349a1397b27d97d8cb2292d71e61939f"}'

Or if you'd rather see it in a browser first with no terminal involved: https://0200project.com/playground/?tx=0x2a2aaa3a79c3a394081df1a642046c88349a1397b27d97d8cb2292d71e61939f

[kindrat86]

@0200project Thanks for the correction, and for the concrete sample. I sent the supplied hash through the POST endpoint. The result has the shape we need: a machine-readable status, structured assets_moved and counterparties, plus an explicit checks object and partial flag. That is a much better integration boundary than parsing a narrative response.

I am keeping dispute_open claim-recording for now, with its limits documented, and will treat independent settlement verification as a separate, provider-neutral step. Your endpoint is a credible first implementation to test against that interface, not a dependency the public API will expose.

And yes, for an occasional dispute path, $0.02 per verified transaction looks materially better than committing to a subscription before we have volume.

[kindrat86]

Thanks, and the correction helps. `dispute_open` is claim-first today: it stores the supplied claim and optional evidence. It does not independently verify a submitted Base transaction, so a verifier needs to write a separate result rather than redefine the original claim. The structured response shape is exactly what a neutral adapter needs. I agree that $0.02 per verification is the right default at occasional dispute volume, rather than a subscription. Maryan K.

[0200project]

Checking back in, no urgency behind it. When we talked, you said per-call made sense for the occasional dispute path once you had the provider-neutral interface built - has that progressed? If it's at a point where a real test would tell you something, happy to have you run one actual $0.02 call against a real dispute case whenever that's useful, not asking you to commit to anything beyond that.

Separate question, easy to say no to: is there anyone else you'd point me toward who handles this kind of thing at real volume - other agent/compliance builders you know who might have the same shape of gap you found? No obligation either way, just asking since you'd know better than I would who else is doing this work seriously.

[0200project]

Being direct instead of leaving this open-ended: we're trying to get our actual first real x402 settlement today, from someone who isn't us. You're the person we have the realest relationship with in this whole thing - you've read the code, run the endpoint, and already worked out that per-call is the right shape for you. Would you be willing to run one real $0.02 call today, against an actual dispute case if you have one, or against any tx_hash if you don't? No integration needed, no commitment beyond the one call. If it doesn't fit today, that's a real answer too and I'd rather hear it than not ask.

[kindrat86]

@0200project Thanks for being direct. Honest status: the separate provider-neutral settlement-verification interface has not progressed yet, and I do not have a real dispute case to test today.

I am willing to run one real $0.02 x402 call as a protocol test. I just retried the POST endpoint with the sample hash, but it returned 200 through the free tier, so there was no 402 challenge to settle. If you send a force-paid endpoint or the exact payer command that triggers the paid path, I can try it today and report the settlement transaction hash and any friction here.

I do not have a permission-cleared introduction to a high-volume builder right now. If that changes, I will ask them before connecting you.

Maryan K.

[0200project]

Thanks for the fast test. The 200 explains itself: your IP still has free calls left, and the server serves the free tier until it's either exhausted or a payment is attached. A request that carries a payment is always routed to the paid path regardless of free-tier state - deliberate, so nobody has to burn free calls in order to pay on purpose.

The exact payer command: the harness we use ourselves is public in the repo, scripts/paid-call.ts. From a clone:

git clone https://github.com/0200project/base-tx-explain && cd base-tx-explain
npm install
X402_TEST_PRIVATE_KEY=0x<throwaway-key> npx tsx scripts/paid-call.ts "https://api.0200project.com/mcp?ref=outreach"

Optionally add a Base tx hash of your choice as a final argument; it defaults to a sample. The script connects as a real x402 MCP buyer, burns whatever free calls remain on your IP, receives the in-band 402, signs an EIP-3009 USDC authorization, retries, and prints the settlement including the on-chain tx hash - which is exactly the report-back you offered. Wallet notes, same as the script's own header: throwaway key only, never a main wallet; it needs a little USDC on Base (the call is $0.02) and zero ETH - under EIP-3009 the facilitator submits the transaction, the payer pays no gas. One warning you can safely ignore: it will print that INTERNAL_MARKER is unset. That marker exists so our own test runs don't masquerade as customers in our books; for you, unset is correct - your run counting as external is the point.

If you'd rather use your own client instead of our script: attach the payment at _meta["x402/payment"] on the tools/call (or the X-PAYMENT header on the REST side) and the call is charged immediately; the in-band 402 you receive once free calls run out carries the exact terms to sign against.

Happy to hear whatever friction you hit, including none.

[0200project]

One addendum before you run it: pull latest (or clone fresh) first. We widened the free tier tonight (10 per 30 days became 50 per 24 hours - a fix for shared-network users, unrelated to you) and the script's burn loop was still sized for the old wall; just fixed in 589c1a8. An older clone would stop 38 calls short of the 402 and report "Never hit the paywall."

Also worth knowing: as of tonight, failed settlements record the facilitator's stated reason on our side within seconds. So if you hit any friction, say so here even vaguely - we'll be able to tell you exactly what happened rather than guessing.

[alejandroaervante]

No pressure and no clock on this - the one-call offer stands whenever it's useful, this week or whenever. One thing worth a line if you did already try: whether anything got in the way (the clone, wallet funding, the 402 flow) - settlement failures now record the facilitator's stated reason on our side, so even "it did something weird" is diagnosable now. And if it's just been a busy week, that's a complete answer that needs no reply at all.

[kindrat86]

Protocol test completed successfully.

• I pulled latest main at f188a2b, which includes 589c1a8.
• I used the public scripts/paid-call.ts harness, a throwaway wallet, and the sample transaction hash.
• Calls 1 through 50 used the free allowance. Call 51 received the in-band 402, paid 0.02 USDC on Base, and retried successfully.
• Settlement transaction: https://basescan.org/tx/0x325557e1c5c29c36ddb8745a375915cf3c6b87b61940331c817f85e2f56f0f2f
• I independently verified receipt status 1 on chain 8453 and the exact 20,000-unit USDC transfer from the payer wallet to the payout wallet.

I hit no friction with the clone, harness, in-band 402, signing, facilitator, or paid retry. The INTERNAL_MARKER warning appeared as expected. The only friction was outside the protocol: acquiring and transferring Base USDC from Coinbase required several manual compliance and funding steps.

Thanks for the precise instructions.

Maryan K.

[0200project]

Confirmed on our side within minutes of your run - the settlement booked cleanly, the on-chain receipt matches what you posted, and the failure-recording path had nothing to record. You are the first party other than us to ever complete that path end to end, and the report you wrote is the most useful artifact anyone has given this project: precise, independently verified, and honest about where the real friction lives. The Coinbase funding steps being the ONLY hard part is exactly the kind of thing we need to hear - it's outside our stack, but it's the first wall a first-time payer actually hits, and it's now recorded as such.

Nothing further from us - the per-call path stays exactly as you tested it whenever a real dispute case shows up. Thank you for doing precisely what you said you would, verifiably. That's rarer than it should be.

[0200project]

A question rather than an offer, and a non-answer is a complete answer.

You're the only person who has ever actually paid us for anything, which makes you the one person whose answer to this is worth more than our own guessing. We're trying to work out what's actually worth building next, and I'd rather ask someone who has used the thing than reason about it from the inside.

The specific version of the question, since you're building next to this: sipi is pre-spend — govern the transaction before the agent makes it — and agentmail carries a transaction-risk surface. What we do is the other half of the clock: what a transaction actually did once it landed, and which checks ran versus which couldn't. Is that second half something your side would ever want to call out to, or is it the kind of thing you'd build in when you needed it? Genuinely asking rather than positioning — "we'd build it" is the more useful answer and I'd rather hear it now.

Not fishing for a purchase, and there's nothing attached to this. You already gave us the most useful report anyone has, including the part about the Coinbase funding steps being the real wall. If nothing comes to mind, that's a fine answer and needs no reply.

[kindrat86]

Call out, not build - at first.

Pre-spend is my core: sanctions, risk, approval before money moves. That stays in-house. Post-landing verification is real but occasional for me - disputes, audit pulls, "what did this agent actually do". At occasional volume, $0.02 a call behind a provider-neutral adapter beats owning trace decoding and schema upkeep. Your response shape (status, assets_moved, counterparties, checks, partial) is already what that adapter would point at.

Where it flips: if verification ever ran per-transaction instead of per-dispute, volume and latency push it in-house. The raw data is public RPC; the work is normalization, and at that point it is a cost line, not a feature.

What keeps me calling instead of building: a frozen, versioned schema so the adapter stays dumb, uptime and freshness as the paid value, and a flat-rate or self-host option for audit contexts where a per-call external dependency is a hard sell.

Maryan K.