Where the decision lives

No model in the decision path

The engine is a few hundred lines with no dependencies, no network calls, and no configurable strictness. It cannot be influenced by a web page the agent read, by a creator’s response body, or by anything else an attacker controls.

It is small because it is the part that has to be audited, and every line in it is a line someone must be willing to defend after a payment goes wrong.

Pricing precedes authorizing

An x402 purchase names a URL, not an amount — the price comes from the counterparty’s own response. So the gate resolves the price itself rather than trusting a number the agent supplied, because the agent read the listing and the listing is attacker-influenced.

If pricing fails, the payment is held. “The price lookup failed so we paid anyway” is not a sentence anyone wants in an incident review.

Every unknown resolves to not paying

Unknown counterparty, unreadable permission, unparseable amount, missing budget, mainnet without an explicit opt-in — all converge on hold or block. A wrongly-held payment costs someone’s attention. A wrongly-sent one is irreversible.

Permission is granted, not configured

A permission names a counterparty, a per-payment cap, an accountable owner, an end date, and the reason it was granted. The reason matters: six months on, that sentence is the only thing that can answer whether it should still exist.

The person who granted it and the person accountable for it are stored separately. The first is a decision made on a date that nothing later changes; the second is who you ask at renewal. People change teams. The decision they made in March does not.

Two systems must agree

The authorized amount is passed down to the payment client as a hard maximum, so the layer below independently refuses to exceed it. Two different systems have to agree before money moves, and the second one isn’t ours.

Refusals are the interesting record

Each entry carries the hash of the one before it, so altering any past entry breaks verification of every entry after it. A log of what an agent paid tells you what happened; a log of what it was stopped from paying is what shows the controls working.

Append-only and hash-chained is not the same as immutable — someone with write access can still truncate a file. It is tamper-evident, which is the honest claim.

If the record fails, the payment does not happen

A payment we cannot write down is a payment we do not make. This is the decision people argue with, because it means a storage outage stops settlement rather than degrading it — and that is the trade we want. The audit trail is the product; a payout nobody can prove happened is worth less than one that waited.

What one process still cannot promise

Passes are bounded across instances by a lease in the blob store, budget is reserved with an expiry rather than deducted, and a settlement that has already been recorded cannot be counted twice. Those three were real gaps once and are closed.

What is left is smaller and named rather than implied: chain verification under concurrent appends has not been proved, and fault injection between reserving and committing is not yet covered by a test. How the rest is tested →

Multi-Provider Settlement Engine

Uses Circle Developer Controlled Wallets REST API to eliminate host CLI session token expiration in 24/7 Cloud Run deployments, with seamless fallback to Circle CLI.

Batched YouTube Oracle (98% Quota Savings)

Groups up to 50 video IDs per single HTTP request, reducing API quota consumption from thousands of requests per pass down to a single batch call.

Slack & Discord Operational Alerts

Dispatches non-blocking, real-time alert notifications for depleted campaign pools, failed payouts, or multi-instance lease contention.

Account Linkage & Brand Ownership

Maps creator Google Auth accounts to multiple EVM payout wallets, while campaigns are explicitly owned by verified Brand Profile records.