{"id":"ERC-4361","name":"Sign-In with Ethereum (SIWE)","status":"Final","chain":"both","category":{"id":"onboarding","name":"Onboarding & Access","description":"Getting users into web3 without friction"},"journeyStages":[{"id":"authentication","name":"Authentication & Identity","description":"Proving who you are and logging in"}],"uxImpact":"ERC-4361 defines a Sign-In with Ethereum (SIWE) message that a relying party can ask a wallet to sign. The signature proves control of the address for that message at signing time. The server still validates the domain, URI, chain ID, nonce, time bounds, and session policy before authenticating the user.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-4361","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-4361","summary":"ERC-4361 defines a Sign-In with Ethereum (SIWE) message that a relying party can ask a wallet to sign. The signature proves control of the address for that message at signing time. The server still validates the domain, URI, chain ID, nonce, time bounds, and session policy before authenticating the user.","applicability":{"whenToUse":["The relying party can generate, verify, and expire SIWE messages.","Users need an address-based sign-in path and can review the requesting domain before signing.","The product can offer another sign-in path when users do not have a compatible wallet."],"whenToAvoid":["The app cannot validate the SIWE domain, optional scheme, URI, chain ID, nonce, and expiration before creating a session.","Shared-device or high-risk actions require a separate fresh-authentication policy.","The wallet, provider, or backend cannot complete the SIWE signing and verification flow."]},"designerTakeaways":["Show the requesting scheme when present, domain, statement, chain, and time bounds before the wallet prompt when the client can do so.","Treat the signature as proof of address control for this request, then create a server-managed session.","Use a stored nonce and verify the scheme when present, domain, URI, chain ID, issued-at, and optional expiration or not-before values.","Keep the message readable and provide a fallback sign-in path when a wallet cannot sign it.","Expire sessions and require fresh authentication for actions that need it."],"problemsSolved":[{"problem":"Every app needs separate account/password","oldWay":"Create account, verify email, remember password, repeat for every site","newWay":"A relying party can verify a SIWE message and associate the resulting session with the address","impact":"critical"},{"problem":"Password reuse and database breaches","oldWay":"Passwords stored (hashed) on servers, can be breached","newWay":"The wallet signs a message, while the relying party still stores and protects its own session data","impact":"high"},{"problem":"Sign-in requests looked like random data","oldWay":"Sign an opaque payload without a readable domain, statement, or time bound","newWay":"A SIWE message exposes the relying party domain, statement, address, chain, nonce, and time fields","impact":"high"}],"uxPatterns":[{"name":"Sign-In with Ethereum Button","description":"One-click authentication with wallet","userFlow":["User clicks \"Sign in with Ethereum\"","Wallet shows sign message popup","User reads and approves message","Server verifies signature","User authenticated + session created"]},{"name":"SIWE Message Preview","description":"What users see in wallet when signing","userFlow":["App generates SIWE message","Wallet displays formatted message","User verifies domain matches","User clicks Sign","Signature returned to app"]}],"uiComponents":[{"name":"SIWEButton","description":"Primary sign-in with Ethereum button","states":["idle","connecting","signing","authenticated","error"],"props":["onAuth","domain","statement"]},{"name":"SessionIndicator","description":"Shows authenticated state with session info","states":["anonymous","authenticated","expired"],"props":["address","expiresAt","onSignOut"]},{"name":"DomainBadge","description":"Verified domain indicator in sign message","states":["verified","mismatch","unknown"],"props":["domain","expectedDomain"]}],"antiPatterns":[{"pattern":"Unclear message statement","why":"Users sign without understanding what they're agreeing to","instead":"Clear statement: \"Sign in to [app name]\"","severity":"high"},{"pattern":"No session expiration","why":"Session lives forever, security risk","instead":"Set reasonable expiration, re-authenticate periodically","severity":"high"},{"pattern":"Not verifying domain matches","why":"Phishing sites could capture signatures","instead":"Server verifies the domain and optional scheme in the message match the trusted request origin","severity":"critical"},{"pattern":"Making SIWE the only auth option","why":"Not everyone has a wallet yet","instead":"Offer email/social as alternatives for onboarding","severity":"medium"}],"keyTakeaways":["SIWE means Sign-In with Ethereum and uses a wallet signature for a relying-party sign-in request","Messages must be human-readable with clear statement","Verify the domain and optional scheme in the message against the trusted request origin before creating a session","Set session expiration for security","Offer alternatives for users without wallets"],"technicalNotes":"ERC-4361 defines a message format parsed by wallets: optional scheme, domain, address, statement, URI, version, chain ID, nonce, issued-at, and optional expiration/not-before/resources. For EOAs, verification uses ERC-191; for contract accounts, the verifier should resolve the account on the message's chain ID and use ERC-1271 or another clearly defined interoperable method. Contract-account signature validity can change with blockchain state. The server still validates the requesting origin binding (for a cross-origin iframe, the iframe's own origin), nonce, time bounds, and session policy; personal_sign is an EOA signing example, not a universal verification path.","lastUpdated":"2026-09-18","specConstraints":[{"id":"siwe-scheme","constraint":"The optional SIWE scheme must be a valid RFC 3986 URI scheme.","appliesTo":"application","normativity":"normative","specQuote":"- `scheme` OPTIONAL. The URI scheme of the origin of the request. Its value MUST be an RFC 3986 URI scheme.","specSection":"Specification — Message Format — Message Fields","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#message-fields","designImplication":"Render the scheme when present and validate it before creating a sign-in request."},{"id":"siwe-domain","constraint":"The SIWE domain must be an RFC 3986 authority and identifies the origin requesting the signature.","appliesTo":"application","normativity":"normative","specQuote":"- `domain` REQUIRED. The domain that is requesting the signing. Its value MUST be an RFC 3986 authority. The authority includes an OPTIONAL port. If the port is not specified, the default port for the provided `scheme` is assumed (e.g., 443 for HTTPS). If `scheme` is not specified, HTTPS is assumed by default.","specSection":"Specification — Message Format — Message Fields","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#message-fields","designImplication":"Show the exact requesting domain before signing and bind it to the trusted request origin."},{"id":"siwe-address","constraint":"The SIWE message includes the Ethereum address performing the signing.","appliesTo":"application","normativity":"normative","specQuote":"- `address` REQUIRED. The Ethereum address performing the signing. Its value SHOULD be conformant to mixed-case checksum address encoding specified in [ERC-55](./eip-55.md) where applicable.","specSection":"Specification — Message Format — Message Fields","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#message-fields","designImplication":"Show which address is signing and keep the resulting session bound to that address."},{"id":"siwe-statement-readable","constraint":"The SIWE statement is a human-readable ASCII assertion and must not contain a newline.","appliesTo":"application","normativity":"normative","specQuote":"- `statement` OPTIONAL. A human-readable ASCII assertion that the user will sign which MUST NOT include `'\\n'` (the byte `0x0a`).","specSection":"Specification — Message Format — Message Fields","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#message-fields","designImplication":"Write a short, readable statement that fits the wallet review surface. Do not hide a multiline payload in the statement field."},{"id":"siwe-chain-binding","constraint":"The required chain ID binds the session and resolves contract accounts on that network.","appliesTo":"application","normativity":"normative","specQuote":"- `chain-id` REQUIRED. The [EIP-155](./eip-155.md) Chain ID to which the session is bound, and the network where Contract Accounts MUST be resolved.","specSection":"Specification — Message Format — Message Fields","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#message-fields","designImplication":"Show the network in the sign-in review and reject a session whose chain context does not match the requested chain."},{"id":"siwe-nonce-replay","constraint":"The relying party supplies a random nonce of at least eight alphanumeric characters to prevent replay.","appliesTo":"application","normativity":"normative","specQuote":"- `nonce` REQUIRED. A random string typically chosen by the relying party and used to prevent replay attacks, at least 8 alphanumeric characters.","specSection":"Specification — Message Format — Message Fields","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#message-fields","designImplication":"Treat a nonce as a one-time sign-in state. Never allow the same signed request to create a second session."},{"id":"siwe-time-bounds","constraint":"Issued-at, expiration-time, and not-before values use RFC 3339 datetimes when present.","appliesTo":"application","normativity":"normative","specQuote":"- `issued-at` REQUIRED. The time when the message was generated, typically the current time. Its value MUST be an [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) datetime string.","specSection":"Specification — Message Format — Message Fields","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#message-fields","designImplication":"Display the validity window in the signing review and reject messages outside the server’s allowed time range."},{"id":"siwe-account-verification","constraint":"EOA signatures use ERC-191, while contract-account verification uses ERC-1271 or a clearly defined interoperable method resolved on the message chain.","appliesTo":"application","normativity":"normative","specQuote":"- For Externally Owned Accounts (EOAs), the verification method specified in [ERC-191](./eip-191.md) MUST be used.","specSection":"Specification — Signing and Verifying Messages with Ethereum Accounts","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#signing-and-verifying-messages-with-ethereum-accounts","designImplication":"Treat contract accounts as a supported sign-in path only when the verifier can resolve and validate them on the requested chain."},{"id":"siwe-contract-state-session","constraint":"Contract-account signature validity can change with blockchain state, which can affect session validation.","appliesTo":"application","normativity":"normative","specQuote":"- Implementers SHOULD take into consideration that [ERC-1271](./eip-1271.md) implementations are not required to be pure functions, and can return different results for the same inputs depending on blockchain state. This can affect the security model and session validation rules. For example, a service with [ERC-1271](./eip-1271.md) signing enabled could rely on webhooks to receive notifications when state affecting the results is changed. When it receives a notification, it invalidates any matching sessions.","specSection":"Specification — Signing and Verifying Messages with Ethereum Accounts","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#signing-and-verifying-messages-with-ethereum-accounts","designImplication":"Define how state changes invalidate sessions and provide a re-authentication path for contract-account users."},{"id":"siwe-request-origin","constraint":"The SIWE domain and scheme must match the origin that made the signing request, including the iframe origin when applicable.","appliesTo":"wallet","normativity":"normative","specQuote":"- The `domain` and, if present, the `scheme`, in the SIWE Message MUST correspond to the origin from where the signing request was made. For instance, if the signing request is made within a cross-origin iframe embedded in a parent browser window, the `domain` (and, if present, the `scheme`) have to match the origin of the iframe, rather than the origin of the parent. This is crucial to prevent the iframe from falsely asserting the origin of one of its ancestor windows for security reasons. This behavior is enforced by conforming wallets.","specSection":"Specification — Relying Party Implementer Steps — Specifying the Request Origin","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#specifying-the-request-origin","designImplication":"Show the requesting origin in the wallet and reject or warn on an origin mismatch according to the wallet’s security mode."},{"id":"siwe-message-validation","constraint":"The signed message must conform to the ABNF and expected values before the signature is accepted.","appliesTo":"application","normativity":"normative","specQuote":"- The SIWE Message MUST be checked for conformance to the ABNF Message Format in the previous sections, checked against expected values after parsing (e.g., `expiration-time`, `nonce`, `request-uri` etc.), and its signature MUST be checked as defined in [Signing and Verifying Messages with Ethereum Accounts](#signing-and-verifying-messages-with-ethereum-accounts).","specSection":"Specification — Relying Party Implementer Steps — Verifying a signed Message","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#verifying-a-signed-message","designImplication":"Keep a visible rejected state for malformed, stale, or unexpected SIWE messages. Do not create a session from a signature alone."},{"id":"siwe-session-address-binding","constraint":"Sessions are bound to the SIWE address, not to resources that may change.","appliesTo":"application","normativity":"normative","specQuote":"- Sessions MUST be bound to the `address` and not to further resolved resources that can change.","specSection":"Specification — Relying Party Implementer Steps — Creating Sessions","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#creating-sessions","designImplication":"Use the address as the stable session identity and refresh derived profile resources separately."},{"id":"siwe-human-readable-signing","constraint":"The user must see a human-understandable interface before signing, mostly free of machine-targeted artifacts.","appliesTo":"wallet","normativity":"rationale","specQuote":"1. The user must be presented a human-understandable interface prior to signing, mostly free of machine-targeted artifacts such as JSON blobs, hex codes (aside from the Ethereum address), and baseXX-encoded strings.","specSection":"Rationale — Requirements","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#requirements","designImplication":"Prioritize domain, address, statement, and time context over raw JSON, hex, or encoded payloads in the signing review."},{"id":"siwe-identifier-privacy","constraint":"Using a new uncorrelated identifier per interaction can reduce the privacy cost of repeated address reuse.","appliesTo":"application","normativity":"security-considerations","specQuote":"- Towards perfect privacy, it would be ideal to use a new uncorrelated identifier (e.g., Ethereum address) per digital interaction, selectively disclosing the information required and no more.","specSection":"Security Considerations — Identifier Reuse","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#identifier-reuse","designImplication":"Treat address reuse as a product privacy choice. Explain what a persistent address reveals and avoid claiming that SIWE provides unlinkability."},{"id":"siwe-key-management","constraint":"SIWE users remain responsible for key management, and the standard does not provide a password-recovery equivalent.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"there is no \"forgot password\" button as centralized identity providers commonly implement.","specSection":"Security Considerations — Key Management","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#key-management","designImplication":"Provide wallet recovery education and an alternate sign-in path where the product needs one. Do not imply that signing creates a recoverable app password."},{"id":"siwe-wallet-server-privacy","constraint":"Client-generated messages are preferred when avoiding an initial server round trip provides a privacy benefit.","appliesTo":"application","normativity":"security-considerations","specQuote":"The latter approach without initial server interaction SHOULD be preferred when there is a user privacy advantage by minimizing wallet-server interaction.","specSection":"Security Considerations — Minimizing Wallet and Server Interaction","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#minimizing-wallet-and-server-interaction","designImplication":"Choose client-side generation when it reduces unnecessary wallet-server data sharing, while retaining server nonce and validation controls where required."},{"id":"siwe-channel-security","constraint":"Web-based message-signing communications should use HTTPS or equivalent confidentiality, integrity, and authenticity protections.","appliesTo":"application","normativity":"security-considerations","specQuote":"For web-based applications, all communications SHOULD use HTTPS to prevent man-in-the-middle attacks on the message signing.","specSection":"Security Considerations — Channel Security","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#channel-security","designImplication":"Keep signing and session setup on a protected channel and make insecure transport a visible failure, not a silent fallback."},{"id":"siwe-session-invalidation","constraint":"Servers should invalidate sessions when signature-relevant ERC-1271 state or declared resources change.","appliesTo":"application","normativity":"security-considerations","specQuote":"- If an [ERC-1271](./eip-1271.md) implementation or dependent data changes the signature computation, the server SHOULD invalidate sessions appropriately.\n- If any resources specified in `resources` change, the server SHOULD invalidate sessions appropriately. However, the interpretation of `resources` is out of scope of this specification.","specSection":"Security Considerations — Session Invalidation","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#session-invalidation","designImplication":"Give users a clear expired-session state and require a fresh signature when the account’s signing state or declared resources no longer match."},{"id":"siwe-resources","constraint":"The resources field is OPTIONAL; when present it lists RFC 3986 URIs the user wishes the relying party to resolve.","appliesTo":"application","normativity":"normative","specQuote":"- `resources` OPTIONAL. A list of information or references to information the user wishes to have resolved as part of authentication by the relying party. Every resource MUST be an RFC 3986 URI separated by `\"\\n- \"` where `\\n` is the byte `0x0a`.","specSection":"Specification > Message Format > Message Fields","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#message-fields","designImplication":"Show each requested resource in signing review with a readable label or destination, and make the optional nature clear when no resources are requested."},{"id":"siwe-ens-resolution","constraint":"A relying party or wallet MAY resolve ENS data to improve human-readable information related to the signing address.","appliesTo":"application","normativity":"normative","specQuote":"- The relying party or wallet MAY additionally perform resolution of ENS data, as this can improve the user experience by displaying human-friendly information that is related to the `address`. Resolvable ENS data include:","specSection":"Specification > Resolving Ethereum Name Service (ENS) Data","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#resolving-ethereum-name-service-ens-data","designImplication":"Treat an ENS name as an optional identity aid and keep the verified address primary; provide a clear state when resolution is unavailable."},{"id":"siwe-ens-privacy","constraint":"When ENS resolution is performed, implementers SHOULD preserve user privacy and consent because the address may be forwarded to third-party services.","appliesTo":"application","normativity":"normative","specQuote":"- If resolution of ENS data is performed, implementers SHOULD take precautions to preserve user privacy and consent, as their `address` could be forwarded to third party services as part of the resolution process.","specSection":"Specification > Resolving Ethereum Name Service (ENS) Data","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#resolving-ethereum-name-service-ens-data","designImplication":"Disclose or minimize third-party ENS lookups, and give the user a way to understand when a human-readable name came from an external resolver."},{"id":"siwe-resource-display","constraint":"Implementers SHOULD ensure requested resource URIs are human-friendly when expressed in plaintext.","appliesTo":"application","normativity":"normative","specQuote":"- Implementers SHOULD ensure that URIs in the listed `resources` are human-friendly when expressed in plaintext form.","specSection":"Specification > Relying Party Implementer Steps > Interpreting and resolving Resources","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#interpreting-and-resolving-resources","designImplication":"Render resource destinations in a readable, inspectable form instead of presenting opaque URI strings as if they were trusted labels."},{"id":"siwe-legacy-warning","constraint":"Wallet implementers SHOULD warn when a legacy ERC-191 message resembles SIWE without fully conforming to the SIWE format.","appliesTo":"wallet","normativity":"normative","specQuote":"- Wallet implementers SHOULD warn users if the substring `\"wants you to sign in\n  with your Ethereum account\"` appears anywhere in an [ERC-191](./eip-191.md) message signing\n  request unless the message fully conforms to the format defined [ABNF Message Format](#abnf-message-format).","specSection":"Specification > Wallet Implementer Steps > Verifying the Message Format","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#verifying-the-message-format","designImplication":"Place the warning in the signing review and explain why the message is not being treated as a standard SIWE request."},{"id":"siwe-i18n","constraint":"After parsing the SIWE message into ABNF terms, translation MAY happen at the UX layer per human language.","appliesTo":"application","normativity":"normative","specQuote":"- After successfully parsing the message into ABNF terms, translation MAY happen at the UX level per human language.","specSection":"Specification > Wallet Implementer Steps > Supporting internationalization (i18n)","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#supporting-internationalization-i18n","designImplication":"Localize explanatory UI after parsing without altering the signed message; show users which content is translated presentation versus signed text."},{"id":"siwe-wallet-server-data-minimization","constraint":"A wallet MAY consult the server for message contents, but when communicating with the server it SHOULD mitigate user information revealed as much as possible.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"- Before the wallet presents the SIWE message signing request to the user, it MAY consult the server for the proper contents of the message to be signed, such as an acceptable `nonce` or requested set of `resources`. When communicating to the server, the wallet SHOULD take precautions to protect user privacy by mitigating user information revealed as much as possible.","specSection":"Security Considerations > Minimizing Wallet and Server Interaction","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#minimizing-wallet-and-server-interaction","designImplication":"Make server consultation explicit and minimize identity, resource, and preference data sent before the user approves signing."},{"id":"siwe-account-choice","constraint":"Prior to signing, the wallet MAY consult the user for preferences such as selecting one address or a preferred ENS name.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"- Prior to signing, the wallet MAY consult the user for preferences, such as the selection of one `address` out of many, or a preferred ENS name out of many.","specSection":"Security Considerations > Minimizing Wallet and Server Interaction","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#minimizing-wallet-and-server-interaction","designImplication":"Offer an explicit account/name choice when multiple identities are available, while keeping the final signing address unambiguous."},{"id":"siwe-field-lengths","constraint":"Implementers SHOULD choose maximum lengths for ABNF terms that balance denial-of-service prevention, arbitrary use cases, and user readability.","appliesTo":"application","normativity":"security-considerations","specQuote":"- While this specification does not contain normative requirements around maximum string lengths, implementers SHOULD choose maximum lengths for terms that strike a balance across the prevention of denial of service attacks, support for arbitrary use cases, and user readability.","specSection":"Security Considerations > Maximum Lengths for ABNF Terms","specUrl":"https://ercs.ethereum.org/ERCS/erc-4361#maximum-lengths-for-abnf-terms","designImplication":"Set and communicate sane limits for SIWE fields, with a recoverable error when a request is too long to review safely."}],"sources":[{"label":"ERC-4361 official specification","url":"https://ercs.ethereum.org/ERCS/erc-4361","type":"official-spec"},{"label":"ERC-1271 official specification","url":"https://ercs.ethereum.org/ERCS/erc-1271","type":"official-spec"}],"lastReviewed":"2026-09-18"},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-4361","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-4361","type":"discussion"},{"label":"ERC-1271 official specification","url":"https://ercs.ethereum.org/ERCS/erc-1271","type":"official-spec"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-4361","markdown":"https://www.eipsfordesigners.com/standards/ERC-4361/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-4361/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-4361","official":"https://ercs.ethereum.org/ERCS/erc-4361","discussion":"https://ethereum-magicians.org/search?q=ERC-4361"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}