A spending limit that lives in a prompt is text. Enforcement has to live somewhere the model cannot talk its way past.

A spending limit written in a prompt is not a control. It is a piece of text, sitting in the same context window as everything else the model reads, competing for the model's attention with the task, the tool output, and whatever a third party managed to get in front of it. When that limit and an instruction to spend disagree, nothing technical decides between them. The model decides. That is the whole problem.

We build Veyline at Payload, so our position is stated plainly up front. Enforcement of an agent's budget has to live outside the model, in a scoped, signed authorization that a server checks before any money moves. Prompts do not enforce budgets. Signatures do.

What uncontrolled spending actually costs

This is not a hypothetical failure. In a public report, issue #427 in the Conway-Research/automaton repository, the project's own self-hosted agent ran an auto-topup loop that paid 10 USDC on-chain while every credit grant failed. The purchase kept failing. The payments kept succeeding. And no authorization gate existed to stop the repeat payments.

Read that sequence again, because it is the normal shape of this loss. Nothing dramatic happened. No attacker drained a wallet in one move. A loop did what loops do, a payment rail did what payment rails do, and the only layer that could have said stop was not there. Ten dollars is a cheap way to learn that lesson. The same loop, running longer, against a larger balance, with a more expensive resource on the other side, does not stay cheap.

Three failure shapes, one root cause

1. Retry and top-up loops

An agent pays, the thing it bought fails, and the sensible looking recovery is to try again. So it pays again. And again. Each individual payment looks legitimate, because each one is small, well formed, and connected to a real task. The loss is in the repetition, and repetition is exactly what a model focused on completing its task will not police in itself.

2. Prompt injection past a text limit

If your spending limit exists as words in a prompt, then words can move it. Injected instructions, a poisoned tool result, or a persuasive page the agent was asked to read all operate on the same surface as the limit itself. The agent is not disobeying a control. It is weighing two pieces of text, and the limit has no authority beyond being text it happened to read earlier.

3. Child agents that outlive their budget

Work gets delegated. A parent agent creates sub agents to handle parts of a task, and those agents inherit the ability to spend without inheriting the full budget context that justified the spending in the first place. The original limit stays behind in a conversation the child never saw. The spending ability travels. The constraint does not.

Different triggers, same root cause. In all three cases the budget was information given to the model, not a condition enforced on the payment.

What enforcement has to mean

Real enforcement has four properties, and a prompt provides none of them.

• The check happens outside the model. The component deciding whether a payment is allowed cannot be the component that can be persuaded, distracted, or injected. It has to sit on the server side, before the spend.
• The authorization is scoped. It covers a defined agent, a defined kind of action, a defined amount, and a defined window, rather than a general permission to spend. Scope is what turns a vague intention about a budget into a boundary a specific payment either fits inside or does not.
• It is signed. A signed authorization cannot be quietly edited by a conversation, a tool result, or the agent itself. The agent can present it, and the server can verify it, but neither the model nor anything feeding the model can rewrite its terms mid task.
• It fails closed. A failed or absent authorization means no payment. Not a payment with a warning, not a payment that gets reviewed later, and not a payment because the task seemed important. No valid authorization, no spend. That single property is what stops the Conway loop, because the second and third top-up attempts meet the same closed gate as each other instead of an open rail.

This is how Veyline works. Veyline checks a scoped, signed authorization outside the model before an agent spends, and the check is enforced server-side. Veyline is noncustodial, and the agent never holds funds. For context, Payload operates in x402 and agent payments, with real Base mainnet USDC transactions and a public payout-evidence record in x402 Foundation issue #3758.

The one next step: run a free preflight

Do not take any of this on faith, and do not start with a subscription. Start with one free Veyline preflight evaluation, which checks an authorization without executing anything.

1. Get a free rail API key from the console at https://payload-rail.fly.dev/revrule-console/
2. Connect the Veyline MCP server from Smithery at https://smithery.ai/servers/kyler-simmons-partners/veyline
3. Run a preflight authorization check. The wrapper exposes veyline_status, veyline_usage, and veyline_preflight, and the preflight evaluates an authorization without executing anything.

That is the entire ask. One evaluation, against your own scenario, showing you what an outside the model check says before money is involved. If your current setup is a prompt and a hope, the contrast will be immediate.

Why the paid step exists

The free preflight matters because it demonstrates the control that the paid product applies to real traffic. Veyline Developer, at $99/mo through the live guest checkout at https://payloadhq.github.io/veyline.html, enforces these controls for real agent traffic, so the budget boundary holds when your agents are actually spending, not only when you are testing.

If you want the fast-start implementation path first, the Veyline Developer Primer is $79 one-time on Gumroad at https://payloadtools.gumroad.com/l/x402-paid-api-starter-kit, and it carries a $79 migration credit toward a first paid Veyline subscription, within a 90-day window.

Your agent will spend money again. The only open question is whether anything other than the model itself gets a say first. Put the signature in charge of that answer, and leave the prompt to do the job it is actually good at.

The useful question is narrower and more mechanical: can a third party take two public records, one that says who was owed what and one that says what actually moved on chain, and recompute whether they match? We recently posted a small public example of exactly that join, and this post walks through what is in it and how to check it yourself.

The public record

The example is a completed entitlement linked payout evidence fixture that we posted to the x402 Foundation repository, in issue #3758:

https://github.com/x402-foundation/x402/issues/3758#issuecomment-6156473438

Everything below comes from that public comment. If a detail is not in there, it is not in this post either.

Provenance, stated plainly before the numbers: this was a Payload operated real money mainnet validation. Real USDC moved on Base mainnet. The entitlement genuinely existed before the payout and governed it. The wallets on both sides are Payload's. It was not a customer payout, and no customer funds were involved.

Step 1: the entitlement comes first

Before any money moved, the engine recorded an entitlement. In plain terms, an entitlement is a ledger line that says a specific participant is owed a specific amount because a specific rule fired on a specific economic event.

The public fixture identifies that line with these fields:

• Graph: x402-3758-validation-v2
• Event: x402-3758-validation-v2-event-1
• Rule: full-to-treasury
• Participant: treasury
• Instruction: dist:x402-3758-validation-v2-event-1:full-to-treasury:treasury
• Entitlement sequence: 1
• Entitlement hash: 737e24894941e49675b9842820baec2da46dce374c91ff620f2a17922cba876d
• Amount: 10000 base units of USDC, which is 0.01 USDC at six decimals

The ordering matters more than any single field. The entitlement was recorded first, as its own ledger entry with its own sequence number and hash. The payout that followed had to answer to that entry, not the other way around. If you record the obligation after the transfer, you have not created evidence. You have created a caption.

Step 2: the payout is an ordinary on chain transfer

The payout itself is a normal Base mainnet USDC transfer. Nothing about it is special, and that is the point. Anyone can look it up without our help:

• Network: Base (chain ID 8453)
• Token contract: 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
• Sender: 0x699c7549c4deb0bd52ebd384cb13d04110ba2b7d
• Recipient: 0xb3ecD1c309bEe30744D28f4B8957aA26D755B36A
• Transaction hash: 0x693287f1c83f4037ea7366d9fab259e76cc069aa4a533bbfc15788cd010e2f11
• Block: 52569480
• Block hash: 0x2db6345a84fa7d98f12f5bad7a986a5a6c3e3ef34608c854f43f7d7c263aae7c

Open the transaction in any Base explorer or pull the receipt from any Base RPC endpoint. You will find the USDC Transfer log in that block, from the sender above to the recipient above, for 10000 base units.

Step 3: the evidence is the join, not a screenshot

A transfer and an entitlement sitting in two different systems still prove nothing together until something binds them. In the fixture, that binding is a payout evidence record that carries both sides at once:

• Evidence ID: 7194cfee4e29eceee393e9bec4a02255c8c1809b6a357512b83923807a99cc21
• Evidence hash: 626212ce2650e81dbdbf69aa8fe17a18f7f5a43feb82673f194e29c52db1d9d2
• The chain locator it points at: transaction hash 0x693287f1c83f4037ea7366d9fab259e76cc069aa4a533bbfc15788cd010e2f11, log index 456, block 52569480
• The entitlement it points back to: sequence 1, hash 737e24894941e49675b9842820baec2da46dce374c91ff620f2a17922cba876d, in graph x402-3758-validation-v2

The log index deserves a word, because it is the field people most often leave out. A single transaction can contain several Transfer logs. The pair of transaction hash and log index names exactly one of them, so the check is about one specific movement of value, not about a transaction that roughly looks right. Joined on network, transaction, and log index, the record cannot quietly point at a different log later.

How to recompute the check yourself

You need no account with us and no permission from us. Three comparisons do the whole job:

1. Read the entitlement side from the fixture. Amount owed: 10000 base units to participant treasury, under rule full-to-treasury, for event x402-3758-validation-v2-event-1.
2. Read the chain side from the transaction receipt. Find the log at index 456 in transaction 0x693287f1c83f4037ea7366d9fab259e76cc069aa4a533bbfc15788cd010e2f11, block 52569480. It is a USDC Transfer of 10000 base units to 0xb3ecD1c309bEe30744D28f4B8957aA26D755B36A.
3. Compare. Amount owed equals amount moved, the recipient in the log is the payout recipient named in the evidence, and the locator in the evidence is the locator you just read from the chain. If any of those failed, the payout would not match the entitlement, and you would know it from public data alone.

That is the whole idea. Obligation recorded first, in the open. Payout executed on a public chain. Evidence that joins the two with identifiers precise enough for a stranger to recompute the match. Trust in a dashboard is not part of the design.

One honest limit: this validates that a payout matches an entitlement. It says nothing by itself about whether the underlying rule was fair or the split was well designed. Garbage rules produce perfectly verifiable garbage entitlements. Verification answers the did-they-pay-what-they-recorded question, which is the question disputes actually start with.

Try the free evaluation path

RevRule is the engine that records entitlements and payout evidence in this shape, and you can run it yourself for free:

• RevRule console: https://payload-rail.fly.dev/revrule-console/ Get a free API key there, define a graph with your own rules and participants, and dry run an event with the simulate endpoint before you record anything real.
• Browser sandbox: https://payloadhq.github.io/revrule-sandbox.html This is a labeled simulation of the real engine that runs in your browser. It needs no key, and it is a good way to see how entitlements are computed before you touch the API.

If you run a payout flow where someone downstream has to take your word that they were paid correctly, try the check above on your own data first. If a stranger cannot recompute the match from records you publish, the evidence is not finished yet.

Payload

Verification and settlement are usually treated as the same event. The facilitator checks the payment, says it is valid, the resource gets served. But they are two different claims. Verification says this authorization is genuine and matches the terms. Settlement says value actually moved on chain. Most of the time they agree, and when they do not, the disagreement is discovered later, by whoever is doing the accounting.

We have seen the shapes this takes. A payment verifies, the call is served, and the settlement quietly fails or lands for a different amount. Or the reverse: value moves, but the verification record never gets written, so the seller's books say unpaid while the buyer's wallet says otherwise. Either way one side is holding a receipt the other side does not recognize.

The interesting question is what the protocol should do at serve time. Serve on verification and treat settlement as a back office problem, and sellers carry the risk. Wait for settlement finality before serving, and every call inherits chain latency. Serve on verification but keep a first class record of the disagreement, so it can be reconciled instead of argued about, and now somebody has to define what that record contains.

If you run paid endpoints or agents that pay for calls: when verification and settlement disagree on one of your payments, which one do you treat as the truth today, and what breaks because of that choice?