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.
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.
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.
Each allow-policy is defined as:
Given a parsed ERC-4361 message M, the wallet MAY auto-sign if:
M.domain == policy.domainM.uri startsWith policy.uriPrefixM.chainId is in policy.allowedChainsM.resources is a subset of policy.allowedResources (order does not matter); otherwise no resources will be allowed at allpolicy.expiresAt is non-zero, the current time is less than policy.expiresAtAll other SIWE validations (nonce uniqueness, time validity, signature domain binding) remain as per ERC-4361 and MUST be enforced by the wallet.
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:
There’s no app-provided hints or headers that influence policy creation.
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.
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 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.
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).
uriPrefix should be kept specific (e.g., /login) to avoid over-broad matches.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.