 So yeah, I'm Stefan. I'm here representing Lib Submarine. I spend most of my time thinking about security tokens, so these financial security is how do we actually represent them on the blockchain. But I've been fortunate enough over the last few months to work with some incredible people in implementing Lib Submarine, which comes off of the work that has been done at IC3 out of Cornell. So Lib Submarine, there was a previous talk earlier today describing how the mechanism is actually used to prevent front running on decentralized exchanges. My talk today is going to talk about how do we actually implement those. What does it look like from the smart contracts perspective and how does it look like from the DAPP perspective to work with Lib Submarine. So let's jump into it. Quick overview, I'm not going to go into detail about this. Lib Submarine is the right solution to prevent reordering attacks and also to increase the level of privacy in a commit reveal scheme and really eliminate the signal that the commit is going to provide. So on the left side of the screen here, you can see what a regular commit reveal scheme will be, which is you have the commit that hashes the data, but you still see the participation, as well as the value that's being committed. Then during the reveal stage, you reveal what the data contains. And maybe this is like a voting mechanism, right? On the right side of the screen, you actually see what it would look like from a submarine perspective, which is the entire commit period is completely hidden. It's masked. You don't see who's participating. You don't see the value that's being committed. And of course, you don't see the data that's being committed. But again, everything is revealed at the end of the day. So how do you actually implement it? Here on the left side of the screen, we have a very simple auction contract that's implemented as an ERC721 token receiver hook. We took out a lot of the basic storage and set up functions that are required for the auction and only left this bid function, which is the one that people would monitor to get an idea of what the active bids are on this auction. So what someone that's monitoring the chain would see is that when someone commits a new bid to the mem pool, they could see it and then make sure that they place a transaction right after that kind of beats the bid and make sure that they're on top of the auction. So what you want to do is be able to mask the value and really the participation inside of this bidding and create what is called a seal bid auction. So this can be done. The only function that you end up needing to change is this bid function. So you actually implement it as an event receiver hook based off of this Libs submarine contract that you inherit from. So you can see at the top, you inherit the new contract. And then you implement this function called onLibs onSubmarineReveal with these data parameters. So the submarine ID is what kind of identifies the bid. And then you have the embedded data, which is that data that was previously hashed in a commit reveal scheme. In this scheme, you have it through this function and as well as the value. Then the logic of your function actually kind of remains the same. You still have the same logical checks, the same storage changes, and the new logic for calculating who is the winner. So this would actually happen on the reveal stage of your commit reveal. So you make sure that you're not liable to someone that's watching all the commits and able to make bids accordingly. So from the user perspective, if you're just modifying a traditional commit reveal scheme, it actually doesn't look very much different from a user perspective. It still needs to do two sign transaction from the user. And then you have this third transaction, which is the unlock transaction, which is generated as kind of a raw sign transaction and can be relayed by anyone that's communicating with the chain. So from a client perspective, then what you have to do is you have to also have your commit that's gets generated on the off chain. And then also you have to generate a Merkle Patricia proof of that commit off chain. And we've added some Python scripts inside of a repository that actually does this for you. And then on chain, we have implemented all the smart contracts that actually execute this submarine commit. And then also verify that the commit is done through doing on chain Merkle Patricia proof verification. So all in all, if you compare kind of the gas consumption of just a regular transaction with the gas consumption of a submarine sent through Libs submarine, you have approximately 200k gas additional per commit reveal kind of process. But on the flip side, you get front running protection and you also get protection against signaling schemes. So we have one dex that's looking to integrate with us already to help them prevent their front running problems. And we encourage anyone that's looking on implementing these kinds of techniques to reach out to us. These are our Twitter hashtags, our Twitter handles. So reach out to us. We'll be happy to answer questions on how to integrate. And you can also check out libsummarine.org. This is just open source code that we're working on for fun. No fees, no token, no nothing. Take a look, implement it, and see you online.