Docs
v0.6.0 — 16 checks / 3 packages

Independent protocol-compliance testing for x402 and MPP on Stellar.

Wasit runs the real payment flow against your service, not a schema check against its response — and verifies settlement on-chain, from the token contract’s own transfer event.

Get started View on GitHub

Open source · Testnet only · No signup · Why we built this

~/your-servicezsh
$ npx @wasit-dev/cli test --target <your-service-url> --read-only
The stack

Two protocols it checks. One chain it trusts.

checksx40210 checks · exact scheme on Stellar, EVM and SolanachecksMachine Payments Protocol6 checks · charge and channeltrustsStellarsettlement read from Stellar RPC
01What changes// same request, two verdicts

A 200 OK is not a settlement.

Without Wasit[ 0/3 ]
  • A 200 OK is the whole signal — nothing confirms the payment actually settled.
  • Payment and channel bugs surface in production, the first time a real payer hits them.
  • “It works” means someone tried it once and it didn't error.
With Wasit[ 3/3 ]
  • Settlement is read from the token contract's own transfer event via Stellar RPC.
  • The same flow runs ahead of time, including the cases a service is supposed to reject.
  • Every result traces to a specific check and spec clause in the Check Catalogue.
02How it works// http + rpc

It never trusts the receipt.

Wasit talks to two things: your service, over HTTP, and Stellar, over RPC. It never trusts the first about what happened on the second.

  1. 01unpaid requestWasit → your service
  2. 02402 challengeyour service → Wasit
  3. 03signed paymentWasit → your service
  4. 042xx receiptthe service's own claimyour service → Wasit
  5. 05RPC: getTransactionWasit → Stellar
  6. 06transfer event verifiedStellar → Wasit
01–04 · http · what the service says
05–06 · rpc · what the chain recorded

Steps 5 and 6 are the point of the tool: Wasit calls Stellar RPC directly and checks the transfer event itself, instead of trusting your service's receipt about what happened on chain. Full flow in the docs →

03Three packages// one core

One suite. Three ways in.

01CLI

@wasit-dev/cli

The wasit command, for a local run or a CI job. Exit codes separate a failed check from one that could not run.

$ npx @wasit-dev/cli checksRead the guide
02MCP

@wasit-dev/server

The same checks as MCP tools, for Claude Code, Codex, Cursor, VS Code and any other MCP client.

$ npx -y @wasit-dev/serverRead the guide
03CORE

@wasit-dev/core

The check suite itself, for building your own tooling on top. The CLI and the server both run it.

$ npm install @wasit-dev/coreRead the guide
04MCP tools// for agents

Your agent runs the checks.

The MCP server puts the same checks in front of Claude Code, GitHub Copilot, Codex, Cursor, VS Code and any other MCP client — as tools it can call, with the check catalogue as a resource it can read first.

Works with
  • wasit_x402_testX402-01–1006 settles a real testnet payment; 07–10 must be refused
  • wasit_mpp_charge_testMPP-01Settles a testnet payment every call
  • wasit_mpp_channel_testMPP-10–12, 14Free
  • wasit_mpp_channel_test_with_close+ MPP-13Opt-in only · closes a channel for good
~zsh
$ claude mcp add --transport stdio wasit -- npx -y @wasit-dev/server
claude code · wasit mcpexample

Is https://api.example.com/paid x402-compliant? Don’t spend anything.

Thought for2.7s

  • Reading wasit://checks
  • Picking wasit_x402_test, read-only
  • Running X402-01 – 05
toolwasit_x402_test
target    "https://api.example.com/paid"
readOnly  true

✓ 5 passed. The 402 challenge is well formed and names a valid network. X402-06–10 did not run: they settle a real payment, and you asked for none.

05FAQ// before you run it

Questions.

The things people usually ask before running it.

01Does it cost anything to run?

Read-only checks are free. Checks that spend or mutate state are opt-in and clearly flagged before they run.

02Is this safe to point at a service I don't control?

Destructive checks require an explicit flag and only run against a channel you name as disposable. Wasit is built for Stellar testnet.

03What's the difference between the CLI and the MCP server?

Same core, two interfaces. The CLI runs from your terminal or a CI job; the MCP server exposes the same checks as tools an agent like Claude Code can call directly.

04Do I need to sign up or configure anything first?

No signup. Run the install command directly with npx — a private key is only needed for checks that touch a payment or channel.

05Where can I see exactly what each check verifies?

The Check Catalogue in the docs lists every check, what it asserts, and which spec or SDK version it was verified against.

06Is the source available?

Yes — Apache-2.0, full source and Check Catalogue on GitHub.

06Get started// one command

Point it at your service.

Get a pass/fail report backed by on-chain verification. No signup, no config file required to start.

~/your-servicezsh
$ npx @wasit-dev/cli test --target <your-service-url> --read-only
Start testing Read the docs