Google controls the authentication layer for over 3.4 billion accounts. Every “Sign In With Google” click routes through Mountain View’s servers, generating a metadata event that records which service you accessed, when, from where, and how often. EIP-4361, the Sign-In With Ethereum specification, does not ask Google for permission to exist. It replaces the entire model.

SIWE represents more than a protocol upgrade. It is an architectural rejection of the premise that identity must be delegated to a corporation. In the 18 months since its formal adoption, SIWE-compatible authentication has appeared in over 12,000 applications, from DeFi protocols to privacy-first messaging platforms. The trajectory is not incremental. It is structural.

The Problem SIWE Solves

Centralized authentication creates a dependency graph that most users never see. When you authenticate with Google, Facebook, or Apple, three things happen simultaneously: you gain access to a service, the identity provider gains access to your behavioral pattern, and the service gains a revocable dependency on the provider’s infrastructure.

This is not a theoretical concern. In 2024, a Google OAuth outage locked users out of thousands of third-party applications for over four hours. The applications had built no authentication vulnerability into their own code. They had outsourced it to Google, and Google failed.

OAuth 2.0, the protocol underlying these “Sign In With” buttons, was designed in 2012 for a web where centralized identity providers were considered trusted intermediaries. The protocol itself is technically sound. The problem is the trust model: OAuth requires a user to prove their identity to a third party, who then vouches for them to the service. Every authentication event generates a correlation point. Over months and years, these correlation points build a comprehensive map of a user’s digital life.

SIWE eliminates the intermediary. The user proves they control a cryptographic key. No third party is consulted. No metadata is generated beyond the authentication event itself.

How EIP-4361 Works

The Sign-In With Ethereum specification, formalized as EIP-4361 by Spruce Systems and the Ethereum Foundation, defines a structured message format and verification protocol. The flow operates in four discrete steps.

Step 1: Domain Issues a Challenge

The service generates a challenge message containing the domain name, a nonce (a random value preventing replay attacks), the chain ID, and a human-readable statement. This message follows a rigid format defined in the EIP-4361 specification:

service.example.com wants you to sign in with your Ethereum account:
0x1234...abcd

I accept the Terms of Service: https://service.example.com/tos

URI: https://service.example.com
Version: 1
Chain ID: 1
Nonce: 8s2k4l0x
Issued At: 2026-03-08T10:00:00Z
Expiration Time: 2026-03-08T10:05:00Z

The message is plaintext. The user can read every field before signing. There are no hidden scopes, no background data requests, no consent buried in a modal.

Step 2: Wallet Signs the Message

The user’s wallet (MetaMask, Rainbow, Coinbase Wallet, or any EIP-1271-compatible wallet) presents the message for review. The user signs it with their private key, producing a cryptographic signature. The private key never leaves the user’s device. The signature is a mathematical proof that the holder of the private key approved the specific message content.

Step 3: Server Verifies the Signature

The service performs ecrecover on the signed message, extracting the public key and deriving the Ethereum address. If the derived address matches the address in the message, authentication succeeds. This verification is pure mathematics. It requires no API call to Google, no token exchange with Facebook, no dependency on any external service.

Step 4: Session Established

The service issues a session token (typically a JWT) and the user is authenticated. The session can be scoped to any duration. At Stealth Cloud, we issue JWTs containing only a hash of the wallet address, not the address itself, with a one-hour TTL. The session is stateless, ephemeral, and contains zero personally identifiable information.

SIWE vs. OAuth: The Structural Differences

The comparison between SIWE and OAuth is not a feature comparison. It is a comparison of trust architectures.

Identity Ownership

OAuth delegates identity to a provider. Google decides whether your account exists, whether it remains active, and what data it exposes to relying parties. Google has suspended accounts without explanation, locking users out of every service that depended on Google authentication.

SIWE derives identity from cryptographic key ownership. No entity can suspend your Ethereum address. No entity can revoke your ability to sign a message. The identity exists as long as the private key exists, and the private key exists wherever the user chooses to store it.

Data Exposure

An OAuth authentication event exposes, at minimum: email address, profile name, profile photo URL, and provider-specific identifiers. Many implementations request additional scopes: contacts, calendar data, drive contents. The user often clicks “Allow” without reading the scope list.

A SIWE authentication event exposes exactly one datum: that the signer controls the specified Ethereum address. If the address has never been used on-chain or is a freshly generated address, it reveals nothing about the user’s identity, location, or history.

Server-Side Requirements

OAuth requires the service to register with the identity provider, maintain client secrets, handle token refresh flows, and manage provider-specific edge cases. A Google OAuth integration requires network calls to Google’s servers on every authentication and token refresh.

SIWE requires the service to verify a cryptographic signature. This operation is CPU-bound, takes microseconds, and requires zero network calls to external services. It can run on an air-gapped machine. It can run in a Cloudflare Worker at the edge with sub-5ms latency.

Adoption Metrics

SIWE adoption has accelerated beyond the DeFi ecosystem. According to data from Spruce Systems and on-chain analytics:

  • Over 12,000 applications have integrated SIWE authentication as of early 2026, up from approximately 2,800 in 2024.
  • The siwe npm package averages 380,000 weekly downloads, placing it in the top 0.1% of Web3 libraries by usage.
  • Major non-crypto platforms including several enterprise SaaS providers have added SIWE as an alternative authentication method, driven by European data minimization requirements under GDPR and the emerging Swiss nFADP framework.

The enterprise adoption signal is the most significant. When regulated companies choose SIWE, they are not making a philosophical statement about decentralization. They are making a compliance calculation: SIWE authentication collects less data, which means less data to protect, report on, and potentially breach.

Privacy Properties of SIWE

SIWE’s privacy advantages are not incidental. They are structural.

No correlation across services. A user can generate a new Ethereum address for every service they authenticate with. There is no shared identifier linking their activity across applications. This is architecturally impossible with Google OAuth, where the same Google account ID appears in every relying party’s database.

No behavioral metadata. Google knows when you sign into every service that uses Google OAuth. They know the frequency, the time of day, the device. SIWE authentication is a direct client-server interaction. No third party observes the event.

No account recovery attack surface. OAuth accounts can be compromised through email account takeover, SIM swapping for SMS-based 2FA, or social engineering of the identity provider’s support team. SIWE accounts have no recovery mechanism to exploit. The private key is the authentication factor. The attack surface is the user’s key management, which they control entirely.

These properties align directly with zero-knowledge architecture principles: the system functions without requiring the server to know anything about the user’s identity beyond what is mathematically necessary.

Implementation Considerations

SIWE is not without friction. Honest analysis requires acknowledging the current limitations.

Wallet requirement. Users must have an Ethereum wallet. While browser extension wallets like MetaMask have over 100 million installations, this still represents a barrier for users unfamiliar with cryptocurrency infrastructure. Smart account wallets with social recovery (ERC-4337) and embedded wallet solutions like Privy are reducing this friction, but it has not been eliminated.

Key management responsibility. If a user loses their private key and has no recovery mechanism, they lose access to every service they authenticated with using that key. This is the inverse of the OAuth model’s centralized recovery, and it places genuine burden on the user. Hardware wallets and social recovery schemes mitigate this, but the responsibility model is fundamentally different.

Address reuse and on-chain correlation. If a user authenticates with the same Ethereum address across multiple services, and that address has on-chain transaction history, their activity can be correlated through blockchain analytics. This is why Stealth Cloud’s GhostPass system hashes the wallet address server-side and encourages the use of dedicated authentication addresses with no on-chain history.

ENS integration. ENS domains can attach human-readable names to Ethereum addresses, which enhances usability but creates a public binding between a name and an address. Users seeking maximum privacy should authenticate with addresses that have no ENS resolution.

SIWE in the Regulatory Context

The regulatory environment is shifting in SIWE’s favor, though not intentionally.

GDPR’s data minimization principle (Article 5(1)(c)) requires that personal data be “adequate, relevant and limited to what is necessary.” An authentication system that collects an email address, profile photo, and behavioral metadata when all that is needed is proof of a unique user violates the spirit, if not the letter, of this principle.

Switzerland’s revised Federal Act on Data Protection (nFADP), effective since September 2023, strengthens data minimization requirements further. Swiss-domiciled infrastructure that implements SIWE authentication is positioned to satisfy these requirements by design rather than by policy.

The tension between privacy-preserving authentication and anti-money-laundering regulations is real. Zero-KYC authentication exists in a legal gray zone in many jurisdictions. But SIWE itself is an authentication protocol, not a financial instrument. Using a cryptographic signature to prove you control a key is no different, legally, from using a password to prove you know a secret. The legal analysis changes only when the authentication is coupled with financial transactions.

The Technical Roadmap

SIWE continues to evolve. Several developments are worth tracking:

EIP-4361 v2 proposals are in discussion, adding support for session binding (linking a SIWE signature to a specific session key for delegation), resource-scoped authentication (specifying which API endpoints the signature authorizes), and cross-chain compatibility (authenticating with Solana, Cosmos, or other chain signatures using a unified message format).

CAIP-122 extends the Sign-In With Ethereum concept to a chain-agnostic standard (Sign-In With X), enabling the same authentication pattern across any blockchain. This is significant for interoperability but also for privacy: users could authenticate using privacy chains like Secret Network or Zcash where address history is shielded.

Session keys and ERC-4337 smart accounts enable delegated authentication, where a SIWE signature can authorize a session key that handles subsequent requests. This reduces the number of wallet interactions required and improves UX without sacrificing the security model.

Why This Matters Beyond Crypto

The significance of SIWE extends beyond the Ethereum ecosystem. It demonstrates a working alternative to the identity provider oligopoly. For two decades, the conventional wisdom held that authentication required a trusted third party. SIWE proves it requires only mathematics.

Every authentication system that does not require an intermediary is a system that cannot be weaponized by the intermediary. Google cannot lock you out of a SIWE-authenticated service. They cannot analyze your authentication patterns. They cannot sell your login metadata to advertisers. They cannot comply with a government request for your authentication history, because they do not have it.

This is not anti-Google rhetoric. It is an architectural observation. When authentication is a bilateral cryptographic operation between user and service, the attack surface shrinks to two parties. When it is a trilateral OAuth flow, the attack surface includes the identity provider, their infrastructure, their employees, their government obligations, and their business incentives.

The Stealth Cloud Manifesto calls this the difference between privacy by policy and privacy by architecture. Policies change. Architectures endure.

The Stealth Cloud Perspective

Sign-In With Ethereum is not a feature we adopted. It is the foundation on which GhostPass is built. Authentication should prove control of a key, not surrender control of an identity. Every “Sign In With Google” click feeds a surveillance infrastructure that has no technical reason to exist.