{"id":"ERC-8019","name":"Optional SIWE Auto-Sign Policy","status":"Review","chain":"both","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"authentication","name":"Authentication & Identity","description":"Proving who you are and logging in"}],"uxImpact":"ERC-8019 defines an optional wallet-managed policy for auto-signing matching SIWE requests. A wallet may auto-sign when domain, URI prefix, chain, resources, and expiry constraints match; the app must still validate the SIWE message and manage its own session.","officialUrl":"https://ercs.ethereum.org/ERCS/erc-8019","lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","kind":"proposal","hasDetailedContent":true,"content":{"id":"ERC-8019","sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-8019","type":"official-spec"}],"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18","summary":"ERC-8019 defines an optional wallet-managed policy for auto-signing matching SIWE requests. A wallet may auto-sign when domain, URI prefix, chain, resources, and expiry constraints match; the app must still validate the SIWE message and manage its own session.","partialDeployment":{"body":"ERC-8019 is Review-stage. Treat policy discovery and automatic signing as conditional on the selected wallet implementation, returned policy, and current SIWE verification evidence; keep ordinary SIWE available."},"designerTakeaways":["Offer automatic signing only after the wallet reports a matching policy; keep normal SIWE as the fallback.","Show restoring, unsupported, declined, and policy-mismatch states before displaying account content.","Validate every SIWE message and keep sensitive actions behind the app's own re-authentication policy."],"applicability":{"whenToUse":["The selected wallet implements this Review-stage policy and returning users benefit from reduced SIWE prompts.","Your app can store and validate a scoped session securely server-side.","The product can keep ordinary SIWE and sensitive-action re-authentication available."],"whenToAvoid":["Shared-device or kiosk contexts where persistence is dangerous.","Regulatory requirements mandate fresh auth every session.","The wallet does not report support, the policy cannot match the request, or the app cannot provide ordinary SIWE fallback."]},"prototypeFirst":[{"screen":"Policy discovery and optional auto-sign","why":"Show the reduced-prompt path only when a compatible wallet reports a matching policy.","covers":["Policy returned","SIWE session outcome"],"include":["Policy scope","SIWE validation","Session result"]},{"screen":"Mismatch or unsupported wallet","why":"ERC-8019 is optional and a wallet may decline or return no policy.","covers":["No policy","Domain, URI, chain, or resource mismatch"],"include":["Plain-language reason","Fallback action"]},{"screen":"Ordinary SIWE fallback","why":"Users still need a usable sign-in path when auto-sign is unavailable or declined.","covers":["Policy decline","SIWE verification or session failure"],"include":["Retry path","Support context"]},{"screen":"Policy and re-auth disclosure","why":"Users need to understand what requests may be signed automatically and which actions still require a prompt.","covers":["Domain and URI scope","Resource and expiry scope","Sensitive-action re-authentication"],"include":["Expandable section","Copy buttons","Explorer link"]}],"mentalModel":[{"label":"Policy discovery","description":"The wallet creates and manages the auto-sign policy in its UI. The app may check the current policy when the optional policy RPC is available; it cannot create or update the policy through app-provided hints."},{"label":"Match checks","description":"The wallet can auto-sign only when the SIWE domain matches the trusted top-level origin and the URI prefix, chain, resources, and expiry satisfy the active policy."},{"label":"Optional auto-sign","description":"A matching policy may remove a signature prompt; hardware-wallet accounts require supportsEIP6492 and a compatible account/delegation path, and initial setup may still prompt. Unsupported wallets, mismatches, and declines fall back to normal SIWE."},{"label":"App session","description":"The app still verifies each SIWE message and creates or validates its own scoped session token according to its security policy."},{"label":"Sensitive re-auth","description":"Withdrawals, settings changes, and high-value actions can require a fresh signature even when a policy is active."}],"statesToDesign":[{"state":"Policy unavailable","trigger":"The wallet returns no ERC-8019 policy or does not support the Review-stage extension.","userNeed":"Continue without losing the sign-in path.","designResponse":"Offer ordinary SIWE and explain that persistence is unavailable."},{"state":"Policy mismatch","trigger":"The trusted top-level origin, domain, URI prefix, chain, resources, or expiry falls outside the active policy.","userNeed":"Know why a prompt appeared.","designResponse":"Explain the mismatch and continue with ordinary SIWE."},{"state":"Auto-sign candidate","trigger":"A wallet reports a policy match for the SIWE request.","userNeed":"Know what may be signed without a prompt.","designResponse":"Show policy scope and trusted top-level origin, and retain an app session and sensitive-action re-authentication path."},{"state":"SIWE validation failed","trigger":"The wallet or app cannot validate the message, nonce, domain/origin, or session.","userNeed":"Avoid entering an untrusted session.","designResponse":"Block session creation, explain the failed check, and offer a safe retry."},{"state":"Sensitive action","trigger":"A withdrawal, settings change, or other high-risk action is requested.","userNeed":"Know that persistence does not silently authorize the action.","designResponse":"Require the app's configured fresh-signature or re-authentication step."}],"designDecisions":[{"question":"How much protocol detail do users see?","recommendation":"Lead with outcomes; tuck identifiers behind review.","rationale":"Users decide on consequences, not function selectors."},{"question":"What happens when support is missing?","recommendation":"Block with explanation and fallback path.","rationale":"Silent failure feels like a broken product."},{"question":"What may auto-sign without a prompt?","recommendation":"Show trusted top-level origin, domain, URI, chain, resource, and expiry scope and keep a normal SIWE fallback.","rationale":"A policy is optional and bounded; users need to understand its scope and when a fresh signature is required."}],"problemsSolved":[{"problem":"Returning users face repeated SIWE prompts","oldWay":"Every visit requests an ordinary SIWE signature","newWay":"A compatible wallet may auto-sign matching requests under a bounded policy","impact":"high"},{"problem":"Policy scope and fallback behavior are unclear","oldWay":"A sign-in flow silently assumes persistence or silently fails","newWay":"The UI explains policy match, decline, mismatch, ordinary SIWE, and sensitive re-authentication states","impact":"high"},{"problem":"Invalid SIWE messages can create unsafe sessions","oldWay":"An app trusts a wallet response without checking domain, nonce, chain, or session rules","newWay":"The app validates each SIWE message and blocks a session when a check fails","impact":"medium"}],"uxPatterns":[{"name":"Silent Reconnect","description":"Restore session on page load without modal.","components":["SessionRestore","AccountChip"],"userFlow":["User returns to the app","App checks the wallet's current auto-sign policy when the optional RPC is available","Wallet may auto-sign only when the policy matches","App validates the SIWE message and session","If unsupported, declined, or mismatched, show the normal sign-in flow"]},{"name":"Remember Me Toggle","description":"Explicit opt-in for persistent auth.","components":["RememberToggle","SecurityNote"],"userFlow":["User reviews an optional remember-me policy","Wallet reports whether the policy is active","App explains domain, chain, URI, resources, and expiry constraints","User can continue with ordinary SIWE when auto-signing is unavailable","User can disable persistence in app or wallet settings when supported"]}],"antiPatterns":[{"pattern":"Treating auto-sign as universal persistent login","why":"ERC-8019 is optional, bounded, and wallet-managed; the app still owns SIWE verification and sessions","instead":"Show policy scope, match state, decline behavior, and ordinary SIWE fallback","severity":"critical"},{"pattern":"Hiding which requests may be auto-signed","why":"Users cannot understand the authority they granted or why a prompt was skipped","instead":"Use outcome language with an explicit policy and sensitive-action disclosure","severity":"high"},{"pattern":"No ordinary SIWE fallback","why":"A wallet or policy mismatch should not strand users who can sign normally","instead":"Explain the limitation and offer ordinary SIWE or a safe retry","severity":"high"}],"vocabulary":[{"use":"Remembered sign-in policy","avoid":"Permanent login","why":"The wallet policy is bounded and does not replace app session security."},{"use":"Sign-in policy unavailable","avoid":"Wallet is broken","why":"Describe optional support without blaming the user or wallet."},{"use":"Sign in","avoid":"Auto-login forever","why":"Keep ordinary SIWE and app-session boundaries explicit."}],"specConstraints":[{"id":"uri-prefix-policy","constraint":"A wallet auto-login policy’s uriPrefix must match the required SIWE URI prefix.","appliesTo":"wallet","normativity":"normative","specQuote":"\"uriPrefix\": \"https://example.com/\",      // SIWE URI MUST start with this","specSection":"Specification > Overview","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#overview","designImplication":"Display the exact origin/path scope of an auto-login policy and avoid treating a broad prefix as a trusted site identity."},{"id":"hardware-wallet-policy","constraint":"The policy includes supportsEIP6492 for smooth hardware-wallet UX.","appliesTo":"wallet","normativity":"normative","specQuote":"\"supportsEIP6492\": true,                   // required for smooth UX when using hardware wallets","specSection":"Specification > Overview","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#overview","designImplication":"Show whether the wallet can verify the account type before auto-login and keep a manual sign-in fallback."},{"id":"siwe-validation","constraint":"Wallets must enforce nonce uniqueness, time validity, and signature-domain binding from ERC-4361.","appliesTo":"wallet","normativity":"normative","specQuote":"All other SIWE validations (nonce uniqueness, time validity, signature domain binding) remain as per [ERC-4361](./eip-4361.md) and MUST be enforced by the wallet.","specSection":"Specification > Auto-sign rule","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#auto-sign-rule","designImplication":"Keep auto-login behind the same SIWE validation state as manual login and show why a message was rejected."},{"id":"hardware-wallet-fallback","constraint":"When supportsEIP6492 is false, the wallet must not auto-login a hardware-wallet primary signer.","appliesTo":"wallet","normativity":"normative","specQuote":"This is why we include the `supportsEIP6492` property. If it is set to `false`, the wallet MUST not auto-login if the account's primary signer is a hardware wallet, as the app has no way of verifying a smart contract signature.","specSection":"Specification > Hardware wallet compatibility and ERC-6492","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#hardware-wallet-compatibility-and-erc-6492","designImplication":"Offer explicit manual verification instead of silently auto-signing or treating unsupported hardware accounts as verified."},{"id":"policy-null-state","constraint":"A disabled ERC or app without an active policy returns null for activePolicy.","appliesTo":"wallet","normativity":"normative","specQuote":"If this ERC is disabled in the wallet, or there is no active policy for the calling app, the wallet MUST return `null` for `activePolicy`.","specSection":"Specification > RPC method","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#rpc-method","designImplication":"Represent no-policy and policy-mismatch states distinctly from an error and fall back to ordinary SIWE login."},{"id":"self-initiated-login","constraint":"Existing apps remain compatible, but apps must self-initiate the login request to use auto-login.","appliesTo":"application","normativity":"backwards-compatibility","specQuote":"## Backwards Compatibility\n\nBackwards compatibility is one of the main goals of this ERC, and it requires no changes to existing apps, building upon [ERC-4361](./eip-4361.md) as-is.\n\nTo fully take advantage of this ERC, apps need to self-initiate the login request rather than expecting users to press a log-in button (using `wallet_getCurrentAutoLoginPolicy`).","specSection":"Backwards Compatibility","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#backwards-compatibility","designImplication":"Add auto-login as an opt-in initiation path while keeping an explicit sign-in fallback for apps that expect a button-driven flow."},{"id":"auto-login-safety","constraint":"Auto-login should be off by default or explicitly enabled for trusted sites, preserve SIWE checks, use narrow URI prefixes, and match the top-level origin.","appliesTo":"wallet","normativity":"security-considerations","specQuote":"## Security Considerations\n\n* It’s recommended for Auto login to be OFF by default on wallets’ UIs so that users can explicitly toggle ON for websites they trust.\n* Managing policies it out of scope of this ERC, as most wallets already manage trusted app lists - however, the recommended best practice is to:\n    * Include a default list of policies for popular apps\n    * Auto-create policies for other apps if the user consents to it\n* Standard SIWE checks (fresh nonce, correct domain binding, time validity) should still be enforced.\n* `uriPrefix` should be kept specific (e.g., `/login`) to avoid over-broad matches.\n* It's recommended to include a top-level setting in each wallet that can disable this ERC.\n* Always match `M.domain` against the top-level origin of each app, to avoid auto-login working in iframes that are included in a malicious top-level origin.","specSection":"Security Considerations","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#security-considerations","designImplication":"Use explicit per-site consent, narrow policy scope, origin checks, a global disable setting, and visible mismatch states before showing account content."},{"id":"auto-sign-match","constraint":"A wallet MAY auto-sign a parsed ERC-4361 message only when it matches the configured auto-sign policy.","appliesTo":"wallet","normativity":"normative","specQuote":"Given a parsed [ERC-4361](./eip-4361.md) message `M`, the wallet **MAY** auto-sign **if**:","specSection":"Specification > Auto-sign rule","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#auto-sign-rule","designImplication":"Show the policy match and the exact app/origin scope before bypassing a manual signing prompt."},{"id":"hardware-wallet-conditional-autosign","constraint":"A wallet MAY auto-login on a hardware-backed account only when it can use EIP-7702 or a limited-scope session key/delegation, and the setup still requires user prompts.","appliesTo":"wallet","normativity":"normative","specQuote":"However, if it's set to `true`, the wallet MAY perform auto-login as long as 1) it can enable [EIP-7702](./eip-7702.md) on the account OR the account is a smart account 2) it can authorize a limited-scope session key or delegation just for the auto-login. If said conditions are met, the wallet MAY generate a login signature without prompting the user on their hardware device. That said, enabling EIP-7702 and the session key/delegation will require prompting the user, so it's up to the wallet to walk the user through it. The exact mechanism of how wallets should manage the session key/delegation is out of scope of this ERC, but [ERC-7710](./eip-7710.md) may be used.","specSection":"Specification > Hardware wallet compatibility and ERC-6492","specUrl":"https://ercs.ethereum.org/ERCS/erc-8019#hardware-wallet-compatibility-and-erc-6492","designImplication":"Separate the hardware-device signing state from setup approval, show the limited scope, and never imply that auto-login authorizes arbitrary messages."}],"technicalNotes":"ERC-8019 describes a wallet-local policy for auto-signing matching SIWE requests; policy creation and management remain in the wallet UI, while an app MAY inspect the current policy through the optional wallet_getCurrentAutoLoginPolicy RPC. Matching the SIWE domain to the trusted top-level origin, URI prefix, chain, resources, and expiry constraints is required, and a wallet can return no policy or decline. Hardware-wallet auto-login additionally depends on supportsEIP6492 and a compatible smart-account/session-key or delegation path; initial enablement may still prompt. Normal SIWE verification and app-session management remain required; auto-signing is not a persistent authentication guarantee.","relatedStandards":[{"id":"ERC-4361","relationship":"SIWE auth that 8019 extends with persistence"},{"id":"ERC-6492","relationship":"Auth for undeployed smart accounts"}]},"sources":[{"label":"Official specification","url":"https://ercs.ethereum.org/ERCS/erc-8019","type":"official-spec"},{"label":"Discussion search","url":"https://ethereum-magicians.org/search?q=ERC-8019","type":"discussion"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/ERC-8019","markdown":"https://www.eipsfordesigners.com/standards/ERC-8019/content.md","agent":"https://www.eipsfordesigners.com/standards/ERC-8019/agent.md","api":"https://www.eipsfordesigners.com/api/standards/ERC-8019","official":"https://ercs.ethereum.org/ERCS/erc-8019","discussion":"https://ethereum-magicians.org/search?q=ERC-8019"},"freshness":{"lastReviewed":"2026-09-18","lastUpdated":"2026-09-18"}}