Scaling Ethereum development with trustless automation — Agustin Lavarello | Mimic Protocol

Hey everyone. Um, so I'm Augustine Lavarello. Uh, I'm the tech lead at Mimic and uh we're going to about uh talk about scaling Ethereum development with trustless automations. Um so yeah I've I've been a developer uh for a lot of time now and this is like a truth that automation is never prioritized. Uh you enter like this endless cycle where you said okay I should automate this I should automate this.

I'm going to do it later. I'm going to do it later. But like in the end you never escape uh manual labor. That's like a reality. And we've seen this at mimic a lot of time that Ethereum developers waste a lot of time uh on automating uh trying to automate stuff.

Uh but there's some things that uh can go wrong. So we've seen this 90% of the time that like there's a repeated process that you have to do maybe uh once a month, once a week uh transferring some assets or uh collecting some other assets. Um this usually it's a waste of time. Uh there's some manual intervention. Uh some people gather in a room or in a Google meet.

Uh there's maybe a multi they have to review the transactions, sign it. Um they moving um like a lot of value. So uh they waste a lot of time and also it's errorprone. We've seen like developers transferring uh maybe some money to the same like contract for example for transferring USDC to the USDC contract and you cannot like recover that. So maybe you build some custom scripts um okay this is a little bit better maybe than manual intervention but the problem is that there's no standard way of like developing these scripts uh that do this uh automation.

So the script starts growing, adding features. It's hard. You have maybe onboard new developers and like uh the new developers like don't really know how that script works. So it's like it's unmaintainable and it doesn't scale well. Also um you rely on private data sources.

So you have to start managing like API keys. Um also these data sources can be unreliable. So quering the chain for an RPC maybe the RPC is down or it's not on the tip of the chain. Um so you have to start building like fallbacks. Um there's a lot of complexity in it.

uh and as I said they're unreliable and like uh one of the uh wor thing is uh like storing the private keys in like the servers that you're going to send the transaction um this like key usually has a lot of permission. If they hack this key uh they can control part of your protocol or mint some um yeah um RC20 token or whatever you're doing. So like um it's really dangerous um and having like uh this key leaked it's a critical mistake. So before talking a little bit about like how we got to the idea of trustless automation let's look at what we have been building since 2021. So we built um some onchain recipes for different protocols.

Uh these recipes they work really good. uh they were like all uh enforced on chain. Um but the main problem they had had that it was really hard to change. They were really couple uh for what like that project needed at that time. Um and if they asked to change some configurations uh we had to reimplement some part of the the stack.

The good thing is that we validate the idea. people were using it uh and they were asking us to build more automations but it didn't scale that well. So we got to the idea okay what if we can extract the configurations uh and make it uh uh that you can custom like and um edit some of these configurations. So we did that in a second iteration. Uh and in here like different like our clients could like edit thresholds, the gas limit of the transaction uh that uh we were automating the like access control uh volumes um everything.

But the problem is that if they ask us to integrate for example another bridge or um another um decks, it was really hard to do it for us um because they were really tight um highly coupled to the protocols. So we started thinking about about how we can build this as a Lego um where we had different blocks and in here that's where we came out with like what we call the protocol connectors. These uh pieces uh they connect and the abstract the way to interacting with these like different protocols for bridging for swapping. This allowed us to create like a a standard task that we developed for all of our clients. So for us it was easier to automate uh because there was a single entry entry point uh a single way of executing this tax task for every client.

And then if they ask us to uh swap via one in we added the one in connector and the paras uh connector we could also add it if they ask us for that later. Um, so it really allows us to model some uh really complex um situations uh that our clients were asking and what we have right now it's like really it's all open source. It's in our GitHub. You can like create your own automations uh and use it yourself. But it's really uh complex.

So they really were uh depending on our support uh for building these automations and sometimes they were asking for um more uh use cases that we didn't have maybe the manpower to create them a little bit of our track record. So we did four billion um total of automated value. So 4 billion uh in value went through our protocol. Um 18 million transactions and we uh did around 200,000 automated transactions and three uh 300 million simulations. Um so and we work with a lot of protocols that are leader in the industry.

Uh 1 in Paris swap, we work with trust wallet, decentralized uh the graph, rainbow wallet. So we have been building since 2021 and learning a lot about how we can automate things for our customers and with all the things that we learned we want to um open the playground. So why we want to do this? Uh we see lots of developer uh facing these needs. um there's no robust solution in the space although there there may be some they they don't fully um I think understand the developer needs and uh we think that the community is in need of a standard a standard way of doing this uh custom integrations and task.

So um it's easier to maintain and build um these tasks. So when we think about trustless automations, what uh are we thinking of? Okay, there has to be a standard process. Um I already explained why we we need this. Also, there must be like a low-level abstraction.

So you don't if you want to swap something, you don't have to like know about like how to swap via one in or um unis swap or whatever exchange you want. the it should be abstracted by the automation. You just want to swap and and that's it and we should find the best um route for that. Uh the same for bridging, transferring all the all that stuff. Um trustless data sources again you don't want to rely on one private uh data source.

Uh so it should provide trustless uh data sources to query the chain. you might be want to like query prices. So the protocol should provide that. Um it should have decentralized execution. We don't want to um rely on just one uh like machine running all the executions.

If it has bugs or uh it's down, we like want to the for for our clients to still have this automated st task working. Um there should be proper access control. We are moving value. Uh we are handling value for for a lot of people. So uh proper access control should be enforced.

And uh I think this is key. There should be really really good uh monitoring tools to know what your task is doing, how you're automating it uh and everything it has done. So I'm going to introduce a little bit about uh the mimic protocol. This is a three layer protocol and this is what we have been building uh the last uh six month so that uh with all the things that we've learned. So this is a three layer protocol.

The first one it's the planning layer where you implement your own task. Uh this is offchain. Uh we compile this task into wasome. So you can code this task uh in whatever language uh you want uh as long as it compiles in wasome uh and then uh you decide how to trigger them. It can be maybe on an event uh of of the blockchain.

It can be like a chron schedule. Um it can be maybe on the balance of uh of an address. you decide how to trigger them and you you and you from that task can access accurated data from oracles uh to get the price of the token or or as an RPC and you execute like you delegate the execution to a network of relayers that they are going to execute this wasome uh task for you. This was task what it produces it produces intense. So basically um with the intense we forget about like how we interact with like unis swap.

We just say okay I just want to swap this for this and then we have a network of solvers that will take those intents and compete to get the best quote uh so that the user really gets the benefit. uh and when the the intent it's um executed um basically the whole process is uh complete but there's the most important uh layer that it's the security layer. Uh so the intents they are executed via settle settler contract. Uh this basically enforce that everything that the user said he wants to to happen it's going to happen and it's going to be enforced. Uh so you can create custom safeguards on on our settler.

Um and all of this is enforced uh on chain. So our goal at mimic it's basically uh to standardize uh how we automate task so that more people can come in into um the web3 space and really focus on building uh great products and not to automate uh operational stuff. um great developer UIs. Um you need to have like a curated uh source of data. Um again delegate execution and we need to abstract complexity for for the developers.

Um so that again they can focus on building great product and not like automating some some stuff. If you want to learn more uh you can go to mimic.fi I uh and the docs or just like deep dive into the white paper. Uh we are start building it. We will have a demo in CCC uh of how the protocol works.

So if you're there, feel free uh to talk to me later and I can invite you to to the demo. Um and yeah, that was it. Thank you so much for listening and I think we have some uh minutes for questions if you have any. I just start with applause. Thank you.

Okay. Thank you, August. Um, yeah, let's start with a Q&A session. Does anybody have a question?

I do actually.

Okay, go ahead.

Yeah. So, uh, do you do you see uh network like do you see chains long term staying siloed or do you think they'll be unifying into one layer? actually. So like do you see the current disperse of liquidity as a long-term problem or is it just something that exists because

we aren't just technically advanced enough at the moment?

Uh I think we we're not like technically advanced enough. I think uh it's going to be easier and easier to maybe prove liquidity on one chain and swap on the other one. Um there there's a lot of uh technical solutions with like CK or or things like that that that can also um yeah you can prove liquidity on one chain and use it on on another one and maybe uh we can automate a little bit of that process hopefully uh to make it easier. Yeah.

Um but yeah I think it's it's a problem that we're having now but eventually it's going to be fixed in the future.

Cool. Base rollups are a cool topic right now. That's one way to solve it. I mean it's it's science fiction right now but the plan is like in 2027 to have like

uh proving as part of the L1 like proving execution. So that's going to be cool.

I have one question for the audience who here are developers.

Yeah. Okay. Not that much but uh do you waste a lot of time on repeated task and and trying to automate things?

Okay. You have the mic.

Ah, sorry.

No, you're good.

Yeah. Uh, a little bit. Um, we are doing some automation uh in in our like day-to-day tasks, but uh there is room for improvement definitely.

Okay. Yeah. So, if you find mimic useful, thanks. Come and talk to me after that. Uh, happy to help.

Yeah, for sure.

Thanks.

Is anyone here working on a D5 protocol?

Okay, you might be interested in talking with him.

Yeah, we

Yeah, there you go.

Why didn't you raise your hand?

So, maybe these slides are a bit old because we have Parasap there and it should be called now Balora. Um, but yeah.

Awesome. Uh, let's give another applause.

Thank you.