What Is ERC-8128? How Ethereum Wallets Can Authenticate HTTP Requests

The way we prove identity on the internet is overdue for an upgrade. Passwords get leaked, API keys get stolen, and OAuth flows add layers of complexity that frustrate both developers and users. ERC-8128 proposes something different: using your Ethereum wallet to sign and authenticate HTTP requests directly.

This draft Ethereum Request for Comment standard bridges a gap between onchain identity and the traditional web. Instead of relying on centralized credential systems, ERC-8128 adapts the IETF's HTTP Message Signatures standard (RFC 9421) so that Ethereum accounts can serve as the cryptographic backbone for web API authentication.

For developers building in the cross-chain stablecoin ecosystem, where wallets already function as portable identity, ERC-8128 could extend that identity layer to off-chain services, APIs, and backend infrastructure.

The current state of HTTP authentication is fragmented. Most web APIs rely on bearer tokens, API keys, or session cookies, all of which share a common weakness: they're static secrets that can be intercepted, reused, or forged. If an attacker captures a bearer token, they can impersonate the legitimate user until the token expires or gets revoked.

Custom signing schemes exist, but they're proprietary and non-interoperable. As one developer noted after implementing custom API security, every vendor has their own approach, requiring different header names, different signature formats, and different canonicalization rules for each integration. GitHub signs webhook payloads with HMAC-SHA256 and a shared secret. Apple's MDM protocol uses a detached CMS signature. Each approach works in isolation but creates integration overhead at scale.

The IETF recognized this problem and published RFC 9421 in February 2024, establishing a standardized mechanism for creating, encoding, and verifying digital signatures over HTTP message components. RFC 9421 supports use cases where the full HTTP message may not be known to the signer and where intermediaries might transform the message before it reaches the verifier. It defines how to sign specific components of an HTTP request (the method, URL, headers, body digest) and includes metadata like creation timestamps and expiration times.

RFC 9421 is algorithm-agnostic. It supports ECDSA, EdDSA, RSA, HMAC, and other signature algorithms. But it doesn't specify where keys come from or how identities are managed. That's the gap ERC-8128 fills.

ERC-8128 takes the HTTP Message Signatures framework from RFC 9421 and maps it to Ethereum's existing cryptographic infrastructure. At a high level, the process works like this:

A client holds an Ethereum account, which is a public-private key pair where the public key derives an Ethereum address. When the client makes an HTTP request to a server, it selects which components of the request to sign (the method, path, specific headers, content digest), constructs a signature base string according to RFC 9421's canonicalization rules, and signs it using the private key associated with their Ethereum account.

The resulting signature, along with metadata describing what was signed, gets attached to the HTTP request via the standard Signature and Signature-Input headers defined in RFC 9421. The server can then verify the signature by recovering the Ethereum address from the signature and checking it against known authorized addresses.

This approach matters because Ethereum's secp256k1 elliptic curve cryptography has a useful property: you can recover the signer's public key (and therefore their address) directly from the signature and the signed data. The server doesn't need to store or look up the user's public key in advance. It just recovers the address and checks whether that address has the appropriate permissions.

ERC-8128 doesn't exist in a vacuum. It builds on and complements several established Ethereum standards for identity and authentication.

EIP-712 (Typed Structured Data Signing) standardizes how wallets present structured data for user signatures. It's widely used in DeFi for permit-style approvals and gasless token authorization. ERC-8128 extends similar signing concepts from onchain transactions to HTTP requests.

EIP-4361 (Sign-In with Ethereum / SIWE) allows users to authenticate with web applications using their Ethereum wallets instead of passwords. SIWE handles session establishment (proving you own an address at login time), while ERC-8128 addresses ongoing request authentication (proving every individual API call comes from an authorized wallet). They serve complementary purposes: SIWE gets you through the door; ERC-8128 verifies your identity on every interaction thereafter.

EIP-1271 (Smart Contract Signature Verification) enables smart contract wallets to validate signatures, something traditional EOA-based verification can't handle. Since the modular smart account ecosystem is growing rapidly, ERC-8128 implementations would likely need EIP-1271 compatibility to support wallet abstraction use cases.

The practical applications of ERC-8128 span several domains where cryptographic identity and HTTP communication intersect.

DeFi protocols increasingly rely on off-chain infrastructure: indexers, relayers, solver networks, and intent-based execution systems. When a cross-chain intent protocol receives an order from a user, the backend services coordinating fulfillment need to verify the origin of API calls. ERC-8128 would let these services authenticate requests using the same wallet identity that holds onchain permissions, eliminating the need for separate API key management.

The emerging AI agent economy on Ethereum presents a clear need for machine-to-machine HTTP authentication. Standards like ERC-8004 register agents with onchain identities, but those agents still need to make API calls to each other and to external services. ERC-8128 could serve as the transport-layer authentication mechanism for agent-to-agent HTTP communication, where each request is signed by the agent's registered Ethereum identity.

Applications that gate access to data or content based on onchain credentials (token holdings, NFT ownership, DAO membership) currently rely on session-based authentication after an initial SIWE login. ERC-8128 would allow stateless, per-request verification. A user requesting premium content could sign each HTTP request with their wallet, and the server could verify both the signature and the user's onchain holdings without maintaining session state.

When onchain events trigger off-chain notifications (bridge completions, settlement confirmations, transaction status updates), the receiving service needs to verify the callback's authenticity. Currently, each protocol implements its own webhook signing scheme. ERC-8128 would standardize this, allowing any Ethereum-native service to verify callbacks using wallet-based signatures.

Understanding where ERC-8128 sits relative to existing authentication mechanisms helps clarify when it makes sense to adopt.

OAuth 2.0 / OIDC relies on centralized authorization servers that issue tokens. These work well for traditional web applications but introduce dependency on the authorization server's availability and trustworthiness. ERC-8128 removes the central issuer entirely; the Ethereum blockchain itself serves as the identity layer.

mTLS (Mutual TLS) provides transport-level authentication using X.509 certificates. It's well-established but requires certificate management infrastructure (CAs, revocation lists, certificate rotation). ERC-8128 avoids this by using Ethereum addresses as identifiers, with key validity checkable onchain.

GNAP (RFC 9635), the Grant Negotiation and Authorization Protocol finalized in October 2024, already supports HTTP message signatures as one method for client authentication. ERC-8128 could integrate with GNAP to provide Ethereum-native client identity within the broader authorization framework.

For applications already operating in the Ethereum ecosystem, where users have wallets and services interact with smart contracts, ERC-8128 offers the most natural fit. For traditional web applications with no blockchain component, OAuth and mTLS remain more practical choices.

Cross-chain protocols introduce unique authentication challenges. When stablecoins move between networks through intent-based execution systems, the off-chain components (solvers, relayers, quote providers) need robust authentication. A solver submitting a fill to a cross-chain bridge should be cryptographically identifiable, and ERC-8128 could standardize how these participants authenticate their HTTP-based communications.

Consider a practical scenario: a solver monitors multiple chains for profitable cross-chain intents. It communicates with quote aggregators, liquidity sources, and settlement APIs, all via HTTP. Currently, each of these services implements custom authentication. With ERC-8128, the solver could sign every request with its onchain identity, and each service could verify the solver's authorization by checking its address against an onchain registry or smart contract.

This pattern extends naturally to any cross-chain token standard that requires off-chain coordination. As the ERC-7683 cross-chain intents standard gains adoption, standardized HTTP authentication for the off-chain communication layer becomes increasingly important.

ERC-8128 is still in draft status, which means the specification is subject to change. Developers interested in this standard should monitor the Ethereum ERCs repository and the Ethereum Magicians forum for discussion updates.

In the meantime, the building blocks are already available. RFC 9421 has mature implementations in Python, JavaScript, and other languages. Ethereum's secp256k1 signing is well-supported across every major Web3 library. The primary engineering work would involve bridging these two ecosystems: configuring an HTTP message signing library to use an Ethereum key pair and adding Ethereum address recovery to the verification step.

For teams already building with Permit2 and multichain token permissions, the mental model transfers directly. Just as Permit2 extended ERC-20 approvals with signature-based authorization, ERC-8128 extends HTTP authentication with wallet-based signatures.

What is ERC-8128?

ERC-8128 is a draft Ethereum standard that enables HTTP requests to be authenticated using Ethereum wallet signatures, building on the IETF's RFC 9421 HTTP Message Signatures specification.

How is ERC-8128 different from Sign-In with Ethereum (SIWE)?

SIWE (EIP-4361) handles session establishment, proving wallet ownership at login. ERC-8128 handles per-request authentication, cryptographically signing each individual HTTP request. SIWE is the front door; ERC-8128 verifies identity on every interaction.

Is ERC-8128 production-ready?

No. ERC-8128 is currently in draft status. The specification may change, and there are limited implementations available. Teams should monitor its progress but not depend on it for production systems yet.

Does ERC-8128 work with smart contract wallets?

The standard can be extended to support smart contract wallets through EIP-1271, which defines how contracts verify signatures. This is important as account abstraction and modular smart accounts gain adoption.

What are the performance implications of ERC-8128?

ECDSA signature verification is computationally more expensive than bearer token validation. For most API use cases, the overhead is negligible. For extremely high-throughput services (tens of thousands of requests per second), the additional computation should be benchmarked.

How does ERC-8128 handle key rotation?

Key rotation would be managed at the application level, similar to how Ethereum accounts are managed today. For smart contract wallets, key rotation can be handled onchain through the wallet's built-in key management features.