DAPPCON 2025: Extending dApp Capabilities Using Reactive Smart Contracts - Ivan Ivanitskiy

Transcript

Hey guys, thank you very much for coming here today. My name is Ivan Ivanitzki and uh I will share some uh coding, some examples, some uh concepts of reactive network. Uh so first of all, thank you very much for your interest. Um I appreciate it a lot because I love sharing the tech stuff and um so before we proceed to discussing the reactive network itself uh let me share the objectives of this workshop. So first of all I'd like to share what we've built and what we can do with those who might be interested in case you want to use

our text tech obviously but that's not the only goal. Also, I would love to share it with with anyone, even if you won't use it in the future, just to hear your ideas on how it works and mainly what it can be used for from your perspective. Uh, then hear your concerns as well and obviously have fun. Uh, even though it's pretty early, right? So this is the telegram chat that I've created to assist you and share the links. So in case you are going to code today, which I hope you are, please share this um please join this chat. I

will be sharing the links there. Also, we have uh a bunch of team members there who will be able to answer your questions and help. So yeah, I will leave it here for probably 30 more seconds for you to be able to scan it and join the chat and meanwhile I will start uh telling about us. So uh reactive network uh it's an interoperability solution. In uh simple words it's an onchain if this and that. So we listen to uh events on one EVM chain then we process the uh them with solidity logic. So we are also an EVM chain and you can describe arbitrary

conditions there and after that we uh uh execute a transaction on a destination chain. It might be the same chain as the first one or a different one. So it can be used for uh cross-chain functionality or it can be used for automation within one chain or several chains as well. And obviously all of that happens in a decentralized manner because even before reactive network arrived there were other solutions that can do the same in a centralized manner like bots other stuff but yeah our idea was to enable doing that uh without centralization.

Okay. Uh so we will do some uh examples deployment today probably live coding in terms of creating new code but not necessarily uh we will just um talk have some questions and we might have some time for live coding but um we definitely will deploy some code examples. So in case uh you want to try them uh yourself, you will need uh some of the stuff that you can see on the screen. So first of all, you will need uh git to clone the uh repository with the examples and the same one will be used in case you uh decide to build with us. Um we will use examples as a

starting point point as a boiler plate. Then you will obviously need a text editor, terminal uh a private key which you can uh derive from your wallet and uh you will need some react tokens uh which we uh will be sharing in our chat. Not a lot of them that's not an airdrop just uh a few for testing purposes. And uh also you will need uh the gas token on the uh destination chain where you want to execute actual transactions. It might be uh Ethereum in my case it will be B uh and and some other chains. I will share the list um later.

Yeah. Uh please go ahead and uh please uh take the mic because we are on the stream and we want our listeners on the stream to hear your question as well. Regarding the supported chains, do you support all the test nets uh that are related to those production chains? Uh thank you for the question. Uh no, not yet. So currently amongst test nets, we support uh Solia Ethereum Sapoleia test net and uh our own test net because it also can serve as an origin and destination chain. So we support a bunch of mainets. I'll show the list and obviously we will support uh test nets for them in the future. And do you have a plans for Chiato since we are here on this? Oh, on on

Depcon that's not for the Nosis. Yeah. No, not yet. But I think that's a good thing to discuss. So you can reach out to me or uh to Emmelius here from our ecosystem team. And one additional to the test nets, uh there is also a need when when you build like a larger solution to have a private test nets for instance from builder or from tenderly. Do you have any discussions with those teams that um that will be supported those privatess which are basically forks? No, not yet. But that's a good idea.

Thank you. Okay. Yeah, thank you for the question and please feel free to ask questions anytime because our main goal here is to form an understanding rather than just go through the materials I mean slides and code that I've prepared for you. Uh yes. Yeah. So what we're going to discuss today is um general concepts what reactive smart contracts do uh how they how they operate uh use cases potential uh uh which might be used in the future and existing which uh already uh work um namely we will discuss uh onestep swap a stop order um we will probably deploy a stop order example if we have enough time uh then we'll

discuss one of the few uh complex uh a bit complex technical concepts that we have which is dual state of reactive smart contracts because generally reactive smart contracts are um solidity smart contracts on an EVM uh virtual machine which makes it pretty easy for all of us to understand. Uh so yeah there is very few uh complex concepts and one of them is this dual state. uh also we will deploy some of the existing examples and if we uh have time we will uh build our own reactive workflows that's um I don't think we will be able to finalize that within uh our time

frame but we can start and we can have questions and discuss just to form a better understanding between us okay so um I've already shared a bit about that but uh let me reiterate because that's basically the main concept So uh reactive smart contracts uh they allow reacting to onchain events with onchain actions. As I have said it's an onchain if this and that. Uh so uh we listen to events we uh process them in the solidity smart contract and then we send a call back to the destination chain where we want to have the actual reaction and that's that's basically it.

So uh this enables three main things. So first of all it's automation. Uh you can do actions within one chain reacting to some other actions. Uh a simple example for this and some other things will be a um uh stop-loss order right where you wait for the price to reach a certain predefined threshold and then you execute the order. So um that's an automation. Also since uh we're listening to a chain and then we're sending a transaction to a chain this might be uh the same or a different chain which leads us to the second point which is crosschain functionality. So we can do a bunch of uh crosschain stuff.

For instance, um for our token, we have built a bridge where you can bridge token from Ethereum to reactive network uh back and forth. And uh this bridge is built on our technology. So in case you want to build a bridge, you can utilize reactive network as well. Uh and then uh last but not least, it enables modularity as well. So you uh might um know such uh products as GMPS um hyperlane, XLR, layer zero, other solutions. And you might even um have a question why would we need reactive if

we have those? Right? So the main reason we need reactive uh even if we have those is that we can react to arbitrary events. We don't need to actively send messages from the initial the origin smart contract. We can listen to an arbitrary smart contract which um gives us uh two good things. So first of all we can listen to a third party smart contract for instance a unis swap pool a chain link oracle other stuff which we have no control over right and then also we can listen to our own smart contracts that have already been deployed and uh let's say we don't want to update modify them we have already deployed them

they're already there on the mainet we don't need to modify them we can listen to an events that they already uh have to use those events to trigger some other actions on the new smart contracts. All of that in a decentralized manner. Uh any questions so far? Please go ahead, who is paying the gas? Yeah, that's a good question. Uh so basically this is a uh B2B or a B2D solution, right? So uh you probably will be building something for your uh B2C users and probably you will be paying for the gas. How exactly?

I will touch upon that a bit later and as a matter of fact even with I will show the code how it is paid. Uh but yeah basically uh let's say you want to listen to some events on oh that's exactly what I'm having here on picture. um you're listening to some events on Ethereum network, right? Then you want to react to them uh in a reactive smart contract and then you have a call back to the polygon, right? So uh in that case we won't need to pay for anything on Ethereum because we just passively listening there. Um uh reactive smart contracts uh they are powered by React token which is basically a gas token the

same as Ethereum and other ones. So you will need to have some react balance on your reactive smart contract for it to listen and send callbacks, right? And then uh since we're sending callbacks to a destination chain uh running transactions on the destination chain, we will also need a gas token there. uh you will also need to put it to your I will explain later what it is a callback smart contract but basically a proxy smart contract and it will be charged automatically by uh the entities that trigger the smart contract but yeah the short answer is u the B2B user pays

for the gas actually originated the transaction. Uh um you asked whether it's the one who originated the transaction. No. Uh so the origin transaction on Ethereum network in this example it can be uh triggered by anyone uh even someone who has no idea about reactive smart contracts and its price it doesn't change uh because of the fact that we're listening to this event. So this person is not paying for anything, right? The uh entity who has built the reactive workflow pays for the stuff.

Yeah, thank you. That's a very good question. Uh yeah, so and that was a perfect question for me to narrate this picture. So we can go to the next Yeah. solution and you need to have some sort of network or something like that. Um um regarding um so so it's regarding those gas fees that means that uh whoever originated there is paying for his transaction as he's used to such like doing the swap and then the let's say I want to react on something that I received or something happened then I am basically paying for my whatever I need

to do like rebalancing treasury or something like that is correct uh yeah but I build that reactive part basically and and the rest and I'm paying for that or my users right uh yeah so um the one who builds the system so the uh builder decides who pays either it's him from his treasury or uh you can somehow implement the system to charge the users for instance even to charge them on a different chain potentially um does this answer your question yeah yeah yeah that answers that uh the second question is the step number one it means the reaction. What is the time span like what is the time re what is the timing of the reaction? You know

when do you actually initiate that that react function in the reactive network? Yeah. Uh so the block time for reactive network is uh 7 seconds right and uh if we have an event on an origin chain beat it uh ethereum or some faster chains uh then it uh in most cases I mean unless uh the block is in 0.3 seconds it will get to the next block. So it will get to reactive network within uh 7 seconds on average and then uh it will get to the next block of the callback transaction will get to the next block uh of the

destination chain if it's a slower chain such as Ethereum and maybe a bit later but I don't have the exact numbers if it's one of the faster chains but yeah uh I would say you can um uh expect the uh resulting transaction to happen within 10 seconds um after the or origin transaction origin event. Mhm. How do you work there with the uncles and basically you know the forking and so on? Yeah. Comment please. H how do you work with the with the uncles? So when you have like you know that particular block and the one is thrown away as h you mean with forks right? Yeah. Yeah.

Yeah. Uh so um since we want to uh react as fast as we can, we uh process this whole thing after zero confirmations. I mean after after the zeroth confirmation, as soon as uh the transaction with the event of interest gets to the block, we react, right? But then if you're um uh like if your setup is sensible to uh the reorgs, right? You can take that into account on a smart contract level. You can uh implement uh waiting for a few blocks. You can wait for some other event. So you can handle it on the application level so to say.

So basically in that react part you can like wait for a few more blocks. Yeah. Yeah. Yeah. So the in reactive smart contract like u we have uh our lead dev pavl here who has built our bridge. So he might share some more um details about the bridge later. But uh in my understanding if you wanted to build something like that uh uh I mean not not not the bridge exactly but if you were worried about the reorgs the simplest thing you could do is uh yeah wait for some. So uh we have some event on Ethereum here on this picture right but we also have uh internally chron events on the system smart contract on reactive

network. So we can wait just for some time to make sure all the rearchs have already happened and then you can process the resulting event. Thank you. Okay. Already uh digging to the bottom of my knowledge but so far I'm holding up. Thank you. Thank you. It's it's uh very pleasant to have an interactive session rather than just talking. Okay. So, uh here I have a list of examples uh which we uh have in mind that's not the full list. Uh but yeah, let me name some of them. So, first of all, there's a one-step swap. I will um

show some schemes about that on the next slides. Uh generally you know that uh whenever you swap on a DEX I believe they uh changed it on a unis swap before and on some other newer exchanges. So this this is one of the old examples but I still like it because it kind of illustrates stuff. As a matter of fact, our team likes it uh very much but nobody outside of the team does not for some reason. I don't know why. Uh okay. So um you need to approve funds first, right? And then you only after that you need to swap and that applies not only to the swap but basically to most of the D5 actions right. So with reactive network you would uh approve and then the swap would happen automatically. I

will show how exactly. So, uh the next uh example uh that is uh pretty cool and still simple is a stop order or or or stop-loss order, right? Where you wait for the price on a DEX to reach a certain threshold and then you execute the trade, right? I believe they have this functionality on some some of the dexes already. Uh and obviously they have this functionality on all of the centralized exchanges, right? But with uh reactive smart contracts, you can implement this thing on top of any existing decks and you can listen let's say to one pool and trade on some other pool. You can listen to for instance uh

the exchange rate of token A and uh let's say you have an idea that it kind of correlated to the uh price of the token B and you can sell token B based on the token A price. So you can do all of those combinations since it's uh solidity smart contracts. You can define whatever conditions you need. So the next example is bridge. Uh pretty selfexplanatory. You can just build a bridge on uh our technology. Uh the next one is crosschain landing. So I believe we had such an example on one of our uh hackathons. Yes, we did. So I might even be able to show some of the uh proof of concept code. Uh so I'm I'm saying uh

that the person has a person has built it on a hackathon. Um meaning that it's pretty simple to build on reactive since it's solidity. There are a few tweaks that we try to explain as u well as we can on the docs but yeah um our experience shows that um mostly developers uh don't struggle with building on us. Uh so yeah crosschain lending where you provide collateral on one chain and um get the loan on a different chain. So then you uh return the loan on a different chain and get back your collateral on uh the first chain. uh also a crosschain oracle where you can listen to oracle updates and uh

kind of copycat them on a different chain. Um I don't think uh all of the oracles provide updates in terms of events but when they do you can listen to those events and you can copy this data to the chain of interest. So, let's say you're you're uh launching a new chain or or you're building a new new chain and you don't have chain link there yet because they're pretty expensive. So, in that case, you can listen to events on one chain and have the same data on the chain of interest. Uh yeah, and the other example is liquidation protection. So you can monitor a um position and then whenever the uh threshold is about to be reached

you can either for instance add collateral or uh or you can uh sell some of the some of the funds. Okay. Uh any questions so far? Okay. So this slide I'm going to yeah so uh basically there's this concept um it might be uh it might explain a bit more we call it inversion of control so in the usual workflow uh the transactions are assigned by uh a user it might be a user or a bot but it's an EOA address right and that's the

only way the transaction is initiated on uh EVM Right. But with reactive network uh transactions can be initiated based on events. So in that terms that's an inversion of control where control goes from from the uh other smart contract that you're monitoring. Okay. So this is a simplified scheme of a unis swap stop order. So we're starting to dive a bit into more technical stuff here. And uh in uh some cases this one included I will share code examples later and in terms you're familiar with solidity it will become even more clear

but generally here's what happens. So uh you approve funds for uh a unis swap pool then whenever a sync event happens uh it triggers a reaction on the reactive smart contract. So a reaction reactive smart contract checks whether the uh price threshold has been reached and if it has then it emits a callback. So basically this line here emit callback uh it's a usual event in terms of usual solidity. It's a keyword in terms of reactive smart contract. So whenever you see emit callback, this is probably the most important part of the reactive smart

contract where it actually uh sends a transaction on the destination chain. In that case, it swaps funds uh on a unis swap pool. But this is a simplified scheme. We will have a more uh strict one later, right? Uh so yeah uh this is um a scheme not for a reactive workflow but for a traditional workflow. So you can see number one here right uh this is the first transaction executed by the user by an ewaya address here and you can see the second transaction here. So the first one is swap um sorry the first one

is approve and then the uh second one is swap. So um as I have already mentioned the user needs to execute two transactions in in other words they need to go to their wallet and sign several transactions click several times right so this looks much more complicated but for a user it's much simpler because a user as you can see so this is the user this is our AOA they only send one transaction and all the other stuff it happens automatically. Right?

So, um let's talk about the entities we have here because this is important for uh us to work with the code later. So um what we have here first of all it's a uh token contract right which you are obviously familiar with two token contracts as a matter of fact because we are talking about swapping token A4 token B right and then uh it's also a DEX pool smart contract which you're also familiar with and then these two are the new entities which I'm going to explain. So this is a reactive smart contract and this is a callback smart contract or you can you can look at it as a proxy smart contract but I will be

uh using term callback smart contract uh from now on right so um here is what happens a user approves funds so a user calls a a approve function of a token a smart contract and uh this approval it's not approval for a dex pool address It's an approval for our callback smart contract address. So the callback smart contract it was deployed by us same as reactive smart contract and token A, token B and uh dex pool smart contract they were deployed by someone else. Uh so uh a user approves funds for the callback smart contract to spend. Then uh reactive smart contract sees this

approval event right and understands checks that this is approval to smart contract. some other conditions probably and then uh executes a call back where callback uh generally it's a swap but it's executed through uh this callback smart contract right so it emits callback in that case it means that it calls the callback function of the callback smart contract sorry for saying callback too many times um basically you can name this function whatever you want you can have different functions and stuff. So this is just the naming issue on this picture and so uh it calls this function here

and within this function uh some stuff happens. So first of all token A gets transferred from the user to callback smart contract right uh then after that token A on callback smart contract is swapped for token B on callback smart contract. So now uh callback smart contract has token B because it has swapped it here on a DEX pool and now it has it and then it transfers its newly obtained token B to the user.

So uh here you can see all the all the uh function calls colored um and uh to summarize this thing what uh has happened from a user standpoint right the user has approved funds to be spent by a callback smart contract and then uh the magic happens and the user gets token B. So uh generally uh uh like obviously since a user was uh approving funds for this particular smart contract in this particular amount their intention was to swap this amount of token A for token B.

But all they do on their end uh in a wallet they just uh approve funds and all the other transactions I mean just the second swap transaction it's executed by the reactive smart contract. I hope that was not overwhelming. Uh do you have any questions, guys? Okay. Um as a matter of fact, we're not going to have uh today much more complicated stuff. So, if you understood this thing, you will understand the rest as well. If you haven't, please feel free to ask questions uh now or later uh in person or in the chat as well.

Okay. So before we proceed to the uh actual coding, I wanted to share uh some more of uh real life examples. So this uh the stuff that I've described so far it's uh more like code examples and uh things for people to use. And the stuff I have here on this slide, it's uh the applications that are already uh that already exist, right? So two of them are already live. They're flexal loan and reactor. So flexal loan is a pretty curious thing. Uh it's a flesh loan where a lender does not need to lock the

funds in a pool. A lender only needs to approve the funds to be flesh loaned. Right? And uh after that whenever a borrower comes and does a flesh loan only within this transaction the funds leave the wallet of the lender go somewhere else are traded and then go back right. So uh what it brings to the lender is uh you can actually approve funds for several uh pools to be uh used in. So uh you can reuse your liquidity for several different pools which uh I believe might be uh beneficial right and uh the other

thing we have is reactor. I might even have a chance uh to show it a bit later. So uh reactor is basically an application to bring our B2D uh B2D solutions to B2C users. So as a matter of fact with reactor you can deploy uh a stop order workflow without the need to write any uh any smart contract code or to deal with it. You just need to enter the parameters like token A, token B, price threshold um and that's it more or less some something else probably. And uh after that you sign a bunch of transactions and you sit and wait for

this to be executed. So you can for instance you can uh secure your funds like that uh on on some of the taxes. So the example that I've shared it can be used without coding. You can look at it as a simplified remix probably but even simpler but um yeah also it has some other automations uh in development and uh currently we are working with uh some other projects which is smart trust um who are building payment um and reputation system for dealing with contractors right Uh it's a DEX trade.

Uh they're using us for guestless transactions after crosschain swaps, right? QSTNs who automate rewards for uh service completion and uh quick swap uh they automate their um fee collection. So they have a bunch of uh a bunch of uh they participate in a bunch of pools in on a bunch of different chains and uh they can collect uh fees automatically. Um before that they needed to do a lot of manual steps and also these were manual steps by uh a seale person because it's a sea level person holding the private keys right

and uh with this workflow this part of this thing is automated and they save time on that. So that's that I would say that's a pretty straightforward use case but it it saves time so it's also good. Okay, any questions so far? Yeah, in that case I will probably skip this complicated part for now and yeah, please go ahead. Yeah. Yeah, please wait for the microphone. Yeah.

In the examples you mentioned oracles basically react on you know the new state provided by the oracles. I understand that this is mostly thought for the push oracles like the chaming is. Um is there a way to also work with the pull oracles like uh uh parrots for instance bits I guess any others? Um yeah so I don't know how exactly they work but the answer will be if they emit events then it's possible if they don't then um pull pull oracles uh work in the way that um you provide the data of of

the oracle from their offchain systems uh as the core data within the transaction and basically there is some verification contract on chain that uh verifies that uh that the origin of the data is is basically valid. Mhm. But within this transaction, no events are emitted, right? No. Okay. No, in that case, we won't be able to because like we um events are the core thing in in our text here. So the the other question that we get uh is can we react to native token transfers and uh the answer is also no for now because they don't yeah don't don't emit events either but

obviously we can react to wrapped tokens transfers and uh since uh everything here is actually based on emitted events um I assume that you are involved in that discussion on your magicians regarding um the potential future uh of the events and potentially that dismantling of the events. I don't know if you heard about that or read about that. Yeah, me personally not yet. Uh I think our dev team works on that. We can ask um team members later but not me personally I don't know about that.

I mean about how we're going to take that into account. Okay. So, uh some more complicated concepts here and uh we will discuss them after we do a bit of coding. And now I will go and code sharing my screen hoping I won't um share any private keys. Okay. So um do we have people here who are planning to deploy code examples? Could you please raise your hands if you are planning to do that?

Yeah. Do you want to participate in live coding so to say? Yeah. Okay. So uh let me take a look at the chat. Right. Okay. Okay. So um to uh deploy those code examples, you will need um React tokens. Uh Pavl, do you think you could help with sending some mainet react to uh I have please share your address. I will share with you and I will ask you to share it with the people who will be

sharing the addresses. uh please share it on the on the reactive workshop at Devcon chat because I won't be opening any other windows to not expose any um information. Yeah. Uh so uh in case uh you guys want to participate in live coding, please share your test or developer addresses uh probably in the chat. Um, I understand that this is might be a privacy violation. Sorry about that. Uh, but jumping between several windows uh will be hard and and you can just take your time and create an empty wallet and

share an empty address. So yeah. Um yeah. So first of all, let me share some of the um React with Pavl and Pav will be sharing it with you. So uh as you can see it's a usual EVM chain. So I'm using uh foundry here and uh foundry commands. So uh this is the address that will be distributing react and I will share half of everything I have with pavl.

Okay. Yeah. Some Now Pavl has some React. So PL will share it with you and you will be able to deploy some stuff on reactive network. So also uh 10 would be uh too much because I've shared 50 with you. Uh yeah uh please raise your hands if you want to develop.

In that case we will have an understanding of how many people will use react. One two three. Okay, we have three live coders here. So, I think 10 10 is okay. Thank you. Okay, now let's take a look at the list of the chains because we will be using those chains for for our demonstration purposes, right? So, uh let me share this link with you.

You can take a look at the website later because now we're have a discussion right docs as well. So uh here is the list of the chains that we support for the mainet right uh currently it's ethereum mainet binance smart chain avalanche cchain base chain sonic mainet and reactive mainet so reactive can interact with itself right um in my case I will be using base chain so I have some uh base guest token sorry I don't have enough to share with everyone so I believe you do have some mainet tokens uh on one of those chains

uh in case you don't you can just uh do all the stuff on reactive mainet so I will be mentioning origin chains reactive chain and destination chain in if you decide to go for this option it all will be reactive manet in my case origin and destination chain will be base chain and reactive is reactive right okay so Let's go to the code. Uh, now you will need to clone a repository here.

So, let's go back to reactive.network. We have GitHub and on GitHub we have re the first one which is reactive smart contract demos. We will be using this repository today and I will share the link in the chat right uh please clone this repository meanwhile I will tell you what's happening there so uh this is this repository right the um sources for demos are in this src demo demos folders and we also have um lib folder here which contains uh

some of the third party stuff such as open zeppelin but uh mainly uh the main thing here is reactive lib we'll take a look at it a bit later right yeah wrong folder this one and this one okay And uh let's let's start taking a look at the actual examples uh that we will be deploying. So first of all let's go to the uh core readme.

We have a core uh readme in a core folder and we have uh readme in for every particular example in core folder. It basically just says how to set up uh the environment right uh how to set up founder here. uh basically just run those commands. Please install Foundry if you don't have it. We will have some time to do that. Currently, I'm just explaining in a few minutes I will be uh running the code. So, uh you will have the time to do that. Okay. And let's go to the basic example. So, the basic example, it doesn't really do anything meaningful. However, it uh demonstrates

the concept in the simplest way possible. So, it has uh the readme here. So, you can go over those uh details uh in written form as well. But uh let me just uh describe it to you um in words and let me share the contracts with you. So you might remember this simple scheme here the first one and uh keep it in mind we have an origin smart contract react smart contract and destination smart contract now the origin smart contract is uh this one right it's basic uh demo L1 contract and

uh all is uh all that's happening here is we have a received event uh that uh has origin center and value and we have uh receive uh payable function uh which emits this event. So the origin is transaction origin the center is me send and value is value and it just returns what we pay to the contract back to the user. So the way we are supposed to interact with this contract is we just send some gas token there uh base in our case in my case and um it gives it back and emits a received

event. So that's obviously an artificial thing. Now uh we also have a reactive contract and a destination and a destination contract or callback contract. So I I will uh show the callback contract first because it's also super simple and after that we'll describe discuss the reactive contract. So the callback contract uh it also has an event uh for us to take a look and debug. It has a constructor and it has a uh function callback which will be called by a reactive smart contract.

Uh so this function basically it just emits uh callback received event for us to take a look at it on uh base scan. So uh it just has one one function that's called callback and it also has some modificators here which we might discuss a bit later but basically this is for authorization purposes and we have this this reactive smart contract here so it's a bit bigger right but not much bigger and significant part of that is a boilerplate code so in case you want uh

did build something new, you most probably will need only to change significantly the react function. But all the other stuff it's it's uh standard, right? So um it is it is inherited from abstract reactive contract. We will take a look at that a bit later. But generally uh from the builder standpoint, we inherit it from from here and use it. And uh this thing here is mainly used for the purpose that we've discussed earlier which is to pay for those callbacks. Right?

Okay. Uh so in constructor we have um this service address which is a system smart contract which we will copy paste from our docs. Origin chain ID where origin is the chain we listen to. Destination chain ID which is the chain we uh send transactions to. uh contract that we are uh listening to on the origin chain. Topic zero of the event uh which is basically a signature of the event that we are listening to and then a callback uh contract address to which we're sending the transactions.

Right? Uh then uh what's uh happening here is basically uh all the stuff just gets initiated and the important part is this where we subscribe to subscribe to uh those events. So we have uh a system smart contract which processes all the events and for our reactive smart contract to know about them we need to let the system smart contract know which particular events on which particular contract we are interested in right so uh in that case we're saying that we want to subscribe

to an event on origin chain uh base chain on this contract address with this topic zero. Pretty straightforward. So this is everything that happens in constructor. We are subscribing to an event of interest. In our case, let me remind you that this is this event received, right? And so topic zero, yeah, it will be specified when deploying. And uh this is the most interesting part which is a reaction. So function react is also a keyword. You're not supposed generally you can but you're not

supposed to um call this function manually. This function is called whenever an event of interest uh happens. Right? So this is a reaction to the event that we want to react to. And um this is what happens here. Uh so we uh specify the callback that we're sending. In our case, we are calling uh function named callback. Uh and and basically that's it. Also we passing zero address here. I might talk about that a bit later. And then we emit in the callback.

So as I have said earlier the uh callback event is a keyword in uh reactive smart contracts. It means that we are sending transaction that we're interacting with the uh destination smart contract. Um at this point I remembered that I forgot about the uh name of this very workshop. So let me uh say a few words about that because that is important.

Extending DEP capabilities using reactive smart contracts. So I've um mentioned that we uh enabling automation crosschain functionality and modularity. This is exactly how we are going to extend DEP capabilities using reactive smart contracts. I just wanted to to clarify this particular thing to uh make sure we're on the same page. And so let me go back to this setup here. Basically, I've uh explained everything about almost everything about the basic example so we can uh uh start deploying it.

This will be a hard part for me because I might mess up some of the numbers and copy paste but uh yeah I will go together with you through this process to make sure you can make this thing work as well. So um I would say our uh code examples uh and um readmies are pretty well written. So if you just follow this workshop uh this this uh readme without my explanation you will get the same result but yeah let us go through this together. So uh first of all we are running some commands here.

Uh you don't need to specify all this stuff in advance cuz I will be waiting for you while we running commands. But anyway, we will need some uh parameters in uh environment variables. Obviously, you can uh just copy paste them. Instead of using environment variables, you can just uh copy paste the numbers themselves. Um but uh it increases the probability of copy pasting something uh mistakenly.

And uh also uh we are using foundry here and all the readme is there for foundry but this also works with ramics and uh I believe since recently it also works with hard hat. So whatever uh tool you prefer you can use it. Uh do you have a question? Um regarding the destination chain I can see that you have like uh coded a constant of the gas limit right uh in the example it's fine uh but what about the gas price of the destination chains how this is handled at the you know u the fluctuation of of the gas price and and potentially like setting up the

the proper prices. Yeah. Uh so this is a good question. Uh as a matter of fact there's two ways to send those callbacks and you can choose between them uh in reactive smart contract. So we have our own setup which works for all the chains listed uh in the docs and we have uh integration with hyperlane where you can send uh callbacks to all the chains supported by hyperlane. So in case you using hyperlane the uh this uh gas spikes problem it's handled by hyperlane. So that's part of the answer.

But in case uh you're using um our um own validators we call them validators because they are in terms of proof stake. Um in in that case uh it's handled on our end. Uh obviously we try to take those spikes into account to estimate how much the transaction will uh cost and not to pay too much or too little and I understand that this is not a very good answer. I'm not really uh ready to dive deeper into that. Ple do you think uh you could say something additional on top of that about the gas

prices? Uh ultimately once again we're trying to build a general solution that allows you to do what you want. So if you want to take gas prices into account, you set up a gas price oracle, you factor this into your decision making in the reactive smart contract. You decide what to do and then you ask us to make a call back and we deliver it. That's it. Basically you decide whether you want to somehow factor the gas price into that. We focus on delivery.

Um honestly in this in this case I would consider it the that the best solution will be that that will become the part of the context that you provide and we are working on that but that's essentially a work in progress and uh once again a fundamental idea is to build a general platform that you can build whatever you want on top of. So that's the approach and yes once again we're working on our own apps. We are working on our own contracts that will provide this environment that will allow you to have stuff like that out of the box. It's just not quite there yet. Once again work in progress.

Yeah. Thank you. Thank you for the question. Thank you for the help. I'm sorry. So the stuff we will need here is uh origin RPC. So as I have said we're using uh the terms origin and destination here. So you might have uh probably already chosen the chain you'll be working with. In my case both origin and destination is um base and I have already set up those environment variables to base parameters. I hope I've done it correctly. Uh so this is the RPC obviously to interact with the chain uh the chain ID for uh re reactive smart

contract to know which chain to interact with and uh the private key that uh you will be using for uh sending a transaction because in this particular example we will be uh manually triggering this reaction. Uh yeah, so we will be triggering this reaction. So we will need a private key on an origin chain uh as well. So uh destination RPC destination chain ID destination private key uh to deploy the destination smart contract basically uh the not the destination smart contract the the the

callback smart contract and which is the same thing. Yeah. and um reactive RPC uh to interact with reactive network to deploy the reactive smart contract. Reactive private key to deploy the reactive smart contract. System contract address uh is derived from from here. Um it is the address of our system smart contract which uh can be seen in its name. Right? So uh to get it uh we can go here or we can go to origins and destinations right. So here it explicitly says reactive mainet and cop

test net use the same system smart contract address. Um so yeah this is the value that we need and then uh destination callback proxy address can be also derived from this link here. Yeah, you can see these addresses here in this thing. This is uh the addresses that will be sending our uh callback signing our transactions.

No, not signing the transactions uh because this is a smart contract. But anyway, this is the address that we need. Okay, so this is the uh values that we will be using. And now let's uh try to actually run this workshop workflow here. So the first thing we need to do is we need to um we need to I don't think I have the right file here. Sorry, give me just one moment. I messed something up while preparing. But yeah uh the first thing we will need to do is we'll need to deploy the

uh origin smart contract uh which will be emitting the events of uh interest right then um let me go back here yeah now it's correct so um let's deploy it using this command here so for this command to work we will need origin RPC which is base RPC in my case and origin private key which I won't tell you. Uh okay. Okay.

Yeah, I think I've prepared everything correctly. Also uh like if you're working with Windows uh same as I do uh you will obviously need to restart the terminal uh every time after you update environment variables which will be quite a bunch of time in this workflow. Unfortunately, if you're using Linux, this won't be a problem. Okay, so let's deploy our uh basic demo L1 contract here. Uh I believe it's um base chain. So we can go to base scan.

Okay. Yeah. And we can take a look at this contract here to make sure it was successfully deployed. Yeah. Hope I'm muted. No, I'm not. One, two. One, two. Yeah, now I am. I'm sorry. Anyway.

Oh, I wasn't muted. Okay. Okay. Okay. So we can see this contract here and we can proceed to the next step. But meanwhile we need to take this thing here uh the deployed to address and we need to save it in our environment variables. So it it says here exactly where to save it. We need to save it as origin address. Okay. Let's go here. Let's hide some of our private keys. Too late. Okay.

Anyway, it's only a test one. I hope so. Okay. So, origin RPC here, right? And origin address. Yeah. So, this is where we need to put it. This is the address of the contract that we will be monitoring. Uh so uh I believe we have two people who are trying to follow the work workflow here right?

Um are you guys here? Please uh if if you're following the workflow, please raise your hand so that I can make sure that you Okay. Yeah. Thank you very much. Uh did you have enough time to do that? Okay. Uh, please let me know if you need a pause because I understand that listening and uh, running the workflow at the same time is kind of hard. Uh, since you volunteered to try this, I appreciate that a lot and I'm eager to wait for you to manage to do that.

Yes. Yes, you can. Yeah. Uh, do you want me to share the address in the chat? Yeah. Okay. Okay. So uh yeah, please let me know if you need more time cuz uh yeah, it's it's cool if you manage to um deploy and try this work. Okay, so the first step is done. We've deployed the origin smart contract and we've saved uh its it's uh its origin address here. Let me double

check. Origin address starts with 83. Amazing. Yeah. And now let's do the second step which is to deploy the callback smart contract. The uh smart contract to which we want to send the callback. So uh in terms of stop order example this would be the contract that would be swapping on a DEX right but here it's just an an a dummy one right okay destination callback proxy address.

Let me also make sure together with you that I have the correct destination callback proxy address because I'm not sure that I had the time to update it. Right? So I'm working with base chain here. It starts with 0D3. Right? And this is destination callback. Okay. I'm I'm I've already exposed my private keys but I don't have any significant spawns there. Um okay destination uh 0 D3 correct and let us let us run this command as well.

Um insufficient funds for gas. H let me check. I want to go to base mainet. This is weird. I seem to have quite a bunch of funds here. Let me see. Uh, destination RPC, destination private key. Destination RPC should be base. It is destination key. the same.

Okay. And what about origin? Yeah. Yep. Yeah. Let us understand what I did incorrectly here. Yeah, let us see my address on base scan.

Okay, I do have some base E here. I might be sending too much. Yeah, yeah, yeah. I'm So, this example was created for Solia. So, we need to put some more zeros here. Definitely. Yeah. So, we need to alter the reactive smart contract, right?

Yeah. We haven't deployed it yet. So it will be the first and also this is uh so this is the funds that we are giving to the callback smart contract to pay for the callbacks. So yeah but we yeah thank you. We need to take that into account as well. So uh I put three zeros there. Will I be good after that? I should be. Yeah. Yeah. Please make sure to not give too much ether as well.

Okay. Yeah. Okay. Now we have the destination contract and let us uh sorry let us copy paste this thing to where to call back address as it states here. Um environment variables callback address.

Okay. Okay. And uh as Pavl has said, we will need to put a bit more zeros to our reactive contract. So for us to check that reactive contracts operates correctly, we have this uh additional condition here. We're only reacting when we've sent more than uh 0.01 ether. So let us put this threshold a bit lower right by adding two zeros and save. Now uh this is exactly what we need and we

will be doing step three uh reactive smart contract uh deploying reactive smart contract and this is my personal uh favorite uh mistake which I do a lot. I uh deployed without uh exiting and reopening my IDE because in Windows as I have said environment variables are only added to the context after you reload the terminal. Okay, now we should be good.

Mhm. Okay. And let us deploy our reactive spot contract. Yeah, in that case we're dealing with reactive network and uh us sending 0.01 ether is okay because the previous uh numbers they were for base and those numbers they are for reactive network. Uh, okay. So, uh, reactive RPC, reactive private key,

system contract address, origin chain ID, destination chain ID, origin address, callbook address. I think we're good. Now is the moment of truth and the fourth step. So, we have deployed the three of the contracts of interest. Now, what we're going to do is we're going to trigger the first one manually. Then the reactive smart contract is going to monitor the first origin smart contract see the received event and trigger the reaction thus uh sending a transaction to the destination smart contract. And also since we're dealing with base here I'm adding more zeros and please do the same unless you want

to send and get back a few hundred bucks. Yeah. Also like um as I have showed here, it sends it just receives the money and sends it back. So it won't be a big problem unless you only have 50 bucks on your testing account like I do. Okay, so it says origin address which is correct. Origin RPC origin private key value ether. Looks good. Okay. Now uh let us go to the origin smart contract first.

This one right. Let us see its address here on the base scan. Okay. It has one transaction here. the one I've just uh initiated uh some transfer from here to here and then as you can see it goes back to my own address which is not important right now but which is important we have a received event here the one that we are monitoring and as you can see this topic zero here of this event it is the same one that we used in our command here right

yep So this is the topic zero of our interest um which is the received event which we pass as a parameter to the constructor of reactive smart contract um as a topic zero and uh okay this event is emitted. Uh the question is uh did it um invoke a reaction by reactive smart contract? to know that. Let's take a look at the uh destination contract. Right now, I'm praying. I'm pretty confident in our tech, not so much in myself.

Uh is it the right one? I here. Yeah. Destination. No, no, no. That's not the right one. That's my address. Sorry. Okay. So, uh since uh the transactions are sent uh not directly to this address but through a proxy contract the address of which we have inputed earlier. Uh this stuff here goes to internal transactions and um you can see it here.

uh the transaction. Let's take a look at the logs whitelist contract. And I believe this is the received event, right? Uh yeah, let's take a look at those parameters here. Um 67F, is it the one I'm looking at? Yeah, exactly. So this address here, the third parameter is my address, the address of my wallet. And let's take a look at the code what it actually means, right? The uh callback.

Yeah, the reactive sender. So as you can see, uh we have uh successfully monitored the origin chain contract. Then we've uh reacted to this to it with a reactive smart contract. And you can see the callback on a destination smart contract. Uh we've spent a bunch of time on that but I hope this demonstrates the super basic core functionality of what we do which is uh on this slide. And now I will probably make a small pause for uh you to ask some questions and uh especially for the guys who are working uh on laptops to make sure that

it works for you. Um any questions guys? Uh okay thank you. So I'm wondering like um for error handling like let's say one of the transactions doesn't trigger or there's any kind of error or like with fees how is it possible to detect or there is like maybe a timeout on the call back to kind of know if the if maybe the event is never like um you know c or like it never happened is there kind of like an error handling part. Mhm. So uh the error handling part most probably it will be on the uh application level so

to say. So um since it's solidity we can do arbitrary checks there. Uh also on top of that we have a system smart contract that emits system events such as chrome events. So you can wait for some time and check some conditions after that. Right? Uh I don't know whether you've heard my answer about reorgs earlier, right? But that in particular that can be used to handle reorgs. So um it depends obviously on what particular type of errors we're talking about here, right?

So uh it might be I think mostly it should be reors, right? What what other errors do you keep in mind because Yeah. Yeah. Uh Pavl, could you maybe share a bit more about what kind of errors we um uh handle in our bridge or how do we handle reorgs in our bridge? uh I don't really have much to add to what I already said because uh yeah once again the idea is that uh the error handling happens at the application level. So it's uh essentially up to the

developers to ensure that they have the error processing they want and yes it's something of now to do that and uh basically our react bridge is all about you know handling and ensuring consistency. So, so it's it's a hard task as usual and once again uh as with the problem of fluctuating gas prices, we are, you know, planning to do something to make it easier and prepare some out of the box solutions, but we're not quite there yet. Once again, we're talking about a platform that's very general in essence.

Yeah. And thank you for the question. Oh, uh, okay. So let me as a matter of fact let me show you the transactions on uh react scan as well. So um we're dealing with base network here. So we went to base scan but also we can take a look at the stuff at react scan. Okay. Uh do we have my address here? Yep, we do. So, we have contract deploy here

and we have uh RVM transactions. Okay. So, uh this is this is uh basically my address and we can see all the transactions that I did on react scan. So, uh I think we're mainly interested in in in the last two probably no in the last one because it's just uh me getting in sending react right I got it initially then I send some of the some of it to power then I got more probably and um this is the transaction of interest me deploying the reactive smart contract which you have seen I don't think we have a lot of uh a lot to discuss does here basically yeah

a contract deployment but this only uh this tab here it um RNK reactive network transactions it says about the transactions that I initiated and to see the transactions uh the reactions actually we need to go here right so and this is the transaction of interest where we react to uh origin contract and um with a destination transaction. So you can see all the links here.

So uh here you can see the link to the origin transaction. Here you can see the link to the destination transaction. So whenever you need to debug stuff, you kind of have all the necessary information here. If a callback for some reason fails, you can see it here. If uh an origin transaction doesn't happen then the reactive transaction transaction doesn't happen. So it kind of helps a lot to understand what has happened and uh yep I believe that's it for the basic demo right um and I have we have 24 more minutes probably right and I have several ideas on how we could spend

it the best uh case for me would be to have some interaction with you guys to hear some more questions maybe to uh if you already managed to have some ideas about how this could be applied to your text tack to your application what you're working on that would be like the best and uh if we if you don't have any questions or ideas then I will just uh show more code I will show how the stop uh limit um stop-loss order works uh because uh because it's pretty interesting because this particular example I've shared uh

before it's artificial and the stop-loss it's pretty real. So any any more questions? Okay. Uh yeah as a matter of fact uh I do have a question. So um I'm trying to understand the structure of the audience in in this particular room but also on the conference in general. So, uh, could you please raise your hands if you're working for an infrastructure project? I know you guys are. Come on.

Uh, yeah. Could you please raise your hands if you work for a tax? Okay, sounds good. If you work for a centralized exchange for some other kind of dep and uh other Thank you. And could you could you please tell me guys what what are you working on in in like a few words? I'm working on a community uh page kind of um

where creators can have their own page and yeah I'm pretty new so uh yeah it's like first time or second time seeing smart contracts so I'm just just looking a little bit and yeah yeah thank you as a matter of fact like that's that's not a usual smart contract so we we going like two levels deeper I hope that's not overwhelming little bit point. It's interesting. Yeah. Thank you very much. Uh yeah, and and you sir Yeah, I work for layer one flare. So that's why I was interested like maybe we can connect uh reactive network to there as well. Yeah. Yeah, that that

sounds great because like uh as a matter of fact u dexes and and deps in general, but dexes specifically are probably our favorite types type of clients and um chains are our favorite types of partnerships because like we obviously we're adding new chains. So yeah, that's good to hear. Okay. So, uh in that case, um let me dive a bit deeper into the stop-loss example. Uh and uh yeah, let me know guys if you're still working on deploying your stuff. Please ask questions anytime you have them. Uh and I will dive a bit deeper into the stop uh loss

uh example. So, I probably don't have enough time to deploy it. uh the reactive smart contract there is pretty simple but to work with the stop order we will need to deploy the the the factor first then the pairs so we will need to prepare a more complicated setup in terms of uh the smart contracts that we will be monitoring and interacting with so I don't want to overwhelm you with that but I'd rather show you uh the code without deploying and then maybe share some more cool pictures on the slides Um, okay. So, I need to go here right?

Where? Yeah, unis swap stop order. And we have we have three contracts here. Uh, it is a callback contract, right? which interacts with the with the pool. This is the uh reactive smart contract and this is the token bigger. Yeah. Uh thank you. I will try.

Did it work? I don't need the terminal anymore. So I will Okay, should be better now. Thank you for letting me know. Okay, so um token is a token. Enough said. Uh this is the reactive smart contract. Uh we'll take a look at it uh after the callback smart contract because first let's take a look at what reaction are we going to actually invoke. So um this is uh a callback smart contract. So let's say uh let's talk about it in in

terms of a dex right let's say you already have some pools and you want to add this functionality to u your dex uh in that case you will need to deploy this callback smart contract. Um as a matter of fact you can deploy it completely on top of the existing setup. So you won't need to change anything in the existence contracts. But obviously like if you develop the next iteration of your contracts with reactive functionality in mind, you can enrich it with much more interesting things. But yeah, you have a callback smart contract here. And let's go back to this this

scheme. Where is it? Yeah, here it is. Uh it's this one, the one that uh is approved uh by the user. So the tokens are approved by the user for the callback smart contract to spend. And this is the one that transfers token A from the user to the to itself. Then it swaps the token and then it transfers the tokens back to the user. Right? So it interacts with token A, token B and the pool. And also like obviously uh it's just a scheme and in in the real code it it also change u checks a bunch of conditions

uh right so I don't think we need to uh get over uh to discuss all the stuff here we can discuss just the stop function so this is the function that will be called by the reactive smart contract right so uh what's happening Here it has the pay address, the client address. It has uh the boolean which uh specifies which token is uh to be sold and which one is to be uh bought. It has the coefficient and threshold which define the uh uh threshold at which we uh actually execute the trade. So it al also exists in reactive smart contract but it also

checked here on the callback smart contract and to make sure basically for security reasons and we recommend doing that. So we have uh token zero here, token one here, we have reserves here, we get reserves. Then we um require that uh we have enough reserves in our um no I mean we we check that uh the rate is not above the threshold, right? So we check that the rate uh the threshold has been reached right. Uh then we u check which token is to be sold and which is to be

bought here on these lines right then we um make sure that we have an allowance to spend. uh then we uh uh make sure that we have enough balance to spend right and then we actually transfer right so this is the first thing that was uh listed on the scheme we transfer the token from the client to this callback smart contract then we approve the funds for the uh pool to spend them uh right uh then we uh save some stuff here and then we execute the actual swap

providing all the parameters and then we transfer the tokens back to the client and then we emit the stop event uh to let the reactive smart contract know that the uh order was executed and we don't need to execute it once again. I believe that is pretty pretty pretty clear. That's that's just um a bunch of transfers and swaps, right? And this is us checking the the the threshold has been reached. So this is the callback smart contract. This is what happens on the destination chain. And uh this is the reactive smart contract.

Uh this is what happens on the reactive network, right? Uh so we have a bunch of events here. We don't need to discuss them in detail. Um, we specify the chain ID. We probably should not have it hardcoded here. Yeah, we will need to change it. So, um, this is the topic zero for unis swap sync event. This is the topic zero for our stop event from our callback smart contract. And this is the gas limit. A bunch of variables here. a constructor where we specify all the stuff such as uh threshold, tokens, client address, all

the other stuff. Here we subscribe to uh sync events from which we derive the price. And here we subscribe to stop events uh that stop uh us from doing this uh thing uh the second time, right? And this is the um react function which is triggered when uh a sync event happens every time sync event happens as a matter of fact. And uh you can see a bunch of todos here because it's just a proof of concept. So in real setup it will be a bit more complicated probably.

And uh okay so we're checking the yeah so this is this is as a matter of fact this is the second thing that might happen and uh the first thing that might happen is we might see the sync event. So if we have uh seen the sync event then this branch of if else here is executed. So uh what happens is also we uh get the reserves we check the threshold and we make sure that we were triggered we emit the callback send event which is purely for debugging purposes don't

confuse it with the call back event right then we construct the payload uh which is how we going to call what function with what parameters we're going to call on destination chain in our case it's a stop function and uh we have address zero address here the pair the client the token uh the token the coefficient and threshold. Then we um record the fact that the stop order has already been triggered because like in this particular setup it only works one time. Uh obviously it can work many times as well in a more complicated uh code. uh and we emit the callback which

executes this stop function here and and that's it more or less. The only thing on top of that is that when we see the stop event uh it basically stops working. It says it's done and it submits done event and uh it stops working. That's it. I had some more stuff to share a bit more uh technical details but I don't think it makes sense to discuss them in the last 10 minutes that we have. I'd rather have a discussion with you or if we have no more questions just chill.

Maybe you can explain underneath how the interaction goes from chain to chain. What are you using there? What's the secret source? Not secret source, but like what's the tech? How can we trust, you know? Yeah. Uh thank you. So um I will explain it uh high level uh first of all because uh like I haven't seen I haven't worked with the core code. I'm only working with the application code. uh but also because uh some of that is still work in progress and uh the changes will be applied. So um yeah let me to

simplify my explanations. Let me get this scheme again. So uh you basically there's three parts of the process. Monitoring u an event on an origin chain then uh processing uh smart contract uh reactive smart contract which is an EVM smart contract and then uh sending a callback. So uh the um reactive smart contract part it's an EVM chain with a proof ofstake consensus uh with a bit of a tweak of parallelization.

So um there is a reactive network EVM and there is smaller EVMS for every address that uh deploys a smart contract. for instance my address there is a smaller EVM because they don't need the common state between all of them right so uh the uh EVM that actually receives a reaction and sends a callback it's a smaller EVM uh my own let's say um I believe it has a bunch of patches on top of G obviously because it's not just one big EVM but a big VM and smaller ons as a matter of fact I have a slide for that

as well. Yeah, like this. So there's reactive network uh where uh everything exists the system smart contract and the reactive smart contracts and then uh for every deploy address there's smaller reactive VMs but generally it's uh GU with some additions uh and and proof of stake uh then um also there's an origin part right So uh we are uh subscribed to chain stack and DRPC and we have what we call a sequencer

which uh gets all the information about the blocks and transactions from those two and uh puts them in a sequence because we're listening to different chains not just one chain and we need to have uh like a a how do you call it uh unified numbers for all the blocks. So let's say uh now I have an Ethereum block which goes by number zero. Next I have arbitum blocks which goes one. Another arbitum blocks which goes two polygon blocks block three. Then Ethereum block four and so on. So we have them all numbered throughout. Uh that is what our sequencer does. And

then sequencer gives this stuff to our reactive network to our uh reactive smart contracts uh to make sure uh they process this information correctly, right? Um and then there's this destination uh part. So u our validators they um hold their private keys, right? And then uh with their private keys they interact uh with their eway addresses they interact with the uh callback proxy contract which then interacts with our callback contract right and uh so they

basically send those callbacks to the callback proxy contract which inter interacts with the callback contract that we've just uh seen in our example. So and as I have mentioned earlier uh there's one of two options. This is the first option to use our validators for all the chains that we natively support. But also we have an integration with uh hyperlane where you can send callbacks through hyperlane uh to the chains that hyperlain supports. I believe this is a pretty brief explanation.

uh I don't think it explains uh everything about decentral uh decentralization of each part but it kind of sheds some light. Thank you. Uh P do you think we can shed more light on the how it works under the hood or do you think that's enough? Yeah. All right. Yeah. And I'm saying pretty much the same thing. Once again, it's a work in progress. Uh I'm not a node

hacker as well. I'm more on the contract side, but yeah, I do know perhaps a little bit more about this than I. Uh but in any case, we we are hoping to improve our decentralization as we are progressing through the network phases. We are pretty early in this right now and we're effectively running a proof ofstake authority. Uh so it's a POS but the valid data set is closed and uh pretty much on every level of what Ivan has mentioned so far. Uh we intend to work on improving the centralization.

We're not quite there yet. Uh interestingly stuff like for example our own transport it's pretty much an accident. We didn't really intend to go with our own in-house transport at first. Uh we just needed it for our own internal reasons. We basically needed a means of communication between our VMs and the reactive network proper. Uh where it's pretty safe and secure because validators can check the requests for callbacks and callbacks themselves. But it turns out that despite the fact that it's kind of centralized approach uh callbacks to other networks were kind of uh interesting to people uh who are using

the rective network mostly because it's really fast and relatively cheap compared to other options. So this is like a tradeoff but the general idea with respect to transport is to integrate with everyone we can everyone interested in this and just let people choose uh which transport works best for them and perhaps we're going to be extending our own transport options as well. So yeah there's that. I hope that helps a little round of applause for Ivan. I really enjoyed the presentation my friend.

Thank you guys. Thank you very much. Uh and yeah, I really appreciate uh you coming that early and uh being here with us for the whole presentation because like two hours it was hard for me and I know this stuff and for you it was probably a lot of content. So yeah, I really appreciate that you're still