Sign-In with Ethereum (SIWE): How Wallet Login Works and What to Verify

A site asks you to connect your wallet, then presents a message to sign. No gas fee appears and no transaction is broadcast. Is this merely login, or are you granting something more? Sign-In with Ethereum (SIWE) gives wallet login a standard format, but you still need to read the request. This guide adds that skill to your crypto wallet security toolkit.

Educational only, not financial advice (NFA). A valid login format does not prove that a website, wallet, or session is safe. Verify the domain and message yourself, protect your keys, and always DYOR.

What Sign-In with Ethereum Is

Sign-In with Ethereum is the common name for ERC-4361, a standard for authenticating an Ethereum account to an off-chain service. Instead of creating a password, you prove control of an address by signing a structured message in your wallet. The service verifies that signature and can then create an ordinary web session, often represented by a cookie.

Think of it as showing a signed visitor pass at a reception desk. The pass names the building, the holder, when it was issued, and a one-use serial number. The receptionist checks the signature and the details, then gives you a temporary badge. Your wallet signature is the pass; the website session is the badge.

SIWE is authentication, not a blockchain transaction. Signing the message normally costs no gas and does not itself transfer tokens. That distinction is useful, but “no gas” never means “no risk.” A phishing page can still request a deceptive signature or use a valid login to access private account data.

How the SIWE Login Flow Works

The ethereum.org authentication guide describes the core wallet-login sequence. In a standards-compliant SIWE flow:

1. The site asks your wallet for a public Ethereum address.
2. The service creates a SIWE message containing the expected domain, address, chain ID, nonce, and issue time, plus optional limits.
3. Your wallet shows the message and signs it locally with the account key after you approve.
4. The site receives the message and signature, verifies both, and confirms that the challenge matches what it issued.
5. If verification succeeds, the site establishes a session bound to the Ethereum address.

The private key never needs to leave the wallet. The signature is evidence that the account approved this specific challenge. It is not a password that the service can later type elsewhere.

For an externally owned account (EOA), ERC-4361 uses the ERC-191 signed-message method. A smart-contract account may be verified through ERC-1271 on the chain named in the message. Because contract signatures can depend on changing on-chain state, services need session rules that account for that behavior.

The Fields You Should Read

A SIWE prompt is designed to be machine-readable and understandable to a person. Its fields define who is asking, which account is responding, and how the challenge is scoped.

Field	What it tells you	What to verify
Domain	The service requesting login	It matches the site open in your browser
Address	The account being authenticated	It is the wallet/account you intended to use
Statement	A human-readable purpose or terms	It matches the action you expected
URI	The resource that is the subject of login	It belongs to the expected service
Chain ID	The network context	It is reasonable for the account or smart wallet
Nonce	A unique challenge	The request is fresh, not a copied old prompt
Issued At	When the message was created	It is close to your current login attempt
Expiration / Not Before	Optional validity window	The session request is not stale or premature
Resources	Optional referenced permissions or resources	Every URI is expected and understandable

ERC-4361 requires a domain, address, URI, version, chain ID, nonce, and issue time. The nonce must contain at least eight alphanumeric characters, but length alone is not enough: the server must issue and validate it correctly.

Wallets implementing the standard are expected to compare the request origin with the scheme and domain in the message. That domain binding is a central phishing defense. If your browser shows example.net while the message says example.com, reject it.

Why the Nonce and Domain Matter

A signature remains mathematically valid after it is created. Without a fresh challenge, someone who captures an old login message could try to submit it again. The nonce acts like the one-use serial number on the visitor pass: the service should accept the expected value once, then retire it.

The official SIWE security considerations say the nonce should have enough entropy for the use case and the server should assert that it matches the expected value. The backend must also validate the message it actually received, not merely check that a signature recovers some address.

Domain binding answers a different question: where was the pass meant to be used? A signature requested by a look-alike phishing domain should not authenticate to the legitimate service. Wallet and server checks work together here. A readable domain helps you notice a mismatch, while strict implementation prevents the service from accepting the wrong challenge.

What SIWE Does Not Authorize by Default

ERC-4361 standardizes authentication. It does not, by itself, define permission to spend tokens, execute a swap, approve an operator, or access every server resource. The specification explicitly separates authentication from authorization.

That means a normal SIWE message should look like a login challenge, not a token permit or contract call. If a site labels a request “sign in” but the wallet displays an approval, transfer, permit, or opaque typed-data payload, stop. Compare it with the expected SIWE fields and use clear-signing checks before approving anything.

The optional Resources section deserves attention. It lists URIs associated with the authentication request, but ERC-4361 does not itself define what each URI authorizes. Read every item and rely on the service’s clear, current documentation for its meaning.

Risks and Limitations

Phishing remains possible

A familiar phrase such as “wants you to sign in” is not proof of conformance. ERC-4361 recommends that wallets warn when this phrase appears in a malformed message. You should independently verify the browser domain and reject mismatches, unexpected subdomains, or unsolicited QR-code requests.

One address can become a tracking identifier

Reusing the same public address across services lets those services—and outside observers—correlate activity. ENS names, token holdings, NFTs, and public transactions may reveal more context than an email alias would. Consider a separate account for public logins when correlation is a concern, but manage its recovery as carefully as any other wallet.

Key loss changes account recovery

There is no automatic “forgot password” flow for a self-custodied key. A service may provide independent recovery methods, but SIWE itself proves control through the wallet. Protect the seed phrase and understand the service’s recovery policy before using wallet login as your only route to important data.

A verified login can still create a risky session

The site may mishandle cookies, keep sessions alive too long, or expose private profile data. Logging in proves control of an address; it does not audit the site’s web security or privacy practices. Sign out on shared devices and review active sessions where the service offers that control.

Smart-account validity can change

ERC-1271 verification can depend on contract state. Owners, modules, or validation rules may change after login. Services supporting contract accounts need a deliberate policy for revalidation and session invalidation.

A Safe SIWE Checklist

Before signing:

1. Open the service from a verified bookmark or official link.
2. Confirm the wallet prompt is a readable SIWE login message.
3. Match the message domain and URI to the browser origin exactly.
4. Confirm the address and chain ID you intended to use.
5. Read the statement, expiration, and every listed resource.
6. Reject any request that instead grants token, NFT, contract, or delegation authority.

After signing, use the session like any sensitive account: avoid shared devices, log out when appropriate, and revoke active sessions through the service if a device or wallet may be compromised. Disconnecting a wallet from a browser interface does not necessarily terminate an already issued server session.

Frequently Asked Questions

Does SIWE cost gas?

Normally no. It signs an off-chain message rather than sending an on-chain transaction. The website still performs server-side verification, and smart-account verification may read blockchain state, but the login signature itself does not require a transaction fee.

Can a SIWE signature move my tokens?

A conforming ERC-4361 login message is for authentication, not token spending. Still, judge what the wallet actually displays. Attackers may mislabel other signature types as login requests.

Is connecting a wallet the same as signing in?

No. Connecting usually reveals an address and allows the site to request actions. Signing a fresh SIWE challenge proves control of that address and lets the service create an authenticated session.

Why does the message include a chain ID if it is off-chain?

The chain ID supplies network context and is especially important when verifying a smart-contract account through ERC-1271. It also makes the intended context explicit to wallets and services.

Does SIWE make login private?

Not automatically. It avoids sharing a password, but a public address can link activity across apps and on-chain records. Privacy depends on address separation, what the service collects, and how it handles session data.

The Practical Takeaway

Sign-In with Ethereum turns wallet authentication into a recognizable challenge: domain, account, nonce, time, and scope. When all parties implement the standard correctly, you can prove account control without giving a website your private key or creating another password.

Treat the signature as a security decision anyway. Match the domain, inspect the scope, distinguish login from spending authority, and protect the resulting session. This guide is educational, not financial advice. Crypto and self-custody can result in total loss; verify current documentation, protect your keys, and DYOR.