# ERC-4361: Sign-In with Ethereum (SIWE)

Source: https://www.eipsfordesigners.com/standards/ERC-4361
Agent brief: https://www.eipsfordesigners.com/standards/ERC-4361/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/ERC-4361
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Final |
| Chain | both |
| Category | Onboarding & Access |
| Journey stages | Authentication & Identity |
| Detailed guide | Yes |
| Official specification | https://eips.ethereum.org/EIPS/eip-4361 |
| Discussion search | https://ethereum-magicians.org/search?q=ERC-4361 |

## UX Impact

Users sign in to websites using their Ethereum wallet instead of email/password — self-custodied identity with no centralized IdP. Design implications: display human-readable SIWE message showing domain, statement, URI, chain ID, nonce, and expiration; design clear 'Sign-In with Ethereum' buttons distinct from transaction signing; show ENS names and avatars when available; implement session management with expiration handling. Design decisions: decide session duration and refresh strategy, choose between auto-login for returning users vs explicit sign-in, design account switching when user changes wallet address, handle signature rejection gracefully without breaking auth flow, consider showing resources array for granular permission requests.

## Summary

ERC-4361 is "Sign-In with Ethereum" (SIWE). Instead of email/password, users sign a message with their wallet to authenticate. The signature proves wallet ownership without revealing private keys. One wallet = one identity across all supporting apps. No more managing dozens of passwords.

## For Designers

- You can design UI that delivers sign message with wallet = instant authentication.
- You can design UI that delivers no password stored anywhere, cryptographic proof.
- You can design UI that delivers human-readable message: "Sign in to app.com at [time]".

## Applicability

### When to Use

- Your product addresses: every app needs separate account/password.
- Your product addresses: password reuse and database breaches.
- The flow should deliver: sign message with wallet = instant authentication.
- You are designing a sign-in with ethereum button experience with visible states and recovery paths.

### When to Avoid

- Server verifies domain in message matches request origin.
- Clear statement: "Sign in to [app name]".
- Set reasonable expiration, re-authenticate periodically.
- Wallet or chain support is fixed and users cannot choose providers.

## Problems It Solves

### Every app needs separate account/password

Impact: critical

Old way: Create account, verify email, remember password, repeat for every site

New way: Sign message with wallet = instant authentication

### Password reuse and database breaches

Impact: high

Old way: Passwords stored (hashed) on servers, can be breached

New way: No password stored anywhere, cryptographic proof

### Sign-in requests looked like random data

Impact: high

Old way: Sign "0x4f8a3b..." — what does this even mean?

New way: Human-readable message: "Sign in to app.com at [time]"

## Anti-Patterns

### Not verifying domain matches

Severity: critical

Phishing sites could capture signatures

Instead: Server verifies domain in message matches request origin

### Unclear message statement

Severity: high

Users sign without understanding what they're agreeing to

Instead: Clear statement: "Sign in to [app name]"

### No session expiration

Severity: high

Session lives forever, security risk

Instead: Set reasonable expiration, re-authenticate periodically

### Making SIWE the only auth option

Severity: medium

Not everyone has a wallet yet

Instead: Offer email/social as alternatives for onboarding

## UI Components

### SIWEButton

Primary sign-in with Ethereum button
States: idle, connecting, signing, authenticated, error
Props: onAuth, domain, statement

### SessionIndicator

Shows authenticated state with session info
States: anonymous, authenticated, expired
Props: address, expiresAt, onSignOut

### DomainBadge

Verified domain indicator in sign message
States: verified, mismatch, unknown
Props: domain, expectedDomain

## On Monad

### Signature Verification

Ethereum: Chain ID 1 in message

Monad: Use Monad chain ID in message

Design implication: Update chain ID in SIWE message for Monad users

## Key Takeaways

- SIWE = "Sign in with Ethereum" — wallet-based auth
- Messages must be human-readable with clear statement
- Always verify domain matches to prevent phishing
- Set session expiration for security
- Offer alternatives for users without wallets

## UX Patterns

### Sign-In with Ethereum Button

One-click authentication with wallet

User flow:

- User clicks "Sign in with Ethereum"
- Wallet shows sign message popup
- User reads and approves message
- Server verifies signature
- User authenticated + session created

Mockup registry key: `concept/siwe-sign-in` (React UI on the live standard page).

### SIWE Message Preview

What users see in wallet when signing

User flow:

- App generates SIWE message
- Wallet displays formatted message
- User verifies domain matches
- User clicks Sign
- Signature returned to app

Mockup registry key: `concept/siwe-sign-in` (React UI on the live standard page).

## Technical Notes

ERC-4361 defines a message format parsed by wallets: domain, address, statement, URI, version, chain ID, nonce, issued-at, and optional expiration/not-before/resources. Server generates message, user signs with personal_sign, server verifies signature matches address in message and nonce matches stored nonce.