A Review of ERC-8128

What does it truly mean for crypto to scale?

I believe it does not merely mean processing a greater number of transactions; rather, it means that an crypto account begins to function naturally as a default unit of identity on the web.

Today’s architecture remains fragmented. We settle on-chain payments through wallets, yet authenticate off-chain API calls through separate logins and API keys. The layers are divided, identity is fragmented, and authority and settlement reside in entirely different systems. The result is not a unified trust model, but a stack of loosely connected mechanisms.

If a single Ethereum account could coherently anchor web requests, authorization checks, and payments, then permissionless interaction across layers—spanning both on-chain and off-chain environments—would become possible.

ERC-8128 represents precisely this attempt: "to implement that transition at the HTTP layer".

Traditional HTTP authentication, by contrast, relies on server-issued secret credentials - JWTs and API keys can be reused if compromised; session-based models require server-side state; OAuth depends on centralized identity providers and complex handshakes.

Ultimately, the trust model hinges on how securely those secrets are stored and managed.

ERC-8128 inverts this paradigm - instead of relying on server-issued shared secrets, the client signs each HTTP request directly with its Ethereum key, while the server merely verifies the signature. Authentication shifts from a credential-issuance model to a cryptographic proof model—request-bound, explicit, and independently verifiable.

The structure is deliberately simple:

┌─────────────┐    Signed Request     ┌─────────────┐
│   Client    │ ───────────────────▶  │   Server    │
│  (signer)   │  Signature-Input      │ (verifier)  │
│             │  Signature            │             │
│             │  Content-Digest       │             │
└─────────────┘                       └─────────────┘
       │                                     │
       │ Signswith ETH key                   │ Verifies signature
       ▼                                     ▼
┌─────────────┐                       ┌─────────────┐
│    EOA      │                       │  ecrecover  │
│     or      │                       │     or      │
│    SCA      │                       │  ERC-1271   │
└─────────────┘                       └─────────────┘

Source: http://erc8128.slice.so

For smart contract accounts, verification is performed via ERC-1271’s isValidSignature() interface; for EOAs, signature recovery (e.g., ecrecover) suffices. Replay attacks may be mitigated through nonce tracking or TTL enforcement.

Crucially, authentication becomes effectively stateless, and the server no longer needs to issue, rotate, or store secrets.

The architecture becomes even more expressive when combined with ERC-8004:

[Agent / Human / Backend]
   └─ (ERC-8128) Signed HTTP Request
        → Service-side verification layer
             ├─ Cryptographic signature validation
                 (EOA via ERC-191, SCA via ERC-1271)
             ├─ Replay protection (nonce tracking / TTL constraints)
             └─ On-chain state resolution via ERC-8004
                 (reputation, roles, permissions)
                    → Policy evaluation and enforcement
                        (rate limits, pricing, access control, delegation)
                         → Service execution
                              → Optional on-chain settlement

If ERC-8128 proves that “this request originated from this address,” ERC-8004 defines “what that address is allowed to do.” Authentication and authorization thus converge into a single address-based flow, extending naturally into execution and, where relevant, settlement.

Whether the actor is an agent, a human user, or a backend system, policy enforcement and service interaction occur on top of the same cryptographic identity.

In this sense, the significance of ERC-8128 extends far beyond improving login UX. It represents an infrastructural shift—one that elevates the Ethereum account into a native web identity primitive. The same address used for on-chain payments can authenticate off-chain API calls; servers, in turn, can resolve on-chain state to determine eligibility and permissions. Without separate login layers, token issuance, or session management, a single cryptographic identity binds interactions across layers.

By inserting a cryptographic identity layer directly into Web2 infrastructure, ERC-8128 proposes a model in which on-chain and off-chain systems are no longer isolated domains but components of a unified trust fabric—one that enables, at least in principle, permissionless interaction across layers.