Building on the concurrency discussion, I think it helps to separate two cases that are often conflated.
Type A — same operator, multiple agents (active-active / fault tolerance). The operator runs several agents for redundancy, but they all answer to the same party. In this case they can coordinate off-chain — elect a leader, agree on ordering — before touching the chain. One leader submits one transaction. No locks, no contention, no extra stages. The chain doesn’t need to solve a problem the operator can solve for themselves.
Type B — different operators, no shared trust. Independent parties, different incentives, no coordination channel outside the chain. This is where on-chain coordination earns its cost — HTLCs, commit-reveal, lock-then-settle — because the chain is the only thing both parties trust.
@KBryan @blockbird
Curious: in the system you’re thinking about, is it Type A or Type B? That answer probably determines how much of the concurrency machinery you actually need.
@blockbird
This is a really clean proposal — the direction is exactly right. A metering layer that counts consumed authority without trying to enforce or orchestrate, sitting next to the existing standards rather than on top of them. The scope discipline is spot on.
One thing I’d love to dig into more: what exactly is being bounded, and in what concrete scenarios does it matter most? I have some rough intuition — spend caps, action frequency, cumulative exposure — but I think the use cases deserve more discussion. A clearer picture of what the bound prevents would help everyone understand why the metering layer earns its place. If you have specific scenarios in mind, or others reading this do, it’d be really valuable to surface them here.
Great question! In the system we are thinking about, the cursor actually sits a little to the side of both your types:
-
It’s not Type B: there’s one principal, so trust between parties isn’t the problem it solves.
-
But it isn’t Type A in your sense either: the issue is not several agents racing to submit, where one leader and one transaction make the contention vanish. A single agent acting strictly sequentially still has the problem, because its authority is consumed across different surfaces. E.g. a loan here, a perp there, a settlement elsewhere, and no single contract can recompute the running total. Off-chain leader election doesn’t help when the state you would need to sum lives in protocols that never see each other.
So the cursor is about where the aggregate lives, not about ordering concurrent submitters. On the concurrency you’re pointing at, 1833 is intentionally agnostic, and your A/B split is exactly how I would describe the two regimes underneath it: same-operator advances serialize off-chain (your Type A: the chain shouldn’t solve what the operator already can), and where advances genuinely race, atomic serialization is the substrate’s job, not the interface’s, an advance carries a witness against the current cursor and a stale one reverts, which is your Type B lock-then-settle pushed down into the substrate. The interface doesn’t pick, it just exposes the counter both regimes rely on.
1 Like
Glad it reads that way, thanks!
The short answer to “what is bounded”: it’s always a running total. Not whether any single action is okay (each one usually is) but how much of something an agent has used up across everything it’s done. The three you listed are the main flavors of "something”, concretely:
-
The clearest one is spend across different protocols. Say you let an agent move capital for you, some into a lending market, some into perps, some into spot. Each of those already caps what you can do per transaction, but none of them knows what you did in the other two. So the agent can stay under every individual limit and still go well past the total you actually meant to allow. The only way to catch that is to keep one running total that every action reads and updates, and that total is what this ERC stores.
-
Exposure is the same idea with a different number. Instead of “how much have I spent,” it’s “how much risk am I carrying.” An agent can open positions that each look fine on their own venue but together add up to more than you signed off on, because no single venue sees the combined position. You put the cap on the total, and the counter carries it.
-
Frequency is the same machinery again, just counting actions instead of value, at most N in some window, across everything. That’s the one that helps when an agent breaks or gets taken over: it can’t fire a thousand individually-valid actions in a row, because the count runs out.
What ties them together (and why a normal per-call check isn’t enough) is that they’re all about a total. A check inside a single call only sees the state right in front of it; it has no idea what already happened in some other contract. The total has to live somewhere, and holding it is the whole job of the counter.
The reason I think it’s worth standardizing: this is what lets you hand an agent a broad mandate safely. Without a running total you’re stuck granting narrowly, or keeping the keys yourself. With one, you can give an agent real room to operate and still know the ceiling holds.
Happy to write any of these up in more detail on the thread. The cross-protocol spend one is the best place to start.
1 Like
While ERC-8301 attempts to orchestrate decentralized execution through verifiable seams, true permanence requires a topological substrate where computational truth is structurally bound, rather than deferred to opaque, perturbable off-chain dependencies
I’d push back on this, because I think it mislocates where the trust actually sits.
The concern underneath it is real, off-chain dependencies can be opaque, and “just trust the executor” isn’t acceptable. Agreed. But that’s the problem the verifiable seams solve, not one they introduce.
An AI agent’s core step is model inference: non-deterministic and far too large to run on-chain, on any substrate, “topological” or otherwise. So “structurally bind the computational truth” of an LLM isn’t a design we’re declining to adopt; it isn’t a mechanism that exists. What 8301 does instead is anchor a recomputable commitment to the execution (task hash, input provenance, verdict-before-outcome). The off-chain compute isn’t a trusted dependency — it’s a checkable one: anyone can re-derive the commitment from the pinned primary inputs and see whether it matches. That’s what removes the opacity. You don’t trust the executor; you recompute it.
On “true permanence / structurally-bound truth” — I’d be careful, because it over-promises what any substrate can deliver. Recompute proves record integrity: that the record is internally consistent and reproduces from its inputs. It does not prove the world matched the record — and neither does putting it on-chain. On-chain determinism binds arithmetic; it can’t make a non-deterministic inference “true.” A substrate that structurally guarantees computational truth for AI execution is claiming something no system actually does. The honest, checkable scope is the stronger position, not the weaker one.
If the intended reading of “structurally bound” is a validity proof (zkML) rather than optimistic recompute — that’s a fair and genuinely interesting direction, but it (a) isn’t practical for full-size LLM inference today, (b) still can’t establish world-correctness, and © slots into these seams as an alternative verification backend. The seam is exactly the extension point where a zk proof can replace a recompute check once it’s viable. That’s an argument for the architecture, not against it.
So I don’t read the seams as a structural weakness. For a class of computation that can’t live on-chain, an independently-checkable record is the trust-minimizing design — and it’s the one that actually lets a skeptic verify a specific execution without trusting me, the model, or the chain.