Alert Source Discuss
⚠️ Draft Standards Track: ERC

ERC-8019: Minimal Wallet-Managed Auto-Login for SIWE

Defines a wallet-local allowlist for automatic signing of ERC-4361 messages when simple match rules succeed.

Authors Ivo Georgiev (@Ivshti), Vijay Krishnavanshi (@vijaykrishnavanshi)
Created 2025-09-02
Discussion Link https://ethereum-magicians.org/t/erc-8019-minimal-wallet-managed-auto-login-for-siwe/25348
Requires EIP-4361

Table of Contents

Abstract

Defines a wallet-local allowlist for automatic signing of ERC-4361 messages when simple, deterministic match rules succeed. Policies are created and managed only by the wallet/user.

Motivation

Users repeatedly sign identical SIWE messages for trusted apps. A small, explicit match policy enables zero-prompt login without involving apps.

Users already get prompted by their wallets if they trust a certain app when they initially connect to it - this flow can also authorize auto-login if applicable.

Specification

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

The term “wallet” refers to wallet user interfaces, regardless of whether mobile, web-based or browser extensions.

Overview

Each allow-policy is defined as:

{
  "domain": "example.com",                  // exact match to SIWE domain
  "uriPrefix": "https://example.com/",      // SIWE URI MUST start with this
  "allowedChains": [1],                     // list of allowed chainIds
  "allowedResources": ["https://example.com/login"], // exact set match
  "supportsEIP6492": true,                   // required for smooth UX when using hardware wallets
  "expiresAt": 1700000000000 // UNIX timestamp when this policy expires, or 0 for no expiry
}

Auto-sign rule

Given a parsed ERC-4361 message M, the wallet MAY auto-sign if:

  1. M.domain == policy.domain
  2. M.uri startsWith policy.uriPrefix
  3. If M.chainId present: M.chainId is in policy.allowedChains
  4. If policy.allowedResources non-empty: the set of M.resources is a subset of policy.allowedResources (order does not matter); otherwise no resources will be allowed at all
  5. If policy.expiresAt is non-zero, the current time is less than policy.expiresAt

All other SIWE validations (nonce uniqueness, time validity, signature domain binding) remain as per ERC-4361 and MUST be enforced by the wallet.

Management of policies

Policies are created, listed, updated, and deleted only within the wallet UI - wallets decide how much control they want to give to users over this.

It’s recommended that each wallet:

  • includes a default list of policies for popular apps
  • automatically creates policies for apps that it considers safe, after the first SIWE signature, with user consent - this implies a different flow where, upon receiving the SIWE message sign request, the wallet will not go through the regular message signing flow, but prompt the user “App X wants to log-in with your account” with a checkbox to “Automatically sign into in the future”

There’s no app-provided hints or headers that influence policy creation.

Hardware wallet compatibility and ERC-6492

Auto-signing is not viable with hardware wallet accounts, as the user will be prompted without context or expectation to sign the login message.

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.

However, if it’s set to true, the wallet MAY perform auto-login as long as 1) it can enable EIP-7702 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 may be used.

RPC method

Wallets MAY implement an RPC method, wallet_getCurrentAutoLoginPolicy, which has no parameters and returns an object describing the current policy for the calling app.

{
  // the object that describes the active policy, or null
  "activePolicy": {
    "domain": "example.com",
    "uriPrefix": "https://example.com/",
    "allowedChains": [1],
    "allowedResources": ["https://example.com/login"],
    "supportsEIP6492": true,
    "expiresAt": 1700000000000
  },
}

The response of this method allows apps to determine whether they can self-initiate login requests without user interaction.

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.

It’s recommended that the wallet returns null if the policy has expired or the app is connected on a non-allowed chain.

Rationale

  • This ERC is designed with minimal modifications to existing apps in mind
  • From a security perspective, it’s much easier to “outsource” the job of determining which apps to enable to this policy for to wallets - most wallets already maintain lists of “trusted” apps
  • EIP-712 (typed data) is out of scope due to SIWE deciding to build on plain text.

Backwards Compatibility

Backwards compatibility is one of the main goals of this ERC, and it requires no changes to existing apps, building upon ERC-4361 as-is.

To 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).

Reference Implementation 

function shouldAutoSign(M, P) {
  if (M.domain !== P.domain) return false;
  if (!M.uri.startsWith(P.uriPrefix)) return false;
  if (!P.allowedChains.includes(M.chainId)) return false;
  if (M.resources) {
    const allowList = P.allowedResources || []
    if (!M.resources.every(resource => allowList.includes(resource))) return false;
  }
  if (P.expiresAt !== 0 && Date.now() >= P.expiresAt) return false;
  // Also enforce standard SIWE validations here.
  return true;
}

Security Considerations

  • Managing policies it out of scope of this ERC, as most wallets already manage trusted app lists - however, the recommended best practice is to:
    • Include a default list of policies for popular apps
    • Auto-create policies for other apps if the user consents to it
  • Standard SIWE checks (fresh nonce, correct domain binding, time validity) should still be enforced.
  • uriPrefix should be kept specific (e.g., /login) to avoid over-broad matches.
  • It’s recommended to include a top-level setting in each wallet that can disable this ERC.
  • 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.

Copyright and related rights waived via CC0.

Citation

Please cite this document as:

Ivo Georgiev (@Ivshti), Vijay Krishnavanshi (@vijaykrishnavanshi), "ERC-8019: Minimal Wallet-Managed Auto-Login for SIWE [DRAFT]," Ethereum Improvement Proposals, no. 8019, September 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-8019.