DEV Community 1h ago

How Does an AI Agent Check Whether It Should Pay Before It Spends? The /bin/bash.005 Spend Gate

How Does an AI Agent Check Whether It Should Pay Before It Spends? It buys a check first.

ScriptMasterLabs' Spend Gate - live-tested October 26, 2026 - charges $0.005 USDC on Base for a pre-payment verdict: four independent paths vote pay or reject on the payee and the quoted amount, the votes combine into a coherence score (|Σ w·d| / Σ w, pass at ≥ 0.6 with a pay-side consensus), and a Jev decision model reviews the payment only if the gate passes.

In the October 26 proof runs the gate passed a $0.001 USDC call at coherence 1.0 and blocked a $5.00 over-cap call at coherence 1.0 - consensus reject, Jev never fired, zero decision-model spend on the block. That is the short answer, with the receipts below.

Spend Gate is the decision-gated payments pattern ( https://scriptmasterlabs.com/decision-gated-payments ) pointed at the buyer's side of x402: the rails move money, the gate decides whether this payment should move.

The taxonomy argument for the missing decision layer is at https://scriptmasterlabs.com/the-fourth-layer - this page is the operational version, with a live endpoint, a price, and settled proof transactions for both a pass and a block.

The check: four paths vote, one number decides

An agent (or its wallet wrapper) sends the gate a payee and a quoted amount before signing anything. Four paths evaluate the payment independently - path independence is the point: a number computed from paths that copy each other would claim agreement that never happened.

provider_trust - What it checks: The payee, via Provider Trust's verify_provider. How it votes: Real verdicts via the fleet operator lane: verified / provisional → pay (0.8); do_not_trust / unreachable → reject (0.8); insufficient_evidence → honest abstention
payload_safety - What it checks: The thing being bought, when a manifest_url names an npm / PyPI / crates package, via ScriptDocs vulnerability check. How it votes: 0 vulnerabilities → pay (0.9); CRITICAL / HIGH findings → reject (0.9); a non-package URL abstains, with the reason stated
price_sanity - What it checks: The quoted amount against a policy cap. How it votes: Cap-only in v1 and v2 - no historical median exists and none was invented. Caller cap overrides; defaults below. Vote weighted by headroom; over cap → reject
delivery_history - What it checks: Whether this host's settlement ledger has actually delivered for this payee before. How it votes: Reads the OmniGate ledger on the same host (67 delivered / 12 failed records at first proof); a payee with no records abstains - the gate's own check history never votes (no self-dealing path)

Default caps (in code and in the product docs): data_lookup / search / content_fetch / verification $0.05, market_data $0.10, inference / llm $0.25, compute $0.50, unlisted category $0.10.

The votes combine as coherence = |Σ w·d| / Σ w, where d = +1 for pay-side, −1 for reject-side, and w is each path's confidence. gate_pass requires coherence ≥ 0.6 AND a pay-side consensus.

Only on a pass does the second opinion fire: Jev (jev-1.14.0 in the proof runs) answers an act score plus a pay / reject / quarantine choice. A block spends nothing on Jev - the expensive judgment is reserved for payments that already cleared the cheap evidence.

The check itself is an x402 call, so the pattern eats its own cooking: MCP tool spend_gate_check and REST POST /x402/spend-gate on the mcp-x402 host, $0.005 USDC per check on Base (eip155:8453) to payTo 0xc29185fa176357612f3194735753e520e91adc46. The gate moves no funds - it returns a verdict; the agent's own wallet still signs (or doesn't) afterwards.

The proof runs: six settled checks, October 26, 2026

Every check below was paid by ScriptMasterLabs' own proof wallet and settled to the fleet's own payTo - owner self-tests, never customer purchases - and every transaction was re-read on Base RPC on the evening of October 26, 2026 for this page: all six at status 0x1 (success).

v1 good - Payment proposed: squeezeos-api.onrender.com, $0.001, data_lookup. Result: PASS. Coherence: 1.0, consensus pay. Jev: act 0.87, choice pay (conf 0.92), jev-1.14.0. Check settlement: tx 0x36a8a11d66e61d8d08745e385fafd677cd9c2eb83ccc048bec321172ec3f6373, block 53,104,724
v1 bad - Payment proposed: nonexistent-payee-zzz-987.invalid, $5.00 vs $0.05 cap. Result: BLOCKED. Coherence: 1.0, consensus reject. Jev: Not fired (gate_blocked). Check settlement: tx 0x3867007818ba10503ee5ad7cb979fb7dd5be62db97bb0a8fd2c7126fdc00f60e, block 53,104,732
v1 restart - Payment proposed: Good payee + npm manifest, after a full service restart. Result: PASS - pre-restart check history read back (state survived). Coherence: 1.0. Jev: act 0.88, choice pay. Check settlement: tx 0x9dff5a704552a9b1b6d75511da9c33ff8962ef2b782af4747e3e678ffe568719, block 53,104,781
v2 trust - Payment proposed: scriptmasterlabs.com, $0.001, cap $0.05. Result: PASS - provider_trust voted pay 0.8 with a real verdict. Coherence: 1.0. Jev: act 0.89, choice pay. Check settlement: tx 0x19ab67471a106026857d6ac498ac5623d0c85ceb43e6f3190d9dd679c3e44deb, block 53,105,535
v2 three-path - Payment proposed: Same payee + npm:express manifest (0 vulnerabilities). Result: PASS - three paths voting (0.8 + 0.9 + 0.99). Coherence: 1.0. Jev: act 0.90, choice pay. Check settlement: tx 0x2b0cf2b9e14249210d31415fc68b86512c86ad19f54f543967d74a87fdcaeeeb, block 53,105,554
v2 bad - Payment proposed: offline-payee.invalid, $5.00 vs $0.05 cap. Result: BLOCKED - price reject 1.0 AND provider_trust reject 0.8 (DO_NOT_TRUST / DNS unavailable). Coherence: 1.0, consensus reject. Jev: Not fired (gate_blocked). Check settlement: tx 0xc82f8d9ac7688e3ae4d20c77fe4d13bf8f438967dd08beb6f6183bc6d27abd1e, block 53,105,555

Details that matter more than the headline numbers:

In the v1 good run, delivery_history voted pay at 0.7829 - a confidence computed from this host's real OmniGate settlement records (67 delivered, 12 failed), not a constant. In the v2 runs the same path honestly abstained for scriptmasterlabs.com, which has no OmniGate delivery records. Abstention is a published outcome, not a failure hidden in an average.

The v1 bad run's price path rejected at confidence 1.0 with the reason stated in the result: the quote "exceeds cap by 9900%." A block that cannot say why is a wall; a block with a reason is an audit record.

v1 shipped with the two evidence paths (provider_trust, payload_safety) abstaining: both upstreams are themselves tolled ($0.001 and $0.009 - together 2× the price of the check), and v1 would not silently spend the caller's money. v2 fixed this without spending anything: the paths now vote with real verdicts through the fleet's operator lane (the fleet's own key on its own services).

The $0 upstream toll is proven, not asserted: a scan of Base blocks 53,105,532-53,105,566 for USDC transfers into the payTo found exactly 3 inbound transfers, all 0.005 USDC, all from the proof wallet - the three v2 check payments and nothing else.

One $0.005 transfer in the v1 session was never redeemed: the first bad-payee attempt sent it, then crashed on a confirmation wait (a public RPC archive-request error) before its hash was captured. The money landed in the fleet's own payTo wallet - nothing left the fleet - but it bought no check, and it is recorded here because a gate product that hides its own failed run has no business selling trust.

Total proof spend across the whole program: $0.035 USDC from the proof wallet (seven 0.005 transfers, six redeemed), all of it landing in the fleet's own payTo, plus roughly 0.0000011 ETH of gas. Jev was called exactly 4 times - only on passes.

ScriptMasterLabs' Spend Gate, live-tested October 26, 2026, passed a $0.001 USDC payment at coherence 1.0 and blocked a $5 over-cap payment at coherence 1.0 - the check itself costs $0.005 USDC, settled on Base.

Re-verified live on the evening of October 26, 2026

Fresh unpaid probes for this page, run twice with identical amounts and statuses (probe file: probe-spendgate-1026.out in the run record):

mcp-x402 /health: HTTP 200 in 1.00s / 0.65s - version 2.1.11, commit 205f1a2078cfc88823c6a9bfaffdc3fa40a4e51f.
/.well-known/agent.json: HTTP 200; 141 skills listed, including spendGateCheck with the coherence formula and its "Use for / Don't use when" text served verbatim.
POST /x402/spend-gate with no payment: HTTP 402 in 0.99s / 1.21s, challenge quoting exactly 5,000 atomic units ($0.005), network eip155:8453, asset USDC 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913, payTo 0xc29185fa176357612f3194735753e520e91adc46.
Companion Verdict probes the same evening: /health HTTP 200; POST /decide with no payment HTTP 402 quoting 250,000 atomic ($0.25) - the heavier jury product below.

How this differs from the guards and checklists already out there

Caps and seatbelts answer "can we afford it." A per-call cap, a daily ceiling, an isolated wallet - all necessary, all blind to whether this payee at this price is a good idea. Spend Gate's price path includes a cap, but the cap is one vote of four, not the whole decision. (SML's own earlier mapping of the guard field: https://scriptmasterlabs.com/x402-agent-spending-guard )

Challenge checklists verify the envelope. Checking that a 402's payTo, amount, asset and network fields are well-formed stops malformed-challenge attacks. It says nothing about the seller's delivery record or whether the package being bought carries vulnerabilities.

Agent trust scores grade the buyer. A credit-check-for-agents answers "should this agent be allowed to spend at all." The spend gate grades the payment - this payee, this amount, this payload - at the moment before signing.

A single model score is one path, not a gate. Spend Gate asks Jev only after independent evidence paths agree, and never on a block. The coherence number is the weighted agreement across genuinely independent paths - the same formula SML uses to gate trades in its Coherent Gate and to gate captures on Arc. One word, one formula: coherence.

Do it yourself: wire a pre-payment check in 5 steps

Intercept before signing. The check only works in the one place a null confirmation callback doesn't: between the 402 challenge arriving and your wallet signing the payment authorization.
Describe the payment, not the task. Send the gate the payee, the quoted USDC amount, the tool category (which selects the cap), and a manifest_url when the purchase is a software package.
Act on the verdict shape, not a vibe. gate_pass true + pay consensus → proceed to sign. gate_pass false → do not sign; the result names which path rejected and why (over cap by a stated percentage, DO_NOT_TRUST, a CRITICAL vulnerability). An abstention-heavy result (few paths voting) is information too: the gate is telling you it could not assemble evidence.
Spend the decision model last. If you run your own scorer, fire it only on gate passes - in the proof runs this discipline kept Jev spend at zero on every block.
Log both transactions together. The check's settlement tx and the payment's settlement tx (or the absence of one, on a block) are the audit pair. An agent that can show "checked, blocked, here is the on-chain check receipt" has a defense exhibit; an agent with only a wallet history has a list of losses.

Minimal REST shape (unpaid call returns the 402 challenge first; pay $0.005 and re-present):

POST https://mcp-x402.onrender.com/x402/spend-gate
{
  "payee": "https://seller.example/api",
  "quote_usdc": 0.001,
  "tool_category": "data_lookup",
  "policy_cap_usdc": 0.05,
  "manifest_url": "https://www.npmjs.com/package/express"
}

The product

Spend Gate is live as part of ScriptMasterLabs' mcp-x402 node: MCP tool spend_gate_check for MCP clients, REST POST /x402/spend-gate for anything that speaks HTTP, $0.005 USDC per check on Base, no account and no API key - the x402 challenge is the checkout.

It is the buyer-side companion to the seller-side decision products: Verdict Protocol ( https://scriptmasterlabs.com/verdict-protocol ) seals a 5-juror Jev decision receipt for $0.25 when the question is a judgment call worth a jury; Spend Gate is the half-cent evidence check for the ordinary payment an agent makes a hundred times a day.

The pattern both implement - decide first, pay second, keep the receipt - is written up at https://scriptmasterlabs.com/decision-gated-payments

Honest limits

Every settled check on this page is an owner proof-wallet self-test. No external customer has bought a Spend Gate check yet, and no number here should be read as market traction.

All six proof verdicts landed at coherence 1.0 because the voting paths agreed unanimously in each run. That is the easy case. The interesting cases - paths disagreeing, coherence landing between 0.6 and 1.0, a pay consensus the Jev review then quarantines - have not occurred in the proof set yet and are not claimed here.

Price sanity is cap-only. There is no historical price median behind it, because no honest one exists yet for these endpoints; the cap table is policy, stated in code, not a market measurement.

The operator lane that lets provider_trust and payload_safety vote is fleet-internal: it works because the gate and the evidence services share an operator. An external deployment of the same pattern would need its own arrangement with its evidence providers - or pay their tolls, which at $0.001 + $0.009 exceed the $0.005 check price. That arithmetic is the honest open problem in the design, published rather than buried.

Payload safety covers package manifests (npm / PyPI / crates). It does not scan arbitrary URLs, and it abstains - out loud - when the manifest_url is anything else.

Known wart, flagged in the ship record and not yet fixed: the MCP tool schema marks tool_category as required while the tool description and the REST schema call it optional, so an MCP caller that omits it gets a validation error before the handler runs. The REST route does not have the issue.

The gate's verdict is evidence for a decision, not a guarantee of delivery. A passed payee can still fail to deliver; the delivery_history path exists precisely because that record accumulates.

Canonical: https://scriptmasterlabs.com/ai-agent-spend-gate

Read on DEV Community ↗ ← Back to News