 Hello, everyone. What I'm going to show today is some progress on our hierarchical consensus framework. If you recall from previous demos, the hierarchical consensus, what we're trying to do is a framework to allow horizontal scaling over the Falcon network. I guess you can see my browser now. I'm going to like briefly explain what we recently introduced into the framework, which is atomic execution between different subnets. If we have the case of, for instance, like an ERC721, where we want to exchange the ownership of assets that live in different subnets, the current cross-net messages that we were having don't allow to trigger state changes into subnets at the same time. And like if we want to move our assets somewhere else, we may not trust the other subnets. So that's why we come up with this protocol to perform atomic execution. And for this atomic execution, what we use is a subnet that we both trust. So generally, we could use any subnet that we trust, but like in the current protocol, what we use is our common parent. And the protocol works as follows. Like first, we will have some kind of off-chain agreement where we say, hey, I'm going to exchange this asset from your subnet for this other asset that is in my subnet and that I'm owning. Once we have this off-chain agreement, each of the parties, what they have to do is to lock the state in their subnet. The reason for this is that we don't want new messages to affect the state that we are putting as part of and as an input in the atomic execution. So both of them lock their states and someone can initiate the execution in the actor sharing the parties that would be involved from what subnet and what are the CIDs of the locked input states. We'll see that in a moment. With this, the atomic execution protocol can start running. And the first thing that each of the parties do is get the locked state so they have knowledge of all the CIDs involved as input for the atomic execution. So they will get the state from the corresponding subnets and run the execution locally to get the output state and the CID of the output state. With this output state, what they do is commit it into the SC actor, if you remember this is the subnet coordinate director, it's our gateway to the rest of the hierarchy. And each of the parties will commit this output state to the SCA of the parent. The SCA of the parent will check if both of them match and if we have more than two parties if the end parties that are involved in the execution, their output match. And if they match what the SCA in the parent will trigger is a top-down transaction. So this cross-net transaction that will unlock the state and merge the final state for the execution. And with this, we will manage to do an atomic execution between two subnets. At any point, if someone, like we have the SCA that is orchestrating all of this relationship between the subnets, if at one point one of the parties does something sketchy, if someone is using an input that is not right, when I get the log state, I see that it's not the log state that we negotiated or something else. Anyone can, before the atomic execution succeeds, any of them can abort the execution. And this is what I'm going to show in a moment over EODCO in our hierarchical analysis. And one last update, we have paper in the works. So if you want to see all the low-level details for these protocol and other things related to hierarchical consensus, they will be public soon. So let me know if you want to, I mean, if you want early access to read it, not like we will share it widely. And now I'm going to share my screen really briefly. So what I have in order to save a bit of time, I already have, wait, you should be seeing my screen. So what I have already is, I spawned two subnets, two subnets, and I added some security supply in each of the subnets so that we can do an atomic execution. And the first thing that I'm going to do is to deploy a new actor. And I built a really simple user defined actor, as we don't have at the end yet, where this actor, what it does is just like it's a map, a balance table where instead of owning a balance, you can own a CID. So I'm going to deploy this actor in each of the subnets. And I'm going to try and own a different CID and have a different state in each of the subnets and then perform every place. So an exchange between the two subnets using atomic execution. So here, the only thing that I'm doing is first deploying in T0100 subnet, the actor, and I'm going to do the same in the other subnet. So also, I just realized that I didn't fund the account, so I'm going to send some funds in all of the subnets for each of the accounts. And if you see here, if I'm going to do, like, I have two addresses here, I'm going to do the exchange from one to the other. So the next thing that we're going to do is like we're going to own. So this is just like part of this sample actor that I used to implement all the locking primitives and show how this would work with what we call the localable actor, which is an actor that implements the interface in order to support atomic execution. And here, the only thing that I'm doing is saying, hey, from this, from my default address in this subnet, I want to own a certain CID with this seed. And I'm going to do the same for the other one, but from the other address so that I have different like CIDs owned by the different addresses in each of the subnets. And if we look now to the state in each of the subnets, so here we're going to look to the state in the first subnet, we see that the, I mean, here is the owner state, which is this balance table that I mentioned, and we see that the state currently is unlocked, which means that I can perform any kind of execution or that state is not locked by any, by any mean. And the same happens to the other subnet. And we see actually that the states are different because we are only like different. I mean, we could even inspect these serialized information like serialized data, but probably won't have time. So just right now what we have is two actors in two different subnets with different states and with unlocked states. So if we imagine that we've done like this off-chain negotiation and we've agreed on the messages that we're going to run for the atomic execution, the next thing that we have to do is each of us in each of the subnets will have to lock our content. So here what I'm doing is we have this subnet atomic list of new comments that would allow us to, that what it allows us is to lock some state in order to use it as for the atomic execution. So here from one of the subnets from this subnet, I'm locking the state in order to run atomically the method six, this like internally what it does is check what is the state that needs to be locked in order to execute an atomic execution for this method in the actor. And I'm going to do the same from the other subnet, but using like the other user that is involved in the execution, which is my other address. As the output of these two locking operations, you see that I'm getting a CID. This is the CID that we're going to use in order to initialize the atomic execution in the parent and notify what is the CID that the other side needs to request in order to execute the atomic execution. So if we look to the state again, I'm going to do it in batch. So I'm going to go fast. We see that now the state is locked. And if we try to perform, I'm going to try and perform like a replace plain replace instead of an atomic execution of plain replace in one of the subnet. You see that it fails because the state is locked. So we can be sure that no changes will be done in the state while we're doing this atomic execution. So the next thing that we have to do is to initialize the atomic execution. And in order to initialize it, we have to, we need the actual address for the atomic execution in each of the subnets, the CIDs of the lock states that we have it here. And also we need the hierarchical addresses, which means like the address of the users plus the subnet context that we want that will be involved in the execution. In this case, like we have also this handy address in order to get like, this is one of my addresses and I want the hierarchical address, which is another kind of address that we've come up with to be able to add additional information about our additional context on subnets. I'm running out of time. So I'm just going to copy paste like this initialization of the execution where we have all of the data populated. So here we added the addresses that are involved in the execution, the lock states that we will use as input and like the source after IDs in each of the subnets. And also the list of messages. So we have like here I'm just adding a list of messages that does the A exchange, the list of messages that we want for the execution. So this is initializing that well, and it felt so forgot to put the messages. I'm going to put the messages initialize the execution and with these we will be able to submit the execution, which is like, this is that the actual off chain execution which each of us will run the execution locally. So here we see that it will list subnet atomic. I can check the list of execution in which this address is involved. I could do the same for the other. And each of us will have to submit right now is just initialized without any output submission. So now if we want to perform the atomic execution, we need to use this submit exec that what we'll do is take all the lock states used from inputs from other subnet run locally and then submit the output received into the SCA of the parent. You see that I receive initialized but if we list the execs, we see that there's one submission. The SCA will wait either for an abort or the rest of the submissions for the parties involved. I do the same from my other address. And oh, okay, wait, I list the execs. This is from my other address you see that I'm using here the other address and now the submitted should be in two and the result should be success. This has triggered a new top-down transaction from the parent to the subnet. And now if we check the state in the subnet, we should see a different state and that the state has been unlocked because the top-down transaction has been propagated. And this is the case. And we should see in this case, as we are just touching one of the states of the actor, we should see the same state in both of the actors because like is the same output after the exchange. Sorry, I run a bit out of time, but let me know if there are questions I can, I had more demo but like for some other day. Thanks.