Web3 Functions: Building Serverless & Decentralized Web3 Apps - Hilmar Orth - Gelato

I think we can get started. Setting my timer here. Yeah, thanks a lot for everyone for coming to this presentation. I know it's late uh for a Friday, so I appreciate everyone joining us here. Uh my name is Hilmar.

I work at Gelato. And today I'm I'm quite excited to talk to you about um a new service that we have been developing at Gelato for for quite some time now, and we already have been testing it for for some time with certain uh projects as well, uh which is called Web3 Functions. Um and what they enable you to do is they enable you to build serverless and decentralized Web3 applications. What does that mean? We will find out in this talk.

And for the agenda, um I will try to walk fairly quickly through the slides, and then we will get into a real-life uh example of how you can use Web3 Functions. So, we will see some code, but it won't be complex code. It will be fairly straightforward, so bear with me. Um and we will first talk a bit about like the backend architecture of most Web3 products today, how they look like, um and then how you actually can build decentralized and serverless Web3 apps using Gelato Web3 Functions, and then going into the demo. So, let's talk a bit about backend here, and like how are What is the architecture look like for most Web3 projects today?

And when I started off building like smart contracts and everything, I kind of thought this would be it, and I would be done here. So, I can write some smart contracts, I can write the business logic in them, the state is being stored in them, and then I can build a front end, and the front end is in IPFS, the smart contracts are in Ethereum, and I don't have to worry about anything anymore. That's what sort of like my dream back then, but uh when we were actually building applications, we quickly realized that it sort of looks more like this. And there are all these sort of backend services that you as a web3 project have to run by yourself in order to actually provide the features and the user experience that you want to get to to actually get more traction. Um and they for example include one big thing being like indexing of data on blockchains.

I think many of you can sing a song about this. Uh blockchains are very tough to read, uh especially historical data. So, if you want to show information to your users on a news interface, for example, you will need to constantly monitor every single block or every single event that gets emitted on chain and then stored it in a centralized database or a decentralized database like IPFS, for example, in order to then actually serve it to the users. At the same time, most smart contracts these days, they don't solely rely on like users interacting with them. They require some other third parties to actually interact with them on behalf of users.

So, let's say you want to I don't know buy a token on Uniswap, but you don't want to buy it right now. You want to buy it when ETH drops below $1,000. What do you do? You can set up a sort of task that someone else can come in later and actually do the transaction on your behalf when the price is met, right? And for that, you need to build these sort of job schedulers in the background, these these sort of cron jobs that monitor the blockchain every minute, let's say, and then once certain conditions are fulfilled, execute transactions.

And this execution of transactions is another service you have to build. And this is what we have here as the as the transaction relaying service. So, you need to write to the blockchain. You not You not only need to read and store, you also need to write to the blockchain programmatically. So, you need a job scheduler that then checks logic and then sends transactions based on that.

But, sometimes even you need more than that. Sometimes you want to access data in your smart contracts that doesn't exist on chain, right? It might live on Facebook, it might live on some centralized API, it might live on another blockchain, right? And of course, we know blockchains are very isolated. They don't have access to outside data.

So, you then have to run another back-end service that calls APIs and then pushes that data on chain to your smart contracts. To do all of that, you need to store private keys somewhere in a cloud or in a server. There's a lot of money on these private keys. You don't want to leak these private keys. When they get stolen, you're in trouble.

And then of course, when something happens, right? You want to get notified. You want to understand that a transaction got executed, an order got filled, or a rebalance has happened in your vault that you're managing or whatever. So, there are all these weapons uh web web3 back-end services that you actually have to run to make your application your sophisticated web3 application work nicely. And of course, this has a bunch of problems.

First of all, you need to run, maintain, and scale these services. And usually building services is not the biggest issue. The biggest issue is actually maintenance and like running it at scale. Um and everyone can build like a small sort of simple system, but as soon as you hit like 10,000, 50,000 transactions per day, it becomes very cumbersome. Then of course, you need constant stable connections to blockchains.

You need to read and write instantaneously. And especially on fast chains like Polygon, RPCs are oftentimes very unreliable. So, you need to have multiple RPCs. You need to aggregate around across them. If one fails, you need to have the next one pop up to have always that 100% uptime.

Um if you then do decide to actually use other infrastructure services, you suddenly have like four, five, six different ones that you all have to pay with multiple currencies. Um Um And if you go multi-chain, this becomes even worse because now you need to replicate all of that for like five, six different chains. Um and then it becomes a very beefy setup that you have to run, especially on not that advanced chains where RPCs and everything is very unreliable are very unreliable. And then of course, storing sensitive data like private keys in the cloud is always a problem, but for me personally, like the worst thing that I sort of encountered back then is that you become the central point of failure again as a project because without all of that infrastructure, your dapp or your web3 application is basically useless. So, you have the smart contract, yes, and people can interact with it permissionlessly, yes, but if they don't have the data, they don't have the maybe the permissions even to execute the transactions, it becomes basically useless and your application is not accessible the right way if you don't have these infrastructure services up and running.

And for me, this is then not a decentralized trust-minimized application. So, we spend a lot of time or this is sort of our mission at Gelato, how we can enable projects to get to that sort of level and the level of serverlessness that we had envisioned at the beginning where it's just your smart contract and your UI. How can we get to the same part and have all these sort of infrastructure services also be run in a way where we as a project are not the central point of failure um of actually providing that to our customers. And this is what we'll look into today with our new service called web3 functions. And in the case you don't know what Gelato is, Gelato is web3's decentralized backend.

And our mission really is to empower builders like all of you guys to augment their smart contracts and create reliable, user-friendly, and scalable web3 applications without sacrificing decentralization and censorship resistance. We want to be We want to enable you to access infrastructure that is as close as possible to the trust guarantees as Ethereum, for example. And this is all like where we want to be at. And yeah, so what are my free functions and what can you actually do with them? So, my free functions are a primitive and I will actually walk you through an example in a moment of how they look like.

But basically, you can think about them as decentralized cloud functions. If you have ever heard about like AWS Lambda or or Google Cloud, for example, you can basically spawn server instances that you can think of as sort of like digital twins to your smart contracts that run at certain intervals or run when certain events are emitted and run logic that is off-chain that has a bunch of cool functionalities that augment your smart contracts. The first one is that it connects your smart contracts to off-chain data. So, in these files, you can call any sort of APIs you want. So, you can call a CoinGecko price API, you can call a a subgraph, you can call um a a maybe like an off-chain oracle system where you get like signed oracle data from.

You can call all of that. Then you can have Then you can get out of the box data integrity. So, you can have multiple nodes of the Chainlink network do that action for you, call that data for you, and then get to a consensus on the data on what it actually is. So, hey, is the price for this particular asset really between 100 and 200? And you can sort of define yourself how you want to cross-check the result from multiple nodes for your particular use case.

Then once you have the data, you can run computation on it. So, you can say, "Hey, I just got an API call with like 1,000 NFTs, and now I want to check which NFTs of these 1,000 have a certain trait. And only for these NFTs that have the certain trait, I want to then maybe execute a transaction based on that to buy it on OpenSea, for example, right? So, you don't have to run this whole computation on chain, you can just run it off-chain. And then, the cool thing is you can execute transactions on chain within the function itself.

Um and you can do it on all major blockchains. I think we support uh 10 or 12 different EVM-based blockchains, and you can get transactions mined all all um on all of them. Then you can get alerted, you can send notifications to yourself, you can send an email, a Telegram message, Discord message, it's up to you. And then you can also store data. So, you can say, "Hey, uh this transaction just got mined, and I did a swap, and this is how much was returned from the swap.

I want to store that data in local storage, and then access it the next time I run this function." Um and this is how the whole process works. So, I will show you in a moment how like the code looks, but basically you write this TypeScript file, and this TypeScript file can do any arbitrary logic you want. You can even import NPM packages in there, the Uniswap library or any sort of library you want. Then, what you do is you compile it down, and you deploy it to IPFS.

Now, this code lives on IPFS, and you can go to Gelato, which is What is Gelato? Gelato is just a smart contract on chain, and you can call a function there called create task, where you pass that IPFS hash into, and then event gets emitted, and all the nodes of the Gelato network will listen to that event, go to this IPFS ID or to this spot in IPFS, load in the logic, and start running it on your behalf. And now the nodes are running it, you're calling data, you're calling APIs, you're doing computation, and then in that sort of logic you defined, "Hey, please ex- ecute a transaction to buy this NFT." Then the transaction will be sent, it will be routed through the Gelato protocol, which is a smart contract, which basically executes the checks, "Hey, does the node that executes that transaction have sufficient stake? Is it whitelisted?

Does it follow all the rules of the protocol?" Yes, it does. Okay, then the transaction hits your target smart contract on Ethereum, for example. And the features of these Web3 functions are quite cool. Um it's all like it natively support TypeScript and it does so in the Deno runtime.

It's a special runtime which is a bit more secure secure. You can't access like system variables and all these kind of stuff. So, it's a bit like an isolated environment, but it works very nicely with most NPM packages. You have RPC provider abstractions, so you don't need to pass that and pay for like your own RPC. Um, this is all handled by the Gelato nodes under the hood, so you can just uh have always reliable read and write access to blockchains.

You can even set environment variables environmental variables, so you can say, "Hey, I have this API I need to call, but of course I don't want to leak my my API key." To access that, you can encrypt it and store it on there. You can have these functions be private or public. Uh, if you maybe run certain market making strategies that you don't want to leak to the public, right? Because you spend a lot of time developing them and you might want to have these private functions, right?

That you don't want to show to everyone in the world. That is as I said, in-state in function state management, so you can store data and access it later. Um, uh this of course costs, right? So, this is it's the the pricing here is very similar to AWS. The more resources you consume, the more you have to pay.

If you only run this once a day, it's basically for free. If you constantly run with a lot of computation, then it's basically how much you use it, this is how much you get charged. Um, and it's all like with crypto USDC. So, you deposit USDC and it's like you get charged per sort of computation here and we don't send on-chain transactions every single time. It works a bit like a layer two.

We settle every hour for all users with like a Merkle root that is being published on all chains, the balances. Then, uh it's basically infinite scalability. It doesn't matter if you need to service 100 or 10,000 customers, it works. And the cool thing is these functions or these jobs, these cron jobs that run these functions can be spawned with an on-chain transaction, so you can have smart contracts creating them. It doesn't you don't need like a API call or so, you can just have a smart contract that creates this task.

Let's say a user calls the smart contract from you and then this smart contract does something and then it spawns this task which then spawns this cron job for you which data and later can then cancel again. So, it's completely permissionless in that way. And yeah, use cases include dynamic NFTs where you can change like the content of them. Uh one major one that we are seeing a lot is that you can use um DEX aggregators to do token swaps. Let's say you are a protocol, you're accumulating fees in a lot of different tokens.

Of course, you want to swap these fees to USDC because this is what you want at the end of the day, right? Or ETH. Um but instead of integrating 10 different protocols to see for this token where is the best liquidity, you just call 1 inch or ParaSwap and then you call the API and then you send the payload of that API on chain. The same holds true with bridge aggregators. You can use for example LiFi for that.

Um you think about like real world events that have been like what's the outcome of a real world sports event, you can put that on chain to resolve prediction markets. You can have AI post messages on Lens and talk to people um and yeah, you can have multi-chain limit orders that scan through all the different NFTs across all blockchain on across all marketplaces and buy it at the right time. So yeah, it's really quite versatile what you can do with it. So now to the fun part. We have a small uh tutorial planned um and half of it is me walking through code and the other half is showing a video because obviously there's no internet in this building.

So, uh live demos are slightly difficult if you don't have internet. And anyways, you shouldn't do live demos. So, very simple use case. We have this website that we built and this website is is nothing else that it there's a smart contract on Polygon and it stores a string, okay? And you can update that string um and what we want to do is we want to create a web3 function that updates that string every 2 minutes by calling a random string generator API.

And then we call that API and then it returns a random string and every 2 minutes we want to update that string. So, the smart contract we don't need to go into it. It just has a string variable stored in state. So, can everyone read that in the back as well the code or shall I make it bigger? Does that work?

Is that good? One more? Is that good? All right. So, this is an example repository that we have um and it includes not only the web 3 functions, but also like a you this basically this UI thing, right?

So, like a UI and everything. So, you can we can share the link in the later somewhere. I don't know where, but we will share it. Um and you can basically spin up a whole repository. But, what we are mostly concerned about is this web 3 function uh repository.

And what you find in here are two files. It's the index uh .js file and a schema. Schema we don't really have to worry about, but here in the future you can specify exactly like how much memory you want to consume, what's the time out of the function. So, if after 30 seconds it still runs, please cancel it, how often it should run, etc.

Right now in the current version it's sort of static. Um and you can define user arguments. So, you can say this function should take um a string for example as an argument or whatever else you want to define. So, you define that. And then you go to the index file which is like the the meat of it.

And the function that we are concerned about is this web 3 function on run function. And this is basically the function that gets run by um Gelato. And as you can see it's just regular TypeScript that you can write and you can import all sorts of packages. You can import ethers. You can import uh KY which is basically like a library that allows you to do API requests very easily, very lightweight.

Um And yeah, then you can basically go in here and you can define what you want to do. Um the first thing which is interesting is you have this context which is passed to all the functions and it contains a couple of cool features. It can contains a storage, so you can have access to reading storage and then writing to your local storage. The storage is just like a JSON file that you can update and then you can update, I don't know, if you scan through a list of NFTs and what are the NFTs I checked out last time, maybe this time I want to check out the next 100 NFTs, right? So you can store that kind of information.

Then you have the user arguments that you define in the schema here. So in this case, the exact address of a certain address that I want to execute. And then you have Gelato arguments, which are basically like, "Hey, what's the block number?" And all sorts of other like blockchain-related information. Then you have the provider, right?

So you have an out-of-the-box provider for all the supported chains that Gelato supports. And then you have these secrets that you define and we go into the secrets in a second. And basically what we want to do here is very simple, every 2 minutes call an API and then update the string of this particular smart contract, right? So what we do is we get the block time of the current blockchain on Polygon this in this case and then we sort of get the current time. And then what we do is we get the secrets that we defined and I will show you in a moment how to define them.

You can define them if you want to test this locally in the in the env file that you have in here, but you can also define them in the web app and I will show you how to do that in a second. But here we we define a couple of APIs and what we want to do, what I didn't mention is we want to update the smart contract with the string and every time we do that we want to send an email to us that notifies us, "Hey, we just updated the string, right?" And for these sort of email providers here, we need a secret and we defined the from email and the to email. And so, here we check out the storage, right? We do an async request to the storage, and we say, "Hey, please get me a Please get me the the value of the number of executions that have happened.

And if there's if there's if it hasn't been set yet, please set it to zero, initialize it to zero." And we get another one here, which is the the last time this was executed, right? Then we instantiate a contract just simply with ethers, as you are all sort of used to. Um don't need to get this here. Um then we check if the smart contract is active, but nothing that we have to worry about here.

And then, let's say we don't want to execute it. Let's say this smart contract is not active. Then we can just stop the execution of the function here and say, "Hey, can execute false. We don't want to continue executing it." And the message that we want to see as a debug message is, "The contract is not active, right?"

So, there the logic will stop, and then it next time it will run it, and it will stop again here. Nothing else will be executed. But let's say um we we do actually want to execute it. So, if if the time hasn't passed yet, we will come into this sort of part of the function, and then we just return, "Hey, we don't want to execute." But if sufficient time has actually passed, now we will do this HTTP request, which is just this one.

Zen quotes is like this random string generator. Um and we are um calling it here. And then we get the uh message returned, the quote returned, which we sort of know at this index zero, there's the message. We log this message, and then we want to We know, okay, now we will execute. So, we set um the We update the number of executions and the last time we executed to the current time in the local storage.

And then we send an email that, "Hey, by the way, we are executing." which will hit our email relay. And then we will um get the data the function that we want to execute, which is the set mock string function. And the only thing we have to do is we have to return can I stack is true and then the call data. And then the rest the transaction gets mined and it gets resubmitted until it's mined and everything is handled under the hood, so we don't even have to worry about it.

Um by the way, this is sort of how you can send transaction how you can do API requests with KY. Um if you're interested in it, the code will be there, so we don't have to go too much into it. Um and here this is actually us sending um the email to the email provider that we're using. Right? So, this is the code.

What what will happen now is we will have to run a command that will push this code. We can first of all test it locally, no problem, but now we want to have it live. We want the Gelato nodes to actually live like run it live in production, right? And so what we have to do, we have to deploy to IPFS, and because you need internet for that, we pre-recorded the video. Maybe it will be a bit small, but I will walk you through it.

So, this is of course the the interface that I showed you at the beginning, and please remember the the sentence it says, "Simple words repeated daily can change your life." Which is a is a great sentence. Um and we of course want to update it now um every 2 minutes. So, what we have what we do here, it's probably too small, but basically we run the command MPX web3f deploy, and then we pass in the path of this web3 function. And what this does, it will push it to IPFS, and it will return us a so-called IPFS CID, which is the ID where we know this sort of code lives.

Um and in this case we we did that we did that this morning actually. And this code now lives on IPFS. The great thing is down there you see then a link that you can click, which will redirect you exactly to uh which will redirect you to the Gelato beta app, the web3 function beta app, and it will basically kickstart the process of creating a task that will start running this. Um and this is where you start with. So, you can first of all define the trigger type.

So, what should trigger this web3 function? Should it be just a regular time interval every minute? Should it be that every block that um is let's say mined on Ethereum, this function should run? Or should it be a webhook that instantiates it and you get like a webhook? By the way, the webhook and stuff is not supported yet.

Right now, only time interval supported. But, you can in the future also define, hey, when this event is emitted in this smart contract on Arbitrum, then please spawn this web3 function only once. And it should do something, right? But, now let's go down. We selected we want to run it every minute.

And then we have to input the IPFS CID so Gelato knows, okay, which function are we actually talking about? This is the smart contract that we want to automate, which we have to pass in via the user arguments. And then we have to define exactly, okay, which is the smart contract Gelato actually should call on chain. It's actually the same one, so we pass in the same address. And we select the function we want to call, which is the set mock string function.

And then we we name the task, obviously. And in this case, we call it web3f uh demo ETHDenver. Then we hit create task. And it in When we hit create task, we will first of all, sign a message. This is just the name that we set, hey, we signed that this task should have this name.

And then we send a transaction on chain, which will then basically enshrine that this task should be run by Gelato and emits an event on all the Gelato nodes all over the world. They now have it. And now you have this task and it's basically being run live by Gelato nodes. Now, you have a couple of options. You can see executions, which show you the past executions.

But, you can also see the task logs. It takes always a moment for the task logs to appear. And the task logs basically show you, yeah, what is happening? What are the nodes seeing? Are there maybe any errors?

Do I need to debug something? Is the code correct or not, right? But, what we see now is actually says, "Hey, there's no funds that were deposited, right?" So, obviously, this computation it all costs a lot of money, so we need to deposit a bit of money to A pay for the computation, as I said, it's still like this elastic model like AWS, and then of course pay for the gas of the transactions because transactions are not for free, unfortunately, in this world. So, you have to deposit some money in there.

And the cool thing is we have this one balance system, and so you can say, "Hey, I want to deposit the two USDC, and by depositing two USDC on Polygon, you can create tasks and pay for tasks and pay for transactions on all chains. So, you just deposit two USDC on Polygon, and you pay for transactions on Arbitrum or Ethereum or whatever. So, one balance for all chains. So, now we deposited we get a confirmation that this money was actually deposited, which is great. And what we can do now is we can go back uh to the task uh and see if the status has been updated.

Um and maybe I can Okay, we'll go there. And so, we are back at the task, and we see, "Okay, it's running." And we will go to the task logs to see has there been any updates? Uh and we see that there's some error, right? Say, "Why Why is this erroring out?"

But, you remember we have some environment variables, some secrets that we defined, and we haven't defined them yet, right? So, the logic will break. Um and that's why we now need to go and define the secrets that we store. And this is what we are doing in the environment variables uh section, and you have to first log in to prove that, "Hey, this is actually you here, right?" And you will It's all like Web3, right?

There's no email sign-in or anything. Nothing. You just If you control the key, you control the account. And here we already pre-populated some uh email addresses, and here we have this ethdenver@gorillamail.com, which is the to address where the email should be sent to.

And so we added and because we already signed the message, we know that we are authenticated to actually update it. And now if we go to the task logs again, it will take a bit of time because the task is run every minute, but then you should see that the first execution should occur. Um and as we see there's one state which is exec pending and you see the transaction hash of the transaction that is happening and so you see Gelato nodes are successfully running um this logic. And um yeah, probably in a couple of moments, what we will see is that the string in the web app has been updated. So the transaction was actually mined.

Um and this is just a snapshot of Guerrilla Mail and you see that we are spamming this email with updates that hey, every 2 minutes we are um updating the string and as you can see now it says, "You're not the drop in the ocean, but the ocean in the drop." Which is of course a very very nice uh string. Um and yeah, that's basically it. Thanks a lot for the applause, guys. Um And yeah, so by the way, you're not the only one using Gelato.

There are a bunch of over 200 projects use Gelato for all kinds of stuff. So you're definitely in good good company. Um and if you are hacking this weekend, we have $10,000 worth of bounties for you uh that you could win this weekend um by trying out this private beta. Just come to our Discord, chat with us, we can white list you. And then you can try it out.

Um and yeah, I think we have some time for questions most likely. So thanks a lot. How we doing this? Do we have a mic as well? Hello.

Oh, yes. Um so I'm wondering um the the the JavaScript No, the JavaScript but the TypeScript code is going to IPFS, but this is download after that and deploy to like a serverless cloud, public cloud, or it's run on every node that you in the network. Yeah. So, you deploy this logic to IPFS, and then this logic is run by Gelato nodes, by the clients we we wrote, right? And these clients are basically run by node operators, for example, like staking facilities, they also run Lido nodes by us, by other node operators, and they actually have different implementations.

So, some of them run on AWS, some of them run on Google Cloud, some of them have their bare metal infrastructure where they run it. So, the implementation is written in such a way where it not necessary is required to be serverless in the background, but you can also use serverless. Okay. So, in in that sense, you can upgrade to like a Python compiler after for the your own time. Uh runtime, yeah.

We are looking into supporting more runtimes as well, yeah. Right now, we start with TypeScript. We actually started in the first version with Assembly Script, but it was such a pain in the ass we then switched to TypeScript, and now it's easier. But, we we are looking into supporting more runtimes. Exactly.

Thank you. Uh who has the ability to read all those secrets in the environment environment variables? Who stores the secrets? Who can read them? Ah, yeah.

So, the secrets right now is like a hosted solution, so we are basically storing the secrets right now. Um we are thinking about different ways how to also make this a bit more permissionless. Um basically, the the node that is running this can read the secrets at runtime. So, um that's right now a hosted service that we are offering. We are thinking about different ways how you can basically encode the secrets with a public key of the node that you sort of like trust to run it for you.

Um but yeah, we we yeah, we're still thinking about how how to best handle this. But right now, basically, we provide that service out of the box. Yeah. How can you trust that the um Gelato node that runs the function is actually running what you asked it to? Yeah.

So, how can you trust that nodes are actually running the the right logic for you and and pushing the right data on chain, right? So, nodes have to stake our token, which is GEL. And if they basically run the wrong stuff, then they can get penalized. But this is more like a a weak sort of uh incentive, in my opinion. Right now, how it works in practice is we whitelist and select these node operators and have like real-life contracts with them that they're not allowed to run anything else than what they're supposed to.

So, there's basically social reputation, uh legal rep- legal consequences, and then also crypto-economic consequences that tries to make it so that the nodes uh actually are running this. Um mul- Uh uh furthermore, we have multiple nodes have to sign off of the data. So, you don't have to trust a single node. You can specify um hey, I want 40% of the GEL stake to actually sign off of that data, and then you have to have multiple nodes actually running. And of course, this is more expensive, but it will provide you with more data integrity.

Uh the on the other side, you can say, "Hey, I sort of trust the staking facilities' nodes, or I trust these node operators because they are reputable to run this logic for me." Then you only need to have one party running it. So, it's kind of like up to you how much security a system needs. Um on our road map, we actually have a couple of things where we want to even lower this. So, we are looking into uh things like EigenLayer, for example, to get decentralization and sort of like data integrity from Ethereum on there.

So this is something we are monitoring very closely and as I said at the beginning we want to go as close to Ethereum as possible when it comes to like the data integrity here. Um but yeah, so this is right now it's basically you choose the choose what you what you want. Anyone else? Otherwise? Yeah, there's one gentleman or two gentlemen.

No, they're at at the top. Are you able to batch multiple transactions together? Yeah. So right now in in this version you would have to call a multi-call contract, but the sort of smart contracts that are getting called they support batch. It's just like in the next release probably you will be able to pass like an array of data to that function that then executes the batch automatically.

And the cool thing what we're actually doing here is you will you are these these transactions are routed through a proxy a proxy contract. So it's kind of like account abstraction. Like there's this proxy contract and that acts on your behalf. So you could deposit funds into that smart contract wallet and then build your own custom sort of yearn that automates stuff on your behalf via your smart contract wallet that could be like a gnosis safe for example which you then also see on the gnosis safe interface. So yeah.

Cool. I think that's it. Thanks a lot. Yeah, we are so