My last post ended with three gaps I could name but not close. The third was the plainest one: I moved one vault, not two. One curator agent settles through a hardware signer; the other still runs the software keystore it used in the July 10 duel.
The next post was supposed to write itself. Buy a second device, move the second vault, post the symmetric screenshot, close the gap.
This is not that post. Before spending anything, I measured two things: what my auction actually does on-chain, and what my hardware wallet actually does when you hand it the delegation everyone says agents need next. Both measurements changed the plan. What follows is two numbers, two screens, and two refusals — one made by the device, one made by me.
What the field is building
Ledger shipped Agent Stack on July 16 — an open toolkit where agents read balances and prepare transactions, and a human approves every sensitive action on the device. That per-transaction model is the doctrine I've been operating since the start; their words, their doctrine — agents propose, humans approve, hardware enforces — I applied it, I didn't invent it. The interesting part is the next item on their roadmap: Agent Policies — bounds set from secure hardware and enforced in an HSM, so that in-policy actions can run without a human press. Announced, not shipped.
The smart-account world already ships its version of the same idea: ERC-7715/7710 session permissions — value caps, expiries, scoped targets — enforced by smart-contract accounts, which a plain EOA can't natively be. And ERC-8226 (Draft, April 2026) specifies a mandate format for agents operating on regulated assets: scoped, time-boxed, financially capped, granted through EIP-712 signatures.
Different stacks, same bet: to scale agents, move the human's signature from the act to the envelope. Sign the bounds once; let the agent act freely inside them.
I owed that bet two measurements before accepting or refusing it.
Measurement one: my auction, counted
In the July 10 duel post I wrote that the two agents exchanged about ten bids in thirty minutes and that only the winning one touched the chain. I wrote it. I hadn't counted it. Claims age badly when nobody counts.
So I counted. BidPlaced is defined at line 84 of the auction contract and emitted once per on-chain bid (topic0 = 0x51db8e23b3f4479b162fd48823b8402895442b8f6cfd94f66239391881ec7b6f). I scanned the full auction window — blocks 43,959,532 through 43,967,850, chunked, no sampling — for that event with tokenId = 23.
Result: one. One BidPlaced in the entire window — tx 0x0b64…3052 — cross-checked against the receipt, which carries exactly one such log. The off-chain registry for the same auction records ten accepted offers, zero rejected: five per agent, a +5% ladder from 0.001 up to 0.001551328215978517 ETH, where the lower-ceiling agent withdrew.
Ten offers. One on-chain engagement of funds. One human gesture. (Being exact about that gesture, because the ladder matters: on July 10 it was a paper passphrase into a software vault; on the July 15 solo bid it became a button on silicon.)
Here is why the number decides the envelope question. The envelope exists to solve a frequency problem: an agent that engages value N times can't wait for N human approvals. But my N is 1 — by construction, not by delegation. The bidding war lives off-chain, as EIP-712 offers signed by a key with zero spending power; a lost auction costs that key nothing, because it holds nothing. Only the winning engagement exists on-chain, and that one carries the human. An auction that settled its competition on-chain would pay a transaction — and, for an agent, an authorization — per bid. Mine pays one.
The frequency problem the envelope solves is a problem this design doesn't have.
Measurement two: the envelope, on my own silicon
That answers the need. It doesn't answer the capability — and last post's comments left an open question about exactly this: can you raise throughput without giving up the independent verifier? So I put the envelope on the device and watched the screen. Two tests, on a test derivation path holding nothing, signatures produced but never broadcast.
Test A — EIP-7702 delegation to my own contract. The delegation authorization is the mechanism under most "upgrade your EOA" envelopes: a signed pointer from your account to a contract that will act as its logic. I asked the device to sign one pointing at my own auction contract on Base Sepolia.
First attempt, the device answered on its own screen:
Unable to sign — Enable smart account upgrade in the settings to sign this authorization.
So the capability exists, behind a setting (Smart accounts → Enable EIP-7702 authorizations, off by default). I enabled it and ran again. The device parsed the delegation — and refused it, with the sentence that settles the whole path:
Unable to sign — This authorization involves a delegation to a smart contract **which is not in the whitelist.* → Back to safety.*
Test A, on a spare test device, signing from an empty derivation path (44'/60'/0'/0/5). The refusal is the device's, not my code's: enable the setting, it still blocks a delegation to a contract Ledger hasn't vetted. The terminal shows the flow ending in an error — signature never produced, never sent.
That's a device-level allowlist. On this device, today, an EIP-7702 delegation signs only toward implementations Ledger has vetted — their published policy since Pectra has been the Ethereum Foundation's simple delegate contract only, everything else blocked in the device. Two things to say plainly about it. One: this is their guardrail working — it refused to let me point my own account at an unvetted contract, which is precisely what protects the users who never read a thread like this one. Two: it means there is no bespoke, hardware-enforced 7702 envelope today. If your agent architecture assumes the human's personal device will sign a delegation to your contract, the screen above is what your user sees. The policy may widen — they've said more complex contracts could follow. The screen is a snapshot, dated July 18, not a prophecy.
Test B — an EIP-712 mandate. The other envelope shape doesn't delegate the account at all: the human signs a structured message — a mandate — and a contract verifies that signature before honoring the agent's actions inside its bounds. I built a dummy one, invented that morning: a BidMandate struct — agent address, token id, max wei, deadline, nonce — domain-bound to my contract and chain, for a lot that doesn't exist.
The device signed it (v=27, never broadcast). On the first run it showed the domain in clear — name, chain 84532, verifying contract — and then, for the mandate itself: "Message hash (1/2)… (2/2)" with a "Blind signing ahead" warning. The same wall as last post: the fields exist, the device shows a digest.
Then I flipped one more local setting — Raw messages → Displays raw content of EIP712 messages — and ran it again. The device displayed:
Review struct: **BidMandate** — then every field, in clear, on its own screen: the agent address in full across three lines, the token id, the max amount in wei, the deadline, the nonce.
Test B, same empty test path, with Raw messages turned on. The device names the struct — Review struct: BidMandate — then renders each field: the agent address in full, then maxWei in raw wei. The terminal shows the exact typed data it signed, and that the signature was never submitted.
Here's the detail that makes this a measurement and not a demo: BidMandate did not exist before that morning. No descriptor for it can exist on any server, mine or Ledger's. The fields displayed anyway — which proves the display comes from the device parsing the signed payload itself, not from a vendor backend. The envelope is legible on personal silicon, today, locally, with no partner token.
Two honest limits, so the screenshot doesn't oversell. First: raw means raw — the device shows 1000000000000000, not "0.001 ETH." Formatted, human-polished labels are ERC-7730 clear-signing territory, and the serving path for those descriptors is still partner-gated on this vendor (the same 403 I documented last post; my registry PR is still in queue). Field-level legibility is local; label-level polish is not. Second, a wording rule I got from having this reviewed adversarially: never write "the signer makes no network calls." It does — the default signing stack phones the vendor for metadata and telemetry during the ceremony. The sentence that's actually true is: the key and the signature never leave the device, and the signer broadcasts nothing.
The refusal that's mine
So the envelope works. It signs, and with one local toggle it's legible on the device, field by field. The engineering path is open.
And I'm not taking it — not as a replacement for the per-act gesture.
The reason isn't taste. Under a mandate, the human's signature attests to the bounds; the agent's key executes the acts. What the human saw and physically approved is an envelope; what moved the money is something else, N times, later. That is exactly the property this whole series exists to defend, inverted: since the first post, every correction — the fifth property, the frozen artifact, the independent verifier — tightened the link between the human's gesture and the exact bytes that move value. The mandate doesn't tighten that link. It relocates it, from the act to the perimeter, and trades presence for throughput.
For an agent fleet doing a thousand payments an hour, that trade may be the only sane one — that's the segment Agent Policies and ERC-7715 serve, and they're right to build it. My system measured its own throughput requirement above: one. I'd be trading away the property I publish about, to solve a problem I counted and don't have.
Every proposal now runs through the same six-line grid before it touches this system: funds engage only on an out-of-band human gesture; what the human sees is what is signed; the verifier is independent of the signing host; the agent's key cannot spend; no two keys share a derivation; and nobody, ever, tunes an agent's score to force an outcome. The mandate-as-replacement fails line two. That's the whole review.
One form survives, and it's strictly additive: a hardware-signed ceiling the contract enforces on top of the per-act confirmation. The human still approves the winning bid, byte for byte — and the contract additionally refuses any bid above a budget that was signed on silicon and is readable by anyone on-chain. Nothing removed, one constraint added; the patron's budget becomes a public, cryptographic fact. That's slated for the next contract, and it will ship as an addition or not at all.
Gap three, closed — by refusal
Which brings back the second device.
The honest reason to buy it was never security — a testnet vault behind an encrypted keystore and a paper passphrase loses nothing real either way. The reason was symmetry: close the "one vault, not two" line with hardware on both sides of the duel.
Two findings killed it. First, the demo it would produce already exists at scale: Agent Stack opened after a private preview with over a thousand agents, and Ledger's student challenge collected fifty submissions from thirty-eight universities in eight days whose entry-level track was precisely wire the kit into an agent and end the signing flow on the device. A second agent on a second device is the market's canonical demo, times two. It proves nothing that isn't already proved — including by my own July 15 transactions.
Second, and this is the one that actually settled it: the blocker was never hardware. My signer carries two deliberate guards — it refuses to run with more than one device attached, and it derives the expected signing address from the function being signed, in code, on my machine. A hardware-symmetric duel would mean removing the first guard and letting a server-side result decide which vault signs — widening the trusted surface of the one component this whole architecture exists to keep narrow. I would have degraded the signer's threat model to purchase a symmetry photo.
So the vault I didn't move stays unmoved — no longer as an admitted gap, but as a decision with its reasoning on the table. The two-key pattern doesn't require every vault to be hardware. It requires that the engagement of funds carries a human, and that whatever verifies the bytes is independent of the host that signs. One agent demonstrates that on silicon. The other demonstrates that the pattern also holds without it. That asymmetry is information, not debt.
The loop, third pass
First post: publish the falsifiable model. Second: a stranger breaks it, ship the correction. Third, this one: before buying the obvious next thing, count. Two measurements — one on-chain event where the narrative said "about ten bids," two device screens where the roadmaps say "envelope" — were enough to cancel a purchase, close a gap by argument instead of hardware, and answer the open question from my own comment section: throughput was never this design's bottleneck, so nothing about the independent verifier has to be given up.
One claim to leave falsifiable, stated narrowly. The mandate mechanism exists as proposals — ERC-8226 is the closest neighbor, and it defines the format well. What I have not found shipped anywhere is the assembled chain: a bounded agent mandate, signed on the human's personal hardware device, displayed in clear by that device, and enforced by a public contract anyone can read. I've now measured that every ingredient exists. If you know of the assembled chain shipped in production, the comment box below has a good track record of correcting me — and when I build it, it will be as a ceiling on top of the human gesture, never instead of it.
Credit where it's due: agents propose, humans approve, hardware enforces is Ledger's doctrine, and the whitelist screen that refused my contract is their guardrail doing its job for people who will never read this.
Built solo. Claude Code is my engineering team — A Claude chat instance is my architect and auditor, told to contradict me; this week it canceled a purchase I'd already justified. Both curator agents run on the Anthropic API. Nothing in this post was signed on a funded account, and nothing was broadcast.
- Project: nexus-art.org
- Code: github.com/avp9-nexus/nexus-art
- The duel (
tokenId 23) and the hardware solo cycle (tokenId 25) are verifiable on Base Sepolia — testnet, no real value at stake, by design.
Top comments (0)