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

Source: Dev.to

Introduction

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.

Enter ERC‑8128

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.

What’s Actually Broken With How We Do Auth Today

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.

How ERC‑8128 Flips the Model

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.

When you make a request under this standard, your client attaches three additional HTTP headers:

• Signature-Input – Describes which parts of the request are covered by the signature (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.

The server receives these headers, resolves your Ethereum address from the keyid in the Signature-Input (formatted as erc8128::), 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.

Replay Attacks and Nonces

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:

1. Timestamps / TTLs can be included in the signed components, so an old request automatically expires.
2. 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 trade‑off 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.

The Bigger Picture: ERC‑8128 + ERC‑8004

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.

Applications Enabled by ERC‑8128

• API billing per request – An API can verify the signature and settle payments on‑chain without ever managing a billing account.
• DAO tooling – Permissions can be enforced by reading on‑chain governance state.
• AI agents – An autonomous agent can carry a user’s Ethereum identity in every API call; the server resolves permissions on‑chain, so the agent never holds any credentials.

That last scenario is especially compelling as autonomous AI agents become more common. Today, an AI agent that calls APIs on your behalf either needs to store your API key (risky) or you must build a delegation system from scratch (painful). With ERC‑8128, the agent signs requests with a delegated key, and the service can verify on‑chain that you have authorized that delegation.

Where SIWE Falls Short (And Why ERC‑8128 Is Different)

If you’ve been in the Ethereum space for a while, your first instinct might be: “Isn’t this what Sign‑In with Ethereum (SIWE) 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, obtain 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.

What’s Still Being Worked Out

It would be dishonest to present this as a finished, ready‑to‑deploy standard. It’s a draft proposal with several open questions.

keyid format

The current proposal uses:

erc8128::

There’s debate about whether to reuse the existing eip155: namespace or adopt a more explicit compound format such as:

erc8128;eip155::

The namespace signals verification semantics; getting it wrong could introduce ambiguity and security issues.

Signature algorithm diversity

Ethereum accounts may eventually support algorithms beyond ECDSA (e.g., P‑256). The standard needs to handle these gracefully without creating algorithm‑confusion vulnerabilities.

Replay‑protection trade‑off

Should strict nonce enforcement be mandatory for compliance, or can a TTL‑only approach be considered a valid (though weaker) implementation? This is still under discussion.

These are not deal‑breakers—they’re the kind of details that get hashed out during the ERC process. If you’re building on this today, keep in mind the spec could still change.

My Take

I think ERC‑8128 addresses 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 we’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 only as a security improvement but also as a conceptual one:

• Credential‑based: Identity is granted by the server.
• Signature‑based: Identity is something you already possess—your private key—and the server simply verifies it.

That aligns philosophically with how Ethereum works on‑chain, and bringing it to the HTTP layer feels like a natural evolution rather than a bolt‑on.

Whether it gets adopted widely will depend on factors such as wallet support, developer tooling, client‑library implementations, and whether the ecosystem converges on this standard versus alternatives. The proposal is thoughtful, the use cases are real, and the timing feels right given the rise of AI agents and autonomous systems.

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.