# Building a Social App With Spend Permissions | Devcon SEA

- Channel: [Devcon](https://streameth.org/devcon)
- Date: 2025-10-07
- Duration: 39:10
- Watch: https://streameth.org/watch/yt-9daSgrLWIgY
- YouTube: https://www.youtube.com/watch?v=9daSgrLWIgY

## Description

Join our hands-on workshop on building a social app with spend permissions!

In this workshop, we'll walk through:
- Writing smart contracts for your social app.
- Creating a frontend for your app.
- Creating and using spend permissions to send transactions without popups.
- Using paymasters to sponsor gas for your users.

Speaker(s): Lukas Rosario, Conner Swenberg
Skill level: Intermediate
Track: Developer Experience
Keywords: Use Cases, Social, Account Abstraction, key, session

Follow us: https://twitter.com/efdevcon, https://twitter.com/ethereum, https://warpcast.com/devcon
Learn more about devcon: https://www.devcon.org/
Learn more about ethereum: https://ethereum.org/ 

Visit the https://archive.devcon.org/ to gain access to the entire library of Devcon talks with the ease of filtering, playlists, personalized suggestions, decentralized access on Swarm, IPFS and more.

Devcon is the Ethereum conference for developers, researchers, thinkers, and makers. 
Devcon SEA was held in Bangkok, Thailand on Nov 12 - Nov 15, 2024.
Devcon is organized and presented by the Ethereum Foundation. To find out more, please visit https://ethereum.foundation/

## Transcript

[Music] hello welcome thank you for coming by uh this is Lucas and I'm Connor and we're here from the base team uh the smart Walt specifically and we're here to talk about this new feature we're launching soon called spend permissions so spend permissions oh that title got messed up sorry uh spend permissions allow you to create oneclick or no click experiences that can spend users tokens this is important because we all want better X within web 3 it's kind of annoying to have pop-ups all the time when you're doing a transaction and so with spend permissions you're able to give permission to an app to spend your tokens so that the app can do fancy transactions to pull your assets and then do fun things with them and this Workshop is going to show you one of those things is a social app and so today we're going to talk about how it works for a brief uh few minutes talk about our road map when we're launching this and when you can get started building and then we're going to talk about some fundamentals this is where the Workshop actually begins we'll be doing some live coding and you can Fork our St repo and then we'll also going to be finishing with an nft micro payment use case at the very end so for those of you not familiar with smart wallet it is a smart contract account that has self- custodial Pas keys this means that users can easily onboard if they have a device that supports Pas Keys which is most people in this room you can scan with face ID if you have iOS or thumb prints if you have uh your computer or your phone with a thumbprint scanner with smart wallet you can also sponsor gas for transactions so users can convert easier and not have to fill up their wallet to get started and you can also batch transactions to make it easier for people to do things with less steps but one of the problems we've encountered with smart wallet and all wallets in general is that there's still too much friction to transact people really are addicted to oneclick experiences like we have in web 2 so there are two ways that we've actually explored doing these one-click experiences in session Keys is where we actually started and it's this idea that you can give permissions to apps to transact as you and so literally the popular way people implement this is they can take control over your account to call other contracts and it's incredibly flexible but after exploring the steeper we realize that this actually has some security discomfort for us and we don't want to let apps call random contracts on our behalf even if we inform the user what's being called and what functions we just don't believe that users are informed enough to give approval to those uh kinds of permissions and so that's what brought us to spend permissions it's a way of tightening the scope of what we allow apps to do on behalf of our accounts and it's focused only on spending assets we think that spending assets is actually the majority of reasons apps need to interact with accounts and after an app has assets from the user it can then do things like mfts swap tokens staking on dii whatever you need uh and in this sense we actually feel way more confident with the security posture of spend only permissions and you can still solve a majority of the things we care about so what are the use cases we think people want to build with uh the first which we'll demo today is microtransactions these are highfrequency interactions that you want users on your app because they're high frequency it's naturally very annoying if you have a pop up every single time and so use cases like this in Social would be aora app where it's basically Instagram but instead of liking you're collecting nfts you may be liking all the time other microtransaction examples would be gaming very high frequency people want to go through many operations uh for a game potentially and do it quickly and so before you would have a pop-up every time but now you can just give permission once to spend some eth or an ec20 and then whenever you click a button or do something in the background it's just going and transacting without you noticing the Second Use case really excited about is subscriptions this is an example of a pattern where users don't have to be on the app anymore and this is where permissions really shine and you can do things uniquely that we couldn't do before with wallets and so in a subscription case you will give your app permission to spend your tokens on some recurring basis and then even when you're outside the app it'll just pull money from your wallet no pressure needed and so in this case uh subscriptions are not the only background process you need to do um other background operations could be automated trading copy trading things that are more div native also shine very nicely with background transactions but these are the two that we think are most relevant uh immediately so how does this actually work so this is a sample diagram of what onchain looks like and typically a smart wallet we think of having one or a few passy owners and so you can see the smart wallet contract in the bottom left it has an owner relationship to a pass key and we typically reference that Pass Key by its public key so 64 bytes smart wallet also supports owners that can be ethereum addresses which include smart contracts and so for the spend permission system we're actually adding a new contract as an owner to Smart wallets called the permission manager and through this ownership system we're able to delegate other permissions to Spenders and so you can see the spender relationship between our permission manager and a spender entity which is itself another ethereum address and so once you have this ownership relation relationship set up the flow of a transaction action looks a bit different than normal so originally transactions for session Keys originate from the smart Wallet account but this time a spender is calling through the permission manager to spend some tokens and then the permission manager being an owner is able to call execute on the smart wallet to get it to call anything at once in this case we want to call the smart wallet to transfer some value and in this case back to the spender and so yeah and so how do you actually use this offchain to the first thing we need to do is approve a permission from the user we do this with eth sign type data it's using EIP 712 signatures we chose this path because it's the easiest way to ask the user for a signature of structured data um before we were working on a standard called RC 7715 we felt that 712 was actually an easier place to start but we're still open to working with 7715 in the future but the user sees a very simple approval here where the app is just asking them to allow to spend some currency on a recurring basis in this case 10 usdc every month could be a very simple transaction um subscription experience and we also have a start and end time so in most cases you'll want the start time to be right now and the xre to be sometime in the future the apps we've been talking to typically want the xre to actually be infinite which is something we think is interesting where users would have to revoke if they ever want to remove the permission but that's up to every app to decide for themselves after the users approved a permission and then therefore signed it with their Pass Key the signature is given back to the app and now the app can use that signature to apply it as an approval on chain and that's that first optional call in the top after a spender has approved the permission with the signature from the user it's able to spend and so then that's number two on this diagram where the spender is calling into the permission manager to use the permission the permission manager will then validate it call execute on the smart wallet and depending on if you're using native token or erc20 token the smart wallet will either call directly back to the spender to transfer eth or call the erc20 uh contract with the transfer function to send the tokens the third piece here is revoking it's very important that users are always able to revoke permissions after they've approved them this is fortunately a way we can actually differentiate from trafi and the existing world because it's very frustrating that you can subscribe to an app but not easily unsubscribe um a lot of apps make it very difficult but we believe that in the new world users should always have control of their assets and have control over their permissions so permission management is always easily accessible within their smart wallet settings and we also went through the effort of making uh revoking an entire apps permissions in case you have multiple easier with a bat roke as well so when can people start building with this well as of today we have as of last week we have um Bas AOA supporting Ethan ec2s and in December prefer at the start of the month we're going to have this live on Main net um on all main Nets that smart wallet supports right now that includes Bas arbitrum op Zora eth main net and a handful of other chains that are less used right now but also in December we're exploring ways of doing bch permission approval so ways for a subscription for example that you can both pay now but also give permission for the app to take your money later which is a more typical experience that we have with permissions um for subscriptions and then in 2025 the road map is still pretty open we're open to user feedback developer feedback on how we can improve spend permissions and build other systems that complement it cool well that's the brief overview of how the system works Lucas is going to take over and give a sample Workshop of our basic demo app um you can open this on your computer it's github.com luucas Rosario um SLS spend permissions demo we'll leave this open for a moment for people to pull up and also before continuing are there any questions about the overall idea or setup of spend permissions yeah what's the difference between transaction what's the difference between uh batching transactions and having like a spend limit uh for let's say have a $10 spend or $20 spend limit for the entire month uh I'm trying to understand oh of that last point I had of batching permission approval yeah that one yeah so right now when you approve a spend permission you're just signing a 712 object and nothing's actually happening on chain and so an app could use that um that permission and immediately start applying it to pull money from you uh so the batching permission approval idea is that you can use a transaction based approval and then therefore batch other operations with it so I could transfer u20s directly to the app and then also give it permission starting next month to withdraw my token so it just makes the ux a little bit easier for the app is it like let's say approv transaction as well as like swap transaction batched in a single transaction and then you approve that corre is that got yeah and there are other way we're also exploring batching where you could sign you could still do the 712 path and sign over multiple tokens at once um so a use case for this would be gaming we've know we've talked with ctown and they actually need eth and kibble which is an erc20 because they use the kibble to fish but they need the eth for chain link vfp and so we'd still want to provide an easy way for users to sign once and approve multiple permissions at the same time so that's the other pattern of batching yeah another question actually like I already implemented the spend permissions in my app like where I built an session ke based uh prediction markets where users just swipe left and right for their action and and the app it does the whole thing under the hood using the session keys and spin permissions like each transaction is 0.01 already cap like the user gives an allowance of 0.1 e every day and we automatically abstract for 0.01 so the issue we occurred was like regarding the finality of the transaction like how does it occur like uh sometimes the transactions May Fail but we show the user like the transaction is succeeded because of the finality is so if I understand the question you have an app already on spend permissions yes you you have a daily refresh cycle and then you're using the money to do some prediction Market use case yes and some of the time the transactions are failing yes and yeah we should talk after then yeah okay thank you yeah I can help debug later yeah cool well I want to hand it over Lucas now we'll take more questions throughout as well cool uh yeah so again this code uh that I'm about to be showing is available at this repo um first I'll just demo the app real quick uh so yeah this is a super simple app this is spun up with uh onchain kit and I have a smart wallet connected here and I can CLI I can click this subscribe button and what this does uh this pulls up the 712 message to sign that Connor was talking about uh that describes the parameters of the spend permission so you can see uh the limit per day uh is a lot uh starts on like forever ago uh not sure what that's about and it's on Bas aoia um so I can sign over this and again this is offchain so it doesn't cost any money uh or or gas to uh approve a spend permission so I can sign this and then this signature is going to get shipped off to this app's backend um who can then use uh the signature along with the the parameters of the spend permission to start um pulling funds from uh my account so that's what these are these are all uh Ops that are landing on chain um yeah so like every 5 Seconds the app will pull the back end to tell uh the apps like spending key to pull funds from the the user's account uh so that's like the short demo and again this is we're excited about this for like subscriptions and this could show like uh this is kind of like a streaming payments kind of use case uh that I think could also be really cool uh so we can go over the the code actually real quick um so we can you can start with the the front end piece here uh there's nothing like super interesting here uh is this big enough maybe that's better um yeah so uh as mentioned this is just like a regular 712 message uh the parameters for these you can find on Smart wallet .dv and there's a we have a guide up on spend permissions now so you can see exactly how these are uh parameterized um so basically when the user clicks this button uh we Define the spend permission uh the account this is the user's account the spender this is my uh like if I'm an app this is the the account that can pull fun funds from a user's account um we have a spend permission for eth uh for uh 10 a day um and this is the these are the like recurring uh the recurring parameters um and then we have some extra Fields here which you can find more about on Smart wallet. uh so we request a signature from the user and then we uh make a request to the app's backend uh with that signature and the spend permission and we can go see what that looks like um so uh the account that we're using to actually do the the withdrawing from the user's account is a smart wallet actually so so we wrap a private key uh in a smart account and the reason we do that is because uh it's it's easier to do than like like batching we can do atomic batching um and uh we can also use pay masters so when I was setting this demo up I spent like 30 minutes trying to get uh basico eth and I actually just ended up wrapping the account in a smart account and using a pay master so that's much easier um so you can see here we have like a bundler a bundler client and we send these calls to the permission manager uh that's the contract uh Connor was was uh mentioning that's an owner of the uh smart the user smart accounts uh so we have an approve of signature so this actually approves the spend permission on chain which needs to be done so that when the um when the withdrawal calls get to the account uh then the spend permission manager has like a record that the user actually did approve the spend permission and then we have the spend call uh which is saying hey I have the spend permission um given that I want to withdraw uh 100 way uh from this from this account and like I mentioned we have this set up with a smart account and a pay master so that I don't have to think about gas uh this is just going to be sponsored by uh by my pay master and then we return the hash to the uh to the client so that we can see that list of of withdrawals in this case um and then we also have this other simple route uh that uh does collection um when the spend permission is already preapproved so you can save some gas here uh by if the the permission the spend permission has already been approved on chain uh you you only need to call spend uh to withdraw uh tokens from the user's account and again using Pay Master uh and then we return the hash to the client and that's where we get this uh this list of uh of hashes and then we just render those hashes and Link them out to a uh a block Explorer uh so yeah again this is available on uh this URL feel free to uh just pull it down and and play around with it and again we have a a guide available on Smart wallet. uh and that goes into all the parameters of the spend permissions uh and goes into more detail um and you can find out more about like use cases we're thinking about there any uh any questions about the demo hi thanks I'm wondering is this uh this pending permissions is creating a session key right no no uh because session key um we we're trying to be very clear that spend permissions don't allow you to arbitrarily execute for the user's account uh in other words like the the key the spender account is not an owner of the user's smart account it just has the right to withdraw uh some assets from the user's account okay so it's a extremely scoped uh uh key that can only spend assets of the user account yeah that's right and that that goes to like the uh we we just felt much better with the security model there uh but you can pretty much get to session key parody and just build like you know if you wanted to have some State tied to the account you can imagine in this back end having you know some database set up that's like uh you know I have this spend permission for this account uh and I can just have my state there and I don't need to execute directly from the user's account uh and I just I just need the assets which I can do and so question the signature here is happening on the client side yes the the user signs uh over the uh the 712 message uh which basically like gives the ability for the the the apps spender to like pull funds okay so at each spent is using the signature that the user gave in order to use the permission you actually don't need the signature after you approve it on chain so you just put a record into the the manager contract that says here's a signature for the spend permission this is valid and then next time when I want to pull funds I don't need a signature again I say here's the spend permission and there's a record of that on chain that it was approved okay thanks yeah any other questions so this will only work with the coinbase smart wallet uh currently yeah well there's nothing stopping other wallets from implementing this uh this feature but you would need to have the owner added as on your account what else like here too so maybe not so the contract that we've written and audited only works for coinbase smart wallet however we wrote it in a way that's easily forkable where other people can just Implement override a specific function of like what the execute looks like on their smart wallet so for example if you want to use I guess like the I think probably like a zero Dev 7579 account has a specific execute function you can just Fork the spend permission manager reimplement the execute function whatever that interface looks like and then everything else can just work as work the same pretty much so one thing oh no yeah one thing we are exploring is if spend permissions needs something like an ERC to make it easier for apps to work with other Wallets on this kind of feature uh We've held off from doing that to make sure that the S the design is actually sane first um but that is something that we're open talking about and working on okay yeah thank you cool uh do you want to do your thing yeah uh if there are no other questions Connor is going to show another demo of how you can tie this in to like a social uh kind of app actually I think I may just like Wing in on this one okay so do you want to plug in actually want to take a chicken s cool we are back all right so we're going to do this like half live um we want to show a more concrete example of what it looks like to actually do Advanced operation server side with SP permissions and so what we're going to build is effectively something like this where your smart wallet has some money but we want to withdraw that money and spend uh to use some kind of operation so Lucas was showing how earlier we could use a coinbase Smart wallet server side with a key that we can sign on demand and with the smart wallet in the server you gain two main things you can use batch transactions which we're going to show in this example and you can also subsidize gas through pay masters to make it easy to not have to worry about topping up some random account you have with enough gas to submit transactions in an automated way and so for this specific example we're going to work with Zora's nfts uh they just a go good goto protocol for anything nft related and incentive alignment with your creators and for us the call Flow is going to look something like this where the entry point because it's a 4337 account is going to execute on our server account which then has a server key we'll be signing with to verify and then we're going to do two calls and batch them together the first call is going to be spending on the smart wallet which will prompt transferring some assets into it and then the second call is going to be minting to the actual Zora nft we need to do the spend call before we do the mint call because we need eth to perform the mint the Z's contracts will ensure that uh it will only allow you to have the nft if you're paying for it and the mint too um emphasis on the two here a lot of contracts out there allow you to Define recipients for token related operations and so in our case we're not going to be minting back to the server account here we're going to be minting the token directly into the smart wallet itself and by doing so we Pro create a effectively what a session key experience is like with one click mints where the user only has to approve the permission to withdraw eth then whenever they click the mint button they're going to have the cloud account withdraw their eth mint something and get it back in there atomically this kind of model can also expand to other operations so for example Dex trading on swaps uh the Unis swap router allows you to define a mint to like Behavior as well where you can define a number of recipients you want for your tokens and so this is a case we're actually exploring with the team Dracula where they support both swaps in their app and nft mints and we're working to move a um these operations to the server so that you can batch withdrawing money and buying something and giving it back to the user and we think this model can actually be replicated across many other examples as well and so what we want to do to start is I have an nft collection on Zora I've already done some sample mints uh in anticipation for the demo but we have uh this is just my pfp and we have a contract address here and so what we're doing let's make that bigger cool and so the first step here is rather simple it's just the usual Grant permissions experience again you're just approving some eth and then you can do allow and then from here we have my pfp this is the nft I'm going to be minting and then when we click mint it should be making a query to the server to Mint the token which will then pull the assets if we have the route up here uh two calls that we need one is or three calls rather so again we're approving the permission with the signature we only need to do this once after we have this approved on chain we actually don't need to apply the signature anymore but then we're pairing together both the spend uh of calling the spend permission manager to withdraw the amount we need for the mint and then as soon as we have that mint value back in the spender client that we have we can do a mint call and then the mint call itself is going to make a call to the Zora Minter contract uh with the mint cost and some data which then just takes a bunch of stuff but really what we need to Define is the recipient the nft contract we're going to be minting on and the token ID we need we want to Mint and after we have all of this then we get user op hash user op receipt and return this back to the client so well that's not supposed to happen apologies let's do a live well this was working just before I came back up unfortunately for us but I have this pushed um a working version of it to a repo that if you go to smart wallet. we have all this documentation here on spend permissions including a basic overview the quick start that has the sample experience Lucas just down mode as well and then within here if you go to the sorry this one Zora branch you can access all of this code here within the app and then we have a mint route that is doing this kind of API work I'm curious from the crowd are there any applications that people are Keen to build with something like spend permissions SL session keys yeah we are building like a generative art platform so ah so we are building like a generative art platform so like the idea could be that like you as a collector you can like approve spending and each time like new mints come it's automatically minted on your behalf so you don't need to wait in front of the like minting button and refreshing the page so that could be probably like idea I would have like with this that's cool it's so this is something where as soon as a new token becomes available like on the drop I can Min yes yes yes exactly so we have like a weekly drops so users don't need to wait like at for example 3 p.m. they don't need to wait you see all the mouses going around cuz we have like a party kit so you see all the like pointers so they are impatiently clicking on the m and it becomes like pink so yeah you approve your minting and that's it so at 3 p.m. Sharp you can mean for everyone who appro the limit yeah I love that I I like how in particular it helps people not be perennially online and so this is a good use case of like the background transactions use case and we are already live on Bas so happy to try it on I love it cool well we skipped most of the workshop by having the code pre pushed because we didn't want people to worry about typing live with us so if people would like to build something together we're here to finish the rest of the workshop but otherwise I think we have most of the content that we wanted to cover actually and then leave the rest of it open-ended for what people wanted to build live so are is the batch Atomic or not or how does it work uh the batching on Smart wallet is atomic yeah it's only Atomic nice thanks um was the account you were using to execute the Unis swap transaction in the example an eoa account or is that another smart wallet and this one um the mint 2 or the Unis swap yeah yeah the server account what kind of account is that it could be any account that supports batching so for us we would just use use the smart wallet because we know those contracts but you can use anything as well up there cool yeah it also doesn't have to be a 4337 account it could just be a contract that supports batching so like multi calling for example who is the one that calls execute on something like a server account uh if it's a 4337 account it would be the entry point because it's what's validating that you are actually you uh with your server key and so after you validate your user op then it'll submit a transaction or a call through the server account to then execute whatever batch you have yeah another question yeah correct this entry point is the 4337 entry point yeah and uh so you guys created one more contract which is the spend permission contract is uh 7528 I'm a little confused can you explain uh like what exactly is uh happening in the spend permission contract yeah what is happening in spend permissions we can actually look at the code to show you some of the logic I play It's relatively simple but when you call spend on it okay this actually is going to be more complex than I was thinking so when you do spend uh it's going to do two things it's going to validate all of the internal logic of is this spending the right token is it spending too much of it for the current period um part of the logic of spend permissions that's different from something like permit 2 or normal erc20 approval is that there is a natural refresh of the permission over time and so when you have a permission I guess from what Lucas showed you earlier that was a typescript object here's the solidity struct we have uh this period value is actually very important because it's what defines how long you go before you reset to zero so for a subscription example you would want the period to be your billing cycle so one month one year bi-weekly whatever it may be uh for something like micro microtransactions we've seen daily as like the most common way to do this and so what the spend permission manager needs to enforce is that for the current period have you spent more um have you spent up to the so if we go to use spend permission that's what it's trying to do so we just make sure that it's approved in some state that we have if it's already approved in state we look at what is the current period is the total spend for this period greater than what the allowance should be and then if it is it will fail and otherwise we can update our last track spend for the period and so we would take the total spend and set it to the value save it back in storage and then emit an event that the spend permission has been used and then after this we would actually execute the erc20 or eth transfer so you mentioned the beginning that uh we could folk this uh uh contract and then uh change something what exactly was that oh okay that'll be this one the execute so the transfer from uh is just a normal transfer of either if it's native token it'll call on the account to transfer value to the recipient if it's an erc20 it'll call the token contract itself with the transfer function defining the recipient in the value it's really this execute internal that you can switch so for us we just import the coin B smart wallet interface and we call its execute function so whatever account you have you can just replace this you have more you want to go through yeah's try to fix the demo yeah actually maybe we could help devote his thing as well red shirt I want to take a moment to see if I can actually debug what was wrong with this minting because it was working momentarily before I thought I commented back in yeah that's a good call we all have the Subscribe case actually there is one more thing we should probably touch on as well that wasn't hit which is people who want to build applications that have a without without a database hopefully that's like a lot of apps at least many apps they can use the blockchain as their database one thing we've noticed is a need for providing index data about how many permissions have been used or how many permissions does your app already have and so we've created a new RPC wallet fetch permissions that allows for that where via API uh you can always ping to know what permissions your spender actually has and so you just provide the chain ID you're asking for uh in this case it only supports basoa but soon everything else um your spender address that would be the server account in the examples we've been giving and then what you get returned back is an array of these permissions and for each permission you would have all the fields and then the signature you need to apply and for something like this you would imagine a subscription would pull all of the accounts I have permissions for on a routine basis and then for each of them prepare this massive batch call to call spend on all the users and so fetch permissions is something that we're also hesitant to go too deep into with something like an ERC because we'd rather make sure the interface makes sense first through production experience but patterns like this we also see as important for building full stock Ops um kind of completing the crud where you can create permissions you also need an ability to permissions um soon we also need to add an ability for you to update a permission for example if you have a subscription that's $10 a month but you want to upgrade someone to Pro you need to say would you like to upgrade you were on 10 we're going to remove that and only conditionally on removing it will we add a new permission for $50 a month um and then the final of delete we already support revoking but also being able to prompt a revoke from the appside as well cool uh yeah if there there are no other questions I think we can end early here but uh Connor and I will be around if anyone wants to uh try out the repo or just have has any questions about uh spend permissions in general we're happy to hang around and and chat cool thank you thank you