Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Luis Schliesske & Hilmar Orth: Gelato Network - Web3 Backend Automation & Relay

Episode Date: February 17, 2023

Web3 has always been criticised for its not so friendly user experience. While one might argue that it requires a mere learning curve, similar to that of e-mail services when first introduced, Web2’s ease of use has become the norm. Account abstraction and smart contract automation are just 2 solutions for unlocking higher flexibility in transaction execution logic. These backend improvements, alongside scaling solutions and a more user-friendly frontend (e.g. wallets, interfaces) will represent the main drivers of adoption.We were joined by Luis Schliesske & Hilmar Orth, founders of Gelato Network, to discuss about Gelato Network’s approach to decentralising Web3's backend through automation and relaying, in order to onboard the next 100 million users.Topics covered in this episode:Luis’ and Hilmar’s backgroundsThe need for automation in smart contractsHow bots operate in automation processesInteracting with Gelato’s node networkAutomation, relayers & gasless transactionsHow automation impacts trust assumptionsGelato beta start & use casesAccount abstraction & user experienceEpisode links:Luis Schliesske on TwitterHilmar Orth on TwitterGelato Network on TwitterSponsors:Omni: Access all of Web3 in one easy-to-use wallet! Earn and manage assets at once with Omni's built-in staking, yield vaults, bridges, swaps and NFT support.https://omni.app/ -This episode is hosted by Friederike Ernst. Show notes and listening options: epicenter.tv/483

This is Epicenter, episode 483 with guests Louis Schleske and Hilma Ort. Welcome to Epicenter, the show which talks about technologies, projects and people driving decentralization and the blockchain revolution. I'm Friedrich Erz and today I'm speaking with Louis Schleske and Hilma Ort, who are the founders of Gelato, a project which makes blockchain deaths lives easier through automation and other things. We will talk about this in just a bit. But before we do, let me tell you about our sponsor this week. Omni is your new favorite multi-chain mobile wallet. Omni supports more than 25 protocols, so you can manage all of your assets in one place.

What's really special about Omni is what you can do inside the wallet. Want to get yield? Omni allows you to get the best APIs with zero Vs and three tabs need to swap. Omni aggregates all major bridges and dexes. So you can bridge and swap across all support networks in one transaction directly in your wallet. Love NFTs. Omni offers the broadest

NFT support of any wallet so you can collect and manage your favorite NFTs across all chains, all in one place. Omni truly is the easiest way to use Web3 and is fully self-custodial, meaning you never have to trust anyone with your assets other than yourself.

And they support ledger. Give Omni a try at Omni.com. Cool. It's super nice to have you buy a both on, Lewis and Hilma. We go where, way back. So pretty early on in your Web 3 journey, you guys got a grant from the NOSIS ecosystem fund. But we'll get to that. So maybe tell us about yourselves and who you were

before, you know, before blockchain and how you guys met. Oh, yeah. Hi, hi, Frederik, of course. First of all, thanks for hosting us. You're excited to finally be on the FESETA podcast. I remember still listening to it when in the their market times 2017, 2018. And of course, beyond that, so it's also awesome to be here. Yeah, maybe I can start giving a quick background, where we actually, how we came into the space. And I think as a sort of context,

what is always interesting for me looking back is like, we are all like post-financial crisis sort of generation after 20, 28. And I think this sort of had quite the impact in how we thought about financial systems and why we were very eager when defy and n y3 came around to sort of participate in that and louis and i we met i think we have like quite the same same journey the two of us so i can maybe speak for the both of us we we met in high school actually already in the ukk and then both studied in london i studied finance lewis politics um he focused more like the game theory side of things. And yeah, we then went to Berlin because we both had sort of like the dream

to become entrepreneurs, founders, doing our own project. And so we started to learn the craft in that sense in Berlin and at some point started our master's degree there as well. And there, actually, we met a colleague of ours who was working at MasterCard and he kept talking about blockchain back then in like 2016 and so on and got us quite excited about it and at the same time the Dow started and I read this article about it and I was super fascinated by it and yeah we participated in the Dow and we I remember we had to buy ETH on on Krakken for the first time when it was like $8 and I was like what is this ETH? I just want to participate in the Dow and yeah that sort of got us hooked so so we were like Ethereum Natus we didn't we kind of skipped the Bitcoin part

hard altogether. And yeah, from then almost just the Revital wrote our master thesis on like crypto, I think Louis U on POS consensus algorithms. And yeah, then we we actually, soon after our master, we started working at a startup in Berlin that helped projects like big European-based projects such as Bayer or Novartis or others experiment with like blockchains. EVM private networks and we helped build those up. But their private blockchain things were I think a bit early back then and I got a bit boring. And so we decided to just like get out there, go back to research, learn more the in-depth engineering of everything.

I participate in hackathons. Literally went to like three, four, five different hackathons all around the world. It's just started building. And I had this idea about this defy application that we wanted to build, which was like a lending protocol on top of the Dutch X that we wanted to. build and I think this sort of like ties us in very nicely into how we met you and the NOSIS team and yeah, then we remember we sort of started applying for for grants like the Gecko one and yeah, this is sort of then how the whole journey officially started I guess.

I think you may have been our most successful Gecko grant receiver. You actually submitted a proposal for something called Incindyx and I actually checked it out last night again. It's actually pretty cool. Do you still remember what it was about? Yeah, yeah, totally. Also, thank you very much, Friederick, for hosting us. I think Hillman, I completely share the history of our private and business lives of the last 12 years. So I don't have to basically everything I do, he does, and vice versa. So, yeah, so actually, I do remember the Instantex quite well, which is, it was Hilma's and my sort of first solidity project other than hackathon projects before. And we basically looked at the Dutch X, which was a really cool idea back then.

As always, Noses was very early, maybe even too early with these great innovations. And the Dutch X was a decentralized exchange by Gnosis that was based on a reverse Dutch auction mechanism. And one of the things there was that users or participants in the auction would have to wait up to 24 hours, I believe, for clearance. And then they would have to come back and remember to withdraw their proceeds. And this, of course, wasn't very great. You X. It was very slow.

You had to wait. You were impatient. So we were then thinking, okay, how can we sort of make this better? Right. And the first idea we had was actually very defy-esque. It was basically having a pool of liquidity to front the proceeds of the auction. Because I think you were able to at least buy a margin, sort of deterministically have a guarantee of roughly how much a user would get.

And yeah, we would then instant DX was basically fronting this money. So you would be immediately able to withdraw a portion of your proceeds. And then, yeah, that actually turned as well into thinking about automating the withdrawers from the auction. And that's really when we stumbled upon the great problem that is smart contract automation and the constraints of an EVM. and that's how we then realized, okay, actually automating withdrawals and so on is actually quite, it's not built into the EVM, it's not supported natively by Ethereum.

So how do we do that? And then we realized, wait a second, there's like a whole need here for a generalistic automation protocol to allow smart contract applications to be automated, to have automated processes. And that's how we very quickly then stumbled upon gelato. I believe we already rebranded from InstantDX to Gelato in May of 2019 and start. the grant as gelato back then with our first mission to automate withdrawers from the Dutch X. Yeah, I think it's super important to kind of remember that this was four years ago. And basically all the things that kind of seem like commonplace now,

back then they were cutting edge. So as a space, we've come quite a way. But kind of the fundamental problem, or one of the fundamental problems with smart contract, automation kind of boils down to the fact that smart contracts don't do anything unless they're poked. Right. So I mean, you can't really say if this happens to that, then basically if that has happened, someone needs to tell the smart contract, hey, check again sort of thing. So can you talk about that problem that you're trying to alleviate? Yeah, maybe I can start. Louis, feel free to jump in, Of course.

Yeah, so I think the foundational problem that, like, gelato or like the initial mission that we want to solve with smart contract automation was that the, the blockchains, the processes run on EVM blockchings, like a theorem are a finite. So if you want to execute a certain business logic, which you encode in a smart contract, let's say you want to transfer, funds to a friend, let's say every day, for example, then you define this sort of logic within a smart contract. And then the actual business logic of that smart contract is actually only run if someone sends a transaction to it. And so if you think about what automation is, automation is sort of, okay, at very granular intervals, I would like preferably at every block, I would like to run the sort of logic that is in the smart contract to then determine whether to send the money to my friend or not. And then there are so like two options, how you can achieve this on an EVM blockchain.

One is you would just send a transaction at every block to that smart contract, right? Which of course is not really feasible because we all know there's the spam protection mechanism with having to pay gas for it. And especially when we started on Ethereum, and it was just completely infeasible because the transaction can cost like $20 if you're unlucky.

And so the other, way of doing this is actually to have this sort of off-chain computation network that does that simulation for you, not on chain, but off-chain. And then once your conditions are met and can be fulfilled on chain, it actually will execute and send the transaction on your behalf. And this is basically what the base problem was that we wanted to solve, but we wanted to solve it in a generalistic We started with the sort of withdrawal issue, but then we realized, hey, it's not only the Dutch X that has that problem. If you want to do limit orders on uniswap, for example, it's the same problem.

If you want to do liquidations for landing protocols, it's the same problem. So we realized that defy, especially in defy at the beginning, it's like the use case array is just infinite. And so that's why we started then building this generalistic solution for it. So gelato kind of boils down to kind of, you know, being this marketplace. But in principle, you could have also just offered the service, you know, as, as an infrastructure company, right? I mean, there's plenty of those out there who whom you can just contract and they kind of run, you know, the DevOps side of, you know, the blockchain business for you. What kind of drove you to kind of building this very generalistic solution?

So basically our mission here was to bring smart contract automation without trading of the core properties of Web 3 like self-custody, you know, private keys. So one way to achieve automation is by giving up access to, your private keys, giving up access to your crypto assets, whatever they be, and give them into the hands of a server company or something, and they then execute transactions for you from your account. But that would essentially be like what banks do nowadays, right? Like they control all of your assets or Facebook controls all of your data. And that's how they can actually bring automation in Web 2, which brings these very cool

web 2 user experiences. So on Web 3, the problem was, okay, how can we have automation? whilst not, you know, forcing users to give up custody over their funds and so on. And that's why we started with a smart contract protocol. Before we even build any servers, we first started with a smart contract protocol, Gelato v1, which had some very, like, I think now functions that have been copied as well a lot and so on. Like it sort of set its own standard of smart contract automation with these on-chain functions can exec. So can I execute here on behalf of a user and then exec?

And during the on-chain execution, a user or an application would be able to define their own business rules into the smart contract, which make it so that, you know, the gelato bots can, first of all, they don't need access to your private keys. They can execute for you via smart contract mechanisms. And also at the same time, these smart contract mechanisms can enforce certain business rules, right, so that the bot cannot just, I know, for example, in a limit order on uniswap or on pancake swap, which uses gelato limit orders, actually. A user, a bot can only execute a limit order at the right price, right? These are very important business rules that are enforced by the smart contract. So as a user, you don't have to trust a gelato bot to execute at the right price. You know that the smart contract logic protects you. And as a bot, you are incentivized to execute at the right price because then the transaction

will be successful and you will get a small reward for it. So these sort of encoding these rules into smart contracts was essentially what we started. with and that there was like the first big version of gelato and interestingly now we're also looking into how we can remove the reliance on just smart contracts because smart contracts and blockchain computation is somewhat limited right like it doesn't work with heavy computation and so on and now we're also chipping away at the problem of okay how can we have off chain computation be secured and somewhat like trustless and and yeah so we're working on that as well I want to hear more about this in a little bit.

That's the private beta that you just released, right? The Web 3 functions. Let's maybe get to the core of it first. So you just said that basically bots do stuff for me, if I want to automate stuff. So who controls the bots? And how do I buy the service from them? So who controls the bots?

So we have, like gelato notes, right? And from him, and these are basically entities that are running, yeah, notes for you. They are like, like you can think of them as similar as like an Ethereum node, for example, just with the difference is that they are not validating blocks or proposing blocks and validating them. They are very fine and checking certain tasks. on your behalf all the time, and then executing them and making sure transactions get included into the blockchain at the right time for you,

and then getting paid for it to do that job, similar to how you pay an Ethereum node, the transaction fee of what you have to pay. And who are running these notes? So today, and this is actually what we... So at the very beginning, we were, of course, running the notes. cells. And this was so like the bootstrapping phase of gelato. Gelato was always designed to be this sort of unstoppable Ethereum-like protocol, which tries to get as close as possible to the trust

minimization guarantees that Ethereum provides. At the very beginning, we started a very bootstrap you and says, okay, let's build all the tools first and everything and then get to that point later, because the great thing about how we started with is that the trust, minimize the trust assumptions very little because we could enforce it all on chain and smart contracts, right? So the only thing Gelato could really do for you at the very beginning was not execute your transaction at the right time. But we couldn't rag you or something. Like the limit order would still always execute and you would always get the money or it just wouldn't execute. Right. So that was the great thing, how we could start and also not worry too much about like the decentralization methods as long as we have reliability uptime.

right and so we've like sort of perfected that process and now i think we will go there probably in a second we're moving much more into how can we offload that computation that is done by smart contracts to enforce certain data integrity of like okay what price to use to execute a transaction or let's say what route should i use to get the most optimal price right these things that are very hard to enforce on chain how can we do that in a trust minimum way off chain. And this is where decentralization comes into play. And this is where you have to basically build up a network of node operators that has stake similar to like an Ethereum proof of stake and follows a certain protocol that is encoded into the clients that if they break it, they will get

penalized. And if they follow it, they get rewarded. And this is actually what we started launching last December. So now just like a major upgrade we'll actually announce pretty soon is already conducted and we already have external node operators running on this network today. For example, staking facilities, they're running LIDO nodes and other nodes for other companies, other projects. And by the end of the year, yeah, it's, it should be that there's no, like the reliance on us is very little to none. And this is sort of where we are evolving towards. As someone who kind of wants to automate a process, do I pick one bot provider to kind of do this for me? Or is it just a generalized pool to which all of the bot providers can, all of the node runners can kind of tap into?

So you can think of gelato as a marketplace where the demand side is you or like smart contract. applications that need automation services. And the supply side is the Gelato network of nodes. And nodes can offer their services on the Gelato network. They have to run our client implementation for that. They have to enter their task executions via our smart contract protocol, wherein certain rules are enforced like payouts and so on. But yeah, basically, you can think of Gelato as a module that you can

plug in and get access to a decentralized market of nodes. So it's not just like some people know that we have relay APIs and they sometimes mistake gelato for a relayer. It's it's not just a relayer. It is a network of relayer. So it is a module that you can plug into your your flow and get access to a decentralized network of relays similar for smart contract automation. So you don't have to pick one.

You just pick gelato the network and all of the basically, what you get out of the box is a coordination mechanism that coordinates amongst a set of notes. Okay. So I don't have a personal relationship with anyone. Gelato note provider, it's kind of like the network as a whole. Does it give me any, basically what legacy businesses would call SLAs? Or is this something that, how do I know that if I use gelato for my decentralized backhand, that it will perform? Yeah, that's a good question. So currently there's no such thing as SLAs or so because I mean, we are sort of an open web three

style protocol that you can use. Currently, I suppose the SLA is the MEV that node operators get, right? So the way the protocol is designed is that for successful execution of your transaction, you have to pay a fee to cover the transaction fee and then some profits. So as long as you believe in like, you know, people like or like note operators wanting to make a profit in this network, you should be, you know, you can basically sleep well and know that someone will go and execute your transactions at all time. Given that the core premise of using gelato network, the services there is that you have to pay for it, right? You have to pay the network for performing these services. So the incentives are designed in such a way that always, you know, similar to how public MEPV.

works or to how Ethereum works, right? Like, why do people keep mining blocks? Because they get a block reward. And similar in Gelato, why will always, will there always be a node executing your task? Well, because they get a reward for it. That's completely fair. So let's talk about the people who actually run the nodes.

Do you have any idea how many different entities there are? Are there any requirements I need to meet in order to run a node? So you said like staking providers and so on, that sounds like very involved. I mean, there's also things you can kind of do from a debt node or so at home. Can I run gelato on my debt node? And if not, what's the barrier to entry? Well, I think in theory, yes. In theory, you need an RPC.

So you need a connection to the blockchain. You need like an access to a phone note maybe. and then you need some server resources, right, to run it. And this is sort of like the theoretical part of it. Now, in practice, of course, Gelado, the sort of like the client implementation is fairly diverse and actually complex by now. And especially since we started off as, okay, we have this note of implementation for smart contract automation, but since then it expanded quite a bit.

And I think we have this very modular microservices like architecture for gelato clients. So you run like running a gelato node comes to like different flavors and you can sort of like opt into certain services that you would like to support because we have this automation service, which is completely detached from the relay service, which is completely detached from our new off-chain computation service that is actually now coming out. And so it depends on what service you want to run. If you want to run like the most simple one, which is basically our execution service, which is just there to get a transaction and not even do the computation itself, just get the transaction and then get it mined for you. Then I would say in theory, yes, you can do it in practice because gelato is also like live on, say, I think over 10 different EVM chains today. You need like stable RVCs with most of them. of course you could choose to only serve Ethereum, for example, and do that.

And then, like later this year, once we go live with our V0.1 of staking, you could be able to just buy some gel, stake it, and then participate in actually actually existing decent transactions. But then you also have to guarantee some uptime because if you're not up when you're supposed to, and if you're not executing transactions that get allocated to you at a certain time, then you will basically no longer receive transactions for like an interval as a punishment. So there is like this sort of mechanism in place, which is we incentivize you to stake, the more you stake, the more transactions you will be able to execute.

But also, if you get these executions allocated and you don't execute them, then you will also not get the next one. So it's like a game of more stake and high uptime. So as long as you can guarantee that, then yes, you will definitely be able to participate. You just kind of touched on the fact that, I mean, mostly so far we've talked about automation, right? You also kind of refer to relays just a bit ago.

Can you kind of explain the distinction? Yeah, I can explain the difference here. So I used to call automation, deferred relaying because automation is also a form of relaying, if you will. It's this idea that a message and operation, a transaction that a user wants to see executed is relayed on that user's behalf. So the user themselves don't have to send this transaction. It's a relayer that puts it on chain for them. And automation is quite interesting because there we couple this transaction relay to a condition being fulfilled in the future.

And that could be a deterministic condition, like the passage of time, right? Like every day do something for me. Or it could be a like condition that is not deterministic. Like if the price, you know, reaches this, then execute for me. That might never happen actually. Or it might. So automation is this sort of relaying on steroids, if you will, where you couple the relaying of a transaction to a arbitrarily user-definable condition on chain and now also off-chain.

Yeah, and then relaying is really the simple primitive of just sending a transaction. And usually that is in the context of real-time relaying. And actually, to be honest, it sounds quite simple and so on. So it's literally just saying, hey, put this transaction for me on chain. But it unlocks like this much better UX for three users where now technically you can interact with an application on a blockchain in real time without needing to have crypto funds in your wallet, for example. this is known as gasless transactions or meta transactions

where it's great for user onboarding, for example. You can use a relayer and a user can then come visit your app for the first time and interact with your smart contract already without needing to go to a centralized exchange first, do KYC and buy crypto or something to be able to send a transaction. But it's a bit more this real-time thing of like, hey, please do this for me now. Relying is also really cool for, not just for users, but also for back-end developers, for example, that are multi-chain. So, for example, Connext has been using Gelato Relay for over a year, and basically, they're a cross-chain bridge. And every Connx transaction is a Gelato Relay transaction.

And for Connix routers, they call them, it's very beneficial to use our Relay APIs and Relay Network because it makes very easy to get transactions sent reliably on multiple chains at the same time at scale. So the relaying is also for us, at least, specializing in the art of scalable transactions throughput on multiple chains and also decoupling payment of native tokens for transactions, removing this need for developers. So developers can, for example, nowadays with our one balance system, put USDC on Polygon, a balance, say, $10,000, to see and then go and have transactions in their applications be executed on multiple different chains while only paying from the single balance on one chain. So it makes the management, the transaction management in the tens of thousands of transactions

per day extremely easy when you use a relayer like gelato. And here again, like gelato is a network of relays. So you can think of gelato like as a single entry point for your relay transaction, but in the background there's multiple relays that are. are competing to execute these transactions. Before we dive into use cases a bit deeper, one final question on the automation. So as a user of the automation, I don't,

I only have to pay once it's executed, right? So can I, can I spam the system by kind of, I mean, basically because the, the, the, the, no, they have to check the conditions at certain cadences. So if I just give them a, lot of work in checking conditions that may never be met or that I engineer is such that they're never met. Can I kind of, can I bring down the network? Yes. So what you rightfully said is what is automation? Automation consists of two parts.

It's the off-chain computation that has to be done. And then it's the transaction relaying that has to be done at the right time when the condition is fulfilled, right? And you're very right. If you create, I'd say, like a hundred thousand tasks or a million tasks that would never execute, you could bring down these sort of networks because, yeah, there's no, there's a lot of cost, but there will never be a reward. That's why many of like these systems. And I think this is sort of how we we started our V1 design.

I think all better or alpha. We want design of Gillato back then, which is, hey, we sort of put this, you put the bounty up and this bounty will then pay. for the transaction. And then I think everyone started to like take it and copy it. And now it turned into like the standard for small contact automation. But it's actually not scalable. And it's actually quite flawed. And that's why we realize also.

And this is this is also what is being rolled out right now. And with our newest release of our basically automate 2.0 or also like Web FreeFinders. that we'll probably talk about in a moment. We already redesigned the system to such an extent that there are basically two payments you have to do. And, or like there are two fees that are being paid. And this is the one fee is for the actual computation. And there it's very, like the analogy is very much basically looking at gelato as like a decentralized AWS or Google Cloud, which is a set of nodes, not one particular data center.

somewhere, but a network of like cell fossil, not operator somewhere in the world, the way you rent that computation for your decentralized application, and they run it at the same, they run it all the time as long as you pay them, of course, and then they execute the transaction at the right time, right? And the execution of the transaction for us is actually done by the executor in the network and the, and the actual computation by another part of the network. And there has to be like, it's in all. to make these systems really sustainable and scalable and work for everything, you need this

sort of distinction between paying for computation. And so this is actually being rolled out right now as we speak. But the cool thing is you don't need to let users deal with that, right? Similar to how users don't pay for the users on Netflix, don't pay for the computation of AWS in the background, right? If you watch a movie there, even though they use IDWS, similarly, like users of, let's say, pancakes swap or like a Dex, they are not using,

they're not paying for the computation that is done by gelato. They're paying pancakes swap like a 0.1% fee on each limit order that gets executed, and they pay the computational fee, for example, right? Let's kind of change course here. Let's talk about the Web3 functions first, before we talk about use cases. you already kind of led into it. So how what I mean, so now you kind of have to pay twice or the payment split between

kind of submitting the automation request and having it fulfilled. Any other updates? Yeah. So what free functions is, I think something we have been talking about for quite a time. It's actually also in our white paper, which is, okay, like smart contracts are like, it's cool to automate smart contracts and there's a lot of stuff you can do on chain and we have seen an explosion of use cases, which we can talk about in the moment. But the real cool use cases and the real efficiency you can gain is when you move the actual computation from on chain to off chain,

where you can do much more. Plus, if you move the data that can be used to automate your smart contracts from only being based on on chain data, to then off-chain data. And this is, I think, where it gets really interesting because now basically what you can think of about what three functions is, it's like a decentralized Cloud Functions. So it's like a decentralized ADLBS Lambda, where you as a developer, you go and say,

hey, I need to query a subgraph, for example, or like some API that returns me a list of all the NFTs that follow, that it has, a certain criteria, all the NFTs that have a certain rarity, for example, right? And what I want to do is I want to check all these NFTs if they can be cuddled with, let's say there's a cuddle function on them, right? And I have to check whether they can be cuddled. And I want to check it and once one of them can be cuddled. I want to, of course, make sure that they get cuddled at the right time, right? This is like a fun use case. And obviously doing this on chain is impossible.

where you can't just query all the, all the NFTs that have that sort of property and that sort of rarity. It's like, first of all, computational, far too expensive. And secondly, mostly impossible because there's no good way of doing it sometimes. Certain, like, data is only with my events, for example. Or let's say they are not even stored on chain, like some information. You need to get them from API like IPFS. Maybe the metadata is on IPFS, and you need to get it from there.

And what you can do with three functions, basically, you can write a, a TypeScript file, like rather than writing a smart contract that encodes the logic that determines what data to use and when to execute transactions, you now write a TypeScript file that you compile and deploy to IPFS. Now this lives on IPFS or other data availability layers that you can choose or we can probably also expand it to other locations later. And you get an ID from IPFS out of it. And then you go to Gelato and you send a transaction on Shane that says, gelato, hey, pointing to this IPFS file, hey, gelada notes, please run for me this IPFS file that I just deployed there, which determines the logic that I just described, and then execute transactions on my behalf to whatever chain I want to, while providing me with certain levels of data integrity that the data that is being generated and is being used is actually the same in the right one, right?

And yeah, this is what you can do. And you can think about it is in allowing. smart contracts to access cloud functions with like a transaction. And this is super powerful for decentralized applications that don't want to like have one company that runs a Google Cloud or whatever. And if they don't pay their bills or if they get censored or whatever, then the whole application goes down and relies on this, which many applications do these days. This is basically a way to make them like to decentralize this process and make them

more unstoppable. That's super powerful. But what does that do to your trust? as like a developer who uses this. That's a good question. And this is also like the evolution and why decentralization for gelato is now becoming very important. And I alluded at the beginning that at the beginning it was okay because trust was sort of on shame. Right.

Now we're moving to a world where trust assumptions are higher because gelato nodes are running computation for you that you cannot verify on chain. And you need to have some sort of trust in it. And so this is where staking and the decentralization of our network comes in hand. And basically how we are envisioning it is that you can define, you have some sort of comparing this to other Oracle networks because it's some sort of like you can refer to as partially like a hybrid Oracle network. And how we are sort of trying to provide users with like a, like the flexibility of writing these things is just much greater than what you're used to in other.

networks, but what you can also do is you will be able to define what sort of integrity you need for that data. So for example, you can say, hey, I want to have 50 or 60 percent of the gelato nodes that have staked their gel to sign off on that data. And only if they all signed off of that data, then a note can take that transaction and execute it, right? And so that way you have 60 percent of the gelato stake that saying, hey, I verified that data and this is actually data that should be used.

And then, of course, if they are maliciously, they will be slashed and can be penalized for this. But you can also say, let's say, my data's not that important, right? And I don't need that sort of integrity. I don't need 6% of the network to run this computation. I only need two nodes to run that computation. And you could also define some lower thresholds here for you. It depends on a use case. But basically now staking and having a valid data set becomes very important.

Okay, I think that solves a lot of the problem, but it's some sort of escalation mechanism. So if I'm not happy with the execution, there's some sort of arbitration protocol that I can run. Because otherwise, what you're incentivizing is basically someone performs the computation maybe maliciously and other nodes are not incentivized to rerun the computation, but can just piggyback. So basically if everyone agrees and it's wrong, but no one's penalized, then that's kind of, yeah. So can I escalate as a dev who uses this oracle? Yeah, so for that we have right now the gelato Dow, right? So we have our Dow right now where users can basically come and say,

hey, this is what was executed. And this is actually, I rerun the computation myself, and this is actually what it's supposed to return, which is not always 100%. It's not easy to make this 100% objective, because if you talk about generalistic object computation, then it's not only, it's not only deterministic. Right. I think for many use cases, it actually is, especially if you talk about like subgraph data or data from other chains. there it is deterministic, but if you think about, let's say, API price data and it depends on which millisecond or node queried your price, right? There you have to have some sort of

defined aggregation and sort of consolidation of that data process defined. And this is what we meant with this, hey, you can define your own thresholds. Let's say, you can say, hey, I want these sort of nodes to run this and they have to agree that this is in a certain range or this is roughly the same in these boundaries. And if it's the case, then I'm cool with that. And then they have to sign it off and send a transaction. And if you look back here and can say, hey, it was completely different,

then you can basically start this escalation process, which is, hey, I want to challenge this. And then there's basically the Dow doing its job and validating it and making sure. But right now, like there is, there's no perfect way of sort of doing it for now, which is always deterministic, objective, no subjectivity involved at all. So we are taking this sort of pragmatic approach to this. No, it's super exciting. So when is this going to be rolled out? Well, actually, the beta starts today.

So we are rolling on the web free functions beta today. We actually were also enrolled in yesterday, but today it's going live, But it is, first of all, in like a closed beta. So we have round about like 30 projects, 30 projects signed up for it now that will be immediately using it. And a lot of really, really cool and amazing use case that I'm super excited from like NFT perpetuals to to NFT lending to decentralized market making to like a lot of different things. So the use case array is really huge. And the beta is there because, yeah, there's a lot of stake here, right?

And data integrity is important. And so we are slowly only onboarding new and new users to the system to make sure we can scale this up, secure this sufficiently and make it work smoothly for everyone. So, yeah, that's why it will probably still be in a close beta for at least a couple of months. Cool. This is a super nice segue to use cases. So we've talked about kind of like the nuts and bolts for the past 40 minutes. So kind of hit hit me with what has been built with it because it's been massively used.

I mean, there's millions of transactions that have been sent using gelato. So what are the use cases and what networks are they on? And what are you particularly proud of? Yeah, maybe I can give a little history, I guess, of use cases. cases. And really, um, what we discovered for years ago was that Ethereum and other EVMs need this generalistic, um, automation or relay protocol that lives outside of the, the, the client implementation of, of the blockchain. Um, and, and really this means that anything can be built on top of this. And, and we've seen this really happening. Like there have been use

cases that we didn't foresee and there, they're, I mean, it all started with DFI, but. because we started gelato in 2019 and in 2019 to 2021. I guess there was pretty much everything was defy, right? And then eventually NFTs happened. But it started with defy and there, I mean, the first use case actually were built by Instadap, by the Instadap team. So they are also legendary members of the Gelato club,

if you will. And they built together with us some extremely complex use cases, automated debt refinancing. So these were things like, I think automatically, for example, automatically moving your other position to compound, if compound has better APIs or something like this. I think this was the number one use case for INSEDAP for a whole while. And I know this is one of the things that I used into SEDAP for.

It was just single click and basically it just switched everything over. It was super neat. Exactly. Yeah. And they used gelato to automate this. And yeah, it was very heavy. on the defy side was using flash loans and this and that. And all of these things were checked basically like all of these things were

gelato conditions like what flash loan to use, whether from DYDX or from other or whatnot. And yeah, so very heavy defy things were built first. And then actually one of the first big use cases that we always saw were limit orders, of course, for AMM. So anybody trading on centralized exchanges would usually place a limit order when they want to buy or sell something, right? but on AMM it's like Uniswop or Kaiba back then even, you didn't have this enabled.

So with Gelato, we built a limit order SDK that was using a smart contract limit order protocol. And yeah, basically this is how big AMMs like spooky swap on Phantom and quick swap on Polygon and Pancake swap on B&B chain all basically were able to offer limit orders on their exchange to users, which is in the background using Gelato automation. And then from there, I mean, eventually once we build our automation UI and interface, Gelato Automate, previously called Gelato Ops, we basically then gave developers a sort of nice way of, you know, self-servicing themselves before it was sort of us. You know, the tech was ready.

Like it could be used, but there was a lot of work you as a developer needed to do and we also didn't have that much documentation. Technically, you could have used Gelato to build anything, but it was. you know how it is you have to make developers lives easier for for them to actually use it so we build this super nice ui product where you can come appdogelato network and you can basically start automating the smart contracts with a click of a mouse button basically and that really i mean that sort of opened the floodgates to use cases there were so many things launching without us even knowing that suddenly we're using the network i remember algorithmic stable coins using it um

for rebasing. Many other things, I'm sure Hilma will give some more color soon. And then for relaying, for relaying, initially our approach to relaying was a bit more backend focused. So really focusing on how can we provide backend projects such as, for example, Connix, the cross-chain messaging protocol. They're using it with a way to get transactions mined on multiple chains with high throughput like really at scale because that's actually quite hard.

Building your own relayer sort of to send a couple of transactions, hundreds of transactions every day is not that hard, but going from there to 40,000 transactions, 100,000 transactions per day on many different networks reliably. That's then really hard. That's production and software. So we sort of started with that and that has been successfully used by Konex for over a year without any problems and, and, and, uh, and, and, and, and, and, and, and, and, and,

recently in the last half year or so, we also focused a bit more on the UI side of things for reeling, so gasless transactions, account abstraction, all these things, making it easy to onboard web two users. And not so much the focus on having, I don't know, a throughput of 100,000 transaction per day for your backend application, but rather having these cool user experiences where as a user, you can interact with smart contracts without the need of having crypto in your wallet and so on. So there will be, I think, some exciting use cases launching soon.

Yeah, for example, we're talking to a betting side on Nosis chain, we want to make it so that users, first time users, first in crypto users can come and place their bet without needing to have crypto in their wallet, for example. Super cool. Helma, do you want to add to the landscape of projects building on Delato? Because if not, I'd like to talk about account obstruction. But Lewis kind of insinuated that you would want to add some color.

And as we heard earlier, you're kind of basically the same person. So I assume Lewis knows what you want. I think Louis already covered a lot. I think maybe to add there is like weird things that I personally didn't anticipate are all these NFT use case. Because we are both from like the defile world. but suddenly we've seen like tens of thousands or 100,000 transactions from like NFT rentals, for example. I don't know. Like I didn't know people rent so many NFTs, but they're like these entire NFT rental marketplaces now where you can get an NFT.

You can literally get the NFT into your wallet. Let's say like a board A for example. And then you can do something. And then gelato will out of like there's a function in the transfer from function. There's like a condition which is gelato can get this NFT out of your wallet instead. days again and we've drawn back to the original owner and this is like happening so literally smart contracts are all the nfts are given to you and then like drawn back in by gelato and this is happening every day like tens of thousands of times on polygon and bn bnb chain and and stuff like that so

these are things that beyond like maker are using it for like their collateral management and you know like stuff like optimism for topping up sequencer notes and stuff like that which are use cases we sort of seen very early on these are like ones that did red that really surprised me personally seeing random monkey yeah i think i think what both hillman i were quite happy and proud of is that we really saw the you know one one guy team developer using this up to you know the blue chip defy projects like aver maker um optimism and and and so on so So really it's for everyone. Cool.

So account abstraction. So I think a lot of our listeners will kind of know this in the context of EIP 4337. This is actually something that we're working on together. So not we as epicenter, but me as noses. And this is kind of finding an implementation for account abstraction without protocol level changes, just using relayers. It's incredibly cool use case. And I actually can see, so we are committed to kind of rolling this out on noses chain.

And I would kind of assume that this goes well and kind of is taken over by other chains as well. So can you explain to me how it works? Yeah. So account abstraction really is the concept of trying to move array from having users interact with smart contracts with their X. internally on the account and rather promoting that they are interacting with a smart contract wallet based or a smart contract based account. And that these are the two accounts that are available on Ethereum. One is created via your private key.

And then the other one, you have to deploy yourself. Let's say the NOSSAF is probably the most prominent example of a smart contract wallet. And the cool thing about a smart contract wallet is I like to compare them as one is like an old school door lock where you have like this wooden key that you get in and then you can kind of like access web free and then the other one's like this digital um door lock that we have in our office here where you can program people to just like come in for like a day or so or you need multiple people to sign off to enter the the building for example right and so it's a programmable wallet the smart contract wallet is a programmable wallet where you can encode advanced functionalities for

example, that you can make transactions be fully gasless on behalf of users without having to change any smart contract code anymore. And this just greatly improves the UX of users that are especially getting onboarded to Web 3. And yeah, there's this whole array of like feature sets that you want, for example, gasless transactions, account recovery, but also in wallet automation, which I think I'm sort of most bullish on account abstraction. And yeah, we actually sort of experimented and been building account of selection stuff since the very beginning. Gelato was actually started off as a module for the Noses Safe. This was our first implementation of Jolato.

And it was literally, hey, you have your smart contract wallet. And now you have like an add-on to the smart contract wallet to make it really, really smart. And it can automate, it can execute things on your behalf, you are not there. This is for me like a smart wallet, right? And we actually deployed nosa saves on our first UIs back then and had like had users interact with our application using their noses save as a proxy, which is exactly what account abstraction wants to achieve and sort of enshrine into the protocol a bit further by with this ESC 437, for example, which basically allows, provides people of like a public entry point

who then say, hey, I want to interact with a certain application and they can define how they want to pay for it, for example, and then there's this public entry point where you can do so. So this is a counterstraction. But it's a very broad topic, so there are a lot of different parts you can go into if you want.

Yeah, absolutely. It's a super big topic. And I think in terms of kind of making Web3 usable for NUMIs, this is really something that kind of we need to hit because, I mean, the current onboarding experience, you need to be able to onboard users with an email or similar, even if that means lower trust assumption. You just have to be able to switch it out later. The user has to be able to switch it out later.

But, you know, this experience where kind of you download Metamask for someone, and then you say, I'm not going to look, but you have to write down these 12 words and you can never lose them, so replicate them, you know, in many places. But you can also never show them to anyone. So replicate them never. It's just, it's, it's a lot of mixed messages and people don't get it. It's just, this is not how we're going to onboard like the next 100 million people or so, right? And until EIP 4337 actually comes, if it comes, I think it'll be an uphill battle in terms of pretty complex and, you know, backwards compatibility. such. What other things are you excited for? So I mean, with the Web 3 functions, you kind of,

you radically enlarge the possibility space of what can be built using gelato. So what are the cool things you kind of you foresee? And what are you excited for? Yeah, maybe I can say, Louis, feel free to add stuff. And so I think maybe tying it back to the account abstraction. For me, this all sort of, for me, with gelato especially, I see all these things converging at some point. So right now, to provide users within sort of these advanced automated services or use cases, let's say, a limit order on Paycake Swap, or let's say, yearn with like, hey, we always give you the best rate where whatever, or other use cases.

what you always had to do is you had to build entire smart contract protocols, which logic is solely based to provide this sort of automation for users in a way where they can, let's say, they just have to deposit their assets into like this pool. And then from this pool, a limit order gets executed or from this pool, it will be invested in the best yield generating protocol or whatnot. And mostly the reason why we have this is because you can't automate transactions from the user's EOA wallet. So other than getting their private key, then you basically own their money. So if we can as a community push this concept of account abstraction and smart contract wallet, then what we gain is basically

what I call in-wallet automation, which is you don't need to build all of these protocols anymore. You can just tie your money or your funds in your wallet to arbitrary off-chain data, computation, or on-chain verifiable data and computation, which allowed for example, and can start getting the best yield everywhere straight out of your wallet. You don't have to pool them anywhere. You don't have to send them anywhere first. just straight out of your wallet they do things. Think about like games, for example, right?

You can build like, you can play strategy games where you run a script that interacts with your account on your behalf or with other people's accounts on their behalf and like direct their actions in like a Pokemon world. Like for me, I see NPCs, non-player characters. All of them will be like a smart contract, which will attack you, like say a Pokemon game, you walk through the grass and suddenly Pokemon attacks you.

It's like an attack function there. And then a gelato sends a transaction, the Pokemon comes, attacks you, and then it's like a battle, and you fight the Pokemon, even if you might not be at the machine at the time. You define your strategy beforehand, and then you can alter it over time.

So I think there, with account abstraction plus automation, especially leveraging data from off-chain, I think you just full, like you 10x or 100x, the possibilities that can be built for Web 3. And it all ties it very nicely together. So I'm super excited about how this.

And I already see a couple of use cases and projects building first things like Brahma is building basically like a yearn, but based on those saves using gelato in the background. So I think I'm super excited about these type of use cases. And they tie everything very nicely together. Yeah. One of the big things that I am excited about is, is basically a whole new web-free user experience.

We are all Web3 natives here. I know I've known you for years now, Riderike, so we're definitely very early and probably you are used to using metamask and so on, but you also mentioned here that it's still very clunky when onboarding new users. It's still always like every time I onboard a friend or family member, I realize how bad it is and that it will never be mainstream

because it's way too complex. And one thing that we have to hand to Web 2 is that the user experiences there are really great a lot of times. And yeah, I think we have to achieve parity with that in Web 3, if not even surpass it. And in Web 3, we have created these amazing backend technologies that make developer experiences very great, right? Like you can build your own bank, you can build whatever, like with a bunch of lines. of code, but on the front end, on the UI level, on the mobile app level, it still is very immature. It scares people off. It's clunky. It's kind of horrible, to be honest. So what I'm really hoping for now that as we move up the stack a bit and we sort of provide technologies like the

relay APIs that we have, account abstraction, smart contract wallets to front end developers, is that we finally have a better frontend to web three. well, not just a good backend. And here what I'm looking out for, hopefully next bull run is that we don't have these things where you definitely know that this is a Web3 site, where you log in with Metamask, you connect to some RPC, everything is slow, you can't do anything because you don't have crypto in your wallet. You have to go visit three other places now to get crypto, to configure your wallet, to write something on paper and store it in a save or something, right? Like, all of this should be gone. And hopefully,

can build Web3 applications where users don't even know that they're interacting with Web3, only the developers of that site and all because they're using the power of WebP Technologies to build amazing backends, to build amazing applications without the need of, I don't know, Web2 legacy licensing or so. So yeah, I really like that's what I'm really looking forward to. And here, our basically stake in this game is our set of relay APIs. You can certainly use automation as well to provide very nice user experiences, but especially with relaying an account abstraction, you can build amazing new user experiences where I hope it will simply be like, okay, we forget completely about connecting metamask and whatsoever.

All of this will be gone. It will just be a nice website and you go to clicking buttons again. You immediately see data and so on and you don't have to have this extension be connected and so on at all times. Like it should be very smooth sort of instant feedback as you use a website to interact with crypto. That's really what I'm looking forward to. Me too. Having Web 3 with strictly better user experience than Web 2, this is, those are goals.

Fantastic. I have one last question. And maybe it's the most important question that I considered leading with. What's your favorite flavor of ice cream? You don't get to be called gelato without, you know, having a good answer to that. That's true. And I do look forward to the next Depcon and the gelato booth there again. Oh, yeah, the most, the favorite booth of all Depcon attendees where you get gelato.

We literally saw people going there eight times in a single day to get gelato. Like, there was this guy who skipped lunch and everything. It was crazy. Dosted. Lunch was also, I think, a vegan or maybe just vegetarian, but was very healthy. So basically this was also one of the main complaints about DAPCon this year that the food was too healthy. But you were there to, you were there to, you know, to rescue the staff attendees. The saviors.

Yeah. But having having a free ice cream truck is definitely a DOS vector. That's for sure. So it was, yeah, we got a grease there. So for me, for me, my personal favorite flavor still is, and this is actually how I, what I ordered when I was a child when I spent all my pocket on me on gelato. And I went to this gelato place close by and I ordered eight scoops. And I ordered eight scoops. And I did it on like a biweekly basis, most likely.

And there were lemon chocolate chili and lemon chocolate cherry. So I like lavender chocolate and specifically just a hinge of chili and some sweetness with the cherry. And then you get a best combination. You have opinions on this. And Lewis, what about you? Yeah, I think for me it's pistachio. And by the way, I have to plug the amazing ice cream shop that is next to FullNote in Berlin. Do you all.

Yes, it's amazing. The Sicilian ice cream there. So, yeah, I was the perfect place. to start gelato in 2019 and have some of the bare market bitterness be washed away with some nice sweet gelato from the shop close by. Fantastic. If people want to find out more about gelato or use gelato or become active in the gelato community, where do we send them? 100%. So first of all, gelato.network is the website there you find all the various resources and links. The most active channel for us is Discord. There, if you're a web three developer,

you're starting out, or you're an advanced person who wants to go deep into Jalalal to just come there and chat with us. And then, of course, follow us on Twitter. We are also producing a lot of video content on YouTube. So make sure to follow us on YouTube as well. We'll probably do some cool vlogs for Yves Denver. So if you're not there and can't participate, but still want to experience it, and make sure to check out our vlog there. And, yeah, so Discord is the best one. and Twitter, of course. Fantastic. Thank you both for coming on. This was super fun. Thanks. Thank you.

Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to Epicenter.tv.t.v. Subscribe for a full list of places where you can watch. and listen. And while you're there, be sure to sign that for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, the guest or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward

to being back next week.