DEV Community

ScriptMasterLabs
ScriptMasterLabs

Posted on Originally published at scriptmasterlabs.com

Our Payment Rail Lost Its Key. So the Server Became Its Own Bank.

#agents #ai #llm #mcp

PRO-LO is our market decision engine. It sells two verdicts to other agents over MCP and REST:

  • Coherence + Jev verdict — POST /api/x402/coherence-jev-verdict
  • Earnings Gate — POST /api/x402/earnings-gate

Each costs 0.25 RLUSD, paid through x402-style payment gating. Both were registered to sell through a hosted merchant rail (402Proof), which issues invoices, takes the payment, and hands back a signed token the server can verify.

Then we lost the merchant key.

The block

Not "lost" the way you lose a file. We swept for it properly: 192 candidate secret values, pulled from every environment across all 47 services on our Render account, tested against the merchant endpoint. Zero matches. The key was never in any environment we control, and it is not recoverable from the code — the merchant service only ever looks keys up in its own database.

The obvious fix was to register a second merchant and get a fresh key. The owner ruled that out. One merchant identity, no duplicates, no quiet workarounds that split the books. Fair rule. Also a hard wall: without the key, the two endpoints could not register on the hosted rail, which meant they could not sell at all.

So the server stopped waiting for its bank.

The workaround

PRO-LO is now its own invoice authority. The flow is four steps, and none of them involve a custodian:

  1. Invoice. POST /api/x402/invoice with the endpoint's UUID. The server issues an invoice: 0.25 RLUSD, the invoice ID carried as the payment memo, a 30-minute expiry, persisted to disk so it survives restarts.
  2. Pay. The buyer pays exactly 0.25 RLUSD on XRPL mainnet to the owner's wallet, invoice ID in the memo. Any wallet works — the reference run used a plain XRPL account paying a Xaman wallet.
  3. Claim. POST /api/x402/invoice/{id}/claim with the transaction hash. The server reads the ledger itself and checks everything: the transaction is validated, the result is tesSUCCESS, the type is Payment, the destination is right, the delivered amount came from the canonical RLUSD issuer, the amount is exact, the memo matches the invoice, and the invoice is unexpired, unclaimed, with that transaction never used before.
  4. Call. The claim mints a signed, single-use token. Present it in the X-Payment-Token header. The token is consumed by the first successful call. A replay gets 402 ERR_TOKEN_ALREADY_CONSUMED.

The live proof

We proved it the honest way first: a self-proof, our own wallet paying our own server, labelled as such. Invoice c0ea16e6-b91b-49ab-a507-9a514ffdf331. XRPL transaction 87F134E9E543121324018BB82776A8FB150E49EBDE3A72481D6CCAE82B69089D settled the 0.25 RLUSD. The claim minted the token. The token unlocked a real verdict on AAPL.

The verdict was DENY.

That is the gate working, not failing. AAPL's coherence read 0.771429 with a long consensus and our Jev review model leaning act at 0.64 — comfortably above the 0.6 coherence threshold. But a PASS also requires at least two agreeing evidence paths spanning at least two independent data families, and only one path voted on that read. One loud voice is not a consensus, so the server refused to sell a pass it could not back. A coherence number you can threshold is only worth something if the gate below it holds.

The replay test passed too: the same token a second time returned 402 ERR_TOKEN_ALREADY_CONSUMED.

Full disclosure, as always: the 0.25 RLUSD in this proof moved between wallets we control. It proves the rail, end to end, on mainnet. It is not a customer sale, and we won't dress it up as one.

What this removes

A merchant key is a single point of failure for agent commerce. Whoever holds it — or loses it — decides whether your endpoints can sell. The invoice pattern removes that entirely:

  • No custodian. Payment goes wallet to wallet on a public ledger. The server never holds buyer funds and never trusts a payment processor's webhook.
  • No accounts. The buyer needs a wallet and the invoice ID. Nothing to sign up for, nothing to revoke.
  • No chargebacks. A validated ledger transaction is the receipt. Verification is reading the chain, not asking a third party whether the money is real.
  • No lock-in. If the hosted merchant key is ever recovered, the same endpoint UUIDs register on the hosted rail with zero buyer-facing change. The self-issued rail is a bridge, not a fork.

The ledger is the receipt. The server just has to read it.

Try it

Mint an invoice, pay it from any XRPL wallet, claim your token, and call the verdict. If your agent infrastructure has a merchant-key dependency in it, you now know what removing it looks like.

FOLLOW
X: @TimmyCrypto78 — https://x.com/TimmyCrypto78
Instagram: @scriptmasterlabs — https://www.instagram.com/scriptmasterlabs
Threads: @scriptmasterlabs — https://www.threads.net/@scriptmasterlabs
Telegram: @x402sml — https://t.me/x402sml
LinkedIn: https://www.linkedin.com/in/timothy-walton-23224052

MY LINKS
Website: https://scriptmasterlabs.com
Books: https://scriptmasterlabs.com/books
Shop: https://shop.scriptmasterlabs.com
Gumroad: https://timwalton.gumroad.com
Whop: https://whop.com/timmy741
Ko-fi: https://ko-fi.com/scriptmaster
Discord: https://discord.gg/jGWDutyVAR
Verdict Protocol: https://verdict.scriptmasterlabs.com
Free VA tools: https://va-ratings.org

Top comments (0)