Why
Autonomous payments are almost always secured with a spend cap, and the cap is the wrong invariant. An agent given $100 that spends $50 on the wrong item has violated nothing — the session key worked, the limit held, the signature verified. The failure that matters is not overspend but wrong spend inside the limit, and unlike a card payment there is no chargeback sitting behind it. So this card is a design for fixing the invariant rather than tightening the cap, written as if entering the Google Cloud × Solana agentic-commerce hackathon, where the stated theme (an agent that settles and signs without human approval inside a budget) all but guarantees that most entries demonstrate the happy path of exactly the mechanism this one argues is insufficient. The competition is not the point; the point is that the strongest form of this argument is a demo in which the audience watches a conventional agent pass every check and lose the money anyway.
How it works
Two mechanisms, and the second is the one that will draw fire. First: sign the intent, not the limit. Before the agent sees any merchant content, a commitment is issued to (item class, max unit price, max quantity, merchant allowlist, expiry), and the on-chain program checks settlement against that commitment rather than against a balance — so an agent whose context is poisoned after the commitment was made cannot settle a purchase that does not match what it committed to wanting. That is AP2's Intent Mandate / Cart Mandate split moved onto Solana; the AP2 card already builds the same separation, so the new part is enforcement at settlement rather than the mandate concept. Second: a veto window on settlement. Between authorization and final settlement sits a short interval — 30 to 60 seconds — in which a separate low-privilege watcher key can cancel, with the privileges deliberately disjoint: the agent cannot cancel its own payments and the watcher cannot spend. This is the the-settlement-instant card's claim about liquidations — an action that fires with zero delay removes the only interval in which a bad input could have been noticed — applied to payments instead of oracles. The demo runs the same agent twice against a merchant API carrying a prompt injection: on a plain session key the limit holds, the purchase is wrong and the money is gone; on these rails settlement fails on the intent mismatch rather than on the amount. Two questions get asked of every entry, so answer them in the design. Sub-second finality is what makes a 30-second veto window a product decision rather than an artifact of block time — on a slower chain that window is indistinguishable from ordinary confirmation latency, and the product does not exist. And the commitment issuer and the watcher have to live somewhere the agent cannot reach, which makes them a policy service with an audit log rather than anything on-chain: enforce on-chain, decide off-chain, the same split the CRE × Cloud card arrives at from the other direction. The objection to answer first, because a payments audience raises it immediately, is that no merchant wants to wait 30 seconds for finality — and the answer is that card networks already made this trade and gave it a name. Authorization is instant, capture is later. This is auth-and-capture rebuilt for agents rather than a new tradeoff, which is also where the rwa-multichain card lands coming the other way: authorize against a limit now, reconcile after. Scope if built: one Solana program (commitment check, timelocked settlement, watcher cancel), a deliberately hostile merchant API, and a Cloud Run policy service. No wallet UI, no multichain, no token — nothing that does not appear in the demo.