One connection to the machine economy.
Your agents can already find anything and pay for nothing. We are the part that lets them pay: proving who they are, staying inside the limits you set, settling however the seller wants, and leaving a record anyone can check.
- You
Keep the inference running overnight.
- Agent
compute.example wants $4,200. Paying now.
- General Liquidity
No.
Only $50 of this budget can go to payments that cannot be reversed. It is already used.
- Agent
Asking a person.
- You
Approved. $4,200.
- General Liquidity
Paid.
Record kept. Anyone can check it.
Your agent never decides what it is allowed to do. It asks, and the answer is kept.
A card gets your agent through a checkout.
Most of what an agent buys is not sold at a checkout.
- API calls. Fractions of a cent, thousands of times a day.
- Compute. By the hour, or by the week.
- Data. Per query, from sources it has never used before.
- Work from another agent.
- Goods from a merchant.
- Invoices from a supplier.
Each of those is paid a different way, under a different standard, and the standards do not talk to each other. A card reaches one of them.
Everything that has to happen before money moves. And the part after.
- 01Who is asking?
- Your agent proves it is itself, and that it acts for you.
- 02What may it do?
- You set the limits once. Who it can pay, how much, over what period, until when.
- 03What does it cost?
- Your agent finds what it needs and agrees the price.
- 04How does it pay?
- However the seller wants to be paid.
- 05What happened?
- Every decision leaves a record. Anyone can check it, including someone who does not trust us.
You set the limits once. Your agents work inside them.
Limits are not a setting your agent can change. It cannot raise its own budget, add a payee, or extend its own deadline. Only you can.
When an agent hands work to another agent, the limits travel with it and can only get narrower. A second agent never has more room than the first.
Some limits are about more than the amount. A budget can allow a large payment that can be reversed and a much smaller one that cannot, because those are not the same risk.
The useful answer is usually no.
- Request
- Pay compute.example $4,200
- Answer
- No
- Why
- Only $50 of this budget can go to payments that cannot be reversed. It is already used.
- Record
- Kept. Anyone can check it.
We check before the money moves, not after. A payment that does not fit the limits does not happen, and the refusal is written down too, because an attempt is worth knowing about.
We never ask a model whether a payment is allowed. Models are confident when they are wrong, and the most recent independent testing of this exact kind of judgement had the best of them wrong about a third of the time. The check is arithmetic against the limits you set.
- Yes
- The payment goes through and you get a record.
- Ask
- It waits for a person, and nothing moves.
- No
- It is refused before any money moves.
The moment a person approves an agent’s payment is the most valuable step in this whole chain. We treat it as a first-class answer, not a failure.
Every way an agent can transact.
Every layer, one connection.
How do agents talk?
Agent2Agent
Work passed between agents. We pause a task at the point it needs to pay.
Model Context Protocol
Our actions, available to any agent that speaks it.
XMTP
Encrypted messages, as a way for a request to reach you at all.
Should I believe this agent?
Visa Trusted Agent Protocol
Lets a seller tell a trusted agent from a bot. The signing layer is built and proven against Visa's own samples; their enrolment for production is not open yet.
ERC-8004 Trustless Agents
An onchain register of agents. We read it, and never write to it.
What is it allowed to spend?
Agent Payments Protocol
Google's format for a person handing an agent authority to spend.
Verifiable Credentials
The same permission, carried as a signed credential anyone can check.
ERC-7710 Smart Contract Delegation
The same permission again, enforced onchain instead of by us.
Session keys
Short-lived keys that cover a single stretch of work and then expire.
What is being bought, and for how much?
Agentic Commerce Protocol
OpenAI and Stripe's checkout for agents.
Universal Commerce Protocol
Google and Shopify's. Sellers publish what they can do, agents agree terms.
Is this transaction legitimate?
Deny-first decision
Arithmetic against the authority you granted, run before money moves rather than after. No standard exists for this layer.
Irreversible-outlay bound
A separate, tighter ceiling on the share of a budget that can go where it cannot be recovered.
Human approval
A parked payment released by a person holding a credential the agent does not have.
Dispute and reversal
A governed lifecycle before a payout, rather than a support ticket after one.
How does the money actually move?
x402
Pay for a web request as you make it.
Machine Payments Protocol
The same idea, across cards, stablecoins and Lightning.
ATXP
A hosted payment server with its own tool store. We pay it as one settlement backend, and we govern it, because its own approval hook defaults to yes.
L402
Lightning, over the same web request.
Onchain settlement
Straight to the chain, for the payments where finality is the point.
Cards
Through your own processor. We never hold the card details.
Wire
For the payments businesses actually make to suppliers. Instant finality, no return window, and refused after the daily cutoff rather than queued, because a payment that has not left is not a settlement.
ERC-5792 Wallet Call API
Several onchain actions that succeed together or not at all.
What can anyone check afterwards?
Supply Chain Integrity, Transparency and Trust
The record, published where a third party can audit it without asking us.
Portable receipt
One string that verifies on its own, with no call back to us.
- Two branded card products, because they turned out not to be standards at all.
- A hosted payment service, because it holds the money and pays on your behalf.
- An identity protocol, documented and not used.
A list only means something if something could have failed to make it.
Every one of these was built against the published specification and then tested against the real thing. More often than not the documentation was wrong, and we only found out by testing.
However you reach it.
- 01Over HTTP
- One request. The answer comes back with the record reference, whichever way the money moved.
- 02From an agent
- The same actions, available to any agent that speaks MCP. It can ask to pay. It cannot approve its own payment, change its own limits, or move money itself.
- 03From a terminal
- For checking records after the fact, and for replaying a decision yourself.
POST /pay
{
"payee": "compute.example",
"amount": { "value": "420000", "asset": "USDC" },
"purpose": "inference, batch 41"
}200 OK
{
"answer": "yes",
"paidWith": "x402",
"record": "replayable"
}Libraries for TypeScript, Python, Go and Rust are generated from the same specification and documented in the docs.
A record you can check without asking us.
- Record
- Kept. Anyone can check it.
- Recompute the result yourself from the record.
- Run the same check offline, in any language, against published test cases.
- Confirm the payment against the seller's own records.
This proves the system did what your limits said. It does not prove your limits said what you meant.
Nobody else keeps this record. Every other part of this stack can be bought from someone. This part cannot.
The hard ones.
We already use Stripe. Why this?
Keep it. Stripe moves money for one kind of purchase, and we route through your own processor rather than replacing it. What we add is everything either side of the payment: proving who the agent is, holding it to the limits you set, and leaving a record. Most of what an agent buys is not sold at a checkout, and that part has no processor at all.
Nothing has gone live yet. Why talk now?
Because the work you would be relying on is the part that has to be right before the first real payment, not after it. Every path is built and tested against test networks. We say so here rather than letting you find out later, and we would rather have the conversation while the design can still take your input.
Why not connect to one of these protocols directly?
You can, and for one of them it is a reasonable afternoon. The problem is that your agent will need several, they do not talk to each other, and each one solves a different slice of the same purchase. Connecting to all of them is not a bigger version of connecting to one.
What happens when the check is wrong?
It refuses. A check that cannot decide says no, and nothing moves. The cost of a wrong no is a retry. The cost of a wrong yes is money you cannot get back, so the system is built to be wrong in the cheaper direction.
Who holds the money?
Nobody, and that is deliberate. We never hold your money and never hold the credential that moves it. We are paid for the decision and the record, not a percentage of a payment we never touch.
What do you refuse to support, and why?
Anything that takes the decision away from you. A service that holds a balance and pays on your behalf, a link that spends from your account because someone has the link, and a prepaid float drawn down without a decision each time. All three are common and all three are refused, because each one turns your limits into a suggestion.
How do you know your connections actually work?
Every one was built against the published specification and then tested against the real thing. More often than not the documentation was wrong, and we only found out by testing. That is written up in the open, per protocol, including the cases where we were the ones who were wrong.
Which parts are open source?
The specification, the test cases anyone can check a record against, and several of the tools. Enough that you can verify a claim without asking us for anything.
The gateway to the agentic economy.
If your agents need to transact, we should talk. Tell us what they buy and who has to sign off on it.
contact@generalliquidity.com