# Sign-In with Ethereum: what a wallet login proves Sign-In with Ethereum uses a structured message and wallet signature to authenticate control of an Ethereum account to a service. EIP-4361 includes the requesting domain, URI, chain ID, nonce and issue time so the verifier can bind the signature to a particular login context. A valid login does not by itself prove a real-world identity or make the service trustworthy. Evidence: [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) Canonical: https://degreesofsatoshi.com/encyclopedia/sign-in-with-ethereum/ Published: 2026-10-02 Substantively modified: 2026-10-02 Independently verified by an automated reviewer: 2026-10-02T19:27:58.939Z Data current through: 2026-10-02 AI-assisted research and drafting with a separate automated source-verification pass; no external expert or named human review is implied. ## Key facts - **Context:** The message includes domain, URI and chain ID. ([Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361)) - **Replay protection:** A verifier checks the nonce and applicable time constraints. ([Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361)) - **Purpose:** SIWE authenticates an account for an offchain session. ([Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361)) ## Read the login context before signing EIP-4361 defines a human-readable message encoded for Ethereum message signing. The account, requested domain, resource URI and issue time are part of that message. Optional expiration and not-before fields can constrain when it is valid. The verifier must check both the signature and the message context. Recovering an address from an arbitrary signed string is not the same as fully validating a SIWE login. Evidence: [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) ## A signature for one site should not log in to another Suppose a login challenge identifies the service you intended and a fresh nonce. A second site receiving the same signature should not accept it for its own domain. A used or mismatched nonce should likewise fail the intended replay checks. This depends on correct verification by the application. A wallet’s ability to sign the message is not a guarantee that every website implements the standard correctly. Evidence: [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) ## Account authentication has limits Successful verification establishes the account authorization relevant to the message and session. It does not demonstrate a legal name, ownership of an offchain item or that the site’s later transaction requests are safe. Distinguish the sign-in message from other signatures. A later permit, order or transaction can grant asset-related authority even if the first interaction was only a login. Evidence: [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361); [Ethereum security and scam prevention](https://ethereum.org/en/security/) ## Questions ### Does a SIWE login normally send an Ethereum transaction? The standard authenticates through an offchain signed message and verification. That login signature is separate from a transaction submitted for onchain execution. Evidence: [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) ### Can a contract account use Sign-In with Ethereum? EIP-4361 includes contract-account verification considerations. The verifier must use the account’s applicable validation method and the chain specified in the message. Evidence: [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) ## Claims and scope ### sign-in-with-ethereum-quick-answer Sign-In with Ethereum uses a structured message and wallet signature to authenticate control of an Ethereum account to a service. EIP-4361 includes the requesting domain, URI, chain ID, nonce and issue time so the verifier can bind the signature to a particular login context. A valid login does not by itself prove a real-world identity or make the service trustworthy. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### sign-in-with-ethereum-fact-context Context: The message includes domain, URI and chain ID. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### sign-in-with-ethereum-fact-replay-protection Replay protection: A verifier checks the nonce and applicable time constraints. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ### sign-in-with-ethereum-fact-purpose Purpose: SIWE authenticates an account for an offchain session. Scope: {"collection":"ethereum","dataAsOf":"2026-10-02","blockHeight":null} ## Sources - [Sign-In with Ethereum](https://eips.ethereum.org/EIPS/eip-4361) — Ethereum Improvement Proposals. Domain, URI, chain ID, nonce and time-bound authentication sessions. Locator: Message format; verifying messages; security considerations. Retrieved: 2026-10-02T18:55:24.817Z. - [Ethereum security and scam prevention](https://ethereum.org/en/security/) — ethereum.org contributors. Primary community guidance on wallet secrets, phishing, malicious sites and transaction checking. Locator: Wallet security; common scams; hardware wallets. Retrieved: 2026-10-02T18:55:24.140Z. ## Revision history - 2026-10-02: First publication after primary-source research and separate automated verification. ## Cite this entry Degrees of Satoshi editorial project. “Sign-In with Ethereum: what a wallet login proves.” Published 2026-10-02; updated 2026-10-02. https://degreesofsatoshi.com/encyclopedia/sign-in-with-ethereum/