Tools: ERC-8128: Your Ethereum Wallet Might Soon Be Your Only Login.

Enter ERC-8128 ## What's Actually Broken With How We Do Auth Today ## How ERC-8128 Flips the Model ## Replay Attacks and Nonces ## The Bigger Picture: ERC-8128 + ERC-8004 ## Where SIWE Falls Short (And Why ERC-8128 Is Different) ## What's Still Being Worked Out ## My Take Let me start with something that's been bugging me for years. I work with APIs constantly. And every time I spin up a new project that touches any kind of Web3 functionality, I end up doing this awkward dance — my users authenticate on-chain with their wallets, and then I also have to issue them a JWT or an API key to handle the off-chain stuff. Two separate identity systems. Two separate trust models. Two separate things that can break. It feels wrong. And apparently, I'm not the only one who thinks so. In January 2026, a proposal quietly landed in the Ethereum ERCs repository that, if it gains traction, could fundamentally change how we think about authentication in Web3 apps. ERC-8128 proposes a standard for signing HTTP requests using Ethereum accounts. Not just signing a login message once (that's what Sign-In with Ethereum does). Not just proving wallet ownership. Every. Single. HTTP request — signed with your Ethereum key, verified by the server, no stored credentials involved. The spec is built on top of RFC 9421, which is the IETF's standard for HTTP Message Signatures. So this isn't reinventing the wheel from scratch. It's taking a well-established web standard and giving it a cryptographic backbone powered by Ethereum accounts. Before getting into the mechanics, it's worth thinking about why this matters. Traditional HTTP authentication has a fundamental flaw baked into its design: it's credential-based. Whether you're using API keys, JWTs, sessions, or OAuth, the underlying model is the same — a server issues you a secret, you present that secret with future requests, and the server trusts you because you have the secret. The problem is obvious once you say it out loud: secrets can be stolen and reused. JWTs get intercepted in transit. API keys get committed to GitHub. OAuth tokens get exfiltrated from browser storage. When that happens, an attacker doesn't need to be you — they just need to have your credential. The server can't tell the difference. Session-based auth has the additional problem of requiring server-side state. Your auth system now has to maintain a database of active sessions, which becomes a single point of failure and a scaling headache. OAuth is arguably the most sophisticated of these approaches, but it introduces a dependency on centralized identity providers and a frankly gnarly authorization flow that I've had to re-learn from scratch every time I implement it. Instead of the server issuing credentials that the client presents later, ERC-8128 makes the client sign each request directly with its private key. The server just verifies the signature. Here's what that looks like in practice. When you make a request under this standard, your client attaches three additional HTTP headers: The server receives this, resolves your Ethereum address from the keyid in the signature input (formatted as erc8128:<chainId>:<address>), and verifies the signature against it. For regular externally-owned accounts (EOAs), this is just ECDSA signature recovery — the same thing that happens on-chain when you submit a transaction. For smart contract accounts (SCAs), verification goes through ERC-1271's isValidSignature() interface, which means account abstraction wallets, multisigs, and other sophisticated account types all work natively. The thing I keep coming back to is this: the server never stores anything about you. No credential database. No session table. No token to revoke. If you stop sending signed requests, you're simply unauthenticated. Authentication becomes a property of the request itself rather than a stateful session maintained somewhere. The obvious question at this point is: what stops someone from intercepting a signed request and replaying it? ERC-8128 addresses this in a couple of ways. First, timestamps and TTLs can be included in the signed components, so an old request automatically expires. Second, nonces can be included to make each request a single-use authorization — if a verifier tracks seen nonces, replaying a captured request will fail. There's actually an interesting open question in the proposal around this. Strict nonce-based replay protection requires the server to maintain state (a set of seen nonces), which conflicts with the otherwise stateless nature of this auth model. The proposal acknowledges this tension: you can have strong replay protection or easy horizontal scaling, and the tradeoff is explicit rather than hidden. I appreciate that the authors are being upfront about this rather than pretending it's solved. It's one of the open questions listed in the Ethereum Magicians discussion thread, and it's the kind of thing that will probably get worked out through real-world implementation feedback. Here's where things get genuinely exciting for anyone building Web3 applications. ERC-8128 answers one question: "did this request come from this Ethereum address?" But paired with ERC-8004, it can answer a second question too: "what is this address allowed to do?" ERC-8004 is a proposal for on-chain state resolution — things like reputation, roles, and permissions associated with an address. When you combine the two, you get a full authentication and authorization flow anchored to a single cryptographic identity, with authorization rules living on-chain where they're transparent and auditable. Think about what this means for the kinds of applications we build: That last one is particularly interesting as autonomous AI agents become more prevalent. Right now, if you want an AI agent to call APIs on your behalf, it either needs to hold your API key (scary) or you need to build a delegation system from scratch (annoying). With ERC-8128, the agent can sign requests with a delegated key, and the service can verify on-chain that you've authorized that delegation. If you've been in the Ethereum space for a while, your first instinct here might be "isn't this what Sign-In with Ethereum already does?" SIWE is great. It solved a real problem — letting users authenticate to web apps with their wallets instead of passwords. But SIWE is fundamentally a login mechanism. You sign a message once, get a session, and from that point forward you're back in the traditional credential-based model. The session can expire or be stolen, just like a regular session. ERC-8128 doesn't replace SIWE — they solve different problems. SIWE is about the login UX. ERC-8128 is about what happens after login, at the API layer, for every subsequent request. It's designed for programmatic use, for machine-to-machine communication, for AI agents — situations where you want continuous cryptographic proof of identity rather than a one-time handshake. It would be dishonest to present this as a finished, ready-to-deploy standard. It's a draft proposal and there are real open questions. The keyid format is still under discussion. The current proposal uses erc8128:<chainId>:<address>, but there's debate about whether to reuse the existing eip155: namespace or use a more explicit compound format like erc8128;eip155:<chainId>:<address>. This matters more than it sounds — the namespace signals verification semantics, and getting it wrong introduces ambiguity that could cause security issues down the line. There's also the question of what happens when EOAs start using signature algorithms other than ECDSA. Ethereum's account model might eventually support P-256 or other curves, and the standard needs to handle that gracefully without creating algorithm confusion vulnerabilities. And there's the replay protection tradeoff I mentioned earlier — whether strict nonce enforcement should be mandatory for compliance, or whether TTL-only approaches can be considered a valid (if weaker) implementation. These aren't dealbreakers. They're exactly the kind of things that get hashed out in the ERC process. But if you're considering building on this today, keep in mind that the spec could still change. I think ERC-8128 is solving a real problem in a clean way. The insight that HTTP Message Signatures (an existing IETF standard) is the right layer to attach Ethereum authentication to is smart — it means you're not asking the web to adopt an entirely foreign concept, just extending something that already exists. The shift from credential-based to signature-based authentication is genuinely meaningful. Not just as a security improvement, but as a conceptual one. In a credential-based system, identity is something the server grants you. In a signature-based system, identity is something you already have — your private key — and the server just recognizes it. That's philosophically aligned with how Ethereum works on-chain, and bringing it to the HTTP layer feels like a natural evolution rather than a bolted-on addition. Whether it gets adopted widely depends on a lot of factors — wallet support, developer tooling, client library implementations, and whether the ecosystem converges on this standard versus something else. But the proposal is thoughtful, the use cases are real, and the timing feels right given where AI agents and autonomous systems are heading. Worth keeping an eye on. The ERC-8128 draft is available on GitHub and the discussion is ongoing in the Ethereum Magicians forum. If you have thoughts or implementation feedback, now is the time to get involved — this is the stage where community input actually shapes the spec. Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse - Signature-Input: Describes which parts of the request are covered by the signature (the method, path, headers, body hash, timestamps, etc.) - Signature: The actual cryptographic signature over those components - Content-Digest: A hash of the request body, ensuring it can't be tampered with in transit - An API that charges per-request could verify the signature and settle payments on-chain without ever managing a billing account - A DAO tooling platform could enforce member permissions by reading on-chain governance state - An AI agent acting on behalf of a user could carry the user's Ethereum identity in every API call it makes, with servers resolving permissions without the agent needing to hold any credentials