Automatic Authentication Signature

Web Wallets
,
21

Hey @sscovil, thanks for bringing this up and reviving this thread. I am happy to help move that forward too.

As discussed earlier in this thread there are 2 non-mutually exclusive proposals that we could push forward

A) EIP-1102 backward compatible extension (adding a challenge string to eth_requestAccounts)

B) Generic Automatic Signatures (PR-2224)

A) is simple and backward compatible. should be easier to get accepted. It does not offer the full feature set of B) but for authentication might be enough. Interested to know what you think here.

B) is more powerful and actually with B you don’t need A) anymore, but there are still open questions that I mentioned in the PR

  • Is it secure to let applications sign at will (even if the message is prepended by “Automatic Signature”) ?
  • Or should we do such signing using a non-hardened derived key ?
  • If so could EIP-1102’s eth_requestAccounts be used to provide the parameter to derive from (could be one based on the origin of the document) ?
  • Should we rate-limit the requests ?

Also if we explore B) we could also explore further proposals that I discussed in the past.

1 Like
22

@wighawag please see my comment on your PR, which includes a proposal for a revised version of the draft. For some reason, I can’t include a link in my post, but it’s https://github.com/ethereum/EIPs/pull/2224#issuecomment-2884118048

1 Like
23

Thanks, as I replied on the PR comment, we should discuss here further before moving with a fully fledged PR.

In particular I would like to know the rationale for generic automatic-signatures compared to having it as part of eth_requestAccounts

The important one I see is that eth_requestAccounts is supposed to be invoked once and asking for authentication signature might require further request.

While eth_requestAccounts can be invoked multiple time, I am not sure of the current behavior across wallet, do they show popup even if the user already accepted the request ?

if so it would make automatic signature more compelling.

Another thing I would like to hear is about potential use case of Automatic signature that would not be fulfilled by an extended eth_requestAccounts

1 Like
24

It’s a great question. At first, I felt the idea of having automatic authentication built right into eth_requestAccounts made a lot of sense. However, I’m not sure what that would look like for an app developer, in practice.

For example, let’s say you visti my site for the first time and click a ‘Connect Wallet’ button. Upon clicking it, my client application code calls eth_requestAccounts, and the account is connected successfully.

In this scenario, how can I as the app developer be sure that the wallet performed any sort of authentication at all? What if the wallet doesn’t support automatic authentication, but does support the current implementation of eth_requestAccounts? Would the return value of eth_requestAccounts need to change?

Changing the behavior of eth_requestAccounts creates versioning and backward compatibility concerns that could be avoided altogether by introducing a new method instead.

A new method could reasonably be expected to return a signed authentication message that the application can verify. I’m not sure it would work if we just modified the behavior of eth_requestAccounts…

25

We should be able to keep backward compatibility with eth_requestAccounts and ensure apps can identify if eth_requestAccounts with authentication is supported by having a different request and response type.

But even if we could not or if we did not want to overload it, we could simply add a new request like eth_requestAuthenticatedAccounts that keep the old behavior of associating domain with accounts but also return signature for authentication.

(EDIT: and after reflection this seems indeed a better approach: having a new method for clarity)

So I would not worry too much at this point about the api itself

In other word, the choice is between
A) having authentication as part of the connection flow
or B) having a method to auto-sign independently

The advantage of having the connection flow return signature of connected accounts, is that we reuse the exisitng user approval and it means it works with hardware wallet or other wallet that cannot support automatic signature without assuming they are connected all the time.

26

Having authentication as part of the connection flow makes sense, as long as it’s verifiable by the application requesting authentication. The server cannot just trust the wallet.

27

Yes of course, that’s why the challenge string is added

And the response type could be something like

{address: '0x${string}', signature: '0x${string}'}[]

(I kept the array type to match eth_requestAccounts but having a single {address: '0x${string}', signature: '0x${string}'} might be preferable and we could then remove the plural form. A strong reason here to have a different method name like you suggested.

And as mentioned in this thread above we can use the same prefix scheme : Automatic Signature: <challenge> for the signed message to be verified

But I still wonder what should the behaviour of wallets be when calling wallet_requestAuthenticatedAccount multiple times
(I used the wallet_` prefix here as it is a namespace we should move to for wallet specific RPC methods)

Currently eth_requestAccounts needs to be called when the wallet was never connected or is locked. Is that sufficient?

What if the backend require the authentication to be short lived and require a new authentication signature even though the wallet is neither locked not disconnected.

Should eth_requestAuthenticatedAccount accept being called multiple time and only show a popup if the rate limit is reached or if the actual private key / signing capability is not available instantly (hardware wallet…)

I guess that works. In some ways it become very similar to wallet_autoSign except that the connection flow is included, solving the case for hardware wallet too and allowing the wallet to continue using eth_requestAccounts-like behaviour to show a confirmation popup if needed (rate limit, locked, etc…)

28

I think the act of a server requesting access to an account from a wallet is distinct enough from the act of a server asking a wallet to verify ownership of an account by signing a challenge message, that it warrants two separate methods.

The first method already exists. The second method is what we believe is essential. If we want to separately propose a third method that combines the two, I would be supportive of that…but for now, I think we should just focus on the path of least resistance.

If an application has to make a call once to gain access to an account, and then once per session to authenticate, that is perfectly acceptable and should raise no concerns.

If, on the other hand, an application makes a since call once to gain access to an account and authenticate, then the application needs to be confident that, once a wallet has granted it access to a an account, it can be sure that wallet owns that account in perpetuity. This assumption is what makes my security senses tingle. It seems like an attack vector that could be exploited.

29

I love this… I 1might have a framework that could partner with what you have here. The potential for automation looks like it could work.

The wallet the two protocols(Browser/Framework), there are more than one browser examples.

I think this is a great foundation for adopting the offchain transactions in DeFi as it is going to increase.

OFF CHAIN TO BOT CHAIN THEN RETURNING TO ONCHAIN 4 CONFIRMATION OF TRANSACTIONS AT LEAST ONCE A DAY.

​🧙 Architecting Scalable DeFi: Automated Off-Chain Transaction Routing
​This framework proposes a scalable, trust-minimized solution for handling the growing volume of off-chain transactions in Decentralized Finance (DeFi) by integrating robust Automation Tools with Protocol-Level Wallets and a dedicated “Bot Chain” layer.
​The core value is delivering high-reach, personalized user experiences (like automated engagement and historical context tracking) while ensuring daily, accountable settlement back to a Layer 1 (L1) like Ethereum.
​The Scalability Challenge & Our Solution
​The immediate challenge in DeFi is managing increasing transaction frequency and user engagement without constantly incurring L1 gas costs.
​Proposed Mechanism:
​Off-Chain User Interaction: User engagement (e.g., micro-transactions, strategy execution, data aggregation) is captured and automated via an advanced Automation Layer.
​Bot Chain Routing: These interactions are batched and routed through a specialized, accountability-focused “Bot Chain” (an L2 or sidechain equivalent).
​On-Chain Settlement: The Bot Chain commits a cryptographic proof of the batched transactions to the L1 (Ethereum) at least once per day, ensuring finality and security.
​Accountability Triad: Accountability for the Bot Chain’s integrity is distributed across three key partners: The Platform Network (Smart Contract Layer), the Protocol/Framework (Routing and Execution), and the DevOps (Custodian/Operator of the Bot Chain).
​Architectural Breakdown for High Reach and Automation
​We break the system down into three layers, prioritizing the layer that offers the widest user reach and deepest automation capabilities.
​1. Automation Tools (Highest Reach, Execution)
​These tools simulate or monitor deep user behavior across decentralized applications (dApps), including intent tracking and navigation history. This layer is crucial for personalized DeFi strategies, automated onboarding flows, and retention mechanisms.

Tool Type Reach Capabilities
Wallet/Browser Protocol Automation Full dApp Control Multi-protocol support, headless operation, historical context logging
Transaction Scrapers / Aggregators Data Sourcing Dynamic data parsing, automated execution of complex financial actions
Cross-Protocol Simulators Cross-Chain

  1. Frameworks (Medium Reach, Strategic Logic)
    Frameworks provide the structure for dApps, embedding the core logic for user tracking, session history, and triggering engagement or transaction automation routines. They define the smart contract interactions based on user behavior captured by the Automation Tools.

Framework Focus Reach Strengths
Frontend Protocol Bindings High UI Control Embedding real-time tracking and wallet interaction logic in components
Server-Side Rendered (SSR) Wallets SEO + Engagement Combining on-chain data with off-chain user analytics for powerful insights
Backend API Logic Core Routing API-based logging of user behavior to determine necessary on-chain settlements

  1. Protocols (Low Reach, Foundational Security)
    Protocols define the fundamental, secure movement of data and assets. While they don’t automate engagement directly, they are essential for structure and trust.

Protocol Reach Use Case
HTTP/WebSockets Universal / Real-time Basic data exchange, real-time feedback, and notification system
OAuth/OpenID (Decentralized Identity) Identity Secure user login, profile access, and key management
Telemetry (gRPC, MQTT) Event-Driven

Integration Strategy for Scalable DeFi Services
To realize this automated engagement and transaction model:
Embed Telemetry: Use Frameworks to capture user intent and micro-actions before they become costly L1 transactions.
Automate Flows: Leverage Automation Tools to simulate and execute complex DeFi strategies (e.g., liquidations, yield farming rebalancing) on the Bot Chain.
Real-Time Nudges: Utilize WebSockets and similar protocols for instant, off-chain feedback to the user.
Track History: Store user session/strategy history (via the Automation Layer) and commit the resulting transaction proofs daily to the L1.
The combination of high-reach automation paired with a commitment to daily on-chain accountability is the key to scalable and personalized DeFi adoption.
Would you like to delve deeper into the structure of the “Bot Chain” or architect a specific implementation, like a DAO Treasury management tool?