Automation Security

Transcript

Hello everyone and welcome to the August edition of the D5 security summit webinar. Hello everyone and welcome to the a August edition of the D5 security summit webinar. As a reminder to you all, the deadline for submitting your speaker applications for D5 security summit ends at August 31st, the end of Sunday. So, this will be your last chance if you want to speak in Buenosirus, November 2021st. Um, DSS this year will be held during Dev Connect. And also as other exciting news, we'll start announcing some of the speakers that have already been accepted

to DSS starting tomorrow. So stay tuned and follow us on Twitter uh to see them. Uh unfortunately due to unforeseen circumstances, Alex couldn't join us today. But we have an excellent uh host of uh moderator and panelists that will talk to you about a very interesting topic today about DeFi automation. And our moderator today is one of the more uh famous security uh engineers out there coming from Trail of Vitz. It's Netto.

>> Whoa. Thanks for the K world jury. Um hello to everyone. Happy and excited to be moderating this panel with a killer lineup with Agustoto and Adita from Mimik and Brahma. So we'll be um discussing automation on DeFi and especially with a security mindset as this is our credor DSS. Um as our first speaker I will give the lead to Agusto um I will let you introduce yourself.

He's working at Mimik as I said already and they specialize on automation on chain. So I've already had a had a glimpse as this presentation and it's pretty interesting. I go to do you want to take David? >> Yeah of course. Uh thank you very much and thank you for giving me the space here to to talk and to present. Uh it's going to be fun. Uh can you see guys the screen? Is that okay? >> Yeah, perfect. >> Okay. So today uh I'm going to talk about scaling Ethereum development with trustless automations. Uh I I'm the tech lead at Mimic. Uh so we do automations we have been doing automations since 2020 2021.

Um so uh okay so basically there's a dilemma that usually automations it's not usually prioritized uh and this we see 90% of the times uh with our customers and myself before working at mimic I work at other companies uh and we have a lot of uh repeated processes but basically they were a waste of time um there were some manual intervention sometimes like involving a multic where a lot of people uh have to sign see all the configurations uh check that everything it's okay and it's usually errorprone.

So a funny story uh basically we were doing some automations for one of our clients and we started automation some operations on chain for for like the the whole like all their processes. Uh but we started with a small part of their processes just to see how it was going because like the client didn't want us to automate all everything. Uh but they have one process where they had to send like we to some like every month to another address and they sent we to the west address to the west like smart contract. uh so they couldn't like basically they they lost all the like

the the web that they were sending and everything. Uh so after that obviously we started uh automating every operation they had uh because because of this it's really errorprone when you do things manually. Um, usually also uh there's a custom script. Uh, I've been there as a dev also where you say, "Okay, I'm going to build this custom script uh to automate something uh some smart contract call uh something on chain." Uh, the problem with these scripts is that only sometimes like only you know how it works and like or or the senior dev knows how it works and go through generation to generation like uh and

it's really hard to maintain. it doesn't have any standards. Everybody does these scripts differently. Uh so this is a great uh issue and also uh when you have to get data offchain for example like the price of something or even onchain sometimes like the the RPCs they don't work uh they go off the tip of the chain so you are not getting the data um like it's outdated data um so yeah it's they are unreliable um and als Also, if you have to send transactions, you have to store the key in the servers. So, maybe sometimes

hopefully using something like KMS from AWS or or other um uh key management systems out there. But um hopefully you use that. But like the the reality is that most of these automated process they have this key store in the server. And basically this is a critical mistake because if that key gets leaked for some reason then they can do transactions on on your behalf. And we've seen like this a lot of times. Um so doing automations uh manually um it's hard and doing automation on chain that it's hard also.

Um so a little bit of our journey on how we uh came up with this idea of trustless automation. As I said we've been doing automation since 2021 and before we did everything on chain like we got a smart contract for every client. Every smart contract was different and tailored to the client specific needs. Um and this was great. We could integrate with uh protocols. We we use onchain oracles but the problem is that it was really hard to change. So if they ask us to change some configuration uh on their end uh it was really hard to change that. Uh so we started adding

customizable configurations. Uh this was like we call the stage two. Uh so if for example they wanted to change if like certain parameters the to execute like the the automation for example if the gas price was uh below a certain threshold we should like do a swap or the price of X uh token was below something we can we can swap them things like that. Uh so customers could change these configurations.

Um but they were highly coupled to protocols. Again we did like we deployed one uh whole like recipe for every client that we have. So we started thinking about like the Lego pieces um where like we created connectors. So basically each connector uh could talk with different protocols. So let's say a client wants to add a new um AMM or a new bridge, it would be easier for us to add them. We just add the connector to like their uh automation and they could start using that. Uh and this was great and we still have this uh running uh

right now for a lot of different customers. But the problem right now is that they depend a lot on us uh to deploy the whole um the whole automation to do any change uh to add any connectors. Um so it's really dependent on us and we think we can do better and and we know we can do better than this. Um a little bit of the track record we already process uh more than seven billion uh in value. uh most uh 30 million transactions they went through our smart contract and systems uh and we automated uh 700 uh thousand transactions uh with almost 100 million

simulations to to check that uh all these uh automations they were successful. Um so the idea is that people can create automations without depending on on us. uh or without doing as I said before like custom scripts having the the keys on their servers relying on on um on on private data. So well this is basically the why um we don't see any robust solution in the space right now.

So that's why we we started building this and this is what we call the protocol. Um so basically what we want to see in this solution a standardized way of doing uh these automations there should be some low-level abstractions and I think this is critical uh basically if you want to swap something or if you want to transfer or just make a call you you don't have to worry if you want to swap you don't have to worry about like which AMM to use or where to swap or which API to integrate if it's 1 in if it's meora if it's unis swap. You don't care about that. Uh you just want to get the best rate possible. Um if you want

to do a generic call to a smart contract, you shouldn't be handling uh um keys uh to send them those transactions. If you want to bridge uh you shouldn't like know which bridge bridges are available to use. Uh so that's what we mean with this low-level abstraction. There has to be like trustless data sources and that can be verified. Also the execution has to be decentralized. Uh this is important. We don't want to rely just in one server that if it uh fails for uh any number of reasons uh your execution uh or your automation fails.

It has to have proper access control. uh it should be that you can enforce everything on chain if you want uh to get more secure um properties and also there should be great monitoring tools. So a little bit of this like protocol that I've been telling you and the idea is that anyone can automate uh things on chain using this protocol. Uh there are three layers what we call the planning layer. So basically in here anyone can implement their own task. The task uh right now we have a library to write a assembly script that get compiles into wasome. Um so in here like the idea is

that in the future we can create a ras library python or the community can create those that they compile into wasome. Um this get picked up by like you publish the task to the registry uh and then it it gets picked by our network of relayers. Um the relayers then compete to run uh the this task based on the triggers that you decide. They can be like time based for example a grown job every I don't know every day every week whatever you like. Or it can be based on like an event on the chain.

So if I don't know some contract emits some some event you can trigger the automation. It could be basically on the price change of an asset also or the balance of an account. So if a balance drops through a certain threshold uh then you can execute for example a task to refill uh the balance of that account. Um so the relayers basically they run this uh task that it's compiled in WASAM. Uh in the task you can access uh different queries to different oracles. So you can get the price of an asset you can check uh balances on the chain you can check uh whatever you want

basically an RPC call and in there the task what they create basically they are intents. So an intent to swap, an intent maybe to like uh do a crosschain swap, an intent to do a generic call, do a transfer, all these kinds of intents that you can do. Um so basically the at the oracles again it's a network of oracles uh it is to have many oracles that they also and you can get the basically the response for different oracles and apply what you want to the results. So if you want to do for example for a price the median of that price that you get from different oracles you can do that. if you want to

do uh the mean, the max, the average, whatever you want on that price and this is all really easy uh using like the library and the tools we have built through the protocols on PDS that for developers you don't have to uh do like create accounts on different basically uh pricing providers or RPCs uh it's get uh it's very easy out of the box and then you create the intents basically specifi uh specifying what you So you don't want you don't have to know about like what protocols are you using.

You just create the intense and this is where it goes to the execution layer. uh in the execution layer basically before it gets to uh onchain we also have like a network of validators where like the relayer they they create the intents they run the task but then also uh the validators they run the task to verify uh that everything that runs it's okay and it's what the user expected to be. So these validators basically it's just really easy uh because the the validators they don't get like they don't have to query your accounts they don't have to know the triggers uh it's

basically verifying for example if it's a timebased trigger they verify that okay it's uh it's the time that the user said it want that task to be executed uh the task runs and generate this intense um with this Oracle responses it generates this intense So the validators basically they validate um everything that the relayer does and once we get enough uh basically verifications from these validators uh we move the ex like the intents to the next step that it's basically auction those intense to the solvers. uh we have a network of solvers

again and these solvers they compete to get the user the best price for those intents. So if it's a swap uh it means that you have less uh slippage um they get they give you more amount out for your tokens. Uh if it's a transfer it means that the fee uh that they taken you from executing that transaction is less than the other one. So basically uh the solvers compete to get you the best value for your intent. Uh and then they can execute those intents and this is where we go to the security layer. I think most people will be interested in that in this um event.

So basically uh we have a settler smart contract where it checks that all the balances everything that the intent says it's being fulfilled by the solver. Uh so we have that uh uh enforced onchain and also uh this is very important we have safeguards that you can build uh that they are basically onchain rules that you can put on your tasks that basically it says okay uh you cannot swap more than x amount or you cannot uh call you can only call this function for example to if you I don't know if uh I'm doing a a task to get assets from my

account and invest them in a okay only you can call uh a and this specific selector of this function to invest in a with this amount uh you cannot withdraw on my name you cannot do anything other than just investing in a and this is obviously everything it's enforced on chain with these safeguards that we have um so yeah And that basically the intent gets executed. The server checks everything. It checks the safeguards that you can uh put. Um and this is how basically you can code things in in Typescript in rasp in whatever you want and just call like a a function to

transfer to swap or to do whatever you want and then get it gets translated onchain um in a secure way. Um so yeah that's basically uh the gist of the protocol. Um our goal is again to standardize the the way we automate things in the industry to have a great developer UX uh uh so that you can use this curated data sources uh and a lot of things that they come out of the box if you use uh basically our protocol uh that as we have seen they are hard to do on their own. Um, so yeah, that's it. If you want to learn more, uh, please visit

mimic.py, you can go to the docs or to the white paper. And I'm also happy always to chat. So you can, uh, look for me in Twitter or in Telegram and ask me questions. Uh, I I really enjoy doing what I'm doing. So uh, I'm always available to chat uh, and to discuss things. Um, so yeah, that's it. Uh thank you guys for giving me the space to talk about this and if there's some questions please uh let me know.

Thanks a lot. Um that was very interesting. We don't have any question yet. Um but on my side I may have one or two. Um if people want to try out and use uh mimic protocol uh how could they do it right now? Um so you can uh basically mimic protocol it's not like live right now for production use cases. Um so you can go to protocol.mmic.fi and you can start like maybe uh in there you can see all your task and everything but the where you should start basically it's in in the docs. So if you go at docs.mmix.5 uh you should see uh how to get started.

There's some examples. We have a repo with examples there. Um so you and you can also I think it's in mimic.py but you can uh subscribe to our newsletter um to get updates on when it's going to be going to be uh production ready and live so you can try uh use it for live uh production use cases. >> Okay. >> But yeah just go to docs.mmic.p5 five and we have a great uh starter example there.

>> Okay, great. And I have another question which was uh you presented a three layers um protocol infrastructure. Which part of these layers was were onchain and which one are offchain? >> That's a great question. Yeah. So basically the security layer that's all on chain and that's where you get like the strongest guarantees that why that's why we have like the settler the safeguards and everything. >> Uh the rest basically the planning and the execution layer they happen offchain. Um so we validate a lot with we play a lot with signatures and like uh permissions that you can give but the everything that it's on chain it's in

the security layer and this is where we have strong guarantees that what you say it's what go it's what it's going to happen basically >> and part of the layers are the um solvers and the relayers uh you said if I remember correctly that you have a network of of solver how how are you whitelisting them who are they basically which type of actor >> okay perfect yeah of course uh so like right now again it's uh in super let's say alpha so we don't have like a network to have like a network of a lot of solvers relayers validators and everything uh basically uh they have to uh basically stake to be able to be part

of like relayers, solvers and validators. And if you want to stake depending on like which actor you're going to be at the stake it's different but you have to stake uh and then uh you can be part of the network and basically you misbehave >> mimic token I guess do you have your own? Uh no no uh it can be ETH. Uh we haven't decided the the exact details yet. Uh but yeah it could be a lot of uh it could be ETH. It could be yeah whatever uh we decide yet. Uh but um yeah that's basically um the idea.

>> Okay thanks. We get one question in the chat. Um, do you have access to the chatindo or or not? >> I don't think so. No. >> Okay, I will read it. No worry. Um, you mentioned that you can verify that what was expected to happen actually happens. Uh, I think it's part of the exe security layer. Can you also prevent unexpected or malicious actions from occurring for for instance hidden malicious approval for a specific token? Um I'm not sure what they mean but like you can in the safeguard specify like everything that you want to uh the the protocol to do. So if you say

okay like uh I just only can invest in a then nobody can call from the automation like hey just uh uh approve this token to be moved for example. Uh but also we take >> I can imagine a scenario for example the UI of a user would be hacked for example and so you know for sure that certain action should be happening and this might be one of them a malicious approval for a specific token in that case you could be um kind of blacklisting this type of actions.

Yes. Or or things that you can do basically it's uh for example one thing that you could do it's have like a security component of with an automation where basically you say okay I'm only going to approve this tokens let's say and if you whatever reason you approve another token this gets emitted maybe uh an event on chain uh you can listen to that event and say okay just like you you can give our settler permissions to basically um just not not approve like disapprove those tokens. So the automation would basically uh be dispatched and and we would like roll back that approval. Uh

that's something that you can do. >> Okay. Thanks. Please let me know in the chat if the if the answer wasn't what you were expecting. Um and I may have one last question. um you if I remember correctly you can trigger some action from an event incoming um onchain. Can you do that also for an offchain event like I don't know you receive a telegram notification or something that would be triggering something onchain? So right now no uh there's might be ways to go around this but um the problem is that we don't have a way to verify that um in the network like the validators

wouldn't have a way but there's a if you like trust one of the actors uh you as a user say okay I trust this actor let's say or this telegram then there's way to do it uh and we maybe wouldn't check that but yeah that like right now that that's why we're going for onchain events and things that can be verified uh so that like because if not we don't have like the validators cannot verify that that indeed happened um so yeah >> sure okay thanks thanks a lot will definitely be following the um development of mimic in the in the

foreseable future um Azone uh which is with us the second speaker of today webinar lead smart contract engineer at Brahma um so I think Brahma is a pretty well-known brand in our space um just for those who don't know Brahma already they pioneers the onchain solution for transaction and volume and so ad if you want to take the mic um we are all ears for your presentation Thanks. Uh, let me just quickly share my screen.

>> Okay, let me know if you guys can see it. >> Yeah, perfect. Thanks. >> Perfect. Hey guys, I'm Adita. I lead the onchain solutions at Brahma. Uh we have been working on this problem for about four years now where uh the core problem is how to automate uh transactions on chain. Uh and uh by automating make the life a little bit more easier for the user. So um give provide them a web to kind of experience where they just set it and forget it. And uh this uh goes into why would you need automation if you can just click your wallet on MetaMask.

A lot of these uh transactions that u automations might want to do are me driven or machine-driven transactions. So um it could be as simple as uh checking an event which got logged on the blockchain or it could be a series of very complicated FNLs and a lot of uh conditions that match together to make sure okay now is a good time to make a transaction. You can do a lot of me you can handle liquidations. You can uh also do a lot of the yield optimizations which is uh if you have a capital allocated in one vault and let's say the other vault or other source is giving you a better uh yield you would like to reallocate the capital to that vault uh in an automated way. Um and then uh there are some transactions which are

not easy to automate which are more like user events. So something like let's say I have a user who wants to pay for a coffee in a cafe and uh as the systems builder I can never predict when that transaction is going to happen when the user wants to pay for that copy. So um that uh is the kind of meaning that we want to provide where the users can uh execute transactions at will and uh we can automate transactions as well.

So, uh, DCS and T-Bops are kind of glossed over, but they're pretty much the same thing. Which user sets a DCA dollar cost average. I want to buy X amount of this asset every hour, every day, every month, whatever they want to do. And doing it on chain is very hard. If I have to do it personally, I would have to, you know, set up a timer, set up an alarm clock, and go to my preferred DEX, place that trade and, uh, make sure I do it every day, every week, whatever my priority is. So, uh, this is something that users should be able to automate pretty easily. But uh currently not a lot of solutions available.

So let's see at what are the requirements to automate a logic transaction. Um and this discussion is very specific to EVM but uh will generally apply to broadly most of the blockchains out there. So you have the first topic is private key management. Uh if you're working on EVM, if you're sending transactions, if you're doing anything at all with EVM, you have to have a private key, right? That's your account. That's how you identify on chain that hey this is me I want to send this transaction and there a couple of solutions available as a also mentioned like you have the keys uh which is a good way to store secrets you have the key vault you have the cashop vault all of these solutions are not built for uh key management per se uh

they are built for secrets management so what that means is uh let's say I was using an RPC and the RPC has an API key which is a secret I can store it on AWS or the wherever I want to I can store it on the hashikop uh and during execution my code on my back end any service can fetch it in the runtime from the service and uh basically then the service has access to that secret in this case uh let's say I had an alchemy key the alchemy key will be present on my service and my service will be able to use it to do anything uh avail anything that it wants including uh uh let's go for the case of private keys if we store private keys on WS Azure uh you can you know easily uh get them into your

service and then you can start sending transactions but then how do you make sure your service is not signing the wrong kind of transactions. So u how do you know a service doesn't go through especially if it's a large organization and you have a lot of people shipping. So uh a way we devised a solution for this is we built a hashop plug-in specifically for Ethereum key management. What it does is uh it acts as a plug-in on top of the hashop vault structure uh which makes uh key management very simple. So now if a service needs to use a key, it uh does not have to fetch the key, it simply sends a message to the Hashikop world saying hey I want to send this transaction and I would like a signature for this and uh if the hashikop says yes

okay you're good to go a hashikop will itself generate the signature in its secure environment uh and then just present the signature back to the service. So this makes sure you're not leaking keys into your services and uh obviously this makes for a much better security model in terms of managing your assets and secrets. Um that's one uh of the innovations that we did over the last four years because we had this problem uh coming up repeatedly. And the other part of the automation stack that you need is RPC. Now as again said RPCs can be very stale. RPCs can go slow. Um you they can be out of sync. uh sometimes by having multiple blocks depends on the chain. So uh unfortunately we haven't find found a found the best solution for that but

right now the current solution that works for us is uh just having an on-prem RPC so we can make sure the uptime is good and uh uh yeah we can monitor for any kind of instability that happens. Moving to the next one. So let's say we have this stack. Let's say we set up our keys. We set up our RPC. We are ready to send transactions. How do we scale it? Uh we use a service. We build a back end. Uh let me go back to the slide itself. So we have a back end. The back end is going to get a signature from the Hashikov vault. Good to go. It's going to publish the transaction and the signature using the RPC on the network and go good. Your transaction is done.

Uh and this could be for whatever intent or trigger that you might have. Maybe a user wanted to pay for his coffee. You got the signal that he wants to pay. Immediately get a signature. Publish the transaction. Boom. But what happens when you have to scale it to uh let's say multiple transactions happening per second. So looking at this case uh you have uh let's say you have one keep here like uh let's say my wallet ABCD uh zero ABCD and uh I'm just continuously fetching signatures. My service is running on the loop. Whenever it gets a new transaction, it fetches the latest signature for that particular transaction, publishes it on chain. Now the issue here is um a lot of the times what we observed was RPCs would give us

stale data or RPCs would give us unconfirmed data which they are purely in the right to do so. So transaction one went through it's still sitting in the me pool. It's waiting to be confirmed. Meanwhile, we wanted to sign a second transaction. The RPC does not know that this there's a transaction already waiting. So it's going to give us the old nons and when we try to sign the new transaction at the same nons the nons will conflict and uh our transactions won't go through. So that was again a big challenge that we have and uh uh to I will address this challenge in multiple ways but the first step with like the first logical step is uh have multiple keys right like have the f have like 10 15 whatever you need depending on your volume have those in a round drop in fashion maybe an array and

just iterate over them whenever you have a mutx lock on them saying uh okay this ka is busy let's go with the next one let's go with the next one now the issue that we is for this uh is uh remember the old key that we had the one key here this used to identify us that hey we are XYZ we are Brahma we have this authority on chain to execute this transaction excuse me guys so executing transaction could mean uh maybe we have approvals to from the user maybe we have some delegations maybe we have some assets that we want to approve so whatever we want to do this is a key pair which has the authority or the assets to do so now we went to now when we move to a multi round robin fashion. Uh it's very difficult to hold assets uh across

multiple keys, hold delegations across multiple keys. It kind of fragments your whole system and uh it's not viable in a production environment. So then uh how do we solve this? So we put an execution contract in the middle which gets all the delegation powers. So as you can see we have one to n keep pairs. We can have like 10, 15, 20, 30, how many other keepers we want who have authority to execute or send a transaction to our execution contract. So this execution contract has all the power. It has all the delegation. For example, if my user wants to pay for his copy, he will delegate his assets to my execution contract, not to my keeper.

This allows me to have a better secret management experience. I can rotate keepers, I can switch keepers. Uh this execution contract is currently a Nosis multi6 safe for us and uh we ended up developing custom plugins noises plugins that can allow us to manage our key pairs and these keep pairs can uh send any number of transactions right so you have keeper one sending nons one key pair on one key two sending nons one whatever uh at the end of the day it's the nons checked at the keeper side but all of these keepers can execute in parallel to the execution contract which unlocks a huge scale for us uh to the destination contract whichever you want.

Uh an additional feature that I kind of glossed over is uh looping multi calls. So because as we know in Ethereum right now um I mean it's a bit outdated but with 7702 is possible but without that you have your key pair which can only execute a single transaction. So it can only either let's say you want to do a swap right you would have to do one approve and then one swap which is not very ideal and with execution contract you can batch all of your calls together in one multi call and then send that multi call to whatever destinations you want. So one call goes to my USDC contract for approving to some swap router second call goes to the swap router to actually swapping the tokens and sending it back to wherever the user needs.

Now u this uh solution worked pretty good for us but uh we were still not satisfied with the amount of security uh that we received from it. So things could still go wrong especially when the services are not acting the way they should. Um so how uh how we added this uh extra layer of security is we expected user to provide the automation delegation to the execution contract and uh let's say you want to automate a user's transactions right I have let's say I have MetaMask now MetaMask has $1,000 and I want to spend my $1,000 let's say MetaMask gives me a card like Visa credit card and I

want to spend it and my funds are in my wallet how does MetaMask ensures they can take my funds out of the wallet they obviously have to do some kind of a uh they need some kind of an authorization right uh either they have my private key which they're storing somewhere which is uh not the ideal solution uh that's why I wrote user should not expected never be expected to provide the proprietary keys what here user does is user gives a delegation uh like an approval of their onchain assets or onchain position this could be your USDC token which you're given an approval for this could also be a USDC uh spending power for example to lend your money into NA uh you want some yield on it you don't want your assets sitting idle right but you could still

approve those assets to us and uh we could borrow based on the behalf so if you like if you lent WBTC you don't want to spend in WBTC but you still want that WTC exposure you have lent your assets in WBTC and we can just simply you know borrow x amount of USDC uh from your collateral available on and uh those are the kind of uh those are the kind of automations that we really wanted to achieve with this solution especially because uh uh stable coin spending is getting a bit old and we do want to get users to that central like bank experience right where your money is still getting yielded uh it's not sitting empty so automation automating on users behalf uh as I told you we were still not very happy with the level of security that we

had achieved uh we were very confident about the secret storing but there was still an ambiguity on what kind of transactions could be executed on users assets now we cannot execute on user wallet but uh that's where we came up with the idea that that okay let's give user the programmable wallet itself so uh we have a key setup here we have an execution contract and here we user we place user with a smart contract wallet uh in this case it can be a noises multisig it can be the base smart wallet it can be any wallet that works with 43 73 uh or the currently in our case we use the safe plug-in methods to add composibility to this model. So uh we added transaction

cards which are available on safe multisc which make sure they do a pre-check and post check after the transaction. So let's say I'm trying to execute a transaction to approve some tokens to a there will be a pre-check transaction where I can scan the bite code. I can do I can have a look at what type of transaction I'm trying to execute. Uh post transaction I can look at what EVM state changes happened during the transaction. How much did my balance decrease? How much did my total go down up? Uh did my balance increase for certain token. So using these parameters we can build onchain validation to make sure that only things that are supposed to happen happen on the user's wallet and at the end of the it's a multisig user can set set it up as a one by one multis so he has full

and sole control over that and they can kick us out of the execution rights at any point in time. Uh so to there's another artifact of transaction simulation that we wanted to do which is when we're trying to execute a transaction we simulate it fully on our back end make sure that matches with our policy as well and uh provide a signature of sorts uh to make sure that okay yes we test this transaction we are confident behind this that this is not a malicious transaction. So coming to real world deployments uh all all the architecture that explained how is it currently being used. So we uh came up with I think there's a third

product in automation. We did AI agents. We did onchain automations uh like DCAing into multiple assets on multiple chains. We are live on nine uh I think 10 chains. And uh currently our latest product is Swipe. Fun where users can just quickly sign up uh and get a visa card issued to them. Uh and uh they delegate us our positions how muchever they want. They can have a six figures, seven figures, doesn't matter. They should only delegate how much they're planning to spend which can be like $1,000, $10,000, whatever they want. And uh the same infrastructure happens where they go, they tap on the coffee shop POS point of sale. The transaction uh validation comes with us like we get a

notification saying okay this guy wants to spend his money. Uh we quickly check whether this guy can abs this guy has enough money in his wallet to actually solve the transaction. So that could be any kind of D5 position he has as long as we are able to solve it into USDC. We will take that out to USDC and we will settle Visa. Uh this all happens in about 800 millconds and uh for the user it's very simple. You just go tap your Apple Pay on any point of sale and uh it works like magic. So anyone who's interested do try it out. Um I think that's it for me. Uh do you guys have any questions? By the way, I'm always available on these links to chat talk. Happy to be here.

>> Thanks a lot Eddie. Um I definitely recommend everyone to try out button. At least the website is really really cool to be honest. uh just went there um before this webinar. I was really impressed. Um I don't think we have any question right now. I may have one um maybe for the both of you. You if I'm not mistaken are both targeting um mainet uh do you have any plan on deploying to other blockchains and if not why?

on on our side um we're not only targeting Ethereum mainet but like optimism base uh polygon a lot of chains um so yeah the idea is to to go in as many uh chains that we can't and also we have like this low-level abstractions where like you can uh do like a crosschain swap or a bridge um to other chains um so yeah the idea is to to embrace >> based uh chains right Um yes, we're working towards having Solana also uh another nonvm compatible but for now yes uh it's EVM.

I I think it's curious because like I I think we name things differently but they are mostly the same when you look at the roles like the settler our settler is your execution contract we have the same issue when like executing on behalf of user like generic calls uh they have to be also smart wallets we cannot just uh do a generic go to an EOA. So yeah, it's it's good and and also the same problem. So I I think we are both on the on the right track. Uh yeah.

>> Yeah. One other issue I noticed with the 7702 implementation is that a lot of wallets have locked it to their own implementation. So I cannot provide my own 7702 implementation. If user is using MetaMask, they would be locked to how MetaMask wants to implement it. And have you found a way to um bypass this restriction by 7702? >> Uh not really. Uh right now as a said we are using smart contract wallets to bypass the issue but at the core level the wallet or the key holder is the wallet provider which is metamask and they hold all the power.

>> Yeah. Um I actually have $1 million question given the um recent news at least for the last few years. Um what about AI guys? Have you implemented it in your protocol? Have you tried it? Have you thought about it? Um I can't think of any team at bit that is not working hard on it. So I guess you should be too at Brahma and and right >> uh we did experiment with a lot of LLMs and with the correct set of permissions we did give them the uh let's say the capability and the context to actually execute and automate transactions for

the user. So we do still have a couple of agents live and I'll be happy to drop a link in the chat. >> Okay. And what were the results of your first experience with a basically autonomous agent managing your users users funds? >> There's a lot of safeguards to be implemented because uh AI or LLMs are such a thing which you cannot really moderate the input that the user can provide. So you have to account for a lot of different types of inputs and what the agent might try to do from that input and you have to restrict the agent into certain boundaries uh certain safe boundaries which are beneficial for both the user and the protocol.

>> Are you doing that? >> So that's through the execution contract >> uh both so we have to set up the LLM also in such a way that it discards 90% of the invalid inputs or invalid requests that the user might provide. And uh setting up execution policies as we discussed in the last slide making sure that you cannot spend more than x amount of money and uh your tokens are only going to all the whitelisted addresses that we have decided for you which might be swap routers which might be guil products etc. So you shouldn't be able to send tokens to random addresses.

>> Thanks. So uh we have like a similar approach uh where we think uh it's not like AI it's going to be like doing everything for the user because again that there's a problem of of the risk and the permissions that you want to give the AI. So in in mimic you can do like small like tasks that do certain things and then like you can change the inputs and the parameters of those tasks. So we don't see like the use like doing the coding of the task themselves but mostly and executing them but mostly like you said a defy like a define uh task that the AI can use and the AI will pick the best one and fill the

parameters with all the safeguards to use them so that like it's uh it has like a little bit of like guard rails uh so that you don't let the eye do anything but just is predefined task that anyone can code. >> Okay. Yeah, makes sense. Seems um sound definitely safer than letting an AI go rogue with any users to be honest. Um okay guys, thank you very much for for this answer. Um we don't have yet any question in the chat. Um Yuri Yuri, sorry, maybe do you have one?

Um, no, not at the moment. But, uh, I've learned a lot. >> Yeah, definitely >> guys. Um, for an interesting webinar, uh, we can see that making things simple and easy for the user is actually a lot of work in usually the case, right? >> Keeping it secure makes it even harder. >> Yes, >> that's true. Uh, if we could only forget that part, but we don't. And uh I'm reminding you again um people in the audience if you have anything interesting about security in web 3 um and you want to speak in defy security summit in November 2021 in Buenosirus

Argentina. Uh the deadline for speaker applications is August 31st which is Sunday. So that's going to be your last chance. Um don't miss it. We want to hear your good ideas, your good insights. Thank you again um Aditia Gustito and for a very interesting webinar and I hope you enjoy and I hope the audience have learned new things. Thanks. Thank you for Yeah. Thank you for the time. Byebye. Bye guys. See you in Bonas.

See you in Bonides.