Scaling Ethereum development with trustless automation by Lukasz Stoczynski

Transcript

Hi there, my name is Lucas. I'm a head of go to market at Mimik. Um, and today I'm going to talk about scaling Ethereum development with trustless automation. Um, so in crypto startups in the dev teams, the automation is never prioritized. Uh, there's always something more important, you know, smart contracts, architecture, security. Um that's why automation what we've seen uh in the past is always uh procrastinated. Um so uh the devs waste too much time on this and waste too much time on doing um repetitive stuff. So what we've seen working with top protocols and applications in the space um there is a lot of repeated processes that companies

do you know simple tasks for swapping bridging um things onchain and this is a waste of time for any team. Um a lot of manual intervention a lot of signing transactions uh in a manual manner. Um this usually uh you know is errorprone and leads to to mistakes, funds being sent to wrong address, calling wrong contracts etc. um you know some more um I would say um experienced team they will build custom scripts um to automate some stuff but you know these are unmaintainable and then there is no standards on how to automate um actions um through through scripts. Um then they always rely on private data sources,

oracles, prices um which is uh usually unreliable. Um and then you know the the biggest problem of these keys to execute those transactions are stored in servers which can lead to critical mistakes uh which we've seen in the past many many times. Um what we would rather see when it comes to automation is to have standard processes things being done in a in a standardized way. Um low-level abstraction. So some like it's always down to interacting on chain calling contracts uh moving assets. So um some things should be abstracted um trustless data sources. So we don't rely on on the private data. We do have the oracles price feeds onchain offchain um that are

trustless. Um the centralized execution because you don't always have to uh decide like what do you want what's what solution you're going to use to to execute your transaction. Um you want to have a a source of decentralized um actors in place. Um proper access control so the team members and whoever needs to access it um uh has has got um proper rights and then obviously monitoring tools uh for um checking the statuses what's gone wrong, what's gone well. Um so yeah this would be amazing if we can have that. Um but you know our journey to trustless automation um we have been building automated automation tools for the past 3 years. Um and the

stage one of the onchain automation we build were what we called onchain receipts. These come with a lot of benefits but also uh downfalls. So you know we were able to do protocol integrations uh we integrated onchain oracles and we had reinforced security through smart contracts but these were very unflexible. These were hard to change um and every receipt um was kind of tied to a very specific customization. Stage two uh was customizable configuration. So we've we've learned a mistake. We wanted something that's a little bit more um customizable and uh we've implemented different things like uh minimum thresholds, time locks, uh volume and gas limits, um and also access control for um different users. But

unfortunately these were highly coupled to the protocols that we've integrated them with. So if our customers asked us hey like we want to integrate another aggregator another protocol um we would have to um go over again. Um so the stage three uh that uh we've had before uh the protocol is with what we call Lego pieces. So it was like highly um modular um system with protocol connectors. So each protocol each um uh had you know they're all um their specific connector. Um we standardized the task. So for every activity we had a um task that also improved the relayer execution. Um and this allowed us uh complex modeling because we were able to have much more flexibility um and were

able to tweak um uh what we can automate. Um the downfall here is also that you know it was heavily dependent on us. So any changes that needed to be implemented um um had to be done by us. So um we definitely validated the idea. We've been building uh automations for the last three years and um what's next. Um yeah, sorry. Um so we have processed over $4 billion in value through the existing um solutions uh and work with some of the top protocols and applications uh in the space. Um so what we want to do now is we want to open up the the playground. So we want anyone to be able to access uh a standardized way

to automate things on chain. Um why we want to do this? Uh a lots of developers facing the same needs. Um every protocol every uh app they're facing the same problems. Um there is no robust solution in this space. Um and you know we need the standards like uh my previous speaker said Vitalik wants you know things that are um trustless that are standardized and we should always aim for um this uh benchmark. Um so um introducing mimic protocol it does contain three different layers. Um so the layer one is the planning layer. So in the planning layer um uh the user or developer can implement their own tasks.

uh these are done programmatically uh through um high level coding or uh through APIs and SDKs. Um and you decide the triggers and conditions on um what you want of what how how you want them tasks to be um or what what's going to trigger those tasks. Um you have access to the access to created data from Oracle. So um we monitor or the protocol monitors um uh different um curated data sources um to trigger those um tasks and uh the um execution is delegated to um relayers um execution layer uh it does require no user intervention. Um that was one of

the key things that we wanted to do. So once a user signs uh the task um it's out in the registry and then uh whenever the triggers and conditions are met the protocol creates an intent on behalf of the user. Um this allows us to um to um uh send the intention to send like what needs to be done um on chain. Um and then we the protocol is leveraging existing solvers infrastructure to find the best way to execute those uh this this task and to uh provide the best price the best execution um uh that is available um out there. Um and yeah um the last part is the security layer uh

which is optional for the users. So basically um uh users can set the the onchain enforcement um uh through the safeguards. We're obviously using the settler contract which is kind of standard thing for uh the intentbased solutions. Uh but user can also set the um the safeguards. So basically you can define what are the limits, what are the things that you want to specifically happen or not happen um in the uh when automating um the workflows when automating the tasks. Um so these um safeguards are um enforced on chain. Um so basically if uh the safeguards are not met um in the execution they will be

basically rolled back and the intent will fail and not get executed. Um so yeah we do need trustless automation and our goal at mimic protocol um is the standardization um we want to uh build automation in a way when it's it's u standardized to um the level that everyone is uh you know using the same battle tested and secure uh processes. We want to improve the developer experience because if developers have more time to um uh focus on things that matter and not on repetitive tasks on on building the scripts all over again and to going through the same cumbersome process, it will improve not only the

developers UX but also the the users um um UX. Um we want to have the curated data sources. So trusted oracles, trusted um offchain and onchain data um delegated execution to the professional uh parties like solvers to to do so and um abstract the complexity that is involved in the um in creating um onchain automation. Um so if you'd like to learn more uh we have got the docs and we have got a white paper if you also want to learn more about the maths uh behind the protocol um the security part of it. Um you can go and uh visit our website and and read more um about this.

Um and yeah that's it. Thank you very much. Uh I don't think if we have got time for question. Do we have any questions? We don't. Okay. So, I think I'm just in time. Perfect. Thank you very much.