Next-Gen Permissions: How MetaMask is Empowering Users

Transcript

[Music] Hey y'all. Uh, I'm Ryan Mcpek. I lead smart accounts with MetaMask and today I'm here to talk to you about our nextgen permission system that's going to be implemented in the wallet. And so today I'm going to start off and tell

you kind of like where we're at like the current paradigm, how we're changing that paradigm and what exactly that looks like and then where we're headed after that. So let's dive into it. So, where we're at right now is the current connect and send transaction flow. The user will go to the DAP, connect the wallet. They'll click like a button that says like buy. Uh, the DAP then builds up the transaction for that, sends it to the wallet. Uh, the wallet parses that, maybe it simulates it. It does its best to see what the DAP is trying to do, and then it tells the user, hey, this is what we think the DAP is trying to do.

uh do you want to do this? And the user goes ahead and and signs that transaction and it gets sent off to the blockchain, settles on the blockchain, and then the user hopes they didn't get rugged, right? So, what we want to do is completely flip that paradigm upside down. And what that looks like is the user goes to the DAP, they click the button that says buy. The DAP then says, "Well, let me request what I need for this purchase." Let's say it's 10 USDC.

Uh, and then that shows up in the wallet. When they send that request, the user can see it. Very readable. This DAP is requesting to use 10 USDC. The user says, "Deal that. That sounds good." They click and grant that request. The wallet gives that back to the DAP. And then the DAP negotiates how to use that 10 USDC which would include you know buying whatever it wants to buy. At the end of the day the user has granted 10 USDC to be used and the DAP's in charge of uh getting whatever that user wants in return.

And so the question you know how are we doing this? Well lucky enough we've been working for about two and a half years on the most powerful EVM permission system. Now this is delegation framework. It's a set of solidity contracts that enables authority abstraction. And what that means is it allows you to share anything you have the power over or authority over with any other account or user or agent or whatnot. Uh so that could be include you know this other account can transfer tokens on my behalf. It could also be this account can transfer an NFT on my behalf. It could even be this other agent can vote and call the vote function on my behalf or a miscellaneous

function like this user can call the shoot function on my behalf or something, you know, and it can get as granular as as you want, right? And we have what we call caveat enforcers which are just contracts that enable uh that enforce the state of the delegation. So they would enforce the token transfer or a vote contract or or whatnot. And those are these contracts these caveat enforcers are completely extensible. So anyone can build their own caveat enforcers to unlock a range of use cases.

One piece here is we also have a delegation manager. That's a that's a that's a huge piece of the delegation framework. What it does is it it has to implement ERC7710 which is the right to uh an interface for redeeming delegations. That delegation manager is the one who validates the delegation and make sure the authority that's being acted upon is within the certain limits. So to continue on how we're enabling this nextgen permission system, we have to dive into ERC 7710 and ERC7715. So like I said, ERC 7710 is that authority abstraction. It's the interface to redeem delegations and act within a certain permission.

7715 is how DAPs are able to request permissions from the wallet. So just like our example, the DAP uses 7715 to request a token transfer from the wallet to do certain things, right? So then the next question is when is this coming, right? Uh and the answer is soon uh classic enough. So the permissions we're going to have at launch uh I'm expecting to have this out in about 2 months. Uh which I I think is super exciting. Uh there's a whole range of use cases, but just to start, we're going to start with token transfers,

token streaming, and recurring token transfers. So, uh, a just an assortment of token transfers which include ETH transfers and ERC20 transfers. And you can see here on the UI like this is a very readable kind of interface that says exactly what's going on from here, what what account you're choosing this permission from, the token you're choosing, the amount, and then you can also add these rules, which is really cool, right? Like under the custom rules, you can add like a start date.

Hey, I want this to start at this date. You can add an expiration date, but that's just that's not it. That's like the rules to start. There could be other rules that that come into play, right? Andun transition. That leads us to advanced rules, right? So, other rules that could come into play are maybe enforced outcomes. Maybe you want to give a permission that says, "Hey, you can use 10 of my USDC if and only if I receive 10 DGEN tokens in return." Right? Now you have intentbased permissions.

And you could think like, oh, what what is that useful for? A a lot of things, right? And it and it doesn't just stop there. It could be here's 10 USDC if and only if I return if I get 10 DGEN tokens and return or a hundred of these tokens and return or this NFT. So the conditionals could be and and they could be and logic as well. I want to return 10 tokens and 100 tokens in return. It doesn't matter. I mean the the use cases are are out there. what else we can do. And and this kind of uh our latest hackathon uh winner was Tech Swap. Uh and what they

did is they requested a permission and it could only be used if a valid ZKTLS was was made from a tweet that the user sent uh saying they wanted to swap certain tokens. So the user would go on Twitter, they would say, "Hey, I want to swap this token for that token." they would this the hackathon winners would wrap this up in a ZKTLS and inject it into our permission system and that's the only way that uh it was allowed to make those swaps. So that that's uh really cool. So, you could also think about, you know, I don't know what else you you could do a whole bunch of stuff like, uh, you could do voting, right?

Like, hey, I'll allow this user to vote on my behalf if and only if they submit this ZKP, uh, validating something, right? You could think account recovery. This user is allowed to recover my account if and only if they submit a ZKP of their email, right? Uh, yeah. So this is how what I just talked about is how we're empowering users, right? Uh now the user can permission. One of the coolest things about the delegation framework is it allows for transitive delegation. So what that means is I can give a delegation a permission to something and then they can redlegate

that and attenuate it further. So I could give a delegation for 100 tokens to this one to an agent and that agent could then redlegate that to a sub agent uh for just like 10 tokens uh and it could keep going down this what we call a delegation chain. So this enables automation. This also enables this whole AI swarm. See that those are AI agents and that's a swarm of AI agents. I know uh it's genius, right? Yeah. Uh so this this enables this user empowers the user to have this whole swarm of AI agents to work on his behalf.

Also while you're out here giving all these permissions to all these AI agents your assets stay in your wallet in your account. These permissions are counterfactual meaning they're gasless. When I give a permission to adapt, there is no gas. There's no gas for the user anymore, right? It's completely gone. It's abstracted away. It's not even like pay paying for gas in a different token. It's just gone because there is no blockchain transaction when I'm giving a permission. It's just offchain.

So when I'm permitting all these permissions to these AI agents, uh the the tokens stay in my account, which means I could be earning yield while I'm giving out all these permissions, right? And it could be something like a game theory as well, right? Like if I give this limit order to a 100 AI agents, it's a game for them uh to solve whoever can best solve that under my terms. Then they win. And really the true winner there is not these AI agents fighting or whatever the solvers are doing. The real winner is the user because they're getting exactly what they want under their terms. they're able to express

themselves specifically. So you see here uh TVL, we're moving to TVU, which is total val value unlocked, right? We're killing TVL. We don't need it anymore. Let's give the the power back to the users and let them use their tokens however they want and express themselves specifically. So thank you guys. That's that's what I got. We have a demo of our current permission system under uh flask uh which is MetaMask extensions kind of canary build experimental build of the extension. Uh so you can go to there.

You do have to install Flask and then install the snaps for that. When we come out to production in about 2 months on Metamas extension proper, it's going to work with 7702. So you won't have to fund a different account. you can use your current EOA with our permission system and then we're going to support it on any chain that supports 7702. Um, yeah, and reach out if you have any questions after this or want to connect. There's my Twitter account and you can reach out. Uh, before I go, we have a little bit of time if there's any questions.

[Applause] How does this um interact with snaps? Can snap developers, you know, extend it, take advantage of it. Thank you. That's a great question. Thank you for that. So, real quick, so all all our uh all our repos are open source. So, you can see the snaps we use. We use snaps to build this. So, there's two snaps. There's our permission kernel snap which is the main registry for for permissions and then there's our kind of like uh gator permissions that we're using to build this. If you build a snap that thing then can register its permissions into our kernel snap then your snap can use this. So it's going to be completely extensible and and uh yeah I think that's super powerful.

Cool. Awesome. Thanks guys. [Applause] [Music]