A Hitchhiker’s Guide to a Trustless Automation Protocol

Transcript

Hello. Can Can you hear me fine? I think you do. Yeah. Well, welcome guys to the Hickor's guide to trust this automation protocol. Thank you for making the time to uh being here for being here today. Hope you enjoy it. My name is uh Fu Espanolo. I'm one of the co-founders and CTO uh of Mimic. We've been doing automation for a while. Um I've been contributing this space for the last uh eight years I think to many different projects but we've been doing mostly automation uh at Mimic since we started it four years ago. So um let's start with the beginning uh what do we mean by automation just to be all of us on the same page.

Maybe in a generic way we could say it would be like interacting with the blockchain without any manual intervention. But if you try to think it from the developer perspective, we could say uh it more be like executing trying or trying to execute code on the blockchain without or when certain conditions are met. So let's uh begin with our guide. Um Marvin is going to help us today. Not sure if you know the character, but it's uh from old book from the 1980s. Hope you enjoy it. But of course, let's always uh we're going to go through different features, but let's always think and not forget about decentralization and and and being trustless. This is uh why we're here mainly.

Chapter one, scale transactions. Uh let's start with something simple. Uh let's say Alice wants to transfer certain amount of money to Bob. Um in order to take care of this, we just need to make sure we need we we can execute certain transactions on time. We could use uh crunch jobs. We could use any decentralized solution. It could be something like defender or gelato. Uh we could program our own smart contract just to make sure cert transactions occur at a specific time. This sounds very simple. Uh so we can add some sort of scaler to our protocol to make sure we can control when certain certain transactions are sent on chain.

Chapter number two. um balance thresholds. Um this is very common, but usually users don't want to send transactions if it's not above or under certain thresholds. Let's say we're talking about money. Yeah, we don't want to send a transfer. If we're talking about just a small amount of money, we want to do if it's more than X or under Y, whatever. Um this looks very simple as well. uh if we keep our onchain uh or our smart contracts implementation we could say we can query balances on chain that looks very simple also there are many uh solutions out there like tools again as I was saying solato or defender and many many um many of these tools uh

allow us to query information on change so this doesn't looks very complex um so let's add these thresholds to to our protocol Chapter number three, um token prices. Usually users don't refer to um thresholds in tokens because this this is not scalable. They they want to refer probably thresholds in any other type of currency like dollars. So they would say okay do it but if it's under or above X amount of USD.

So we will need to add rates between tokens in order to do this. uh we could rely on if we still want to do the onchain thing we can rely on on chain oracles it could be chain link or any other one we could use dews uh from many dexes uh many of them support them um again it doesn't look very complicated to do this we can add some token rates to our protocol kind of easily but what will happen if we want to add like any token price uh u our user will probably need uh prices for any weird token out And this is as you may know, not sure if you uh tested some of these onchain oracles, but it's not a common thing.

There are many tokens out there that don't have uh support on chain to query their prices. So, we will need to rely on some sort of offchain of off-chain data source. But remember, it has to be trustless. So, now things get a little bit more complicated. we'll need to add some sort of offchain uh trustless data source to our protocol. Let's think about the operations uh the operations that users want to automate. We said about transfers but what other types of operations defer is probably one of the most important ones. Uh we could say um any type of tokenized operations. We could say uh swaps, we could talk about investing, borrowing,

um any any type of tokenized operations. Of course, we we can in integrate dexes. Uh we can also craft our D5 protocols integrations with our smart contracts, but it doesn't feel uh very scalable. We could uh try to integrate aggregators uh relying on some of these off-chain uh quotes, but the execution is still on chain. we'll see. So definitely D5 is something that we need in our protocol. Let's try to be a little more generic about the operations. So it's very common that at some point users need to execute a custom function on their protocol to do something like a

recurring uh operation. I know I I need to claim uh tokens from my protocol. You need to call this function every 15 days. Um that's it. So in this case, we're talking about arbitrary calls. Um but the problem is we'll need to program each of this. Every time we need to integrate with a with a custom protocol, a custom function, we'll need to integrate that in our protocol. So this again doesn't feel uh very scalable at all. Um but let's say we want to add this. So let's try to have generic calls in our protocol as well.

Let's move to the next chapter chapter uh custom triggers. Um let's say just a quick example. If A occurs on on chain X, I want you to perform uh B on chain Y. This could be uh like a crosschain trigger or something like that. But at some point we can summarize this as uh arbitrary event triggers. We could uh rely on onchain oracles information. If uh like some of them are available for events but not many of them, it's not that easy to query uh other chains information from one chain. So um at some point we still need to rely on on some trustless um data off chain to do this.

But let's add add this uh arbitrary triggers to our protocol. This is uh probably uh one of the most important ones like um if we're saying we're allowed to execute generic calls uh at some point we can think about permissions. We don't want to store keys uh in in our scripts or programs that we're executing for our users. Um the thing is uh we need to we need to think about something permissionless. We need to think about uh trust what we call trustless execution. At some point it's true that if we can verify that all the conditions are met uh that were

specified by our users then it should be um it should be a public execution should be possible. Um but it's definitely something something uh very complex but let's let's add trustless execution to to our protocol again. And finally easy updatable. This is uh probably the most important one. Change is definitely the the rule, not the exception. Um our our users are changing requirements and needs all the time. They're trying to tweak triggers. They are trying to tr twe the conditions, the input uh to whatever they are automating. They want to automate different kind of uh operations. Uh they

want to stop what they're doing. They want to scale scale it a bit more. Um I definitely definitely at the at the end of the day we need some code that they can update um about the things they want to automate. So um now what um people usually think this is uh automation is something simple um but definitely it isn't. If we look at all this um I'm I'm I'm not sure if you can find some some solutions out there that that you can access to all these features.

uh with a with a as a single as a single tool that you can use as a developer. It's definitely not simple at all and this is something that uh we've been doing um we've been putting all all the efforts uh into into our protocol to deliver all this for the community. Let me tell you a little bit more about how mim mimic protocol works. Um essentially mimic protocol uh is a three layer uh solution to help developers interact with the blockchain without too much intervention. The main idea is to for the developer to focus on what do you need to automate to focus on the code to focus on when the things should happen but without taking care about

anything anything um more than that. The idea is to not to care about RPCs, not to care about um execution, not to care about the transactions per se, not to care about uh integrations with D5 protocols, um not to care with uh the integrations with oracles and and much more. Let's jump a little bit into the details about which are these uh three layers. So the first one is what we call the planning layer. The plane layer is basically where the developer uh can write their own tasks to to automate what they want to do. They just need to define uh what's what's the trigger. It could be as we were saying before something related to time, something

related to onchain events, related to balances, related to prices, whatever. Um the good the cool thing about here is that they can rely on the on the oracles to access any type of uh data source that they want to use for their automation. It could be prices, it could be information about the chain um information, I don't know about tokens, about guest prices, whatever. And finally, the most important thing is the relayers. They don't need to care about the execution. Uh this is where trustless execution comes in. this is um being taken care by by the relayers. So users just deploy their code and that's it. Uh the relayers will do the uh the

thing. Then it comes to the execution. So uh what's the output of these tax tasks that are being executed by the relayers? Uh this is where we we're leveraging the intent um uh infrastructure out there. uh there are many um I mean this is something trendy in in the space and definitely we're uh leveraging the uh the concept. The idea is that the tasks are going to um output intents to a network of solvers. So basically you you just need to care about what you want to do but know how you do it. This is basically going to be uh these intents are going to be auctioned to a list of of solvers and the best um match is going to be executed on chain. And finally basically

the onchain layer what we call the settlement. Um this is the the part where we basically enforce that whatever solution the solver is trying to execute is matching what the user uh requested in the in the code itself. So we're here to uh push for a standard. Um we're we're releasing an another version. It's already live in optimism. If you want to try it, um you can read more uh about this in our website. We have our um doc site also available for you to um to read more about each of these layers, the the SDK, the API, uh the library to code your tasks. Uh much more about the the

architecture. Also, there's a section about the white paper if you want to deep dive into the technical details. um allow you to take some pictures of the cure co and uh we're doing a live demo tomorrow. Uh we're hosting a side event uh during the afternoon. So if you want to see it uh working live, you can join us. Um yep. Uh well, hope you enjoy it and thank you for being here today. If anyone has a question, just raise your hand and I'll bring the mic to you.

Thank you. I might have missed it, but can I also react to an onchain event by firing an off-chain task? Let's say trigger notification to Telegram, Discord, whatever. Not right now. um like we were u mostly focused on the other way around like trying to execute something onchain. Um but it could be something interesting to to look into it. All right. Thank you so much today.

Thank you guys. [Music]