ERC-7710: Smart Contract Delegation

Transcript

And if we can achieve this instantly and without gas, then that means users don't have to think about gas. And I think that that's actually like a huge win topic of this ERC 7710. This is the method for redeeming a delegation. It's just a standard way for any contract to say, "Hey, I gave you permission to do something. Well, here's how to now ask me to do it." If you're an app developer, try out our hackathon. You can just try it from the outside. So, receive a permission, use it. That's one side. And then for smart contract account developers, take a look at it. You know, try building this into your account. If MetaMask could do one thing that it doesn't do today, what it should be, let you sign into sites with a DAO like represent organizations when you connect to stuff.

[Music] Welcome to Penney, where we unpack Ethereum improvement proposals with people who write them, review them, and help bring them to [Music] life. This episode is brought to you by ECH Institute and I'm your host Puja Randal. Today we are diving into ERC 7710 smart contract delegation a new proposal that introduces a standardized interface for delegating capabilities to contract and EOS. Especially excited to

welcome Dan Finlay, co-founder of MetaMask and one of the co-author of this proposal. Dan has been instrumental in pushing the boundaries of users experience, smart wallet infrastructure and now modular delegation framework through this ERC. Welcome Dan to Penney. Hey Puja, thanks for having me. I I really love PPE as a resource for reviewing proposals. So I'm excited to get this one in the cannon. Right. I mean it is a long wait. I I remember four years ago I had a conversation with Eric when we first knew how Metam Mask is involved with all interface proposal and help them support get finalized. So it's a long wait but really finally happy to have you here. So for those who

are new to the ecosystem, may you want to share a little bit about yourself, how you found Ethereum, your journey and what is that you are looking forward to in 2025? Sure. Yeah. So, I was around Ethereum kind of at the beginning and it was appealing to me because it seemed to scratch an itch that a lot of applications I wanted to make kind of needed. They they would benefit from some kind of trustworthy computer to use. Some way to pay, some way to vote where no one can corrupt it, some way to signal opinions. I think a lot of people were trying to figure out how we can use computers to do slightly more ambitious things while keeping safety. And so MetaMask was just a requirement like we

needed a way to for users to interact with this new generation of accounts. And our first generation of MetaMask was basically just implementing the GU RPC API which has like send transaction. And so when you start from that low-level API, you have a certain relationship to the proposer. And you know, I don't think send transaction was originally designed as this is something you'll give to a stranger, but that's the situation we found ourselves in today where strangers tell you some bites and then you try to guess what they'll do and then you try to make an informed decision. And that's that's just not enabled the kind of ecosystem I really want. I really think that we've got an opportunity to build much more collaborative, much more sophisticated,

you know, organizations, economic relationships, things where funds can flow over many hops easily with custom terms and organizations at any point in the network. And so, it's taken a long time to mature our thinking, requirements, and designs for a better way for wallets and apps to interconnect. And so today I'm I'm hoping to share one very simple interface that I think makes a pretty big change to the relationship between user wallets and applications they connect to. And I think that uh you know its simplicity may kind of hide the fact that this kind of thing composes really well. And you know I think my favorite software in the world it's software you

know it's not just a good feature it's a composable component that allows complexity to emerge. And I think this is a really emergent kind of pattern and and I think we've seen web 3 is all about emergence. You know, you never know how someone's going to use your contract once it's out there. So what are the kind of interfaces that allow the good kind of emergence where people know what they're doing and they're composing freely without the bad kind of emergence where people are making mistakes and, you know, losing their funds and and just kind of generally uninformed about what they're doing. That is pretty interesting backstory.

And I don't know how many people remember my ether wallet because when MetaMask was there like it was like a revolution and it helped in many way for smart contract developer as well as end users. So thank you for providing that and also helping us with these kind of proposals interface layer proposals which are really important for all upcoming projects. Well done. I'm looking forward to learn more about EIP7710 smart contract delegation. But before we get to the technical conversation, I would like to share that today we are also joined by an incredible group of contributors. Our community partner ETC clutch and the Ethereum community in Romania. ETC

clutch is organizing an event in summer and uh this is a very good opportunity for people to learn more about ERC's as well as get some discounted ticket for events. So I would like to invite Simona and her team to maybe share a little bit about uh the event and how people can participate. We'll get to know more details at the end. But Simona, you are welcome. Hello. Thank you so much Pusha for the nice introduction. Lovely to be here. Thank you for the invitation. So just a very little bit about Yeah, we're a technical Ethereum community to be more precise. We are focused around education and growth and located in the heart of uh Transennsylvania inclusion the conference this year it's our first

one it's just basically a main event let's say for this year but the initiatives that we develop are spanned all throughout the year and we encourage everybody to join in and see what we're all about. So yeah as for the conference as you very well mentioned puja we have developed this initiative called road to ethl cluge and what we want to achieve with this is make sure that we have people who are interested in the technical knowledge that we are trying to put out there to join in our meetings whether they are online or in real life or just purely social you know just want to get to know us or just chat with us please feel free to join in and anybody

that attends s one of our meetings will be able to mint a POP. This POP grants its holder with a 25% discount to the conference. And yes, this can be accumulated to up to one free ticket. We want to be generous with everybody that is curious, passionate or wants to get involved in the conference. And u yeah that's the goal of this campaign. Thank you so much Puja and Ethereum cat herders for hosting us. And yeah, without further ado, um, open the way for the actual presentation and um, thank you for having us again. Cheers.

Thank you, Simona. I really hope that conversation that we are going to have here today will be helpful for the technical community that you're trying to grow over the it clutch community and Romania. Thank you. Well, that's out of the way. Uh, perhaps we can dive into the proposal. So, without further ado, let's weep in. Okay. So today I'm talking about redeem delegation. This is Oh, it's actually ERC7710. Yeah. So like I started describing earlier, ERC7710 aspires to describe a new way for smart contract accounts to grant permissions to other accounts. So you'll see I I use the words delegation and permission a little interchangeably in

this talk. In fact, at one point, I think they're even called permissions context to refer to the the raw bytes that represent this thing. And I think the theme has to do with how do you represent an open-ended authorization in a world where user accounts are increasingly programmable. I think I think we're entering the programmable accounts era. So to uh set the stage, I'll talk about the current state of DAP development. I'll describe a generally different model for interacting with things in computers and how that might be applied to Ethereum. Then I'll talk about how we can make that possible. And I'll talk about the implications for embedded wallets, which I think are a nice fun topic these days. So, first of all, the the current state of Ethereum app development is all about connect.

And I'd argue that connect is very ambiguous. I've been a part of absolutely countless debates and conversations about what the heck connect means. And actually, most wallets, I should have another screenshot of what wallets show when connection is requested because it kind of has to list a bunch of things. It says, "Oh, well, it'll be able to see your address. It'll be able to see all your assets. It'll be able to propose transactions and signatures." And being able to see all your assets is pretty big deal. So, it's generally I think the good thing about this is it's modeled after web 20. So, it's a very familiar pattern. you see a connect button, you you get the idea you're going to be logging into this site. But because you have that disclosure of all assets, you get some interesting uh problems. Also,

there's no proof or empowerment here, right? So, at best now, it can show you what you already know you have, and maybe it can suggest more contextual interactions, but at the very least, you're going to now have subsequent interactions. There's there's going to be a signature proposal, a signin with Ethereum proposal, maybe an allowance, and then a send, right? There's always more. So this interaction alone is it's simultaneously kind of more than necessary like all your knowledge of all your assets and then also less than necessary because it doesn't allow anything to be done. So this general pattern you can describe as show me what you got and give me what I want. This is what daffs get to say to a person today.

So first you say show me what you got and then once they see everything you have then they get to suggest something and now your wallet tries to estimate what will happen. Let me see here. So the requesttor is always in a position of specifying the terms. The user at best so they get full v visibility into what you have and and fishers can and do adapt their second request based on what you have. So a fisher might say okay I'm going to make sure lots of smalltime buyers get a normal experience that you know you put in an ETH you get an ETH or whatever you get a raft and then I wait for a whale and then I give them my real payload where I do something malicious or sneaky. And so since the DAP gets to request anything they want, it puts the

the user's wallet on defense mode. You try to interpret it, but it's not inherently readable. Nothing about the proposed transaction bytes is readable. It's it's left to the wallet. The wallet has to say, "Okay, so how do we interpret it?" Okay, wallets can do today is they can have a centralized registry of contracts and their known interfaces. This is hard to maintain. It's slower than the ecosystem moves. Uh it's prone to errors. You can have a four byte registry. This is another popular centralized registry, but you get situations where there's like a race to register and sometimes trolls will register fake method identifiers and so you can't just rely on that either. And also not to mention method interfaces don't have parameter names. It's not

really enough information to render a rich interface. You can have curated metadata. You might have seen Ledger's clear signing proposal. This is like a nice increasingly rich database of of good metadata that shows you know somewhat certified interfaces for different contracts. This this is huge. It requires a lot of curation and it's creates a bigger and bigger wallet package or hosted infra and of course it doesn't work on new contracts and yeah compiling verified contracts and hosting that. We've actually we've tried that at MetaMask and it was actually a really big complex backend and people weren't using it that much. is a kind of sad in between spot of being really expensive and and not that useful. And then how

about simulation? Simulation has kind of emerged as the new popular way for wallets to deal with this. And I think some people feel like maybe we've found correct solution to this problem with simulation. The core problem with simulation is that it's only estimated changes. But that's not the only problem. So, so first of all, since they're estimated, fissers are manipulating simulations with trap doors. And as people lean on simulations for safety more, fishers will do this more often and with more sophistication. That means having a contract that you know in one moment would give you what you expect, but they you know aim to frontr run your actual transaction. You know just between the time of proposal and submission. So even if your simulation is totally right and even if

you're submitting to a private me if they have an opportunity to change the state of the contract, they can change what it does. Also, approval signatures that are off-chain are unsimulatable. You don't know exactly what how an allowance is going to get used, especially if that contract isn't on chain yet. You can't simulate something you don't even know about. And simulations require they can only simulate each transaction that the user is considering. Which means we're still in this world where you connect and then you have to approve every single interaction that is ever performed on your behalf. Even if they're all within a broad category of things that you kind of approved, like you went to an exchange, you gave it an allowance to swap for a token you want, but now you

still have to approve each swap, which is tedious and annoying and and probably unnecessary because you already expressed your security preferences. And not to mention the massive infrastructure, right? simulations require somebody's running the whole chain. You know, we hope that light clients can make this a little bit better, but this still brings, you know, it brings extra computational weight just to be running these contracts that you hope are behaving the way you expect. So, let's talk about a different model. You know, computers have been around for a while. People do things a lot of different ways. How do other kinds of software deal with this kind of problem? Well, for one thing, we can think about the file picker. File picker is a really familiar pattern. We've all

used it. It's been getting used since like 1990, right? So 35 years of experience picking files. It's and it's kind of nice. It's it's crossplatform. It's a really well established pattern. Works on touch and mobile. And the requesting application never sees what you have before it picks a file. Right? If we did the connect and then propose transaction model on a file picker, it would be every application gets to see your whole file system and then sends you some unreadable bytes about some transformation to perform. That would be unacceptable. We love that we can pick one file and upload that file. And this pattern has some cool features. You know, the requesttor can even specify a type and so you can filter what you're picking from. And now you reduce the user's cognitive overhead. You're only

thinking about a JPEGs. you know, you're in a image editor, you should only be looking at images in your file system. And so now you're very contextual. And because you're in the context of your file system, you're much less likely to make a mistake. They're not just naming a random file path and requesting it. You are navigating on your disk to select the file that you intend. I think this is a really powerful moment where by putting the responsibility in the user's hand, you ensure a deliberate action. And the general picker pattern has only gotten better over time. You know, the iOS photo picker finally added a great feature where you can even change how much you're granting when you select a photo. So something might ask for a photo, but you might decide to

exclude your location from it, which you know is pretty valuable if you're, I don't know, in crypto for example, right? So reducing we we in computer security, this is sometimes called the principle of least authority, right? You should always be striving to grant the smallest thing necessary to enable the thing you're trying to do. And a lot of times, you know, the picture is the only thing you're trying to send. The location was like toxic waste. It was it was pure danger. There was no reason to be granting it. So, are we doing something similar in web 3? Could we let users pick what they have and attenuate it a little bit? So, now here's here's the fun slide. We got a little wireframe here. So, what if you had that pattern in web 3? So the site could specify what it needs and then the user could choose

what they want to grant and we can filter what they have based on which accounts have the relevant balance and you know perhaps the user could even add extra terms. They could add I I didn't uh have the time to add um some extra screens for this, but you know, the user could add extra terms. For example, an expiration date. Um maybe a changing amount, maybe even an expected outcome where you would only grant this amount if you were actually going to receive a token in return. So rather than putting the guarantees on the the contract you're interacting with and your simulation estimating what it's going to do, what if your wallet knew how to

enforce those expectations? And so the approval that you grant to the site itself is your own smart contract code enforcing your expectations of the interaction. By the way, this is inherently chain abstracted, right? If the requester just says what currency on what chain, the user never really has to think about it. They pick from the accounts that have that token on that chain and that's the end of it. And by the way, this works without the connect pattern, right? A site could request some allowance or some subscription or even a vote delegation or, you know, the right to set your ENS name without knowing what you had beforehand. It could just say, "Hey, I'm a ENS updater or I'm a, you know, I'm a Warpcast

poster. If you give me permission over a Warpcast account, I can, you know, post the weather for you or whatever." And you could then just pick a compatible asset and grant that. So, this is a way to preserve some more user privacy, too, because the user doesn't need to disclose anything before the site potentially requests it. So, and by the way, I believe that this can be achieved instantly without gas. And if we can achieve this instantly and without gas, then that means users don't have to think about gas. And I think that that's actually like a huge win.

It's not just a win because of the cognitive overhead. It's also a win because today needing to have Ether or the the chains gas token in your account blocks a buyer estimate up to 40% of transactions. So, it's like a huge user obstacle. People don't get why they have to have another currency. I've I've got the money that they're asking for. Why can't they pay the transaction from that? I think we can do that. Okay. So, this is kind of the pattern that I'm aiming for with this proposal. So, I've kind of set the stage here. I think this is entirely possible. And so, we're trying to lay the groundwork for that.

Now, to grant requested permissions, first we have to define a permission. What is the thing that we're approving? What is the thing that we're giving to the website? And that's going to be the topic of this ERC7710. This is the method for redeeming a delegation. It's just a standard way for any contract to say, "Hey, I gave you permission to do something. Well, here's how to now ask me to do it." This is the whole interface. It's just one method. I think it's worth a talk though because it completely flips on its head the way that we interact with DAPs. So, any account can just specify a delegation manager. You can be your own delegation manager or you can subscribe to one. It could be an owner on your account. But the important thing is that it

implements this redeem delegations method. Now the redeem delegations method I'll first just touch this modes and execution call data. That's the kind of confusing complicated part. Oh, also it's three arrays, right? That's because it's delegations. So you can think of these as one array where each item has a permission, a mode, and a call data. All right. Now, the mode and call data pattern we borrowed from ERC 7579. It's the minimal modular smart contract standard that I think you've had on the show. So, that's nice because it gives us um a way to express any kind of action that an account might perform.

So, mode zero is a normal execution. Mode one, this will be interpreted as a batch. And there's room to continue adding modes. So, they can be do things like creating new contracts. And yeah, this is a way to just redeem a batch of permissions. Often it might just be one permission, but if you provide a full batch, then they will be executed atomically. So you can actually have permissions that require the results of other actions in the same batch, which I'm not even going to try to get into too. Well, tell you, I'll give an example. If I if you said, hey, I'll give you 10 USDC for that NFT, but I don't have that NFT, and I find somebody else who says they would give it to me for nine, right? I I could actually

batch those and because the permissions might each give me permission to have something on the condition of having the other thing at the end of the transaction at the end of the batch, then I can actually I can kind of flash borrow all of the permissions as long as I can resolve the batch in a way that satisfies all of their terms. I know that's a big one, but uh I have a talk from ETHC Brussels last year in 2024 and and we talk quite a bit more length on that topic. Okay. So, so this doesn't have any opinion on how the contract enforces opinions that that that's probably the most frustrating thing about this. I think most people who read this, they're like, "Okay, yeah, but how do you implement the permissions?"

Actually, what we were finding is that when we were exploring ways of creating this kind of file picker-l like pattern, we kept coming up with ways of doing it better and better and and not only did we come up with our own improvements, we kept seeing other people have their own improvements for how to do this better. And so, we wanted room to compete, we wanted any account to be able to implement this, no matter how they work internally. And we wanted room to improve. I think really critically privacy preserving is something that you know our current drafts of this don't have but this interface could completely do. You could imagine a lot of smart contract accounts sharing a single delegation manager that obscures which account is actually granting some given assets. So this is a path. This is a

pattern that allows us to have simple permissions today, but with that same interaction pattern, establish a pattern that can keep on improving for a long time to achieve some pretty important goals I think for blockchains as a whole. And I think privacy needs to be part of our roadmap and and it is part of this road map. So the important thing is that the delegate does need to know the address of your delegation manager. So, however you give some permission to somebody else, they need to know the address of your delegation manager. They need a sense of what the permission you gave them lets them do. And from there, they should be able to call uh methods on your behalf. That's basically the goal of this method. It's a method to standardize how accounts expose a

singular way of sharing any permission. I I believe any account today should be able to add this. You know, for example, if you're a modular smart account, you could add you could just add a delegation manager as a module. And so now you would be able to specify that delegation manager and you could have many different delegation managers as multiple modules for different kinds of permissions that you might want to issue and ah yeah and I already touched on how the batch is atomic. All right. So I touched briefly on privacy. I want to emphasize that a little more. By separating the redemption from the issuing account, we have a path to privacy. I think I hit that, but I'm really excited about it. Okay, so now I'm going to compare this pattern to a

few other things. Okay, so we've got this redeem delegation. What's the common pattern today? Today, permissions for using an asset are always defined on the assets contract itself. Why does that matter? What does that change? So in ERC20, you have approve. On 721, you also have a slightly different approve method. And users aren't able to express a permission in any more sophisticated terms than that. You don't get an expiration. You don't have some other condition like if somebody else signs on it or as long as the price is this or as long as I get that asset in return.

Anything more imaginative or more complex is simply not available today. And so we're just stuck. If your token implemented that, that's what you can give. If it doesn't offer anything else, that that's too bad. And some contracts only expose methods that are very insecure. Like I think notoriously ERC 1155 with its set approveof all, it only lets you give allowance to all of your NFTts. So for example, every time someone wanted to sell a single board ape, they would have to give that exchange permission to take all of their board apes uh with no recourse. And this of course resulted in some mistakes. You know, it would be one thing if you got fished and you lost one of your favorite

NFTts, but what if every time you got fished, it was for all of them? That would be very tragic. And you know, so we're not saying you we can solve mistakes. Sometimes you might use a bad exchange. Now, I do think we can create terms that protect you in a lot of cases, but at the very least, limiting damage is a really powerful tool that you just don't get from some contract allowance methods today. Also, a lot of times contract accounts might not be supported for counterfactual permissions. So, ERC20 does sometimes use an extension where you have the permit method. And the permit method lets you sign a a message that gives somebody an allowance. And that's that's pretty cool. It doesn't work for

contract accounts. You don't have an easy way to mass revoke them. Uh there's also no way to mass revoke them. Also, let's say you make a new asset type, you know, like a domain name or a vote app, right? Every time you make a new function in the Ethereum blockchain today, you're stuck with the question of how should you model your permissions? You're making a new attestation system. Well, you better bake in a delegation system, too. Like, how do people share and authorize what they can do? It's I think it's it's I sometimes call it the shared electron of cooperation is just sharing authority. It's something that's fundamental to anything you can do.

anything you can do, you might want to let somebody else do under some conditions. And it's such a fundamental thing that I think it's worth having basically at the account layer and and not leaving it up to every single new asset to implement correctly, but instead have a standard way where where users are in control of what they're granting. Okay. And on the other hand with these account delegations, these accounts with the delegation manager, they can be as open-ended as the serer account can express. So at the very worst, you know, it only supports some kinds of permissions. And in that case, you sacrifice some devspace open-endedness for this kind of strong user space guarantee. I believe that we

can make this kind of pattern increasingly rapidly extensible and and so the curation of the supported permission types I think is going to be a really important question here. I think that developers are likely able to trust themselves to add new permission types and so they'll be free to kind of do whatever they want. And then odds are we're going to need an increasingly sophisticated system for kind of aggregating our best community uh insights for what permissions can be safely issued from a normal user. But at least they get those strong guarantees.

And then with EIP702 in PCRA coming up very soon, this kind of account delegation could be issued from any account. So I think 7702, everybody's excited about it because it gives smart contract features to normal accounts. And that's exciting for as many reasons as there are interesting things to do with smart contract accounts. And I just want to emphasize that, you know, sometimes establishing new patterns, especially how a DAP talks to a wallet, it can be difficult because, you know, you if you're making a DAP, you want to make sure it's compatible with all the wallets. And fortunately, with EIP7702, we're going to be able to bring whatever smart contract features there there are to any EOA wallet. So, you're

going to be able to try things like this, use features like this, and more users will be able to uh benefit from it. hopefully all of them. One of the other problems with like uh assetbased signatures is you know you have to keep track of all of them in case you need to revoke them and that can be really scary because if you have a data loss you don't know how many permissions are outstanding. If your account is responsible for issuing all of your permissions you can have just one delegation nons that you can just rotate and it just invalidates all of your outstanding permissions. So if you're ever a little worried you could just kind of rotate this knots and kind of start from square one. That would be like a kind of extreme nuclear option, but it's exactly what you want when you're having a extreme security

incident. I had a domain hacked this last year and the worst part is now going to every site that you ever use that domain on and having to reset its its password. We can reduce that in web 3 down to a single interaction. Were you concerned about where this key has been? Boom. Auto revoke everything. You've got a clean slate. You can move on with your life. Um, I think it's going to be great for safety. I'll also compare this to another major pattern in uh smart contract account development. Kind of one of the hottest proposals for smart contract accounts today is ERC7579, the minimal modular smart contract account. I talked about it a little earlier because we're actually borrowing some of its interface. Now, a module for in this system is able to

execute operations just like I showed, but without that permissions array or here I show it as delegations array. you know the parameter names don't matter within AI. So why is that different? It basically means that every module can do anything on your behalf. That means you have to be really careful when you add a module. In effect, it's meant that you have kind of very very tight curation systems around the modules and you basically never allow users to interact with modules that aren't very very tightly vetted because it hits all of your users entire safety at risk when they add one of these. So even if the code is audited also, you know, even if your team signs off on it and says it's great, you know, wouldn't it be nice to still minimize the risk, wouldn't it be

nice to say, okay, well, we've audited this module, but also we could say concretely, actually, this module is only supposed to ever set your ENS name. So, you know what? What if we could set a permission and say that this ENS module can only set your ENS name? Then even if it's made by good-hearted people and even if your audit was very thorough, if there was some mistake or some catastrophe in the worst case scenario where that module went corrupt, you could limit the total damage that resulted. And so yeah, what if modules were always added with explicit permissions? I don't think that our delegation pattern is actually that different from a module pattern. I think it's just introducing and hoping to normalize the idea that actually modules

should always come with a policy like and that's actually pretty much always a good thing. And you can think about the difference between if you uh run some software on Windows 95, you know, even a calculator can steal your your credit card number from a text file. Even if it was just, you know, it was you're playing solitire. It doesn't need that access, right? Similarly, you know, something just intended to vote on a single system shouldn't be able to take your life savings. Yeah. Let's minimize the damage. So, yeah. And then I kind of have this as a as a imagination prompt like if you were adding if you're the author of wallet modules what permissions would minimize the damage from a mistake in your module right cuz then you could give guarantees you could

say you know I know it well from our time in MetaMask because we shipped a browser extension and actually the only permission a browser extension can ask for to provide an API to every site is permission to read and edit every site. It's a terribly broad permission. early on a lot of security conscious users did and and probably still should be concerned about what it means to install a new browser extension that has those capabilities. I think it's a very good just norm in computing that things should be able to ask for a more refined set of authority. Okay. So then the question you're probably asking at this point is how do daps get those permission payloads so that you can use them? And I'm sorry to say that that's

kind of the topic of another ERC, but I will show you a little peek at it so that you can get involved if you're interested. Okay, so 7715 uh it's again ERC7715 is a way to request these permissions. And this is a simplified draft version of a permission request. This this was resembles the kind of object you would use. Okay, so please don't take this as gospel. Take this as the intention of the spec so that you could get involved more easily. So again, the app does not need a prior wallet connection and the app can request any kind of permission on any chain. Now, the curation again of the types of permissions and their corresponding parameters, that's an open-ended topic that we're actually

kind of I think there's a debate in the 7715 community about how many of these types should be included in the ERC. I think we're starting there's a little bit of motion towards keep it minimal. Maybe have one to start and then let additional ERC's have them because to tell you the truth some wallets bounced when the the first spec had like four or five permissions. It was just like well I'm not going to do all of those and so now I won't do the big one. So I think keeping it small keeps it more collaborative and inviting to implementers. Yeah. Okay. And practically what does that look like?

Here is an example of requesting a token stream. Sorry it's not bold. It would be nice. But uh so you specify a chain ID and then you say what permission. In this case, it's a ERC20 token stream. You say what token address. You say how much starting when. And we even, you know, have a justification field. You can say to the user why you're you're requesting this. And you have to of course specify what account you're hoping this permission gets granted to. So this one's asking for $20 a month of USDC on Lineia. And uh yeah, so that's basically what it looks like. And you could just imagine additional ERC20 token requests. So one cool thing is we can even have native token stream. So that means we can grant ether allowances and even streaming ether allowances

without wrapping the ether. So the permissions let us basically add features to any existing asset without having to wrap them. And I think that not needing to wrap assets is actually a huge unlock. Um one way I put this the other day is I said people talk a lot about total value locked. How about total value unlocked? the more funds you don't have to deposit into something to create new offers and you know relationships, you might actually be effectively lending out the same asset on many protocols at once if you don't need to lock them. I think this could unlock a lot of liquidity. Okay. And then here's what the response generally looks like. So it basically repeats everything that was asked of it back which can include some extra metadata about what was approved because the user

might have changed their agreement, right? And this is important. the user might have said actually I won't grant that much or only for this long or only on these other conditions. So there is some potential for the user to customize the response and that's something you can't do with um modern signature request methods today. Signature request methods all basically require the user to either sign or reject and that means there's no opportunity for the user to tune what they agree to. But yeah, so oh and additionally, so this this includes an account meta array and this is an interesting component that kind of emerged from starting to build on this because we noticed that sometimes the permission that you might want to grant might actually depend on things that aren't on chain yet. You could consider

maybe you're going to a site that will help you sell an NFT, sell tickets to a site and actually you haven't even put the NFT on chain yet. you don't even want to pay to publish it unless you sell a ticket perhaps. You know, let's we we talk a lot about uh bandwidth of transactions, but we don't talk about minimizing transactions and like what things actually don't even need to go on chain. Well, maybe an NFT that's never minted uh is just saved bandwidth. Um so, you could actually have an array of dependencies. You could say, well, I I said that I was going to mint this and I gave the authority to my friend and his smart contract account is also not on chain and then he's the one who's signing in here. And so if you want this permission, you actually would have to

deploy the NFT and my friend's account, you know, and that's that yes, that will be more expensive for the recipient and they'll have to make their own decision about whether that's cost effective for them, but it means that every interaction until the one that involves someone paying is free and instant. So, we talk a lot about gas abstraction. How do you take gas out of the hands of users? How do you let users not think about it? I think one solution that I'm kind of proposing here is allow gas payment to be postponed and reassigned to wherever it is natural. Whoever is willing to pay something is I think and we've we've done we've kind of redteamed this a bit. It seems like the vast majority of the times and I'm looking

for good exceptions to this, but here I I'll go far. I'll say maybe all the time. Maybe all the time that there's an onchain transaction or series of interactions, there's somebody at the end of the line who actually wants to pay for something. And what if you could just put the gas and build it into their cost? Um, and everyone else had free interactions. I think that's possible. And yeah, of course, we include the delegation manager because you need to know it uh in order to use the approved permission. And the context that is the bytes that is the permission. So sorry, we use three different words permission, delegation, and now context. But those are the same thing here. Okay. Yeah. So yeah, reiterating this includes all the things you need to use 7710. The permission payload itself, the context,

the contract to call, which is the delegation manager, any dependencies, that's the account meta, and then the mode would just depend on the permission type. So the mode isn't depicted here. It would be kind of specified permission. Okay, so that's a lot. Take a little breath here before we talk about uh embedded accounts in the future. I would say embedded accounts are not just a trend. Yeah. Let me just talk a little bit about embedded accounts. Embedded accounts are a really cool new pattern, right? They let users on board with less friction to applications. They give applications more control over their interactions, fewer confirmations. You can actually make web 3 experiences totally invisible. It'll look like maybe you're signing in with a popular social media

and maybe you're backing the keys up to that. And maybe you think that's not the most secure thing in the world, but it's as secure as that social media login, which is as secure as most things people do online today. So there's a lot of merit to this pattern as a way to make accounts totally invisible. And and actually, I think that redeem delegation is a a wonderful way for these accounts to compose. So embedded accounts already can use any backup system. So they can use pass keys, they could use a social media cloud hosted thing, maybe an ERC7763 wallet drive key. That's that one does not deserve a talk. It's just the idea that the wallet could give a key to the site. I think there's other approaches to that, but the point is, you know, the site says how they want to

use a permission. Okay? And so now for the issuer to be able to define complex terms like I've described, you know, I said they might have a time limit and they might even the most complex example I gave was what if I only want to give this permission if I get something in return. That's like the ultimate permission I think cuz that's where you get the user experience of simulation. You could say, "Look, you can take as much money as, you know, as you want for me as long as I'm getting $1 ETH or something, you know, and uh and so I could just have that as an outstanding permission." But in order to issue a permission that has stateful terms, the caller has to pay the gas. You cannot check stateful terms within ERC 4337 account abstraction. It does not support

the signature validation to check external state. the state it can check is only within your account. So if you want to be able to issue permissions that kind of are interconnected and dependent on the whole blockchain potentially other chain events they need to be able to look at other contract and so actually I don't say it in this deck but I sometimes call this authority abstraction. We talk about account abstraction and what we're really talking about when we say account abstraction usually is we're talking about gas abstraction. We're saying someone else can pay the gas. But that's not the only thing accounts do. And so I'm declaring that authority, authorization of an account, is another thing that's been hardcoded into the EOA

and into the asset patterns that are dominant today. And I'm calling for us to abstract authorization. I'm saying there are infinite ways that we might issue offers and agree to terms. And that needs to be a design space. And that design space deserves to be in the hands of the user. A user custodial smart contract, right? You shouldn't only be the subject receiving smart contracts and agreeing to or not. You should be able to participate in the agreement adding your own terms. And that requires the gas payment to be on the embedded account. So that's a kind of big thing. I think sometimes people hope that, you know, it would be nice if we could just have a session key. A session key would be nice. it's just a

key on your account. But if you only use session keys, the policies you grant to those keys can only be very simple. It can be an allowance. It can have a time limit. That's about it. I think there's a lot to gain by accepting that postponing gas payment further down the chain is not just necessary, but it's actually desirable and it creates much better user experience uh in the long term. So yeah, that that means the best practice will probably be to cover gas from the funds granted in an an allowance. This is I'm making a big claim here because we don't want users to think about gas. I think we all agree about that. I think people are taking a lot of approaches for how to avoid gas payment. The most naive popular one is just pay for gas. Like maybe developers

do it, you know, just put it on the devs. But, you know, having been a scrappy dev, I don't want to pay for anything to be honest. Like I'd like to minimize my overhead. But if I'm already asking for an allowance from the user, I already have an operating budget kind of allocated to them. So I think that there's no reason we shouldn't be able to utilize the granted allowances for gas payment. And I think it's going to make a really wonderful experience where you have all-inclusive costs. It's like how much are you paying this service? Okay, well that covers your gas. You know, it should be baked all in. Basically, every other service in the world works this way. You know, you pay a flat rate. You pay what you're going to you pay what you agree to for what you expect to get. You don't when people

keep adding little sir charges, you call that nickel and dimming, right? They're being very crafty to you. And of course, for embedded accounts, we also love that easier onboarding. And you know, so experiences that start with an embedded account never need confirmations for the assets it holds. But that usually has meant domain lockin. It means if you onboard to an embedded account today, you can only use those assets on that domain unless you transfer them out or unless you know the kind of embedded account is actually you know an iframe to some centralized account and they actually do need confirmations in that case. How do we get out of domain lockin? Well, what if you had delegations from your embedded accounts and you could save to a wallet? And so

now you preserve the autonomy of an embedded account, but you're able to grant the user the flexibility of signing into other sites. So I think that so I I said I would just touch 7715 briefly and here I'm hinting at a sequel to 7715. Obviously, I think 7710 is kind of a gateway to a a kind of subdomain approach of new site composition. So, so I'm kind of trying to paint the bigger picture here. And by the way, these same kinds of permissions that you use for redeem delegation and they're great for logging into sites, they are also great for invite links. Even if you don't have 7715 and you're just using this interface for an embedded account, it gives you a framework for invite links.

And I think invite links are a fantastic way to make more social experiences and you can give people actual one-click onboarding where you the link imbuss the permission and so you don't need a wallet to click a link and then do something on chain. Oh by the way over at MetaMask we actually have a hackathon where we have a draft a working kind of developer copy of MetaMask that you can try this stuff on today. So it's it's a month-long hackathon. I think the registration is open for 2 weeks. So, uh, we don't expect you to do anything. Don't please don't work for a full month. But the point is, the door is open for a while. And we're we're putting extra energy into supporting anyone with questions or if you find bugs. This is a great time to try the spec, see if it meets your needs, see if

it actually unlocks new things, and give us input so that we can improve these specs because they're very much kind of in motion right now. And this is a good time to kind of contribute and suggest ways that this whole thing could be better. So, thanks. That's my talk. Great presentation, Dan. Thank you so much. I mean, you had me at the instant when you said it was like instant transaction and without gas. That's exactly what a typical user wants. And the fact that privacy is also built into the standard, it makes it even more compelling. I mean, the batch and autonomousity, it feels like a complete package like both end user and smart contract developers are going to love it. So, a great proposal.

Congratulations on that. Thank you. Yeah, I'm very very happy that it spoke to you. Right. And you also shared a little bit about 7715 which is a bonus and I am also looking forward to the sequel as you mentioned that there could be more of the processes around that and we are looking forward to different proposals. I agree to your idea that let's keep it small. Having a small proposal has good chances of getting into finalist status. So let's take one proposal at a time. Yeah, good advice.

Right. I think today I learned about a few new terms as well. Like many people know account abstraction but for me gas abstraction and uh authority abstraction. Yes, that was til. Thank [Music] you. And you already have shared answer to many questions. Those were on my list. But I will still like to catch up with a couple of more questions just to make sure that people who are listening understand it better. You touched on the proposal 7579 as well and I noticed that this particular proposal is added in the required section of the EIP 7710. It

definitely helps in modularization. I'm curious to understand here. Do you think that proposal 7710 can go without 7579? I will respond why I'm asking this question after your response. Yeah, we had multiple debates in the author's group of 7710 whether we should include it as a requirement because it's actually not inheriting that specification at all. It's just reusing one interface basically two types from that proposal. And yeah, I think it's useful to refer to that uh ERC because it documents the the way that modes and the execution call data should be used.

And so I think we spared ourselves redomenting those types, but those are the only parts of that proposal we're using. So we're definitely not dependent on that proposal as a whole being implemented by the account. That gives me a lot of comfort and I feel like the chances of getting 7710 towards final status is even more because the EIP read that this proposal is compatible with ERC 4337 although it does not necessitate the implementation of 4337. However, ERC 7579 has it in the required section. So from the process point of view unless 7579 has more matured status 7710 cannot get beyond draft. So if

there is no requirement it would be recommendation to like not have that in the required section if we are just using one module of it. Oh cool that's really great context. Yeah thanks for giving me better insight into how that process is run. Sure. I see there is a question in chat here. Alex, if you would like to read the question. Yeah, sure. First of all, uh thanks Dan for the presentation. Yeah. So, I'm trying to wrap my head around the new because I remember the first time when I started coding smart contracts and I had it was very unnatural to understand the simple token approved system for someone coming from web 2. I don't know if you had the same

experience in the beginning but it was kind of uh unnatural but now we have this new way of uh granting access basically or allowing contracts to do stuff with our accounts and um it seems interesting at least to have the two options in parallel so that someone could choose between them but my question is it's my my first impression that it feels that there are some risks that might be involved with the new paradigm. So for example, if a delegation manager becomes let's say super popular and everyone starts using this and then you can get into some kind of centralization risk. Let's say not

centralization but single points of control risk. Well maybe it has a bug or something like that. How would you address that? Yeah. Yeah. I think that that kind of risk concern is basically universal and it applies to anything that we interact with or use. Every smart contract you lock some funds into or any wallet software you paste your seed phrase into has control over those funds and there's always control and there's always risk. You know, I like to say you there's a saying no risk no reward, right? Composition is built out of risk and so this is a framework for risk minimization. I think of this as it makes the account into like the kernel of an operating system. The kernel has to be the safest part of an operating

system because everything else inherits its safety from that. The alternative is we're asking each new asset to implement some kind of authorization system. And yeah, I guess you know it's an interesting philosophical question like whether every asset can come up with better authorization systems, but at the very least I think we find they are less dynamic and probably less likely to represent a user's needs. So I I think there's a lot of reason to think that a user should want to be able to adjust their terms. And so yeah, that means that they're going to potentially put their funds into a smart contract implementation. What does that mean for control or centralization of faults for control? You know, there's the balance

between publishing a contract as immutable. I I think our hope would be that we have implementations of contracts like this that are immutable, but the user has a proxy contract that lets them update between those. So that I think is a pretty good u pattern for balancing kind of the centralization of control because if you just let's say you had a proxy or or you added a module that was a delegation manager as long as you can opt out of it and and upgrade to a different one I think you have pretty good optionality there's still a central point of failure and so just like there is with your favorite wallet software or the most popular DeFi contracts there's a high need to keep those as safe as

possible. Okay, got it. Thanks. My next question for you, Dan, is about the security consideration. As I was going through the proposal, it suggests that the introduction of customizable authorization terms requires careful consideration. Furthermore, it also suggests that it is recommended that application implementing this interface undergo through security audits to ensure that authorization terms are handled securely. You also in your presentation talked about the risk that is in between the time we are selecting it and executing. Other than that particular risk, are there any security edge cases or potential misuse scenario that you can foresee with this

delegation flow? First I want to touch one of the claims you made in your question was that application developers using this framework would have to undergo extra auditing. But I think the opposite is true. If you were building an application for this kind of pattern, you would be offloading the authorization code to the signer. So if you say, you know, basically what I'm proposing is wallets take the responsibility of writing some truly bulletproof authorization code. And if we can do that, then application developers, they can focus on the functionality aspect. So if you're making a game, you focus on the things the user can do. you know, maybe they have an in-game currency, maybe they can take some actions, but now you don't

have to add delegation or sharing code. And by not having delegation or sharing code, which is probably the most security sensitive code you're ever going to write, you you write simpler smart contracts. And so now the audits you do undergo are simpler and safer. So I think that we can actually make it safer to write applications more easily using a framework like this. So, one that's kind of interesting is it kind of inverts the out of gas problem. So, today when you interact with an app, it'll propose a transaction to you. And then your wallet's job is partly one of its jobs is to estimate if you're going to run out of gas and warn you to not do the thing. If you're just granting permissions, you're never running out of gas. But the the app could. So now the

app is you know the same way it's in charge of paying for the gas it has to do all the things that are involved in managing gas. So we do have to have good kind of headless embedded you know wallets that are fully capable of all the edge cases involved with gas. So and yeah and not just gas right a user could potentially now write a trap door on their own permissions. One thing, you know, in the least innocuous case, they they say, "I gave you permission for this." If you don't simulate it and you just try, you could waste some gas. If you do simulate it, you know, then maybe there's a trap door. Why would a user write a trap door? Uh just to waste your gas. And then in the there's actually I should have had a slide on this. One

benefit to having the embedded account like an account per user per application is that if that account has all of a user's if you're able to say this only has this user's things then you can have some concrete guarantees. If you didn't, let's say you used one account on the back end for all your users stuff. Well, then I might give you I might say that my delegation manager is some other user's delegation manager or it's actually some other contract that you have an allowance on. And you know, maybe by some coincidence of a collision of method IDs, I can convince the recipient of a permission to call a method they didn't mean to. that would be, you know, we we debated this a little bit of how likely it is cuz it

depends on a a method collision, but the point is that it's possible. It's theoretically possible. And so I think that from a security perspective, this is an argument for embedded wallets to be, you know, have one embedded wallet per user per application because then you can say, well look, anything this thing does is something the user wanted me to do. So it doesn't the user can't trick me into doing something that I could do otherwise cuz it can only trick me into doing things that they wanted me to do on their behalf. So this is basically their account. So I think there's a pretty simple way of addressing that category of concern. But it's interesting because it it kind of guides us towards this this embedded wallet pattern, you know, where it's like I think some people saw embedded wallets, they're like is this the end of

wallets? I kind of think of a wallet as like a bucket that you use to interconnect multiple sites, you know, they they actually work well together. embedded wallets for you know making invisible experience and possible and then traditional wallets for interconnecting those things. Very interesting and embedded account or embedded wallet definitely sounds like another revolution in wallets that will help onboard even more mainstream users without to worry about what's going behind the scene. So I think that's a great maybe use case of this particular proposal that we can see in future.

Cool. Well, I would be curious to hear about the next step. Is the proposal ready to move to the next status which is review? And what support are you looking for from the community to support advancing ERC 7710 to go to the last call and eventually to the final? Do you think the spec are stable? And if you can foresee any blocker that may delay the status advance. Yeah. Well, I guess based on your feedback, we should probably remove the dependency on 7579 at the very least, but we recently went through a round of kind of enhancing it to answer a lot of questions we'd gotten. So, I think that it's not only been stable for a while, but I think it's um it's kind of built up a little

bit of robustness and it's a little more self-documenting now than it's been. So, I I think we've got a pretty good uh shot at having something worth uh taking into draft after we make that change. That sounds good. And I believe this proposal is here for about a year. So it's about time that we can move it to review and move it forward from review. So we can actually see some projects. Good to know that there is a hackathon which is encouraging people to make use of these uh EIP and yeah right to for calls to action. Yeah. I guess the two is you can if you're an app developer try out our hackathon. You can just try it from the outside. So receive a permission use it. That's one side. And then for smart contract account

developers, take a look at it. You know, try building this into your account. Can you make that, you know, to actually build an ecosystem with resilience? We need options. Users need options. I would love to see more. We've got a couple other contract teams that are implementing this. We have support from wallet connect and zero dev, but I'd love to see even more wallets jumping on board. And uh so so those are the two calls to action, I suppose. Well, thank you. And I really hope that people watch to this episode, learn more about it and would be uh eager to help out with different kind of implementation. I know there are so many brilliant minds out there and they and people used to love experiments. So I hope we get some participation over there. Well Dan, that brings us to the end of this question

answer round, but I would love to go over a quick fun entertaining rapid fire round. Are you open? Okay. All right. Let's do it. [Music] All right. So, you may have to respond to all these questions in either one word or one sentence, but we'll try to keep it within one minute. Okay. The first question, what was your first Ethereum project ever? I think it was like register a hash. I thought of it as like an intellectual property thing. What is your favorite onchain app you have used recently? I mean I mean probably Wcast. I don't um that was that was the most recent one. Yeah. What's the one principle you always follow when

writing a new ERC? Keep it simple. One EIP or ERC you are most fond of? I think it's 173. ERC 173 was the ownable one standard. I think it's one of my greatest most widely adopted proposals. One mistake every DAP should avoid when using permissions especially for these ERC's that we talked today. Don't roll your own permission system. I also ask for just enough. You know, the responsible thing is always ask for the smallest permission you can. Yeah, that's the best advice.

Most misunderstood thing about wallet permissions? That they're really complicated. It's just that they're abstract and open-ended. They're actually really simple. What's harder to design for developer or for user? I'll say users because you can't build for users unless till you've solved the developer once. So, it's a supererset. Developers generally go with single mind and users can have different ideas around. Yeah, there's way more. If you could fast track one Ethereum improvement proposal, what would it be? How about sharding? I'm just going to go back a whole bunch. Like I like sharding. I like async programming. All right, the last one for you here is if MetaMask could do one thing that it

doesn't do today, what it should be? let you sign into sites with a DAO like represent organizations when you connect to stuff. Awesome. Very well done, Dan. Thank you so much for all these answers. Cool. Yeah, thank you. I know you already have shared your call to action, but if there is any message that you would like to share from this platform. Yeah, I know I'm suggesting a pretty big different way to make smart contracts, you know, like but this should all work with existing contracts. It's just an opportunity to simplify how you write contracts in the future. And by adopting embedded wallets, I think just making it all invisible. So, it's going to be a little rough for a little bit, but I think the people who adopt this stuff are going to be making the best

experiences in about a year. Thank you so much, Dan, for taking out time and sharing about ERC 7710715 and a few other ERC's that you touched upon. We really appreciate you taking our time here. Cool. Yeah, thanks for having me. Thank you. That wraps up our deep dive into ERC 7710 smart contract delegation. A huge thank you to Danfinlay for joining us and sharing his insights into this proposal that could reshape the way contracts authorize and interact with each other. Your perspective as a co-author as well as a wallet developer always helps bridge the gap between users need security and

protocol design. Thanks as well to eat clutch and everyone who joined the conversation to ECH contributors Akash and for getting this episode to you. These conversations are how standards move forward and how Ethereum stays decentralized, open and constantly evolving. If you enjoyed this episode, don't forget to subscribe and check out past episodes on other EIPs. Until next time, this is Puja Ranjan signing off. Keep learning, keep building, and keep improving Ethereum. Cheers.