# Building a Social App With Spend Permissions

- Speakers: [Lukas Rosario](https://streameth.org/speakers/lukas-rosario), [Conner Swenberg](https://streameth.org/speakers/conner-swenberg)
- Channel: [Devcon 7 SEA](https://streameth.org/devcon_7_sea)
- Date: 2024-11-13
- Duration: 39:16
- Watch: https://streameth.org/watch/67347f6a9dbb7a90e1b460fc
- Download: https://vod-cdn.lp-playback.studio/raw/jxf4iblf6wlsyor6526t4tcmtmqa/catalyst-vod-com/hls/457fu5h940scstmp/1080p0.mp4

## 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.

## About the speakers

### Lukas Rosario

Lukas is a Software Engineer at Coinbase working on account abstraction on the Base team.


## Transcript

Hello, welcome. Thank you for coming by. This is Lucas and I'm Connor and we're here from the base team, the smart wallet specifically. And we're here to talk about this new feature we're launching soon called Spend Permissions. So Spend Permissions, that title got messed up, sorry. Spend Permissions allow you to create one click or no click experiences that can spend users' tokens. This is important because we all want better UX within Web 3.0. 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 few minutes, talk about a roadmap 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 starter repo, and then we'll also be finishing with an NFT micropayment 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 passkeys. This means that users can easily onboard if they have a device that supports passkeys, which is most people in this room. You can scan with Face ID if you have iOS or thumbprints if you have 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 one-click experiences like we have in WebTube. So there are two ways that we've actually explored doing these one-click experiences. And Session Keys is where we actually started. And it's this idea that you can give permissions to apps to transact other contracts. And it's incredibly flexible, but after exploring this deeper, we realized 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 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 mint NFTs, swap tokens, staking on DeFi, whatever you need. And in this sense, we actually feel way more confident with the security posture of spend-only permissions, and you can still solve the majority of the things we care about. So what are the use cases we think people want to build with? The first, which we'll demo today, is microtransactions. These are high-frequency interactions that you'll want users on your app. Because they're high-fre 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 a Zora 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 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 ERC20 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 we're really excited about is subscriptions. This is an example of a pattern where users don't have to be on the app anymore. 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, subscriptions are not the only background process you need to do. Other background operations could be automated trading, copy trading. Things that are more DeFi native also shine very nicely with background transactions. But these are the two that we think are most relevant immediately. So how does this actually work? So this is a sample diagram of what on-chain looks like. And typically a smart wallet, we think of having one or a few PASC owners. And so you can see the smart wallet contract in the bottom left. It has an owner relationship to a PASCII and we typically reference that PASCII by its public key so 64 bytes. Smart wallet also supports owners that can be Ethereum addresses which includes 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 relationship set up, the flow of a transaction 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 it wants. In this case, we want to call the smart wallet to transfer some value, and in this case, back to the spender. And so so yeah. And so how do you actually use this off-chain? 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. Before we were working on a standard called ERC 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 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 expiry to be sometime in the future. The apps we've been talking to typically want the expiry 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 user has approved a permission and then therefore signed it with their passkey, 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 ERC-20 token, the smart wallet will either call directly back to the spender to transfer ETH, or call the ERC-20 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 TradFi and the existing world because it's very frustrating that you can subscribe to an app but not easily unsubscribe. 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