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.
Where it lands in Jayverse
- Rabbit: enforce intent mandates, not just spend caps, on session keys. A 7715 session key that only bounds an amount lets an agent pass every check while buying the wrong thing; Rabbit's mandate design should commit to (item/action class, max price, counterparty allowlist, expiry) and check settlement against that commitment.
- Rabbit: add a low-privilege veto window between authorization and settlement. A separate watcher key that can cancel but not spend, given a short window before finality, is a concrete addition to Rabbit's mandate flow that catches a wrong-target action a spend cap alone would miss.
- Verex: apply the same two-mechanism split to withdrawal or settlement automation. Any automated flow (agent-triggered settlement, auto-withdraw) should be checked against a signed intent rather than a balance limit, with enforcement on-chain and the policy decision off-chain.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| spend cap | 지출 한도 · 금액만 제한할 뿐 무엇을 사는지는 못 막는 장치. "a spend cap is the wrong invariant" |
| chargeback | 지불 취소, 카드사가 대금을 되돌려주는 절차 · 온체인에는 이게 없다는 대조점. "on-chain there is no chargeback behind it" |
| veto window | 거부권 행사 구간 · 정산 전 잠깐 취소할 수 있는 시간. "a veto window on settlement" |
| draw fire | 비판을 받다, 공격의 대상이 되다 · 논쟁적인 설계 선택을 가리킬 때. "the second is the one that will draw fire" |
| disjoint | 겹치지 않는, 서로 분리된 · 권한을 일부러 나눠 한쪽이 남용 못 하게 할 때. "the privileges deliberately disjoint" |
| auth-and-capture | 승인-매입 분리 방식 · 카드결제처럼 먼저 승인하고 나중에 확정 처리하는 구조. "auth-and-capture rebuilt for agents" |
| reconcile after | 나중에 대조·정산하다 · 일단 한도 내에서 승인하고 사후에 맞춰볼 때. "authorize against a limit now, reconcile after" |
| all but guarantee | 사실상 보장하다 · 거의 확실하게 그렇게 될 것이라고 말할 때. "all but guarantees that most entries demonstrate" |
| poisoned (context) | (입력이) 오염되다, 조작되다 · 악성 데이터가 에이전트의 판단을 흐릴 때. "an agent whose context is poisoned" |
| happy path | 정상 흐름, 문제 없는 이상적 시나리오 · 대부분의 참가작이 보여줄 뻔한 흐름. "the happy path of exactly the mechanism" |
| AP2 | 에이전트 결제 프로토콜(Agent Payments Protocol) · 구글의 Intent Mandate/Cart Mandate 구조, 이 카드가 솔라나로 옮겨온 개념. "That is AP2's Intent Mandate / Cart Mandate split" |
| CRE | 체인링크 런타임 환경(Chainlink Runtime Environment) · 온체인 집행·오프체인 결정 분리 패턴을 다루는 다른 카드. "the same split the CRE × Cloud card arrives" |
| Cloud Run | 구글 클라우드의 서버리스 실행 서비스(Google Cloud Run) · 에이전트가 접근할 수 없는 곳에서 정책 서비스를 돌리는 위치. "a Cloud Run policy service" |