Extending dApp Capabilities Using Reactive Smart Contracts

Hey guys, thank you very much for coming here today. My name is Ivan Ivanitsky, and I will share some coding, some examples, some concepts of reactive network. So first of all, thank you very much for your interest. I appreciate it a lot because I love sharing the tech stuff. And so before we proceed to discussing the reactive network itself, 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 tech stack, obviously, but that's not the only goal. Also, I would love to share it with anyone, even if you want to 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. Then hear your concerns as well. And obviously, have fun, even though it's pretty early, right? So this is the telegram chat that I've created to assist you and share the link.

So in case you are going to code today, which I hope you are, please join this chat. I will be sharing the links there. Also, we have 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 telling about us.

So Reactive Network, it's an interoperability solution. In simple words, it's an on-chain if-this-and-that. So we listen to events on one EVM chain, then we process them with Solidity Logic. So we are also an EVM chain, and you can describe arbitrary conditions there. And after that, we 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 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 our idea was to enable doing that without centralization. OK, so we will do some examples deployment today, probably live coding in terms of creating new code, but not necessarily.

We will just talk, have some questions, and we might have some time for live coding. But we definitely will deploy some code examples. So in case you want to try them yourself, you will need some of the stuff that you can see on the screen. So first of all, you will need Git to clone the repository with the examples. And the same one will be used in case you decide to build with us.

We will use examples as a starting point, as a boilerplate. Then you will obviously need a text editor, terminal, private key, which you can derive from your wallet. And you will need some React tokens, which we will be sharing in our chat. Not a lot of them. That's not an airdrop, just a few for testing purposes.

And also, you will need the guest token on the destination chain where you want to execute actual transactions. It might be Ethereum. In my case, it will be Base and some other chains. I will share the list later. Yeah, please go ahead.

And please 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 testnets that are related to those production chains? Thank you for the question. No, not yet. Currently, among testnets, we support Cepolya, Ethereum Cepolya testnet, and our own testnet because it also can serve as an origin and destination chain.

So we support a bunch of mainnets. I'll show the list. And obviously, we will support testnets for them in the future. And do you have plans for Chiato? Since we are here on this, on Blipkon, the testnet for the Gnosis.

Yeah, no, not yet. But I think that's a good thing to discuss. So you can reach out to me or to Emilius here from our accessibility team. And one additional to the testnets, there is also a need when you build like a larger solution to have a private testnet, for instance, from BuildBear or from Tenderly. Do you have any discussions with those teams that will be supported, those private testnets, which are basically forks?

No, not yet. But that's a good idea. Thank you. OK, yeah, thank you for the question. And please feel free to ask questions any time 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.

Yes, so what we're going to discuss today is general concepts, what reactive smart contracts do, how they operate, use cases, potential, which might be used in the future and existing, which already work. Namely, we will discuss one-step swap, a stop order. We will probably deploy a stop order example if we have enough time. Then we'll discuss one of the few complex, a bit complex technical concepts that we have, which is dual state of reactive smart contracts. Because generally, reactive smart contracts are solidity smart contracts on an EVM virtual machine, which makes it pretty easy for all of us to understand.

So yeah, there is a very few complex concepts, and one of them is this dual state. Also, we will deploy some of the existing examples. And if we have time, we will build our own creative workflows that I don't think we will be able to finalize that within our time frame. But we can start and we can have questions and discuss just to form a better understanding between us. Okay, so I've already shared a bit about that.

But let me reiterate because that's basically the main concept. So reactive smart contracts, they allow reacting to on-chain events with on-chain actions. As I have said, it's an on-chain if this and that. So we listen to events, we process them in a solidity smart contract, and then we send a callback to the destination chain where we want to have the actual reaction. And that's basically it.

So this enables three main things. So first of all, it's automation. You can do actions within one chain reacting to some other actions. A simple example for this and some other things will be a stop-loss order, right? Where you wait for the price to reach a certain predefined threshold, and then you execute the order.

So that's an automation. Also, since we're listening to a chain and then we're sending a transaction to a chain, this might be the same or a different chain, which leads us to the second point, which is cross-chain functionality. So we can do a bunch of cross-chain stuff. For instance, for our token, we have built a bridge where you can bridge a token from Ethereum to Reactive Network back and forth, and this bridge is built on our technology. So in case you want to build a bridge, you can utilize Reactive Network as well.

And then, last but not least, it enables modularity as well. So you might know such products as GMPs, Hyperlane, XLR, Layer0, other solutions, and you might even have a question, why would we need Reactive if we have those, right? So the main reason we need Reactive, 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 gives us two good things.

First of all, we can listen to a third-party smart contract, for instance, a Uniswap pool, a Chainlink, 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 let's say we don't want to update, modify them. We have already deployed them. They're already there on the mainnet.

We don't need to modify them. We can listen to an event that they already have to use those events to trigger some other actions on the new smart contracts. All of that in a decentralized manner. Any questions so far? Please go ahead.

Who is paying the cost? Yeah, that's a good question. So basically, this is a B2B or a B2D solution, right? So you probably will be building something for your 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 I will show the code, how it is paid. But yeah, basically, let's say you want to listen to some events on... Oh, that's exactly what I'm having here on picture.

You're listening to some events on Ethereum network, right? Then you want to react to them in a ReactiveSmartContract. And then you have a callback to the Polygon, right? So in that case, we won't need to pay for anything on Ethereum because we just passively listen in there. ReactiveSmartContracts, they are powered by REACT token, which is basically a gas token as Ethereum and other ones.

So you will need to have some REACT balance on your ReactiveSmartContract for it to listen and send callbacks, right? And then since we're sending callbacks to a destination chain, running transactions on the destination chain, we will also need a gas token there. You will also need to put it to your... I will explain later what it is. It's a callback smart contract, but basically a proxy smart contract.

And it will be charged automatically by the entities that trigger the smart contract. But yeah, the short answer is the B2B user pays for the gas. So you mean the one who actually originated the transaction? You asked whether it's the one who originated the transaction. No, so the origin transaction on Ethereum network in this example, it can be triggered by anyone, even someone who has no idea about ReactiveSmartContracts and its price, it doesn't change because of the fact that we're listening to this event.

So this person is not paying for anything, right? The entity who has built the Reactive workflow pays for the stuff. Yeah, thank you. That's a very good question. Yeah, so and that was a perfect question for me to narrate this picture.

So we can go to the next... I'm sorry for the other part. This is highly interesting. I'm trying to know whether you're dealing with any larger solution that you need to have some sort of a Reactive network or something like that. Yeah, regarding those gas fees, that means that 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'm basically paying for my whatever I need to do, like rebalancing treasury or something like that. Is this correct? Yeah, I build that Reactive part basically and the rest and I'm paying for that or my users, right? Yeah, so the one who built the system, so the builder decides who pays, either it's him from his treasury or you can somehow implement the system to charge the users, for instance, even to charge them on the different chain potentially. Does this answer your question?

Yeah, that answers that. The second question is, step number one, it means the reaction. What is the time span? Like, what is the timing of the reaction? When do you actually initiate that React function in the Reactive network?

Yeah, so the block time for Reactive network is seven seconds, right? And if we have an event on an origin chain, be it Ethereum or some faster chains, then it, in most cases, I mean, unless the block is in 0.3 seconds, it will get to the next block. So it will get to Reactive network within seven seconds, on average, and then it will get to the next block, the callback transaction will get to the next block 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, I would say you can expect the resulting transaction to happen within 10 seconds after the origin transaction, origin event.

How do you work there with the unclos and basically, you know, the forking and so on? How do you work with the unclos? So when you have, like, you know, that particular block and the one is thrown away? With forks, right? Yeah, yeah.

Yeah. So since we want to React as fast as we can, we process this whole thing after zero confirmations. I mean, after the zeroth confirmation, as soon as the transaction with the event of interest gets to the block, we react, right? But then if your setup is sensible to the reorgs, right, you can take that into account on a smart contract level. You can implement 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 in Reactive smart contract, like, we have our lead dev Pavel here who has built our bridge, so he might share some more details about the bridge later. But in my understanding, if you wanted to build something like that, I mean, not the bridge exactly, but if you were worried about the reorgs, the simplest thing you could do is, yeah, wait for some. So we have some event on Ethereum here on this picture, right?

But we also have internally cron events on the system smart contract, on Reactive network, so we can wait just for some time to make sure all the reorgs have already happened, and then you can process the resulting event. Thank you. Okay, already digging to the bottom of my knowledge, but so far, I'm holding up. Thank you. Thank you.

It's very pleasant to have an interactive session rather than just talking. Okay. So here, I have a list of examples, which we have in mind, but not the full list. But yeah, let me name some of them. So first of all, there's a one-step swap.

I will show some schemes about that on the next slide. Generally, you know that whenever you swap on a DEX, I believe they changed it on a Uniswap before and on some other newer exchanges. So 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 very much, but nobody outside of the team does for some reason. I don't know why.

Okay, so you need to approve funds first, right? And then only after that, you need to swap. And that applies not only to swap, but basically to most of the DeFi actions, right? So with Reactive Network, you would approve, and then the swap would happen automatically. I will show how exactly.

So the next example that is pretty cool and still simple is a stop order or stop loss order, right, where you wait for the price on the DEX to reach a certain threshold, and then you execute the trade, right? I believe they have this functionality on some of the DEXs already, and obviously, they have this functionality on all of the centralized exchanges, right? But with Reactive smart contracts, you can implement this thing on top of any existing DEX, and you can listen, let's say, to one pool and trade on some other pool. You can listen to, for instance, the exchange rate of token A, and let's say you have an idea that it kind of correlates to the 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 Solidity smart contracts, you can define whatever conditions you need. So the next example is bridge, a pretty self-explanatory. You can just build a bridge on our technology. The next one is cross-chain lending. So I believe we had such an example on one of our hackathons.

Yes, we did. So I might even be able to show some of the proof of concept code. So I'm saying that a person has built it on a hackathon, 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 well as we can on the docs. But yeah, our experience shows that mostly developers don't struggle with building on us.

So yeah, cross-chain lending where you provide collateral on one chain and get the loan on a different chain. So then you return the loan on a different chain and get back your collateral on the first chain. Also, a cross-chain oracle where you can listen to oracle updates and kind of copycat them on a different chain. I don't think 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 launching a new chain or you're building a 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 in one chain and have the same data on the chain of interest. Yeah, and the other example is liquidation protection. So we can monitor a position and then whenever the threshold is about to be reached, you can either, for instance, add collateral or you can sell some of the funds. Okay, any questions so far? Okay, so this slide I'm going to...

Yeah, so basically there's this concept. It might explain a bit more. We call it inversion of control. So in the usual workflow, the transactions are signed by 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 EVM, right? But with a reactive network, transactions can be initiated based on events. So in that terms, that's an inversion of control where control goes from the other smart contract that you're monitoring. Okay, so this is a simplified scheme of a Uniswap stop order. So we're starting to dive a bit into more technical stuff here.

And in 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 you approve funds for a Uniswap pool. Then whenever a sync event happens, it triggers a reaction on the reactive smart contract.

So a reactive smart contract checks whether the price threshold has been reached. And if it has, then it emits a callback. So basically, this line here, emit callback, 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 sends a transaction on the destination chain.

In that case, it swaps funds on a Uniswap pool. But this is a simplified scheme. We will have a more strict one later, right? So yeah, this is a scheme not for a reactive workflow, but for a traditional workflow. So you can see number one here, right?

This is the first transaction executed by the user by an UA address here. And you can see the second transaction here. So the first one is approved. And then the second one is swapped. So as I have already mentioned, the user needs to execute two transactions.

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 UA, they only send one transaction. And all the other stuff, it happens automatically, right? So let's talk about the entities we have here because this is important for us to work with the code later.

So what we have here, first of all, it's a token contract, right? Which you're obviously familiar with, two token contracts, as a matter of fact, because we are talking about swapping token A for token B, right? And then 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 look at it as a proxy smart contract.

But I will be using the term callback smart contract from now on, right? So here's what happens. A user approves funds, so a user calls an approved function of a token A smart contract. And 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 DEX pool smart contract, they were deployed by someone else. So a user approves funds for the callback smart contract to spend. Then reactive smart contract sees this approval event, right? And understands, checks that this is approval to the smart contract, some other conditions probably, and then executes a callback, where callback, generally it's a swap, but it's executed through 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. Basically, you can name this function whatever you want. You can have different functions and stuff.

This is just the naming issue on this picture. And so it calls this function here. And within this function, some stuff happens. So first of all, token A gets transferred from the user to callback smart contract, right? Then after that, token A on callback smart contract is swapped for token B on callback smart contract.

So now 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 here you can see all the function calls colored. And to summarize this thing, what has happened from a user standpoint, right? The user has approved funds to be spent by a callback smart contract, and then the magic happens and the user gets token B.

So generally, like obviously, since a user was approving funds for this particular smart contract, their intention was to swap this amount of token A for token B. But all they do on their end in the wallet, they just 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. Do you have any questions, guys? Okay, as a matter of fact, we're not going to have 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 now or later in person or in the chat as well. Okay, so before we proceed to the actual coding, I wanted to share some more of real life examples. So this, the stuff that I've described so far, it's more like code examples and things for people to use. And the stuff I have here on this slide, it's the applications that are already being that already exist, right?

So two of them are already live. They're FlexiLoan and Reactor. So FlexiLoan is a pretty curious thing. It's a flash loan where a lender does not need to lock the funds in a pool. A lender only needs to approve the funds to be flash loaned, right?

And after that, whenever a borrower comes and does a flash loan, only within this transaction, the funds leave the wallet of the lender, go somewhere else, are traded, and then go back, right? So what it brings to the lender is you can actually approve funds for several pools to be used in. So you can reuse your liquidity for several different pools, which I believe might be beneficial, right? And the other thing we have is Reactor. I might even have a chance to show it a bit later.

So Reactor is basically an application to bring our B2D solutions to B2C users. So as a matter of fact, with Reactor, you can deploy a stop order workflow without the need to write any smart contract code or to deal with it. You just need to enter the parameters like token A, token B, price threshold, and something else probably. And 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 secure your funds like that 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 yeah, also, it has some other automations in development. And currently, we are working with some other projects, which is SmartTrust, who are building a payment and reputation system for dealing with contractors, right? It's a DEX trade.

They're using us for guest list transactions after cross-chain swaps, right? QSTNs who automate rewards for service completion. And QuickSwap, they automate their fee collection. So they have a bunch of, they participate in a bunch of pools on a bunch of different And they can collect fees automatically before that they needed to do a lot of manual steps. And also, these were manual steps by a C-level person because it's a C-level person holding the private keys, right?

And with this workflow, part of this thing is automated, and they save time on that. So I would say that's a pretty straightforward use case, but it saves time, so it's also pretty 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, please wait for the microphone, yeah. Okay. In the examples, you mentioned oracles. Basically, it reacts on the new state provided by the oracles. I understand that this is mostly thought for the push oracles like the chairman is.

Is there a way to also work with the pool oracles like Perth, for instance? I guess, any others? 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 pool oracles work in the way that... You provide the data of the oracle from their off-chain systems as the core data within the transaction and basically, there is some verification contract on-chain that verifies that That the origin of the data is is basically valid.

Mm-hmm, but within this transaction No events are emitted, right? No. Okay. No in that case. We won't be able to because like we Events are the core thing in in our tech stuff here so the other question that we get is can we react to native token transfers and The answer is also no for now because they don't Don't don't emit events either.

But obviously we can react to wrapped token chances Since everything here is actually based on emitted events I assume that you are involved in that discussion on a geomagicians regarding the potential future 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 I think our dev team works and that we can ask 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 some more complicated concepts here and 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 share any private keys Okay, so 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 sort of thing?

Yeah, okay, so let me take a look at chat, right Oh Okay, so to deploy those code examples you will need React tokens Puzzle do you think you could help with sending some mainnet react to I Have Please share your dress. I will share with you and I will ask you to share it with people who will be sharing the addresses Please share it on the on the reactive workshop at DEF CON chat because I won't be opening any other windows to not expose any Information Yeah, so in case you guys want to participate in live coding, please share your Test or developer addresses Probably in the chat I Understand that this is might be a privacy violation. Sorry about that But jump in between several windows Will be hard and and you can just take your time and create an empty wallet and share an empty address So yeah Yeah, so first of all, let me share some of the React with paddle and paddle will be sharing it with you. So as you can see, it's a usual evm chain. So I'm using foundry here and foundry commands So this is the address that will be distributing react And I will share half of everything I have with puddle Okay Mm-hmm Yeah, some now puddle has some react so I will share it with you and you will be able to deploy some stuff on reactor network, so also 10 would be Too much because I've shared 50 with you.

Yeah 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 ten ten 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 let me share this thing with you You can take a look at the website later because now we're Have a discussion right docs as well So here's the list of the chains that we support For the mainnet right currently It's Ethereum mainnet by the smart chain avalanche c-chain base chain sonic mainnet and reactive mainnet So reactive can interact with itself, right? In my case, I will be using base chain, so I have some Base guest token. Sorry.

I don't have enough to share with everyone So I believe you do have some mainnet tokens on one of those chains In case you don't you can just do all the stuff on reactive mainnet 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 minute in my case origin and destination chain will be base chain and reactive is reactive, right? Okay, so let's go to the code 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 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 All right Please clone this repository Meanwhile, I will tell you what's happening there so this is this repository right the Sources for demos are in this SRC demo demos folders, and we also have Lib folder here which contains some of the third-party stuff that just opens up and but Mainly 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 Let's let's start taking a look at the actual examples That we will be deploying so first of all let's go to the Core readme. We have a core readme in a core folder and we have Readme in for every particular example in core folder.

It basically just says how to set up The environment right how to stop founder here 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 Running the code so 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 Demonstrates the concept in the simplest way possible so it has the readme here so we can go over those details in written form as well, but let me just Describe it to you in words and Let me share the contracts with you so you might remember this simple scheme Here the first one and Keep it in mind.

We have an origin smart contract, re-ethic smart contract and destination smart contract. Now the origin smart contract is this one right it's basic demo L1 contract and All is all that's happening here is we have a received event that Has origin center and value and we have receive payable function Which emits this event so the origin is transaction origin the center is meshed cylinder and value is value and it just returns what we pay to the contract back to the User so the way we're supposed to interact with this contract is we just send some Gas talking their base in our case in my case and It gives it back and Emits a received event so that's obviously an artificial thing now We also have a reactive contract and a destination shipping and a destination contract or callback contract So I will show the callback contracts first because it's also super simple and after that we'll describe discuss the reactive contract So the callback contract It also has an event for us to take a look and debug it has a constructor and it has a Function callback which will be called by a reactive smart contract So this function basically it just emits callback received event for us to take a look at it on Base scan So it just has one one function that's called callback and it also Has some modifications 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 to Build something new you most probably will need only to change significant as a react function But all the other stuff, it's it's standard, right? so It is it is inherited from Abstract reactive contract we will take a look at that a bit later, but generally From the builder standpoint we inherited from from here and use it and This thing here is mainly used for the purpose that we've discussed earlier, which is to pay for those callbacks, right? Okay so in constructor we have 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 send transactions to contract that we are Listening to on the origin chain topic is zero of the event Which is basically a signature of the event that we are listening to and then a callback contract address to which we're sending that transactions Right then what's Happening here is basically all the stuff just gets initiated and the important part is this where we subscribe to Subscribe to those events so we have 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 In that case we're saying that we want to subscribe to an event on origin chain Base chain on this contract address with this topic zero pretty straightforward So this is everything that happens in the constructors We are subscribing to an event of interest in our case. Let me remind you that this is This event received right So topic zero yeah, it will be specified when deploying and 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 Call this function manually this function is called whenever an event of interest happens right so this is a reaction to the event that we want to react to and This Is what happens here So we specify the callback that we're sending in our case.

We are calling function named callback And and basically that's it also we're passing zero address here I might talk about that a bit later, and then we're emitting the callback so as I have said earlier The Callback event is a keyword in reaction smart contracts it means that we are sending transaction that we're interacting with the destination smart contract At this point I remembered that I forgot about the Name of this very workshop, so Let me Say a few words about that because that is important extending that capabilities using reactive smart contracts, so I've mentioned that we are enabling Automation crossing functionality and modularity this is exactly how we are going to extend that capabilities Using reactive smart contracts. I just wanted to to clarify this particular thing to Make sure we're in the same page and So let me go back to this setup here basically I have Explained everything about almost everything about the basic example so we can Start deploying it This will be a hard part for me because I might mess up some of the numbers and copy pastes, but Yeah, I will go together with you through this process to make sure you can make this thing work as well, so I would say our code examples and Read me is a pretty well written, so if you just follow this workshop this this Read me without my explanation you will get the same result, but yeah, let us go through this together So first of all we are running some commands here You don't need to specify all this stuff in advance because I will be waiting for you while we are running commands but anyway, we will need some parameters in environment variables obviously you can Just copy paste them instead of using environment variables. You can just copy paste the numbers themselves But it increases the probability of copy pasting something Mistakenly and also, we are using foundry here and all the read me is there for foundry, but this also works with remix and I believe since recently it also works with hard hat so whatever Tool you prefer you can use it Do you have question? Okay Regarding the destination chain. I can see that you have like Quoted a constant of the gas limit right in the example.

It's fine What about the gas price of the destination chains, how this is handled up, you know the fluctuation of the gas price and potentially like flipping up the The proper prices yeah, so this is a good question As a matter of fact, there's two ways to stand those callbacks and you can choose between them In reacting smart contracts, so we have our own setup which works for all the chains listed in the docks and we have Integration with hyperlane where you can send callbacks to all the chain supported by hyperlink So in case you using hyperlane the this Gas spikes problem is handled by hyperlane. So that's part of the answer, but in case You're using our Own Validators we call them validators because they are in terms of proof-of-stake In that case It's handled on our end obviously, we try to take those spikes into account to estimate how much the transaction will 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 ready to dive deeper into that puddle Do you think you could say something additional on top of that about the gas prices? 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 a decision-making on the direct 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 this into your decision-making We focus on delivery Honestly in this in this case I would Consider 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 Once again a fundamental idea is to build a general platform that you can build whatever you want on top That's the approach and yes, once again, we're working on our own apps We are working on our own Contract 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, Pavel, thank you for the help I'm sorry, so the stuff we will need here is Origin RPC. So as I have said we're using the terms origin and destination here so you might have probably already chosen the chain you'll be working with in my case both origin and destination is Base and I have already set up those environment variables to base parameters. I Hope I've done it correctly so this is the RPC obviously to interact with the chain the chain ID for reactor smart contracts to know which chain to interact with and the private key that you will be using for Sending a transaction because in this particular example, we will be manually triggering this reaction Yes, so we will be triggering this reaction so we will need a private key on an origin chain as well So destination RPC destination chain ID destination private scheme To deploy the destination smart contract basically not the destination smart contract the the callback smart contract and which is the same thing and Reactive RPC To interact with reactor network to deploy the reactor smart contract reactor private key to deploy the reactor smart contract system contract address Is derived from from here? It is the address of our system smart contract which Can be seen in its name, right? So to get it We can go here or we can go to origins and destinations Right.

So here it explicitly says Reactive mainnet and copula testnet use the same system smart contract address So, yeah, this is the value that we need and then destination callback proxy address can be also derived from this link here Yeah, you can see these addresses here in this thing, this is the addresses that will be sending our callback sign in our transactions No, not signing the transactions because this is a smart contract, but anyway, this is the address that we need okay, so this is the values that we'll be using and now let's Try to actually run this workshop workflow here. So the first thing we need to do is we need to We need to I don't think I have the Right Here. Sorry. Give me just one moment. I missed something up while preparing but yeah, the first thing we will need to do is we'll need to deploy the Origin smart contract Which will be emitting the events of interest, right?

then Let me go back here. Yeah now it's correct. So Let's deploy it using this command here. So for this command to work We will need origin RPC, which is based RPC in my case and origin private key, which I won't tell you Okay Okay Yeah, I think I've prepared everything correctly also Like if you're working with Windows Same as I do You will obviously need to restart the terminal 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 basic demo L1 contract here I believe it's 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 You Yeah, I hope I'm use it no, I'm not One two one two, you know, I am I'm sorry anyway, oh I wasn't use it. 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 the deployed to address and we need to save it in our Environment variables.

So 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 So I believe we have two people who are trying to follow the workflow here, right? I Guess you please if you're following the workflow, please raise your hand so that I can make sure that you okay Yeah, thank you very much Did you have enough time to do that? Okay Please let me know if you need a pause because I understand that listening and Running the workflow at the same time is kind of hard Since you volunteered to try this. I appreciate that a lot and I'm eager to wait for you to manage Yes, yes you can yeah, do you want me to share the address in the chat? Yeah, okay Okay, so yeah, please let me know if you need more time because It's cool.

If you manage to Deploy and try this workflow. Okay. So the first step is done We've deployed the origin smart contract and we've saved its its its Origin address here. Let me double-check origin address starts with a three amazing. Yeah now Let's do the second step which is to deploy the callback smart contract the Smart contract to which we want to send the callback so in terms of stop order example This would be the contract that would be swapping on a decks, right?

But here is just 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 Have the time to update it, right? So I'm working with base chain here. It starts with zero d3 right And this is destination callback Okay, I've already exposed my private keys, but I don't have any significant funds there okay destination zero d3 correct and Let us let us run this command as well Insufficient funds for gas. Hmm.

Let me check I want to go to base mainnet This is weird, I Seem to have quite a bunch of funds here. Let me see Destination RPC destination private key destination RPC should be Base it is this niche for key the same. Okay, and what about origin? Yeah Yeah Yeah, let us understand what I did incorrectly here Yeah, let us see my dress on base can Okay Okay, I do have some Base is here. I Might be sending too much Yeah, and so this example was created for support air So we need to put some more zeros here definitely Yeah Yeah, so we need to alter the reactor smart contract, right Yeah, we haven't deployed it yet, so it will be successful and also this is 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 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 Sorry, let us copy paste this thing to where? To call back address as it states here Environment variables. Callback address. Okay.

Okay. And as Pavel has said, we will need to put a bit more zeros to our reactive contract. So for us to check that reactive contracts operate correctly, we have this additional condition here. We're only reacting when we send more than 0.01 Ether.

So let us put this threshold a bit lower, right, by adding two zeros. And save. Now, this is exactly what we need. And we will be doing step 3. Reactive smart contract.

Deploying reactive smart contract. And this is my personal favorite mistake, which I do a lot. I deploy it without exiting and reopening my IDE because in Windows, as I've said, environment variables are only added to the context after you reload the terminal. Okay. Now we should be good.

Okay. And let us deploy our reactive smart contract. Yeah. In that case, we are dealing with reactive network. And us sending 0.

01 Ether is okay because the previous numbers, they were for base. And those numbers, they are for reactive network. Okay. So reactive RPC rate, private key, system contract address, origin chain ID, destination chain ID, origin address, callback 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 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, as I have showed here, 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, let us go to the origin smart contract first.

This one. All right. Let us see its address here on the base scan. Okay. It has one transaction here, the one I've just initiated 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, which is the received event, which we pass as a parameter to the constructor of reacting smart contract as a topic zero. And okay, this event is emitted. The question is, did it invoke a reaction by reacting smart contract? So to know that, let's take a look at the destination contract. Right now, I'm praying.

I'm pretty confident in our tech, not so much in myself. Is it the right one? If I input here, yeah, destination. No, no, no, that's not the right one. That's my address.

Sorry. Okay. So since the transactions are sent not directly to this address, but through a proxy contract, the address of which we have inputted earlier, this stuff here goes to internal transactions. And you can see it here, the transaction. Let's take a look at the logs, whitelist contract, and I believe this is the received event.

Right? Yeah, let's take a look at those parameters here. 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 callback, yeah, the reactor center. So as you can see, we have successfully monitored the origin chain contract. Then we've reacted to this with a reactor smart contract, and you can see the callback on the destination smart contract.

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 on this slide. And now I will probably make a small pause for you to ask some questions, and especially for the guys who are working on laptops to make sure that it works for you. Any questions, guys? Okay, thank you. So I'm wondering, for error handling, let's say one of the transactions doesn't trigger, or there's any kind of error with fees, how is it possible to detect, or there is maybe a timeout in the callback to kind of know if maybe the event is never caught, or it never happened?

Is there kind of an error handling part? So the error handling part, most probably it will be on the application level, so to say. So since it's Solidity, we can do arbitrary check there. Also, on top of that, we have a system smart contract that emits system events such as cron events, so you can wait for some time and check some conditions after that. Right?

I don't know whether you've heard my answer about reorgs earlier, but that in particular can be used to handle reorgs. So it depends obviously on what particular type of errors we're talking about here, right? So it might be, I think mostly it should be reorgs, right? What other errors do you keep in mind? Pavel, could you maybe share a bit more about what kind of errors we handle in our bridge, or how do we handle reorgs in our bridge?

I don't really have much to add to what Ivan already said, because once again, the idea is that error handling happens at the application level. So it's essentially up to the developers to ensure that they have the error processing they want. And yes, it's something of an art to do that, and basically our React bridge is all about error handling and ensuring consistency. So it's a hard task as usual. And once again, as with the problem of fluctuating gas prices, we are planning to do something to make it easier and provide 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, thank you for the question. Okay, so let me, as a matter of fact, let me show you the transactions on React scan as well. So 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, do we have my address here?

Yep, we do. So we have contract deploy here, and we have RVM transactions. Okay, so this is basically my address, and we can see all the transactions that I did on React scan. So I think we're mainly interested in the last two, no, in the last one, because it's just me getting and sending React, right? I got it initially, then I sent some of it to Pavel, then I got some more properly.

And this is the transaction of interest, me deploying the ReactiveSmart contract, which you have seen. I don't think we have a lot to discuss here. Basically, yeah, contract deployment. But this only, this tab here, rnk, reactive network transactions, it says about the transactions that I initiated, and to see the transactions, the reactions, actually, we need to go here, right? So, and this is the transaction of interest, where we react to origin contract and with a destination transaction.

So you can see all the links here. So 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 an origin transaction doesn't happen, then the reactive transaction doesn't happen. So it kind of helps a lot to understand what has happened. And, yep, I believe that's it for the basic demo, right? And I have, we have 24 more minutes probably, right? And I have several ideas on how we could spend it.

The best case for me would be to have some interaction with you guys, to hear some more questions, maybe to, if you already managed to have some ideas about how this could be applied to your tech tech, to your application, what you're working on, that would be like the best. And if we, if you don't have any questions or ideas, then I will just show more code. I will show how the stop limit, stop loss order works, because it's pretty interesting, because this particular example I've shared before, it's artificial, and the stop loss, it's pretty real. So any more questions? Okay.

Yeah, as a matter of fact, I do have a question. So I'm trying to understand the structure of the audience in this particular room, but also on the conference in general. So could you please raise your hands if you're working for an infrastructure project? I know you guys are. Come on.

Yeah, could you please raise your hands if you work for a DEX? Okay, sounds good. And if you work for a centralized exchange? For some other kind of DEP? And other?

Thank you. And could you please tell me, guys, what you're working on? In a few words. I'm working on a community page, kind of, where creators can have their own page. And yeah, I'm pretty new, so it's like first time or second time I've seen a smart contract, so I'm just looking a little bit.

Yeah, thank you. As a matter of fact, that's not a general smart contract, so we're going like two levels deeper. I hope that's not overwhelming. It's a little bit, but it's interesting. Yeah, thank you very much.

Yeah, and you, sir? Yeah, I work for LayerOne Flare, so that's why I was interested. Like, maybe we can connect a reactive network to there as well. Yeah, yeah, that sounds great, because like, as a matter of fact, DEXs and DEPs in general, but DEXs specifically, are probably our favorite types, type of clients. And chains are our favorite types of partnerships.

Like, we obviously, we add new chains. So, yeah, that's good to hear. Okay, so in that case, let me dive a bit deeper into the stop-loss example. And yeah, let me know, guys, if you're still working on deploying your stuff. Please ask questions anytime you have them.

And I will dive a bit deeper into the stop-loss example. So, I probably don't have enough time to deploy it. The reactive smart contract there is pretty simple, but to work with this top order, we will need to deploy the factor first, then the pairs. So, we will need to prepare a more complicated setup in terms of 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 the code without deploying, and then maybe share some more cool pictures on the slides.

Okay, so I need to go here, right? Where? Yeah. Uniswap stop order. And we have three contracts here.

It is called the contract, right, which interacts with the pool. This is the reactive smart contract, and this is the token. Thank you. I will try. Does 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 token is a token. Enough said.

This is the reactive smart contract. We'll take a look at it after the callback smart contract, because first, let's take a look at what reaction are we going to actually invoke. So, this is a callback smart contract. So, let's talk about it in terms of a DEX, right? Let's say you already have some pools, and you want to add this functionality to your DEX.

In that case, you will need to deploy this callback smart contract. 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 existing contracts. But obviously, 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 scheme. Where is it?

Yeah, here it is. It's this one. The one that is approved 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 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, it's just a scheme, and in the real code, it also checks a bunch of conditions, right? So, I don't think we need to get over 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, what's happening here? It has the pair address, the client address. It has the Boolean, which specifies which token is to be sold and which one is to be bought. It has the coefficient and threshold, which define the threshold at which we actually execute the trade. So, it also exists in the reactive smart contract, but it also checks here on the callback smart contract and to make sure, basically, for security reasons, and we recommend doing that.

So, we have token 0 here, token 1 here. We have reserves here. We get reserves. Then, we require that we have enough reserves in our – no, I mean, we check that the rate is not above the threshold, right? So, we check that the threshold has been reached, right?

Then, we check which token is to be sold and which is to be bought here on these lines, right? Then, we make sure that we have an allowance to spend. Then, we make sure that we have enough balance to spend, right? And then, we actually transfer, right? So, this is the first thing that was listed on the scheme.

We transfer the token from the client to this callback smart contract. Then, we approve the funds for the pool to spend them, right? Then, we 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 to let the reactive smart contract know that the order was executed and we don't need to execute it once again. I believe that is pretty clear. That's just a bunch of transfers and swaps, right?

And this is us checking that the threshold has been reached. So, this is the callback smart contract. This is what happens on the destination chain. And this is the reactive smart contract. This is what happens on the reactive network, right?

So, we have a bunch of events here. We don't need to discuss them in detail. We specify the chain ID. We probably should not have it hard-coded here. Yeah, we will need to change it.

So, this is the topic zero for Uniswap sync event. This is the topic zero for our stop event from our callback smart contract, and this is the guest limit, a bunch of variables here, a constructor where we specify all the stuff such as threshold, tokens, client's address, all the other stuff. Here, we subscribe to sync events from which we derive the price, and here we subscribe to stop events that stop us from doing this thing the second time, right? And this is the react function, which is triggered when a sync event happens, every time a sync event happens, as a matter of fact. And you can see a bunch of to-dos here because it's just a proof of concept.

So, in a real setup, it will be a bit more complicated probably. And, okay. So, we're checking the, yeah. So, this is, as a matter of fact, this is the second thing that might happen, and the first thing that might happen is we might see the sync event. So, if we have seen the sync event, then this branch of if-else here is executed.

So, what happens is also we get the reserves, we check the threshold, and we make sure that we were triggered. We emit the callback sent event, which is purely for debugging purposes. Don't confuse it with the callback event, right? Then we construct the payload, which is how we're going to call what function with what parameters we're going to call on the destination chain. In our case, it's a stop function, and we have address, zero address here, the pair, the client, the token, the coefficient, and threshold.

Then we record the fact that the stop order has already been triggered, because like in this particular setup, it only works one time. Obviously, it can work many times as well in a more complicated code. And we emit the callback, which executes this stop function here. And that's it, more or less. The only thing on top of that is that when we see the stop event, it basically stops working.

It says it's done, and it emits the done event, and it stops working. That's it. I had some more stuff to share, a bit more 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 sauce? Not secret sauce, but what's the tech? How can we trust? Yeah, thank you.

I will explain it high level. First of all, because I haven't worked with the core code. I'm only working with the application code, but also because some of that is still work in progress, and the changes will be applied. Let me simplify my explanations. Let me get this scheme again.

Basically, there's three parts of the process. Monitoring an event on an origin chain, then processing Reactor smart contract, which is an EVM smart contract, and then sending a callback. The Reactive smart contract part, it's an EVM chain with a proof of stake consensus with a bit of a tweak of parallelization. There is a Reactive network EVM, and there is smaller EVMs for every address that 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.

The EVM that actually receives a reaction and sends a callback, it's a smaller EVM, my own. I believe it has a bunch of patches on top of GIFs, obviously because it's not just one big EVM, but a big EVM and smaller ones. As a matter of fact, I have a slide for that as well. Yeah, like this. There's Reactive network where everything exists, the system smart contract and the Reactor smart contract, and then for every deploy address, there is smaller Reactive VMs.

Generally, it's GIF with some additions and proof of stake. Then also, there's an origin part. We are subscribed to Chainstack and DRPC, and we have what we call a sequencer, which gets all the information about the blocks and transactions from those two and puts them in a sequence because we're listening to different chains, not just one chain. We need to have a, how to call it, unified numbers for all the blocks. Let's say, now I have an Ethereum block, which goes by number zero.

Next, I have Arbitrum blocks, which goes one, another Arbitrum blocks, which goes two, Polygon blocks, block three, then Ethereum block four, and so on. We have them all numbered throughout. That is what our sequencer does. Then sequencer gives this stuff to our Reactive network, to our Reactive smart contracts to make sure they process this information correctly. Then there's this destination part.

Our validators, they hold their private keys, and then with their private keys, they interact with their UA addresses. They interact with the callback proxy contract, which then interacts with our callback contract. They basically send those callbacks to the callback proxy contract, which interacts with the callback contract that we've just seen in our example. As I have mentioned earlier, 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 Hyperlane, where you can send callbacks through Hyperlane to the chains that Hyperlane supports.

I believe this is a pretty brief explanation. I don't think it explains everything about decentralization of each part, but it kind of sheds some light. Thank you. Pavel, do you think we can shed more light on how it works under the hood, or do you think that's enough? All right, yeah.

I'm saying pretty much the same thing once again. It's a work in progress. I'm not an old hacker as well. I'm more on the contract side, but yeah, I do know perhaps a little bit more about this than I am. But in any case, we are hoping to improve our decentralization as we are progressing through the network spaces.

We are pretty early in this right now, and we're effectively running a proof-of-stake authority. So it's a POS, but the validator set is closed, and pretty much on every level of what Ivan has mentioned so far, we intend to work on improving decentralization. We're not quite there yet. 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.

We just needed it for our own internal reasons. We basically needed a means of communication between our VMs and the reactive network proper, 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 a centralized approach, callbacks to other networks were kind of interesting to people who are using the reactive network mostly because it's really fast and relatively cheap compared to other options. So this is like a trade-off. But the general idea with respect to transport is to integrate with everyone we can, everyone interested in this, and just let people choose which transport works best for them.

And perhaps we're going to be expanding our own transport options as well. So yeah, that is that. I hope that helps a little. Thank you. Round of applause for Ivan.

I really enjoyed the presentation. Thank you, guys. Thank you very much. And yeah, I really appreciate you coming that early and being here with us for the whole presentation because like two hours, it was hard for me. And I know the stuff.

And for you, it was probably a lot of content. So yeah, I really appreciate that you're still here.