The most dangerous signature is the one you cannot read.
I learned this the hard way in 2017, four months into an ethical audit of three ERC-20 projects in Cape Town. One of the wallets I was testing showed me a hardware screen with nothing but a 64-character hash. No recipient. No amount. No token. Just noise, dressed up as confirmation. The user tapped "approve." I watched a reentrancy vector drain a test balance seconds later, and I understood something that has never left me: the entire security model of self-custody rests on a human being confirming something they cannot possibly verify.
That gap — between what you sign and what you mean — is the wound Ethereum is now trying to close. A proposal circulating in the ecosystem claims that native transaction assertions could "enhance transaction security" and "reduce dependence on wallet interfaces." The headlines are already calling it a cure for blind signing. The reality, as always, is more interesting, and far less settled.
Let me be precise about what blind signing actually is, because the term gets flattened into a buzzword. When you sign a transaction on a Ledger or a Trezor, the device is deliberately dumb. It has no screen real estate and no semantic parser. It cannot tell you that you are approving an unlimited USDC allowance to a contract you have never seen. So it shows you a hash, and you trust the computer you plugged it into. That is blind signing: consent without comprehension.
The industry has spent years attacking this from one direction. ERC-7730, the "clear signing" standard, tries to teach wallets to render human-readable intent — "you are sending 100 USDC to Alice." Account abstraction, via ERC-4337 and EIP-7702, tries to make wallets programmable so they can enforce rules before signing. Both are worthy. Both share a hidden assumption: that the fix lives at the edge, in the client, in the interface.
The new proposal flips that assumption. If the reporting is accurate, it suggests that a transaction could carry its own assertions — declarative pre- and post-conditions that the execution layer checks. "This call may transfer no more than X tokens." "After this call, this balance must be at least Y." If reality deviates, the transaction reverts. Instead of making the user understand, the protocol refuses to let the outcome betray them.
Here is where I have to trace the code back to the conscience behind it, because the architecture tells you what the builders actually believe about human beings.
The first thing to notice is what "assertion" implies about trust. Today, the trust chain runs from user to wallet to RPC to node to EVM. Every link is a place where a malicious or compromised party can lie about what a transaction will do. An assertion collapses part of that chain. It says: we will not ask the user to trust the simulation. We will make the EVM itself the arbiter. That is a philosophical shift from "inform the human" to "protect the human from the human's own limits."
That is not a small idea. It is, in fact, an admission that the last eight years of security UX have largely failed the least technical users. And it rhymes, uncomfortably, with something Solana already does. Solana's transaction model has long supported compute-unit budgets and pre/post-condition-style constraints baked into how transactions execute. If Ethereum ships native assertions, it will not be leading. It will be catching up — and I want to say that plainly, because the evangelist's temptation is always to frame every Ethereum move as pioneering.
The second thing to notice is the proposal's most politically loaded claim: that it would reduce dependence on wallet interfaces. Read that sentence twice. It is not a technical footnote. It is a redistribution of responsibility. Under the current model, the wallet is the last line of defense — MetaMask, Ledger, Rabby, and the transaction-simulation startups like Blockaid and Tenderly all sell security at the interface layer. Move the guarantee down into the protocol, and you have quietly devalued the interface. You have moved safety from a product you buy to a property of the chain itself.
I find that deeply attractive on principle. Safety should not be a premium feature. The artist selling her first NFT should not need a $200 hardware wallet and a PhD in calldata to avoid getting drained. Artists own their pixels; we just hold the keys — and too often, the keyholder is the one who loses everything.
But attractive on principle is not the same as sound in practice, and this is where my audit instincts kick in.
Let me apply the pragmatism test, because the bull market is already treating this proposal as delivered infrastructure, and it is nothing of the sort.
First, the information itself is thin to the point of being a warning sign. The reporting says "Ethereum proposes" — but Ethereum does not propose anything. People propose things, through the EIP process, with a number, an author, a discussion thread, and a grueling march through All Core Devs calls that takes one to three years and kills most proposals along the way. A claim attributed to a faceless "Ethereum" is a claim you cannot evaluate. There is no mechanism, no testnet, no client implementation. When a security promise arrives without an author's name attached, treat it as a rumor with good branding, not a roadmap.
Second, the cognitive trap. Any mechanism that "backstops" the user invites the user to stop paying attention. This is the oldest failure mode in security UX, and I have watched it kill people's savings. If users believe assertions make them safe, they will sign more recklessly — and the assertions, being declarative, will cover only the scenarios their authors imagined. The attacker does not need to defeat the assertion. The attacker needs to find the transaction shape the assertion never anticipated. False safety is more dangerous than acknowledged risk, because it removes the caution that was doing the real protecting.
Third, the incentive problem nobody wants to say out loud. If protocol-level assertions work, the differentiating value of a "secure signing" wallet evaporates. Some of those teams will resist, quietly, in standards discussions. And the biggest silent winners may not be Ethereum at all — they may be the custodians like Fireblocks, who need auditable, machine-checkable transaction intent to satisfy the compliance regimes they answer to. This proposal may not be a gift to users. It may be a gift to institutions wearing a user-protection costume.
I say this with love for the ecosystem that raised me. Open source is not a license; it is a promise. And a promise to protect users is only as good as the mechanism that keeps it — not the press release that announces it.
So where does that leave us? Not with a cure, but with a direction worth guarding.
The right question is not "does Ethereum solve blind signing?" It does not, not yet, not even close. The right question is whether the ecosystem is finally willing to admit that the answer to a human problem is not always a better interface — sometimes it is a protocol that refuses to let the human fail. That is a humbler, more honest ambition than the last decade of "just read the screen" advice.
My hope is narrow and specific: that whoever is actually behind this proposal steps forward with a number, a name, and code. Then we can audit it. Then we can argue about it in the open, the way this community is supposed to. Until then, keep reading every signature you can, keep your hardware wallet's screen in your field of vision, and remember that education is the only true decentralized currency — the one no assertion can backstop for you.
Every line of code is a hand extended in trust. Let us make sure this one is actually reaching toward us, and not past us.