An agent with a wallet does not fail the way a human does. It does not get nervous, ask a friend, or notice that the address looks wrong. It builds an intent, signs it, and the chain executes. By the time a dashboard shows the result, the money has moved.
A pre-signing gate inserts one step before that signature: take the exact intent, check it against the chain and a caller-supplied policy, return a verdict, and issue a receipt. The point is not to predict whether the trade is profitable. The point is to catch the class of mistakes that are visible before signing and expensive after.
That class is narrower than a security audit and wider than a wallet warning. Being precise about the boundary is the whole product.
What it can check
1. The shape of the payment
For an x402 payment request, the gate can check the scheme, the CAIP-2 network, the asset contract, the raw amount, the payTo address, the resource URL, the timeout, and the authorization window. A swapped payee, a lookalike asset, the wrong chain, or an amount that exceeds the caller's cap is a reason to stop — not a reason to ask the model to try again.
The amount is read in raw units. On a six-decimal stablecoin, 10000 is 0.01, not 10,000. That distinction alone has ended more agent demos than any exploit.
2. The caller's policy
A verdict without a policy is just an opinion about the chain. The caller can supply a maximum amount, allowed networks and assets, allowed payees, allowed resource hosts, an expiry, and a rule against unlimited approvals. The gate checks the intent against those rules and names which one failed.
If the caller never supplies a limit, the gate cannot enforce it. "It stayed under my cap" is only meaningful when the cap was part of the request.
3. The calldata
For an EVM transaction, the gate decodes transfer, approve, transferFrom, permit, and common V2/V3 swap selectors. It can flag an unlimited approval, an unknown spender, a swap deadline that has passed, a zero minimum output, or an output recipient that is not the signer. When a from address is supplied, it simulates the call from that wallet at the current block.
This is EVM-only today (Ethereum, Arbitrum, Base). It is not a general transaction interpreter, and it does not know what an arbitrary contract will do after the call returns.
4. Freshness
Chain state expires. A quote, a balance, or an allowance read at an old block can be true and useless at the same time. The gate pins a block, reports its age, and treats stale state as a reason rather than a silent pass.
5. The obligation, when the caller supplies one
If the caller provides an idempotency key and an obligation policy, the gate can check a settled key and a cumulative spend or grant against the stated limit. That turns "I already paid this" and "this would exceed the budget" into explicit reasons instead of assumptions held in the agent's prompt.
6. The receipt itself
Every response carries a short-lived HMAC-signed receipt. It binds the normalized intent, the original request, the block, and the expiry. A second endpoint can verify the signature and both bindings without another chain call. An executor can require a valid receipt before it calls the signer.
What it cannot check
This list is not a disclaimer at the bottom of the page. It is part of every response, under notChecked, because a PASS without scope is a blank check.
- Whether the payee is honest, or owns the wallet. A matching address is not a reputation score. A payout allowlist is a list the caller chose; a signed manifest is a stronger binding, but neither proves the counterparty will deliver.
- Whether the agent's goal is legitimate. Prompt injection, a manipulated plan, or a user who was tricked upstream can produce a perfectly well-formed intent. The gate checks the intent, not the reasoning that produced it.
- What the contract does after the payment. An upgradeable proxy, a hook, or a transfer restriction can change the outcome after a valid call. The gate can simulate the call; it cannot audit the contract.
- Whether an off-chain resource will be delivered. A resource URL can be bound to the receipt. The content behind it is still an off-chain promise.
- Whether the trade is profitable. That is a measurement question, handled by the paid checks, and even those return a verdict at a block — not a forecast.
- A limit the caller never supplied. The gate is not a mind reader. Policy is an input, not a guess.
A gate that claimed all of this would be lying. A gate that names the boundary is useful, because the operator can see exactly which decision is still theirs.
Why a scoped PASS is stronger than a green check
"Safe" is not a testable claim. "At block N, with this policy, these checks ran, these did not, and the receipt is bound to this intent" is testable. It can be verified, disputed, and re-run. It can also be wrong in a way that produces a useful bug report.
That is the design goal: make the failure falsifiable. A false PASS — an intent the gate allowed that the operator believes is unsafe — is the only finding that matters. A false BLOCK is annoying; a false PASS is the reason the gate exists.
Try it on an intent you would actually sign
The free gate is read-only. It does not connect a wallet, move funds, or require an account. The public demo settles testnet payments only; analysis reads mainnet chain data.
If you build agents that sign, send three intents: one you expect to pass, one you are unsure about, and one you think should be blocked. I will run them and reply with the raw verdict, the reason codes, and the notChecked list — including where the gate disagrees with you.
The ask
Bring three intents.
One expected PASS, one uncertain, one expected BLOCK. No wallet, no payment, no signup. Redact anything sensitive.
Next: A receipt is not a guarantee. It's a falsifiable record. · All notes