Title: ERC_7710__Smart_Contract_Delegation
Category: Web

Author: danfinlay
Date: 2023-11-19T14:53:19.880Z

Edit: I have updated the title of this post to reflect that it evolved into a concrete ERC, with greater specificity, and this thread is the official discussion post for that ERC. Original title is below:
Title: Towards More Conversational Wallet Connections: A Proposal for the redeemDelegation Interface
Expands on ideas first shared in this talk at the Wallet UX Unconference in Istanbul 2023:
https://streameth.org/watch?event=wallet_unconference&session=65b8f8d6a5b2d09b88ec192f
Hello Ethereum Community,
I’m reaching out following my presentation at the Devconnect 2023 Istanbul UX Unconference. For those who couldn’t attend, I plan to share a video of that talk shortly. The focus of my presentation, and the reason for this post, revolves around reimagining how wallet connections could be more conversational and user-centric in the Ethereum space.
I’m here not just to propose an idea but to initiate a dialogue about how we can collectively enhance user interactions within our ecosystem. The concept I’m about to introduce is very much in its infancy and open to evolution, especially with insights from this community.
The Core Challenge
Our current model of initiating connections by exposing a user’s public address has several drawbacks, including vulnerability to phishing and the pressure on application developers to maintain complex indexing infrastructures. This system tends to favor well-established assets, creates barriers for newer entries, and has been tending wallets towards more and more centralized infrastructure to try to combat scams and add readability to an interaction pattern that is inherently unreadable and prone to excessive disclosure.
One way to improve user coherence and reduce reliance on centralized infrastructure is to put the site connection back in the user’s hands, and empower them to issue “session keys” for the dapp connection. These interactions can be explored if we first have a standard method for contract accounts to issue arbitrary session permissions (which can hopefully grow and evolve as an ecosystem).
One way session permissions can be issued is by giving a site a mechanism to request the type of asset it needs to proceed, and then giving the user an ability to select the set of assets/permissions that they want to share (requiring additional deliberative steps for the user, and reducing the risk of confirmation-fatigue).
Introducing redeemDelegation
To address these issues, I propose an abstract Solidity interface named redeemDelegation. Here’s a preliminary look at the interface. It’s very much a draft, and meant to start conversation:
function redeemDelegation(
    address onBehalfOf,
    TxParams calldata txParamsToCall,
    bytes authorization
) public;

The intent behind redeemDelegation is to enable contract accounts to adopt diverse authorization logics, thereby allowing for tailor-made and user-directed authorization when connecting to websites. This approach diverges from the current norm of websites dictating transactions, sometimes through obscure allowance methods, and could reduce the dependence on centralized infrastructures.
Envisioning Diverse Applications
With redeemDelegation, we could explore various innovative models:


The Powerbox/File-Picker Approach: This model would enable sites to request specific permissions, with users having the freedom to select assets and set boundaries for site interactions. This not only empowers users but also eases the burden on developers.


AI/LLM-Enabled Interactions: Imagine users specifying authorization terms in their own language, and AI models translating these into tangible authorization parameters. This could make for a more intuitive and user-friendly experience.


A Collaborative Journey Ahead
This concept is not just about a new interface; it’s about rethinking our approach to user interactions in the Ethereum ecosystem. It requires not only new code but also new ways of thinking and building.
I look forward to your thoughts, critiques, and suggestions. Let’s collaboratively explore how we can make wallet connections more secure, intuitive, and user-friendly.
Thank you for your time and consideration.
Best regards,
Dan Finlay, MetaMask

Author: danfinlay
Date: 2023-11-19T14:55:45.126Z

I want to just add: I think this is valuable to standardize around because while many wallets are creating session key standards right now, if we want applications to be able to request those session keys but not be locked into a single wallet, we need to be willing to converge around a common interface.

Author: danfinlay
Date: 2023-11-19T14:59:52.560Z

I was originally going to roll this together with a provider/RPC method also for requesting this session information, but at the Wallet Unconference a reasonable point was made: We might want that method to also abstract chain/execution-environment away, and so I will be working on a proposal for that at the CAIP level next. I consider this a bit of a prerequisite for an Ethereum contract acount to participate in that type of connection interaction.

Author: kdenhartog
Date: 2023-11-19T16:20:20.950Z

+1 to what you’re proposing here as a step forward. I do think it would be useful to consider how this might work with multi tenant smart contract wallets too. In this case, I suspect we’ll need support for stating the index of the address as well which means we may also need an optional 4th parameter for indicating to the smart contract which index is granting this permission.

Author: danfinlay
Date: 2023-11-20T13:16:25.275Z

kdenhartog:

I do think it would be useful to consider how this might work with multi tenant smart contract wallets too.


Is the type of multi-tenant account you’re talking about one where each account still has a unique address via a proxy, or no? If not, any link to standards related to addressing the latter type?

Author: kdenhartog
Date: 2023-11-20T16:56:09.770Z

Originally I wasn’t thinking about it in that way although an upgrade path to that would be incredibly useful (especially to prevent account freezing in the smart contract) at the tradeoff of the user managing their own smart contract/control their account more if they want.
Instead I’m thinking about it as a maps all the way down scenario.
E.g.
smart contact address maps to a “bank smart contract” which contains an individual identifier for each user called a bank account. Each user bank account then contains an identifier that maps to each session key. So, when user A with an EOA wants to send to user B who’s got a bank account they can send to smart contract identifier+bank account identifier kind of like how tradfi has a routing number and bank account number. When the smart contract receives the funds it updates the index of the user based on the identifier.
When user B wants to spend they can sign with any session key and submit to a bundler (probably hosted by the EOA wallet but not required). Each session key would map to an EOA account managed by the wallet and now we’ve effectively moved to a basic session key model with AA all managed by EOA wallet providers. The best part is because EOA wallets are helping to manage all this they can leverage their economies of scale to combine users transaction bundling in a way that incentivizes migration away from EOAs too.
The way in which you get more complex logic would be to use a proxy contract as you suggested. Originally I was just thinking all bank account get forced to use the same logic but that breaks a lot of the useful delegation primitives for no reason. If there’s a way we could just point to a single instance of a Authz validator contract that relies on state in the bank contract too then it would mean only a single instance needs to be deployed for everyone at the beginning and as users want their own bespoke Authz logic they can update over time. Alternatively the bank can also just update the default for users.
I’ve got to play catchup on some other work, so I’m hoping just writing about this for now is good enough for other people to understand until I can make a PoC to show what I mean by multi tenant wallets better.

Author: danfinlay
Date: 2023-11-21T13:27:30.916Z

kdenhartog:

I’m thinking about it as a maps all the way down scenario.


I think my example interface could handle this situation:
function redeemDelegation(
    address onBehalfOf,
    TxParams calldata txParamsToCall,
    bytes authorization
) public;

In this scenario, any contract can implement the redeemDelegation method and allow an authorized msg.sender to submit its bytes authorization to it in order to send a transaction onBehalfOf another account. It doesn’t really matter if that other account is a proxy account, or some NFT held within the onBehalfOf contract, what matters is that by submitting a valid payload to an authorized & authorizing contract, a recipient is able to invoke some given TxParams.

Author: 0xInuarashi
Date: 2023-11-29T07:29:51.157Z

in your vision, are functions of this interface intended to be single use (consume txdata, end) or are they moreso intended for some abstracted “allowance” functions ?
also im not sure how this would be uniquely more useful (in the instance where they are still single use transactions) than interpretting calldata into conversational language for users?

Author: danfinlay
Date: 2023-11-29T20:12:56.643Z

0xInuarashi:

in your vision, are functions of this interface intended to be single use (consume txdata, end) or are they moreso intended for some abstracted “allowance” functions ?


As abstracted allowance functions, because this can inherently also have call-count restrictions, making it work the other way if needed, making it more open ended, potentially supporting intent-style permissions.



 0xInuarashi:

im not sure how this would be uniquely more useful (in the instance where they are still single use transactions) than interpretting calldata into conversational language for users?


These are two different approaches to achieving some kind of safety. A couple advantages to this interaction pattern are:
This approach doesn’t rely on disclosing any information to the site (like your account & tx history) before granting it relevant permissions, improving privacy and reducing cherry-picking phishing attacks.
Comprehending arbitrary bytecode is an inherently hard problem, and most modern solutions rely on introducing new centralized systems for helping analyze this potentially inscrutable data. These systems are prone to censorship and downtime, are not available to offline signers, and are not able to represent all kinds of actions that an application might want to perform on a user’s behalf. By inverting the order of proposals, the user is able to understand what they are putting at risk with potentially no external dependency, while still permitting the application to perform arbitrary actions on their behalf.

Author: 0xInuarashi
Date: 2023-11-30T07:07:09.843Z

I see, great points!
In this flow, at what point and how, would the contract account approve the delegation and/or submit the delegation?

Author: MarkosHelp
Date: 2023-12-07T18:09:30.515Z

Fascinating proposal on the redeemDelegation interface for Ethereum wallet connections! I’m impressed with the idea of shifting the control of site connections back to the user, allowing for the issuance of session keys to dapps. The concept of varying authorization logic for contract accounts sounds promising for enhancing user-controlled and personalized authorization. The Powerbox/File-Picker model and AI/LLM-supported interactions are particularly intriguing. They seem to offer a more intuitive and user-friendly approach. This forward-thinking initiative could significantly reshape user interactions within the Ethereum ecosystem. Eager to see how this develops and the impact it will have!

Author: danfinlay
Date: 2023-12-15T03:30:59.160Z

Sorry for being so late, but here is the talk that introduced this pattern!: Decoding the Enigma: A Model for Transaction Safety

Author: danfinlay
Date: 2023-12-15T03:33:05.128Z

0xInuarashi:

In this flow, at what point and how, would the contract account approve the delegation and/or submit the delegation?


In response to a site initiating a request for some type of permission. The difference is the app would define its request by needs (not knowledge of the user), and the user would select appropriate permission on their side before returning a response.

Author: karandeep
Date: 2023-12-21T17:04:40.175Z

Here is a Proof of Concept (POC) that I did a week ago. You can view the demonstration video Demo Video and access the demo app Demo App.
It appears that this discussion revolves around a similar flow. The POC involves a complete client-side interaction, where the dapp interface requests permissions/scopes for the user’s account. The user then grants permissions based on their comfort level. This process creates a scoped session commitment on the blockchain, enabling the user to perform actions approved within that scope using the dapp interface.
I am interested in discussing this further if it aligns with the topic of conversation mentioned above.

Author: Praneeth
Date: 2024-01-27T02:26:53.816Z

Would it be possible same interface support things like closing out a session voluntarily (akin to course_notify) or maybe also a time-based one? Not sure if there might need to be more session state stored in the contract account related to user sessions.

Author: kopykat
Date: 2024-02-03T17:21:13.013Z

Very interesting discussion. How does the idea around redeeming delegation fit into existing smart contract accounts with a modular architecture, eg Safe, ZeroDevs Kernel or the Biconomy account? It seems like the modular approach to signature validation in these accounts tries to achieve a similar goal as the architecture described above.

Author: mcoso
Date: 2024-02-21T16:03:45.527Z

I think it could work quite well together. A specific plugin thats works with modular accounts could be created to support this extensible feature, redeem delegation. But whats good about generalizing the redeem delegation function is it doesn’t lock anyone into anything. Ex. it doesn’t force you to have a modular smart account

Author: tomarsachin2271
Date: 2024-02-28T20:29:58.862Z

Not able to access this link, can you please check. Link opens up this page
Screenshot 2024-02-29 at 12.28.51 AM2030×1156 104 KB

Author: bumblefudge
Date: 2024-02-29T01:19:36.188Z

tomarsachin2271:

Not able to access this link, can you please check.


I think this is the recording he means, but his talk was broken up across multiple sessions, so it might make more sense to try multiple of them for full context (and Q&A):
https://streameth.org/devconnect/wallet_unconference

Author: danfinlay
Date: 2024-03-12T18:39:49.838Z

Thanks! Updated the OP.

Author: danfinlay
Date: 2024-03-12T18:44:56.259Z

This proposal is intended to provide a unified interface that can be exposed from any smart account, allowing us to advance towards a safer dapp-wallet connection while unimpeding the innovation of smart accounts.

Author: danfinlay
Date: 2024-03-12T19:03:15.894Z

karandeep:

Here is a Proof of Concept (POC) that I did a week ago. You can view the demonstration video Demo Video  and access the demo app Demo App .
It appears that this discussion revolves around a similar flow. The POC involves a complete client-side interaction, where the dapp interface requests permissions/scopes for the user’s account. The user then grants permissions based on their comfort level. This process creates a scoped session commitment on the blockchain, enabling the user to perform actions approved within that scope using the dapp interface.


Yes, this looks like a UX that could be built on the proposed interface, in a way that allows the requesting dapp to interact with many types of smart accounts, not just one.

Author: danfinlay
Date: 2024-03-12T19:09:03.601Z

A point that is in the video talk but not in this original post is the idea of the wallet provider method that might pair with this. Something like wallet_requestOnchainPermissions.
The goal of that method would be to allow the site to specify what it needs to do (and possibly justify that request), while remaining agnostic to the implementation of the granting account (possibly by utilizing a generic redemption method like the redeemDelegation described above).
A very simple conversation-starter level sketch of that method might be:
const [approverAddress, approvingBytes] = await provider.request({
  method: 'wallet_requestOnchainPermission',
  params: [{
    method: 'erc20_transfer',
    contract: TOKEN_ADDRESS,
    chainId,
    justification: "Just in case I want to spend it."
  }]
});

The approvingBytes could then be usable as described above:
const approver = new Contract(approverAddress);
approver.redeemDelegation(approvingBytes, intendedOperation);

Author: danfinlay
Date: 2024-03-13T00:42:05.923Z

I did a fresh summary of the current state of this thread’s proposal in a new tiny blog post.

Author: xinbenlv
Date: 2024-03-15T14:38:06.018Z

Love the idea, Dan.
We are resuming the regular call of AllERCDevs, care to come to share the idea with ERC authors and builders? Next is 2024-03-21 UTC1700 online if you are open to it.

Author: danfinlay
Date: 2024-05-21T20:57:56.898Z

We have now developed this idea to enough maturity that we’ve opened an ERC!:
https://github.com/ethereum/ERCs/pull/433

Author: fmc
Date: 2024-05-22T11:27:01.669Z

Looks like a whole new vector for the proposal!


Could you please elaborate on how you see it compatible with 4337 gas compensation mechanism? Let’s say redeemer wants Smart Account to pay for gas. However, the userOp.sender has to be Delegation Manager.




A Delegation Manager is a singleton smart contract
Any ideas on the potential architecture for it?


Is it going to store the permissions per smart account to validate a delegation?
or is it expected that the signed permissions object is provided as part of _data argument of executeDelegatedAction function? thus only the logic of validating this object against action sits in the Delegation Manager?
or any other approach?

Author: mcoso
Date: 2024-05-22T20:33:18.380Z

Could you please elaborate on how you see it compatible with 4337 gas compensation mechanism? Let’s say redeemer wants Smart Account to pay for gas. However, the userOp.sender has to be Delegation Manager.


The userOp.sender doesn’t have to be the Delegation Manager, the call just has to go into the redeemDelegation of the Delegation Manager. So the userOp.sender would be the 4337 SCA and the userOp.callData would call the execute function on the SCA which then calls redeemDelegation on the Delegation Manager.


A Delegation Manager is a singleton smart contract
Any ideas on the potential architecture for it?


I think the best approach is keeping the delegation validation logic in the Delegation Manager. Passing in the signed permissions via the _data field of the redeemDelegation function.

Author: danfinlay
Date: 2024-05-26T19:06:15.820Z

Another component of the OP talk & concept has now been reflected in a new ERC: 7715, an RPC method for sites to request permissions from a signer: Add ERC: Request Permissions from Wallets by pedrouid · Pull Request #436 · ethereum/ERCs · GitHub

Author: VGabriel45
Date: 2024-09-30T17:18:57.574Z

Awesome idea, it seems like a very nice way to improve the current UX while also adding an extra layer of security. I like the part where the user doesn’t have to expose his public key anymore and the fact that the proposing power is in the user’s hands.
However, I have a concern about the potential risks once permissions are granted. Under this model, once a user has delegated authority to a dApp for a specific action, such as minting an NFT or performing token swaps, can the dApp execute these actions without requiring further user approval? If so, wouldn’t this be very risky for big Dapps like Uniswap, where a user might need to allow a lot more permissions and assets.

Author: danfinlay
Date: 2024-11-14T17:07:56.423Z

VGabriel45:

once a user has delegated authority to a dApp for a specific action, such as minting an NFT or performing token swaps, can the dApp execute these actions without requiring further user approval? If so, wouldn’t this be very risky for big Dapps like Uniswap, where a user might need to allow a lot more permissions and assets.


That describes the current state of the art with a dapp like uniswap, where it reqeusts a token allowance for each token you intend to swap with. So at the very worst, it would be no different.
However, the user’s account would also be able to add additional constraints:

Time limits
Expected return rates
Subscribe to security/revocation services
???

Also, these permissions could issue other things (not just token allowances), so while the benefits to a highly trusted site like Uniswap may be minimal, it would also allow signing into sites with other types of permissions as readably as token allowances.

Author: frangio
Date: 2024-12-22T17:11:06.585Z

I like the design of this ERC and I think it solves a real problem, but I think the specification is so minimal that it is very difficult to follow and understand, and I’m concerned it will be an obstacle for adoption. This is not a comment on the scope, which I understand and appreciate is minimal by design, but on the thoroughness with which in-scope elements are described.
Here are some questions I have that I think should be answered in the ERC:

How does a delegate obtain a delegation?

Is it explicitly out of scope of this ERC? If so that’s good but IMO deserves clarification.
Is ERC-7715 accepted by the ERC authors as a/the way to request a delegation?


In what sense and why is a delegation manager a singleton?

Other parts of the spec imply there may be many delegation managers, with potentially different implementations, which doesn’t square with my concept of a “singleton” (something that would be shared by all users of ERC-7710).


Can a delegator be its own delegation manager? Would this make sense?

What is the rationale for having delegation managers rather than putting the redeemDelegation function in delegators themselves?


What does the delegation manager actually do during redeemDelegations? Specifically how does it validate permission contexts?

If this is up to implementers, it would be good to show an example.
I would make it explicit that (at least by default) a permission context is only valid for a specific delegation manager, and that the structure and semantics of a permission context depends on that delegation manager.

Update: Just noticed the comment below, I think it needs to be more prominent. Where it says bytes[], is that implying that the structure of the _permissionContexts array (length, ordering) is implementation-dependent, or is it referring to each individual bytes element?

@dev the structure of the _permissionContexts bytes[] is determined by the specific Delegation Manager implementation







More technical points about redeemDelegations that I think should be spelled out:

Should the three arrays be interpreted as a list of n tuples (contexts[i], modes[i], data[i])?

If so, what should happen if the arrays have different lengths?


What should happen if one of the permission contexts is invalid? Or if it is valid but the delegator reverts on executing the delegated action?

I assume neither case should interfere with the rest of the delegations in the bundle.


Should an implementation first validate all permission contexts and then execute all actions, or should it alternate between validation and immediate execution of each one? Perhaps both are acceptable but there is reason to recommend one?

Since the ERC has evolved quite a bit from its original form, and this post is linked as the discussions thread, it would be good to update the title and change the first post to match the new design or add a notice about the changes.

Author: Arvolear
Date: 2024-12-24T12:58:52.767Z

Want to also ask several questions about the EIP purpose and applicability.

As far as I understand, the current EIP specification has come quite far from “Conversational Wallet Connections”. To me, the phrase “Wallet Connection” means some front end interaction between a DAPP, RPC, and a wallet (like WalletConnect). Currently the EIP is more about the generalization of an “approve” semantics.
It would be great to see some elaboration of the “permission validation” section. Is this an ECDSA signature, a ZK proof, or a transaction that changes a smart contract state to “approved”?
How exactly will this EIP fight the “interactiveness doom”? I mean, Uniswap implemented Permit2 which improved the UX a lot. However, a user still needs to click the “sign” button in the wallet every time.

I suppose there have to be some session keys introduced. But what is a session key in the first place?


How will the DAPP check that it actually has a permission to execute a certain action on a user’s behalf? I believe the ERC7710Manager has to be expanded to allow for these checks. Say if the check returns false, a DAPP will be able to “reask” a user for the new permission.
Unfortunately there is no getting away from the poor ERC20/ERC721 approve mechanics. How will this EIP aid this?

Thanks!

Author: danfinlay
Date: 2025-03-19T17:26:04.975Z

Hey @frangio and @Arvolear, thanks for the read and questions, and sorry for the slow reply.
I went over your questions with my co authors this morning, and we’ve PR’d some updates to the ERC here: Improved ERC in response to feedback on ethereum magicians by danfinlay · Pull Request #982 · ethereum/ERCs · GitHub
I’ll now have an AI pull out the specific answers to your questions from the doc here:
Obtaining Delegations
The ERC explicitly states that the process of obtaining delegations is intentionally left out of scope. From the specification:

The process by which a delegate obtains a delegation is intentionally left out of scope for this ERC. This ERC focuses solely on the interface for redeeming delegations and the validation of delegation authority.

Regarding ERC-7715, the document acknowledges it as one potential way to request delegations:

The mechanism for requesting and granting delegations may be implemented in various ways depending on the use case, such as through ERC-7715 or other protocols.

Delegation Managers
The document clarifies that multiple Delegation Managers can exist with different implementations:

A Delegation Manager is a smart contract that validates delegation authority and calls on the Delegator to execute an action. It implements the ERC7710Manager interface. A Delegation Manager verifies and processes delegation redemptions, and multiple Delegation Managers can exist with different implementations.

And yes, a contract can be its own delegation manager:

A contract account can be its own delegation manager.

Rationale for Delegation Managers
The specification explains that Delegation Managers were introduced to improve compatibility with existing smart accounts. Initially, the ERC required delegators to implement a specific execution interface, but this approach had limitations:

Existing smart accounts won’t be compatible with this spec (unless they happen to implement the execution interface).

By removing this requirement and placing responsibility on the Delegation Manager, the standard maintains flexibility while ensuring:

We rely on the Delegation Manager to correctly call the delegator, and we rely on the fact that a delegator would only create _permissionContexts for a Delegation Manager that knows how to correctly call it.

Permission Contexts and Validation
You’re right that more clarity is needed on how permission contexts are validated. The specification now references the MetaMask Delegation Framework as a reference implementation, which includes “EIP-712 signature validation for delegations” and “Support for both EOA and contract signatures (ERC-1271)”.
Regarding the structure of _permissionContexts, the ERC specifies:

The three arrays MUST be interpreted as a list of tuples, where each tuple consists of (_permissionContexts[i], _modes[i], _executionCallDatas[i]). The function MUST revert if the arrays have different lengths. Each tuple represents a single delegation redemption with its associated permission context, execution mode, and execution data. Implementations MUST enforce atomicity of the batch.

This clarifies that:

The arrays form tuples
They must have the same length
The batch is atomic (if one fails, all fail)

Permission Verification
The ERC recommends a simulation-based approach for permission verification:

While this interface does not include an explicit method for checking delegation permissions, dApps SHOULD verify permissions before attempting to execute actions by:

Simulating the redeemDelegations call with the intended parameters
Using the simulation results to determine if the delegation would succeed
If the simulation fails, the dApp can request new or updated permissions from the user


Additionally, there’s a security considerations section that addresses permission verification:

dApps MUST NOT assume that having received a delegation in the past guarantees future execution rights. Delegations can be revoked, expire, or become invalid due to state changes.

Relation to “Conversational Wallet Connections”
While not explicitly addressed in the document, the ERC does mention use cases related to reducing user interaction:

The proposed standard aims to solve these challenges by enabling the creation of long-lived sessions and delegated permissions through a single signature. These delegations can be used to:

Establish persistent sessions with dApps that don’t require repeated signing
Grant bounded permissions to AI agents or automated systems


This hints at how the standard could help fight “interactiveness doom” by enabling persistent sessions that don’t require repeated signing.
Session Keys
Session keys now highlighted in the Motivation section, and are addressed in greater detail in ERC-7715.

I hope these clarifications are helpful! Would you like me to elaborate on any particular aspect of the ERC?

Author: poojaranjan
Date: 2025-04-30T14:15:17.357Z

ERC-7710: Smart Contract Delegation with @DanFinlay