What Your Agent Can Still Do On Its Worst Day.

Somebody is going to sit across from you this quarter and offer to put an AI agent on your treasury. It will watch your positions, rebalance when they drift, take profit on a schedule you set, pay your contractors on the first. The demo will be good. They usually are.

You will ask the only question that matters, which is what happens when it is wrong.

And you will get a real answer. They will show you a policy screen with an approved list of destinations, a daily cap, a rule that says never touch the reserve. It will look exactly like the controls you already use for company cards, and you will recognise it, and that recognition is the problem.

Every one of those controls runs before the transaction, in software the vendor operates.

The agent decides to move funds. It asks the vendor's service to sign. The service checks its rules, decides yes, and signs. The signed instruction goes to the blockchain, and the blockchain executes it, because a signed instruction is a signed instruction. Nothing in that final step knows a rule existed. The chain was never told about your daily cap and has no way to be told.

This is not a gotcha and it is not sloppy work. It is how the whole category ships. Coinbase's developer platform documents its Policy Engine plainly, in its own words: the APIs "evaluate policies (a set of rules) to govern the behavior of accounts or projects, such as enforce allowlists and denylists." Read what those rules attach to. They attach to requests to sign. The rule decides whether Coinbase's service will sign, on Coinbase's servers, before anything reaches the chain.

Grant them what they earned. It is a lot. The agents reason well. They read a position faster than the person who owns it and act more consistently than that person does at eleven at night. Coinbase's engineering is careful and their policy layer is a real product built by people who thought hard about it. None of that is what is wrong.

What is wrong is where the limit sits. A limit that is not checked when the money moves is not a limit. It is a preference, held by somebody else, on a machine you do not run.

There is a version of this that does hold. You can attach a small piece of software to a company wallet that caps spending, and it lives on the chain with the money, and it is consulted every single time funds leave. It cannot be talked around, because nothing is deciding whether to sign. The cap is part of the moving.

That thing exists, and it has existed for years. So the honest question is not whether it is possible but whether anybody uses it, and nobody had published that number, so we went and took it.

We sampled 29,157 company wallets created on Ethereum since 2018, drawn from 260 evenly spaced windows across the whole period, and asked each one directly what it has installed. 24,885 answered.

3,067 of them have installed the piece that lets other software act on their behalf. That is the part that makes an agent possible, and it is growing fast: among the newest wallets in our sample it is the majority, up from about one in fifty two years ago.

95 have installed the piece that caps what that software can spend.

One has both.

Not one percent. One wallet. Out of 24,885 read live off the chain, a single company has given something the ability to act for it and also given it a ceiling.

A number that small invites the obvious objection, which is that it might be an accident of how we sampled. It is not. The check is worth showing, because it cuts the other way.

The 3,067 are lumpy. A handful of operators deploy wallets in batches, and three of our windows are packed with them, which is why the headline adoption figure is higher than a typical window. Say that out loud rather than hide it: most of the growth in what agents can do is a small number of companies doing it at scale.

The 95 are the opposite. They are spread across 74 separate windows, never more than six together, scattered across eight years. Nobody batch-deployed them. They are 95 independent decisions by 95 different companies, each of which sat down and decided a ceiling was worth the trouble.

Ninety-five, in eight years, out of hundreds of thousands.

Because until now a limit that actually holds has meant running your own contract.

Not configuring one. Deploying one, paying for it, and then owning it: a piece of software live on a public network holding your money, which you now have to audit, monitor and upgrade. And you need a fresh one per agent, because the whole point is that this agent gets this ceiling and that one gets a different ceiling. Multiply that by every automation you would like to run and the reason for 95 stops being mysterious.

So the industry did the sensible thing and moved the limit to where it was cheap. A rule on a server costs nothing to write and nothing to change. It just is not attached to your money.

Which brings us to the part that surprised us, and it is the reason this post exists.

The good version is not missing. It is built, it is documented, and it is already sitting inside the product being pitched to you.

ZeroDev lets you attach a ceiling to an account that the chain itself enforces while the transaction runs. A maximum value that can be moved. A specific destination and nothing else. A cap on how many times a thing may happen in a window, which they implement as its own deployed contract rather than a check in a library. Conditions on the individual numbers in the instruction, so an agent can be permitted to swap but only under a price. That is a real lane and it is good work.

And Coinbase's agent toolkit ships with it. Their published wallet list exports a ZeroDev option next to the plain ones. Anybody who tells you the bounded version cannot be built is wrong, and we are not going to be the ones telling you that.

So read how it is wired. In the 421 lines of that integration the account is created with one plugin in one slot, and the slot is the unrestricted one. There is no ceiling, no destination, no rate, no condition. The default is the version that can do anything, and the bounded version is a thing you would have to go and build.

That is the shape of the whole market. Not a missing capability. An unused one.

Company wallets are not the only kind, so we counted the other kind too, which is the newer sort of programmable account that most agent tooling actually builds on. We read every add-on ever installed on one of them on Ethereum: 346,173 installations across 197,934 accounts.

24,757 of those accounts do carry a permission add-on. That is one in eight, and on its face it is the opposite of everything above.

Then you read which permission they installed.

The most installed one on Ethereum is called SudoPolicy. Sudo is the word engineers use for unrestricted, the setting that means do not ask, and the name is not a slip. Its published source contains two decisions, one for whether to allow an action and one for whether to allow a signature. Both of them return approved, always, with no conditions of any kind. It is thirty lines long. It cannot say no to anything, and it was never built to.

It has been installed 13,946 times, which is more than every genuinely restrictive policy on that list put together.

So the picture does not change when you widen it. It sharpens. Given a slot built specifically to hold a limit, the most popular thing to put in it is a limit that permits everything.

That gap is a category, not a criticism. Every serious company in this market has spent its engineering on making the agent more capable and nearly none on making it more bounded, because being bounded was the expensive half.

This is what Plug is for, and the difference from what you just read is worth being precise about, because we are not claiming to be the only way to bound an agent on chain. We are not. ZeroDev's validators do it and they do it well.

The difference is what it costs you to have one. Every on-chain answer available today is a piece of software you deploy and then own, one per agent, because this agent gets this ceiling and that one gets a different ceiling. That is the bill that produced 95 and produced a default wired to the unrestricted slot. Plug's claim is a category claim: programmable transactions on Ethereum without deploying a smart contract at all.

A plug is a set of conditions you sign once, and those conditions are the permission. Nothing about it has to be fixed at the moment you sign. The amount can be a share of whatever the balance turns out to be. The recipient can be whoever holds a role on the day. The price can be whatever the market says at the second it executes, with a floor under it. All of that is worked out when the transaction runs, on the chain, with the money.

Which means the ceiling is not a note to your agent. It is the thing being executed. An agent handed a plug did not receive the ability to move your funds and a request to be careful. It received the ability to do one bounded thing, and the bound is checked by the same machinery that moves the money, at the same instant, every time.

And because there is nothing to deploy, a lane is something you hand out rather than something you commission. A different one per agent, revised in an afternoon, taken back by letting it lapse. The reason 95 companies bothered and hundreds of thousands did not was never that they wanted their agents unbounded. It was the bill. Take the bill away and the number stops meaning what it meant.

Go back to the meeting.

The question in front of you was never whether the agent is clever. It probably is. It will get cleverer between now and the day you sign, and none of that touches what you are actually deciding. The question is what is still true about your treasury on the day it is wrong, or the day somebody who is not it gets hold of it.

If the limit lives on somebody's server, the honest answer is everything the key can reach.

If the limit is the instruction itself, the answer is the lane, and only the lane, on its worst day.

We enumerated wallet creations from all four Safe factory contracts on Ethereum mainnet across 260 evenly spaced 5,000-block windows from block 6,000,000 to 25,893,732, then asked each resulting wallet directly, at a recent block, what it has installed. That is 29,157 wallets sampled, 24,885 answered, and about 446,000 created in the period. The spending cap counted is Safe's own allowance module, which enforces its ceiling in the same operation that transfers the funds. The execution piece counted is the pair of Safe modules that implement account abstraction, identified by asking each one which entry point it supports.

The second count reads every module installation event on Ethereum from block 19,000,000 to 25,893,852, in 69 windows, each answered independently by two separate providers with any disagreement recorded rather than believed. All 69 resolved and none disagreed. Everything above is read from the chain rather than from an API, so there is no quota and nothing to throttle, and anyone can re-run it. The Coinbase figures come from their own published policy engine documentation and their own published source, including the ZeroDev integration it ships. The permission machinery described is ZeroDev's own documentation, and SudoPolicy is read from its verified source as deployed at 0x67b436caD8a6D025DF6C82C5BB43fbF11fC5B9B7.