+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.
1 Like
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?
1 Like
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.
1 Like
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.
1 Like
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?
1 Like
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.
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.
I see, great points!
In this flow, at what point and how, would the contract account approve the delegation and/or submit the delegation?
1 Like
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!
Sorry for being so late, but here is the talk that introduced this pattern!: Decoding the Enigma: A Model for Transaction Safety
1 Like
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.
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.
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.
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.
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
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):
1 Like
Thanks! Updated the OP.
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.
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.
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);