What is this about?

The discussion focuses on improving the Ethereum user experience by proposing a more conversational approach to wallet connections. The redeemDelegation interface, introduced by Danfinlay, aims to allow contract accounts to use various authorization logics, which would enable personalized user authorization when connecting to websites¹. This interface would let a contract authorize a transaction for another account with a valid authorization payload⁸. The idea of multi-tenant smart contract wallets is also explored, suggesting that a smart contract address could function like a "bank smart contract," with unique identifiers for each user⁷.

How is the community reacting?

The community is supportive and actively engaged in discussing the proposal's potential impact, particularly on multi-tenant smart contract wallets. An optional 4th parameter has been proposed to help smart contracts identify the user granting permission⁴. Danfinlay has requested clarification on the type of multi-tenant account under discussion and has asked for links to any relevant standards⁶. Kdenhartog has suggested a system for these wallets and is developing a Proof of Concept (PoC) to showcase the idea⁷. The community is collaborating to refine and understand the proposed systems.

Additionally, 0xInuarashi has raised a question about the specific point and method in which a contract account would approve and submit a delegation within a certain process¹¹.

Why this is positive?

• The proposal could reduce reliance on centralized infrastructures, empowering users and simplifying the development process¹.
• It opens up new possibilities for the application of redeemDelegation, such as the Powerbox/File-Picker Approach and AI/LLM-Enabled Interactions¹.
• Discussions about multi-tenant smart contract wallets may lead to a more comprehensive and inclusive solution ^4,6,7.
• Danfinlay's focus on standardization is seen as beneficial, as it could allow applications to request session keys without being tied to a single wallet infrastructure².

Why this is negative?

• The proposal adds complexity, especially with the implementation of the redeemDelegation interface and the potential addition of an optional 4th parameter for multi-tenant smart contract wallets⁴.
• The drive for standardization could hinder the speed of adoption².
• Conversations around multi-tenant smart contract wallets introduce additional complexity and challenges for the community to solve ^6,7,8.
• 0xInuarashi has concerns about the use of functions in a certain interface, questioning their purpose for single-use transactions or "allowance" functions, and the unique value of the interface for single-use transactions compared to making calldata understandable for users⁹.
• Danfinlay explains that the interface is meant for abstracted allowance functions, which may include call-count restrictions, providing flexibility and supporting intent-style permissions. This method has benefits over translating calldata into conversational language for users, such as better privacy, lower phishing risks, and independence from centralized systems that may face censorship or downtime. It allows users to understand risks without external dependencies while still enabling applications to perform arbitrary actions on their behalf¹⁰.

Next actions

No next action has been determined.