Decentralized Capital Market Infrastructure with Jay Jog of Sei

Transcript

we are live I'm sub 3.0 and I'm here today with Jay co-founder of say Labs say is a sector-specific blockchain that's built purpose built for Capital markets and defy so we're gonna be diving deep into say today um why it's better than other blockchains out there that are doing D5 stuff and I'm also trying to find out why Jay thinks app chains are not the best solution for Building Products right now so before we get started make sure to subscribe hit the notification Bell and like button to get notified when we do live streams every Thursday my guest Jay dog is coming up next right here on the interrupt thank you

hello hello son good afternoon thanks for joining me um yeah so yeah I've been researching uh say for like a little while I met your colleague uh over at Cosmo verse and like I hadn't really I like I hadn't really you know done a whole lot of research about the project then it's when I met him that I started looking into it like this is interesting so what is this thing like who's that actually for and um you know why is it better than some of these other kind of app chains out there that are doing D5 or you know other D5 applications you know on like modeling chains and stuff like that so yeah I want to get you on today to understand like how this product is

positioned and uh who it's for but also how it works technically because as I've been finding out you guys are doing some pretty interesting stuff under the hood to um really optimize this chain for you know fast transactions and like high transaction throughput and uh and really like optimize it for trading so before we get into that um tell me about your background and I as I understand you're working with Robin Hood before so I'm curious like what you were doing there and how uh that experience informed you know what you're doing now absolutely yeah so first of all thank you for having me on podcast said um appreciate you taking the time and thanks for everyone who's in the audience following along um so a little bit about me um I'm a co-founder of stay labs and I

lead engineering I personally got into crypto back in 2017. um at that time my roommate who was going through binance Launchpad and we tinkered on a few different projects together um and afterwards I ended up joining Robin Hood so I spent almost four years over there um saw the company 10x and I was an engineering lead when the GameStop crisis happened last year so I'm sure you were following along with it was not handled very well um and I think the biggest reason for that is because there was a complete lack of transparency around what was happening um Robin Hood was not communicating very well with insiders and with customers and that just led to people becoming very very unhappy with the entire situation and that honestly highlighted to me how whenever you have these opaque systems things when they start going wrong they become very messy very

quickly and we've seen this play out time and time again most recently we saw it with 3ac and FTX and one thing that people don't really understand is just how powerless you feel as an Insider working at one of these places because you put your reputation and your career on the line when you make a decision to join the company and um you like when leadership is just completely being opaque with you and not telling you about anything that's going on behind the scenes um it just gets extremely frustrating especially when there are people on your team that are asking you questions and you have no real idea how to respond to them because you have no clue what's happening either so after going through that experience I became much more of an on-chain Nazi um whenever things happen on Jane when

everything's happen to decentralized way they're inherently trustless they're inherently uh transparent as well and that would have resolved a lot of the issues that we saw with uh to a degree with Robin Hood and definitely with three AC and FTX um so because of that last year we started building a decentralized Robinhood um more specifically a derivative exchange is what we started building at the end of last year and then since then we we started looking to the infrastructure we could use to build something like that on WE ultimately realized that the infrastructure is lacking which is what ultimately led to us buildings say so it's a little bit about my journey yeah I I I'm yeah it's interesting about the Robin Hood uh situation you know I was following like a little bit of it

you know but like not really in depth but um you know what was it was it the case that there or was some like a lot of opacity going on internally about um you know like user funds or like what was what was going on there because I wasn't really following that closely yeah so Robin Hood disabled um specific stocks from being purchased um these were stocks that were extremely popular at the time um so like GameStop AMC for example um and I personally believe that the reason Robin Hood did it was not malicious it was largely because of capital requirements requirements that they had with counterparties um but though there was just no transparency around that at all like users just woke up one day and there had

been this massive run like this massive Bull Run on GameStop um AMC and other songs and you just weren't able to buy these stocks anymore and it was just extremely extremely negative from a customer standpoint um and I mean that specific day of the day after that I got like dozens of messages a lot of messages from people that I hadn't talked to in years and people are just really unhappy they're like yo what is going on um and I think Robin and definitely could have done a better job like I think the ramifications of that are still being built for the company overall like if that one specific event had not happened I think Robinhood would have had a much more positive reputation and I think they definitely could have more for just keeping the community informed around why they would make the decisions they ended up needing to make

yeah okay I see yeah and I mean being in Europe like I we don't have Robin Hood here like I don't use it I think someone showed it to me once it's got a good UI and everything so I can tell I could see why why it's so popular um but yeah so they were just like they just decide to turn off uh trading for these assets um I think I remember in that I kind of remember now you know now that you mentioned it um so you're given the events that happen in the last week um yeah what's your kind of you know given given what you've been through at Robin Hood and haven't haven't been through some sort of you know large company with lots of customers being opaque uh with with their customers

about what they can and they can't do with their money um what what is your feeling about what's happening now like you know um how does that feel to see this also happening you know very much in the crypto space yeah I mean it feels pretty terrible to see all the things playing out in real time um I think with FTX specifically it's especially bad because in the case of 3hd it wasn't like normal users that were necessarily getting infected as much but in the case of FTX I think that it's a lot of people who are putting trust in basically in this centralized entity and there was good reason to put in the trust because like the contract that they signed was basically saying that FTX could not do anything um with the money that the users were

depositing and I think that there's going to be a lot of short-term ramifications for this like we're seeing this play out already like first of all a lot of people lost a lot of money so they're going to be less likely to engage defy um then there's also everyone who um is basically losing their confidence in the entire crypto industry overall um so I think there's going to be pretty strong ramifications from that and then there's also the regulatory side of it um I ironically I think one of the really good things that is coming out of this is the d5's value proposition has never been stronger um doing things on chain doing things in decentralized way would have solved a lot of these issues um because there's complete transparency it's completely a trustless system and I think it in any kind of centralized setup if there are

incentives to be opaque you know there are ways that people can misuse that to get an edge over others and I think we will see unethical players taking advantage of that um so inherently like long term I think the only real solution is going to be to do things in a trustless um and transparent way yeah I I think that you know a lot of the ecosystem and a lot of folks that you know sort of I gravitate around in my community obviously the narrative has been uh you know this is why we need defy you know it's paradoxical but like this is what will uh actually accelerate uh the use of defy you know that that narrative feels great and you know it's it's

really unfortunate that people lost their money and like I hope this is a is I hope that this is a lesson that you know in five to ten years from now like we'll look back on this as like a pivotal point where everything shifted but I don't think it's the only outcome I think there's also a possibility that um you know that that the ecosystem suffers greatly from this and that um that it actually has the inverse effect and what I mean by that is that it's it's possible that this um this actually pushes Regulators to regulate the entire space as one so putting D5 and centralized exchanges sort of in the same basket and by doing that we're going to create you know better centralized exchanges where this

sort of thing likely is much more difficult to happen um to to to to you know for this kind of fraud to occur uh but on the other side basically like obliterating all of defy um by by make it very difficult by making it very difficult for Innovation to happen there by making lots of use cases also like outside of the regulatory scope um and uh yeah so that that's also like something that I worry about um but yeah I mean we need to keep pushing this narrative that uh Defy is the solution it's the reason why we're here right like Bitcoin was created as a way to exit the financial system and all of defy and the entire crypto project is sort of descending a descendant of that ideology and of that project so you know

we need to you know really keep pushing the narrative and you know I think that there is like one positive thing that comes out of this possibly is um that people build really great user experiences and a lot of the technique like this accelerates the technical uh solving some of the technical challenges and user experience challenges that we've had around defy and actually makes you know taxes much better than taxes uh in in the short term so you know it can go either way uh obviously like I wanted to go like so the positive direction but it's a long road head yeah yeah I mean one thing that I'm honestly looking forward to is having some greater degree of regulatory Clarity around everything that is happening and if I could I think one just problem about being an American working on anything related to crypto is

just the lack of regulatory clarity about a lot of things so at least I think one yeah the same thing yeah yeah it's a greater degree degree of clarity um so yeah I mean difficult to comment on like what the actual um repercussions and like how stringed the regulations will be but I think having greater Clarity is going to be helpful yeah yeah well we'll we'll see what kind of clarity we get um so yeah let's let's dive in and say and um so like what what is what did he say and you know on your website you say it's a it's a it's a blockchain for Capital markets uh I think like yeah infrastructure powering Capital markets and there's one thing that's I that I

hadn't heard yet and I find kind of interesting and I'm curious what it means is you say that say is a sector-specific blockchain and yeah how is that different from an act application specific blockchain um what's what's the real distinction there and how is it actually manifest in the product and like how people use it absolutely yes I mean the story around say is we were recently building that decentralized Robin Hood um and then we started looking into every layer one every Layer Two and all the other infrastructure we could use to get an exchange build um and we realized that layer ones today are holding back exchanges um they have no Dex optimizations they all run into congestion issues which is

tolerable if you're an nft collection for example but catastrophically bad if you're an order book um and they're also a bit too slow even the newer ones like Aptos and sweet and this isn't the fault of the layer ones themselves this is just because exchanges are very unique types of applications that have really astringent throughput reliability and lead to requirements um so after doing that investigation we started building say which is a layer one that is optimized for trading so you basically customize every single part of the stock to help give exchanges an unfair advantage um so if you look at the distribution of layer ones out there right now they basically fall under two extremes on one hand you have general purpose chains like ethereum and Solana um chains that are basically examples of

the biggest chains out there they're the ones that are most successful um on the other hand you have application specific ones like um dydx V4 and osmosis and rather than taking either of these extremes saves building and exploring the design space right in the middle so we're not quite general purpose we're not quite application specific but rather we're use case and sector specific um this helps unlock an entirely unused side space so the benefit of building an application specific chain is going to be the customizability so you can tweak every single part of the stack to make sure you have the optimal infrastructure for your type of application um that is something that we benefit from we're making use of Cosmos SDK tenderman core and we're able to optimize the entire product to help give

exchanges the best possible infrastructure to build on but we're also taking to a degree a general purpose route where we have general purpose smart contracts that are allowed to get built on top of it rather than having say only be an application specific chain um and what this results in is social coordination is the biggest benefit so what I mean by social coordination is you can have multiple teams that are building on this ecosystem and every single team is part of the same community and they help the community grow a lot faster than if the community were just one specific project if it needed to grow by itself and that's why every single project that is a major project out there it it has this social coordination element to it like if you look at the top 10 20 chain

that basically all have some degree of social coordination um and that is the biggest benefit that we get from the general purpose side so um with this sector-specific approach we have customized um infrastructure that is built and we also have uh the social coordination piece where multiple teams can build on sale so at this point we have over 80 teams that are part of the state ecosystem and they're all part of the same Community all helping State ecosystem growth and this the specialization is something that we've seen in web 2 as well um blockchains are essentially just distributed databases so we could look at the database industry for inspiration um it started off very very general purpose with products like Oracle getting released back in the day right um and then it gradually became more and

more specialized so now you're seeing products like databricks Warehouse that are optimized for AI and ML and we think that there's going to be a similar shift in crypto where we started off with these general purpose chains and now we're going to go more and more towards these um specialized chains like say getting built in the future yeah no this um this makes a lot of sense and I you know it's it's funny because I've been putting together a deck right now um where all a lot of these sorts of narratives are are being presented and you know with regards to the the internet you know like I think the internet um evolved when things started to

modularize and we had competition at every layer of the stack right and this is what enabled um a lot of innovation to happen and optimizations to happen and I feel like blockchains are kind of going through that same pattern you know with modularization of the tech stack so you know the data availability consensus uh State and and execution but also the services layer so things like liquid staking things like Mev so there's there's a similar sort of modularization that's happening in the blockchain that in the blockchain space that happened in the internet you know over the last I'd say throughout the early 2000s and you know up until now um really accelerated in the last 10

years um you know what kind of social like I'd like you to talk about this social coordination stuff a little bit more and um what what is what are the kinds of social coordination that we're looking for in this extra specific chain and you know what are the benefits to social coordination that sector-specific Chains would enable so I think there's the community aspect of it and there's also the technical aspect of it um technical aspect is pretty straightforward um if you have everything being part of one blockchain then you can have Atomic transactions that span multiple projects um and I do believe that will lead to substantially greater Innovation than if you have projects that can't interact with each other I mean I think that's

one of the limitations honestly of building in web 2 right now like different companies are not able to necessarily interact with each other in a super seamless way like they generally have to have these massive like um agreements and like I saw like how slow the process was when I was working at Robinhood um in in D5 things can just happen like in the scope of like a day or two like people can set up smart contracts that are crossing multiple projects and like The Innovation space is just much faster and I think that's one of the limitations at least right now of doing stuff is um completely multi-chain um like to adding different app chains um it's that you can't have Atomic transactions so there is like what I mean by anatomic transaction is if you have like two separate parts of a transaction

executing something on let's say project a and then executing something on Project B and if that thing on Project B field fails then you'll roll back that thing on Project a um that's not something you inherently get with um multi-chain transactions in multi-chain transactions cases you will have something happening on uh jna and then afterwards it'll be something that asynchronously happens on chain B and there's no good no good way to refer to State on chain a if what's happening on JP fails um so that's the technical side of it and we think that will enable much faster um Innovation uh the second part of it is more a social piece and if you look at every single ecosystem that is become massive like if you look at ethereum if you look at Solana even if you look at

Terra like Terra is a algorithmic stable coin like their algorithm stable coin filled but they were able to Foster an entire lunatic community that was very very strongly knit um and in my opinion that helps the ecosystem grow not just like linearly faster like if there's end projects I don't think it's going to be linear growth I think it's going to be more perfect exponential growth that happens when you have multiple projects that are all part of the same ecosystem that can all help back ecosystem grow so um that's why I think most of the big ecosystems out there they all have the social coordination element to them um and that's why I also think that sector-specific chains are going to be a lot more prominent in the future yeah I mean with with the technical

aspect so of course when when you're building a chain that has a like contracts living on the same state you're going to be able to have this composability um oh I'm losing yet yeah okay standing desk get it um so you're gonna have to be able to have this we're gonna be able to have this composability um and uh and atomic transactions right so like yeah we're used to this we're used to this in ethereum of course and with the multi-chain uh uh in a multi-chain environment you know those those messages have to pass between chains and then there might be some kind of callback or like one chain might be might be um examining the state of another chain

but it's not entirely impossible yeah I mean like you know with things like interchange queries interchange accounts I think we will get there at some point um and it will feel pretty seamless in the same way that it feels quite seamless today like when you're using an app that's making an API call when that API call fails like you get some message uh or when it works like you get some result right but in the end I think it's it's inevitable that these things will happen all right the fact that we live in a multi-chain world means that we will have changes that talk to each other means that we're going to have to like optimize this kind of the user experience around this um that will be different from you know if you're just doing it internally on your own chain it's like when you're

going when you're on Facebook like you're or any you know any application um that application might have different pieces to it or different services but uh yeah you don't really as a user you don't know there's just something thing happens right um yeah so yeah from from yeah yeah so I I definitely agree that there will be better infrastructure and tooling built up around this in the future I think that right now it is definitely a lot clunkier like it introduces additional latency to the user experience it also it introduces a lot more complexity if you want to have like these callbacks that result in rollbacks happening on like channel for example like if you had a market order getting placed and build on channel then that's updated the entire state of the

order book and there's a lot of transactions that are dependent on that that also got executed like there might be 20 transactions got built on the same market and then you need to somehow roll back the transaction that failed um and then also update the prices did the other 20 transactions and in that same time there might have been second order effects of that like those 20 orders might have been used to do other things so I think it just becomes a very complicated problem um to do we to be doing seamlessly but I I do think that there will be a lot of innovation happening in this space especially is um there start to be larger app chains I think it's kind of inevitable that there will be um more people spending more time to close out this tooling um I think right now this tooling isn't

at a anywhere close to terminal state yet um that's why I also think that it's an application specification um you are going to definitely have better infrastructure than any kind of General uh provision like that is one of the biggest reasons to build an opt-in um I also think it's going to be harder to become as big as a general purposition unless you take more of a sector-specific approach where you start fostering a community on top of your uh on top of your chain yeah yeah so when you were describing you this like monolithic chain application chain sector specific kind of in the middle earlier you know what came to mind is osmosis and like I I see osmosis as an application chain that will probably

tend towards sector specific because they've enabled cosmoasm uh because they're uh and and they're allowing you know they are allowing or they will allow contracts to to deploy there in a permissionless in a permissioned way uh because they're optimizing you know every layer of the stack and making it better for D5 and stuff so I feel like the application chains of today will become the sort of sector-specific chains of tomorrow I wonder if you think this is the case or if you think things will just like remain very specialized I definitely think there will be a push to make something like that happen I I really think it depends on what the specific um thinking behind the community of that chain is um for example with dydxd4 I don't

necessarily think they will open it up to make it more sector specific I think that in dydx's case they want to control the entire experience and therefore they only want to allow dydx granted products people in that ecosystem um in the case of Osmosis we're starting to see this happen and I think that'll happen for other application specific chains as well um I think the fundamental issue with starting off as an option and then migrating over to a sector-specific chain is credible neutrality because as an option you've already built your product and at the chain level you're always going to be supporting that specific product and at the chain level there's also going to be um I guess overarching things that you are trying to aim towards like in osmosis case for example it probably wants to

become like finance and there will be applications that are getting built on top that are now going to be competing against the core decks of the chain and in the future they might be competing competing against the aspirations of what that chain wants to be supporting as well so if you're building a purpose exchange you'll notice on osmosis right now um in the future osmosis might try to launch it on its own prep exchange and that credible neutrality piece is a little bit up in the air whereas if you start off from a purely general purpose or sector specific route um like we're not building any applications on set and I think that it's going to I mean that's one of the reasons why we have over 80 teams that are part of this ecosystem right now because they're not worried about what the future growth is

going to look like and if we're going to be biased towards any specific projects okay is it from fully permissionless so like anybody can deploy there without uh like a governance Vote or or anything like that yeah so we started off wanting to be permissioned um and that is uh what resulted in uh like the first five to ten teams coming on but after chatting with a lot more teams after doing a lot of debate internally um we've decided that we're going to be making permissionless at mainnet Genesis um largest reason for this is we don't want to be limiting the types of applications that you'd be getting built on top of it um for example if you look at nft marketplaces if you look at games um one of the biggest things that they're doing is creating tokens that are then created

um and yeah I mean the entire purpose of say is to be enabling on-chain trading so we don't want to be the ones deciding like what applications are a lot to be getting built on today and which ones are not so we're going to be letting the basically open market decide um so yes they will be fully permissionless foreign what's you know what what what's the risk of like let's say say you know like grows to become massively successful um there's all sorts of applications building there that are kind of in the you know Capital Market sector or like the finance sector and then you know someone wakes up one day it

says oh I'm gonna like deploy my nft market space Marketplace there because like say super fast and I don't know there's like some features that are interested interesting for this and and all of a sudden it sort of gets captured by this industry that you didn't intend it to um yeah well yeah so I guess the inherent question you're asking Blake how do we stop congestion from happening right well how do you curate the ecosystem I mean like stopping congestion is one thing but at a social level it's like how do you sort of curate the experience of and I don't know if that's something you're looking to do but like yeah what's the yeah I mean we we realized pretty quickly that it's difficult for us to be making any significant decisions around

that like we don't want to be saying whether an nft Marketplace should be allowed or should not be allowed because currently every single application in crypto it's the main thing that ends up happening like with these applications they create some type of tokens that then need to be traded um so essentially a lot of things are very popular in crypto right now like everything related to D5 also think it's related to nft marketplaces and like games are also built up around exchanges like they all need some um infrastructure to be trading on so we're not going to be excluding certain types of applications from getting built on say foreign SEC here but you know at some point like I think the thing about application

specific chains that that um you know it that is the advantage here is that you know whatever happens like they can always like the the number of transactions will always be sort of limited to that application and you know um you can optimize that blockchain to uh have the highest amount of throughput for your application but you're just dealing with you know one application space uh and no no one's competing for the bandwidth um you know what we've seen is we've seen this problem in ethereum where applications are competing for bandwidth uh for transactions uh for for transaction throughput and even though shortlist like 23 000 transactions per

second as you say on your website like Fast finality what's the strategy if it becomes massively successful and then you know those limits are starting to get pushed are you thinking about like what is it like a layer are there like layer twos or you start building your own ecosystem or what's the strategy here yeah so a couple of thoughts around that um I guess first of all we one of the reasons we decided to make use of Cosmos and tenement is because it's extremely modular so we are we've already done a lot of work to help basically push the balance for a cause unless the tenement can offer um in the longer term we can try to replace certain parts of Cosmos and tournament for example changes the consent changing the consensus mechanism um or changing the mental implementation

to give us higher throughput that we can support um so the core idea over there is the first approach would be to try to vertically skill and take the current infrastructure that we have and make that better so that we don't need to horizontally scale in any way um then at that point the second question becomes like with any ecosystem there ends up being a point where like you're just capped off at the amount that you can go vertically um then at that point you have to grow horizontally and then the question largely becomes like what is the kind of access patterns that you're seeing in the current ecosystem and like what do they need to grow so for example if you're seeing a lot of applications that are not necessarily composed with each other it might be okay to have a sharded architecture where you have different

charts that are don't necessarily need to be atomically composing with each other and that ends up being a very simple way to scale um where the main Cosmos uh like where the main cha becomes similar to Cosmos Hub um and then there's consumer chains to get pulled out the other approach that we're exploring is having rollups getting built and we're already seeing a roll-up getting built on today right now um that's called Nitro that is a svm optimistic roller so it's basically like autism or optimism yeah um except it's running the Solano virtual machine so sea level um so we're already seeing examples of that happening onto it um and it's difficult for me to comment exactly which approach will become more popular in the future um but there's I think a lot of it will depend on the access patterns but

there's a good amount of thinking that we've done to our side yeah that's interesting yeah the Nitro team I I I have them on my radar I wasn't thinking should I get them on should I speak with them or not um do you so you think it's interesting what they're doing yeah yeah so one of the things that we noticed from our side like when we started chatting with folks that are um building D5 applications building trading applications in other ecosystems um there were a lot of Solana teams that were interested in coming and building in the cosmos space uh the only thing that was preventing them from doing so is they needed to take their um Solana smart contracts and convert them into cause and Watson smart contracts and there's a lot of lift that comes with that like even though they're both in

Rust it still requires a substantial amount of time to uh have it fit the cosmos certifications and you also need to get it audited again which requires more money um so if you could just seamlessly deploy to your audited contracts in the cosmos ecosystem that would be huge and that's why Nitro started building on an sem roll up because it makes it extremely easy for Solana teams to start building in the cosmos ecosystem um and yeah I mean they're still very clear demand from Solana teams to start to expanding to other ecosystems right now okay yeah I think I'll reach out and get them on at some point um cool so yeah let's let's dive into the technical stuff so uh the your doc says there's a twin turbo consensus engine uh with uh

intelligent block propagation and optimistic block processing so I don't know what that means uh the native order book matching engine um and you know you guys have optimized tendermint and there's like this parallelization so yeah let's let's walk through all the different uh technical optimizations uh that that you guys have built foreign layer one blockchain uh with this own validator set so we are not making use of any kind of shared security um we initially got started by building with the cosmos SDK and tenement core um at this point we have forged both of

them to give us better performance for what we're trying to build um now at a high level there are three things that we have done the first is to interval consensus um so we basically took tender mint and worked with the cosmos team worked with saki to figure out how we can make it faster so now it's the fastest it can possibly be um we're seeing lower bounds of 300 millisecond up times in our internal test net and tender inches cannot become faster than uh currently is right now um the second thing that we've done is we've added in parallelization so we're currently the only Cosmos chain to make use of parallelization and this has helped us substantially improve throughput as well um and the last thing is we have a native order matching engine so this helps prevent front running it helps

exchange its skill um and it's just a primitive that's built into the chain that exchanges can make use of to very easily deploy um so is this the only primitive that's in the chain or are there others as well like other kind of financial Primitives uh this is the only financial primitive that's in the chain so there's other stuff that we've built out as well like native priced oracles for example but I don't think that's the same same experiences and when you say it's native like it's it's a cosmos SDK module or it's like it's it sits at the application there it's not causing modern contracts uh the native priced Oracle and the order book uh the order of matching engine those are both uh SDK modules that we've implemented okay okay and through all these changes that

we've made we're seeing in terms of like the performance stats we're seeing a lower bound of 300 millisecond time to finality in our internal test net and we're seeing an Upward Bound of around 22 000 orders per second that we can process um in our internal test net as well all right like how does this consensus work yeah what's what's different about this consensus yeah let's do let's do a deep dive into um yeah yeah do a few things like vanilla tender mint versus uh say tender uh twin turbo yeah so there's two things that we've done with twin turbo um first is we've changed the way the blocks are propagated and secondly as we've changed the way the blocks are processed so I can go over both of them um for Block propagation the way that things normally work with tendermint um is that there will be a block

producer and they will construct an entire block that'll have full transactions inside of page so let's say there's transactions ABC it'll have the entire concepts of transactions ABC inside of that block and then it'll break that block up into chunks and then send it over the network and then validators will be waiting and then they'll receive the different chunks um that have the full content of transaction ABC the only problem here is that every validator has a local mempool and what generally ends up happening is all the transactions in the block they're already there in the validators local Med pool so because of the gossiping layer the other validators they will probably already have transactions a b and c in their event pool so it's extremely inefficient for them to wait to receive transactions a b and c over the network um rather than just being told that like

you should just look at having a very succinct identifier for transactions a b and c um so what we've ended up doing is we've changed the way that blocks uh it's like is this like segwit this is a segment that works like this in Bitcoin uh I think that this is similar to what Bitcoin uh at least the proposal that came out in Bitcoin and I'm not sure about this specific stuff Segway okay yeah sounds familiar sorry go ahead go ahead yeah yeah so um yeah so the block uh proposal message now will just have transaction hashes for a b and t um and then the block uh the validators they'll receive this block proposal um and they will then make use of uh

they will construct the block locally rather than needing to wait for it to open the network um so we saw pretty substantial performance improvements by doing this um the second thing that we've added in is optimistic block processing so the way that optimistic block processing works is normally with Cosmos and temperament you have to go through the pre-vote step and the pre-commits that before you start to process the block um and this is definitely inefficient because most of the time the block that is proposed is the one that's being approved so what we started to do is we have validator spin up a concurrent process so they'll run some basic sanity checks on a block they receive then they'll spin up a concurrent process and they'll go through the voting steps as normal but this concurrent process will be updating a candidate today so it'll

start executing the block and updating candidates it and at the end of the voting period if that block is approved that candidate state will get committed and if that block is rejected then that candidate state will get discarded um and we only do this for the first lock at any given height so if the first lock fails then for subsequent logs in that height um we will not be optimistically trying to process it to prevent validators from getting just overloaded with trying to run too many concurrent transactions so we also saw pretty substantial performance improvements from doing that and both of those two things make up um optimistic plot processing or make up twin turbo consensus okay so the the block propagation if I can summarize this uh so validators you

know like received received transactions to the mempool when they would typically in vanilla tournament they would construct that block with all the transactions that means that the block um you know like quickly grows in size because there's all the transaction information meanwhile that information is already uh already exists on all the other validators uh mempools um so instead of having the entire transactions where the blocks are only being propagated with the hash of those transactions hoping that the other validators have them and so they match them up whenever um whenever they uh whenever they receive them uh whenever they receive the block um what happens if like let's say there's

some latency I mean like I realize in 2023 you know the validators are quite professional they're usually in data centers with high availability fiber connections um what happens if transactions are not uh equally problem across the network yeah yeah so yeah that so the happy path is the transactions here in the middle um the unhappy path would be where validators don't have transactions ABC in their mempool so in that case we still have the block producer like they will send the proposal message that has the transaction hashes inside of it and then they'll still construct a book and then send it over the network to the other validator so if you're a validator and you don't have transaction a for example um you can just wait and you'll get the

block parts and then you can just construct it using the same approaches you would be using with normal tendermen okay so there's like a failback mechanism so it sends the block uh with the transaction hashes the sort of optimize block um yes valid or is any organic get that thing first because it's small because it's lighter and smaller um but yeah basically so some short amount of time later they'll get the real block or the phone yeah exactly so it'll be the block proposal message that has a transaction hashes so the proposal message is always the first thing that gets sent um and yeah with normal temperament it would just have a trend a block hash inside of it in our case we add additional data to it so we add the transaction hashes inside of it um and then the other part of it where

you send the entire block over the network that part does not change but validators can just construct the entire block locally as they as soon as they receive that proposal message okay interesting so do you have a sense of whether or not these sorts of optimizations would get Upstream into vanilla tender mint as a way to optimize it or um yeah absolutely so that's one thing we've been chatting with uh Marco about so we'll we'll figure out I mean all this is already open source so if anyone wanted to they could Upstream it themselves otherwise we'll be working with the customer stream it after we launch mainnet okay

and how does this fit into like I'm not super familiar with what's going on here yet uh I'm hoping to do a podcast about this but like what's your sense of how this also fits into like the whole tendermint to heterogeneous paxos you know um thing uh yeah I don't have too many thoughts about that right now so I need to chat more I can also assume to figure out how those would work together okay cool and so you yeah so you've you've forked um the cosmos SDK and um yeah so there's so yeah that was the first piece around

twin turbo consensus um yeah the second piece is around parallelization which we can get into as well unless there was a yeah yeah let's let's talk about that yeah I'm curious about that as well okay yeah so um normally the way that a lot of blockchains work is they process transactions sequentially so if there's five separate transactions then each one will need to be run one after the other um and this is inefficient because a lot of times these transactions they are not mutating the same state so you can be running them at the same time so if you're running all five transactions at the same time it'll take less time for that block to get processed than it would if you're running all five of them one after the other um so the idea of parallelization is pretty simple

um it's also something that's been extremely common in web 2 um and currently no other Cosmos chain makes use of it um because I guess the the main the main reason why you would use parallelization is if you think that your um CPU Bound in terms of processing time so if you think that a lot of your time to finality or block uh block time ends up being tied to how long it takes to process something so there's some change that have come up with solutions for this and there's essentially two different cancer Solutions one is the solution that is the cell of what Aptos is doing um so this is where you try to run everything in parallel initially and then there ends up being conflicts and then you rerun those conflicts sequentially um I'm personally not the biggest fan of

this approach because if the overall goal that you're trying to do is optimize for performance um having to rerun things leads to worst performance and what typically ends up happening in any ecosystem or in any changes there ends up being hot spots of activity for example on ethereum it might be stuff like uh unit Swap and open C contracts that end up getting uh a lot of traffic so a lot of the stuff that you try to run in parallel will end up having conflict anyway and then you'll need to run that sequentially um so then the other approach is where the dependencies are defined up front and then you construct some kind of access list when that block is being processed and then afterwards you will run that and um this has the additional complexity where the developers need to define the

dependencies up front but it does result in better performance at the processing level this is similar to the approaches that Solana and Twitter taking um I'm sorry do you have a question no yeah I mean like I'm not very familiar with how uh Aptos and sui process transactions but so the the the idea here is that you can process transactions in parallel rather than sequentially so can you give some like a concrete example here um so I think I've sort of figured I I think I sort of get it but I'm not entirely sure yeah so let's say there's me and you and then there's two other people let's say I'm trying to send some say from my account to your account and

then these two other people you have person C kind of send say from their account to person T's account um so with sequential processing first it'll be my me sending queue that happens then afterwards it'll be person C sending to person D um these are independent events they can be run in parallel so it'd be faster to run them in parallel so what happens with say is we have dependencies getting defined at the chain level um that'll then get filled in at runtime based off of what is actually happening so in the case of this bank send um there will be the the resources that will be updating are the fourth hour bank accounts right so it'll be my account will be getting updated your account will be getting updated in person C and T's account um so at runtime at the chain level

there's a template that's defined so it's basically saying for the bank send message there's a template that'll get filled in that it looks at both people's accounts um and then at runtime it'll get filled in with all four of our accounts and then a now we know that these four accounts are the ones that are being touched so then an access list can get created and since there's not the same accounts being touched both of these transactions would get run in parallel now let's say there's another transaction um there is person C sending something to you and let's say that the ordering of transactions within the block is first I sent to you then afterwards C sensity then afterwards C sends to you then in that case we know that there are there's a dependency the dependency over here would be that transaction from C

sending to you can only run after I'm done sending to you and after C is done sending to D so in that case the access list would get created where you have the two parallel transactions initially of me sending to you and then to you sending to D and then afterwards there's the other transaction of c-standing queue that is dependent on the two earlier transactions so we basically have something like that getting constructed at runtime okay and is is there an opportunity like to to like I don't know front run transactions here where you could potentially be executing a transaction like on some other part of the chain whereas like this part of the chain thinks that

it's perfectly fine and like there would be some conflict or no so that will be everything is fully deterministic there's no possible way to do that with the currency implementation um and that's because there is a pretty clear order ordering of transactions within the block so as long as that ordering has been defined um the processing of it will be completely deterministic so you still need consensus on the ordering the transactions within the block and then at the execution layer you will be able to process and parallel and when you say that it's being paralyzed and like the processing is being paralyzed you're talking about like actual validator nodes and how they process these transactions on their CPU that is at that level it's at that level exactly okay

so that that optimization um like that creates enough optimization to be significant like yeah yeah so we're still running low tests on this specific piece but we anticipate it to be very significant when there's a lot of different types of messages coming along so a parallelization ends up being useful when there are parallel fertilizable workloads so if you have everything going through one smart contract then the effects of parallelization will be minimal but if you have a lot of different activity like different types of activity happening in ecosystem um then it will be pretty substantial in terms of the performance improvements um so that's one type of work that we've

done which is deliver TX parallelization so that's what we were just talking about like in the cosmos SDK the way that you will be processing is it'll be a begin Trend or begin block stage then there will be a delivery tax stage and then there will be an in-block stage so the delivery TX stage is where all normal transactions get processed and then you can also Define additional functionality it began block and unblock we actually have two types of parallelization we have stuff at delivertics and then we also stuff have stuff at the inbox stage um so in the case of say we wanted to make use of frequent batch auctions which we can get into later but basically basically the native order matching engine runs at the end of the block and because of that we also have parallelization happening at the end of

the block where independent markets will be getting run in parallel with each other so if you have like ACA spot market and then a Bitcoin perks Market they're not dependent on each other at all um they will also be getting run in parallel and uh in that case as well it's the same kind of idea where if you have different markets a lot of different markets that are being processed that'll lead to substantially improved performance if you basically only have one market where all of the activity is happening then the performance improvements will be minimal hmm okay yeah that's interesting yeah I I had I hadn't considered that you know at the validator level parallelizing transactions was such a performance of improvement but I guess yeah I mean if you're running like

a blockchain that has like tons of transactions and you can parallelize some of those I suppose then you can produce blocks much faster uh exactly so just to just to be clear this isn't the execution stage that it's being paralyzed so validators will agree at the consensus level the transaction to the VCR are getting run in this order and then when they're actually executing it being able to deterministically paralyze the transactions will uh improve performance if there's paralysis add execution yeah yeah so on on state transition essentially exactly yeah okay yeah yeah that makes sense yeah cool um yeah let's talk about this front front

uh front running protection uh what's what's the approach here yeah um so say it's a native order matching engine which runs at the end of the block and there's a couple of things that it facilitates one is front running prevention the other piece that we can talk about as well is order patching um so around front running prevention what would normally happen when you're processing transactions is they would be getting one one after the other um in the case of say what we do is we aggregate all these transactions together at the end of the block and then we execute them at the same time so uh the execution price will be at a uniform clearing price so it's going to be a price that is the same price for everyone so to make this more clear let's say that the order book has two

sell orders on it um let's say one sell is for ten dollars the other sellers total eleven dollars and then two Market orders come in to buy that asset um and let's say that all of these are one unit each so what would normally happen with sequential processing is the first order will get filled at ten dollars the second order will get filled at eleven dollars so the ordering of transactions within that block matters if you're first you'll get a cheaper price sample um with frequent batch auctions they both get filled at the same price so they would both get filled at ten dollars and fifty cents so the market orders would get a more fair price within that block it also makes it so that the ordering of transactions within that block no longer matters um and whoever has placed limit orders those makers would be still getting the

exact prices they wanted of ten dollars and eleven dollars um so we we are making use of frequent badge auctions for this processing at the end of the block and it'll help prevent any front running related to um order book transactions within the scope of a block um does that kind of make sense so far uh sorry you're muted yeah yeah it makes sense I'm wrapping my head around it so um yeah and so how does this fit into your say broader like Mev strategy because you know some some chains like osmosis have one you know one or wanted to internalize a lot of the Mev at the chain level others are landing markets

kind of decide how any of these should be distributed um what's your strategy here yeah so the first approach the first line of thinking we have is we should try to prevent all negative types of Med as and when we can that leads to the best user experience so that's why we've added in frequent batch auctions to help with front running prevention because that will help prevent this negative Med now we also realize that it's impossible to completely prevent immediate um first of all there are some types of negative Mev that validators can still do one example would be multi-block front running so in the case of this order book example um if you have validators that control three blocks so if there's validated occlusion they control three blocks and you submit a transaction to purchase an

asset and let's say that asset is ten dollars and you accept up to five percent flippage on it so you're willing to buy it for up to ten dollars and fifty cents um a validator could see that and then they will just exclude your transaction in block a and they will put in their own Market order to buy that asset for ten dollars then in Block B they'll place a limit order to sell it for 10.50 and then Block C they'll include your transaction in that blog so your transaction will get built in 10 dollars and fifty cents so that's an example of multi-block fund running um we are going to just comment in is this common for uh this is like a common MPV strategy in say like ethereum or other chains uh I I don't think it's I don't think multi-block strategies are that common

yet uh they're substantially more complicated um I I think in the cosmos ecosystem as well it's not common um however with that being said like this is a theoretical approach that could happen and once there starts being greater um just volume of activity happening it'll become more and more profitable to be trying to run strategies like this so because of that like one thing that we're looking into is randomizing block proposers so right now with Tinder mint it's deterministic to know who the block proposer is um there are other changes that have made use of logic to randomize that uh entire process so that's one thing that we're looking into as well that can help prevent that type of negative Mev um but for anything that's not related to the order book for example if there's like an amn built on say um we can't prevent front running on

that and then there's also other types of Mev like liquidations and arbs that are generally considered to be positive for the ecosystem um and we would want to prevent spam tied to those types of me because what example what happens on Solano for example right now um is that if there's a liquidation or an ARP that is extremely profitable a bunch of people notice it and if you have to pay a fraction of a penny to get a new transaction it's extremely profitable for you to just Spam the network with as many transactions as you can to try to be the first one to win that liquidation or our opportunity um so we rather than having like that be the default mode where like people just try to scan the network um what we want to have happen is something a system similar to flashbots

on ethereum where there's off chain auctions that happen um and these off chain auctions would be people submitting private transactions and then whoever submits the highest bid will win a specific opportunity for example win a liquidation or win an ARB and then that off-chain node will submit a prioritized transaction bundle um to the core like whoever the block producer is going to be um and then from there that block producer will just make sure that uh that transaction gets prioritized that bundle of transactions get prioritized and then there will be me redistribution housing as well so whatever the bids were that were submitted to these off-shan nodes you'll get redistributed to values and stickers uh that's what we think will happen in the longer term

um I'm also not the biggest fan of having in protocol Meb um specifically like the idea of say having logic getting run after every single transaction you try to ARB across different markers for example um I personally think that that'll lead to additional complexity of the chain level and that will discourage sophisticated Market participants from coming in especially when the like when you have these off chain auctions happening anyway um that'll result in most of the Meb being redistributed to validators and stickers so being redistributed to the chain um so I think that there's less upside tied to an approach like that per se specifically okay so you so um

yeah I mean like what one thing here like Mev is not a topic that I'm like very familiar with like sort of at a high level so I mean I understand that there's you know there's what is considered kind of good Mev and what is considered bad Moody and then there are there are chains that have the approach of wanting to internalize all that Mev or internalizing the bad Mev or kind of minimizing the ability for the market to um execute on the bad me view while leaving Market participants the ability to um to compete on the good Med or you know like uh non-value extracting Mev or whatever

uh and then there are chains who are just like you know do do what it like Market participants can capture all the Mev and I think this is really the kind of the ethereum flashbot approach um where basically it's all up for grabs um you know osmosis would be sort of on the other end of that Spectrum it sounds to me like from what I'm hearing um there's there's a desire to uh capture some of the quote unquote baton EV while leaving uh the rest of it up for Market actors too so what I would prefer is for there to be no bad I mean Beyonce and we'll do it our weekend to prevent that from

happening um yeah we also think that validators in the cosmos ecosystem to an extent are going to be like because their reputation is on the line on every single chain that they're validating on um I think it's going to be less likely for them to engage in that Mev um with that being said it's still a possibility like there's nothing we can do to prevent it then it makes the most sense to have that get redistributed to uh the chain rather than having that go entirely to whoever infrastructure is that identified that opportunity yeah I think the question here encourage me if I'm wrong the I mean the issue is that it's yeah sure there's a reputational risk but um it's very difficult to identify when

uh a validator is in fact um trying to capture the bad muv is that like yeah so unless you're doing like an audit of their software yeah yeah you're doing like a one-off like noticing a little one-off case is going to be more or less impossible because you don't actually know what transactions the validator had received in their mempool when they were choosing to order those transactions um but it's definitely possible to start seeing patterns of behavior and I think that's what a lot of these um audits that have been performed retroactively to see like how much any reviews they're on ethereum or like how much mebs they're on osmosis um I think that's one of the things they look for as well but yeah in the case of like a one-off thing um it will be difficult to identify that

okay uh I I heard somewhere that and I haven't confirmed this so this might be just just rumors or hearsay but I I heard somewhere that osmosis was discussing um penalizing validators that run uh Meg software um I don't know if you've also heard this I'm I'm not familiar with that no I have not heard then let's just forget I said anything uh yeah so yeah let's talk about this this order matching engine um what's what's that look like and how

can applications building on say leverage it yeah so it is a primitive that is built into the chain level so it's an SDK module um and if you want to build an order book Base Exchange on say you can make use of that module and in your smart contract you just need to define a few functions around how order placements order matching order um basically settlement would work and then you can very easily easily deploy that to our contract and then say we'll handle the rest of it so say we'll handle the entire process around order matching it'll be storing all the states tied to the order book in the chain itself and it'll also be handling um settlement to funds once uh depending depending on the behavior that you've

defined so it makes it very easy for you to deploy these smart contracts and also make use of frequent batch auctions under the hood um so that any smart contracts you deploy that you want to be making use of with this order matching engine um will help prevent order book related uh front running from happening hmm interesting so at a high level this is a cosmos and chain right we haven't talked about this but I presume applications are building using cosmosum yeah so in the longer term we envisioned that it'll be completely language and execution environment diagnostic like in web 2 no one really cares about what language you're using whereas unfortunately it's extremely critical

right now in what three um so to get started we are making use of only cosmosum but in the longer term we envision that there will be multiple execution environments supported at the chain level really interesting okay so you know you could have cosmosm as a module you could also have like you know etherment and and any other um Cosmos SDK module that's our execution module exactly so yeah like um I guess the obvious one would be evm to get started with and I mean under the photo it's really happening with like the evm module on hypnosis um it just creates Cosmos SDK messages and then these messages are interoperable if you're able to Define behavior with other possible authenticate messages so we can make uh that evmb interoper pull with the rest

of the chain and be in trouble with the order matching engine um then we can also do that for other types of um execution environments like I think SVN and move VM would be two of the other big ones right now but whatever ends up being popular in the future it is possible to support that um the only downside is it ends up being a non-trivial amount of work to build it in at the chain level um so I think that that would be the biggest thing that would potentially slow down that process hmm yeah sorry in the interest of specialization um I mean isn't there a case also to be made just to have one execution environment or like a very specialized

execution environment and also probably in the interest of composability and um and having reusability of code um yeah so I mean for composability that doesn't necessarily get hurt if you're like the really good benefit of making use of Cosmos as you can tender Mentor is that you have complete customizability over every single part of the chain um so you can still have composability between smart contracts like if everything under the hood is just becoming a cosmos message um but yeah like the other point that you're making around potentially having um only one execution environment and then just spending all of our time trying to optimize that execution environment

um that is one thing that we thought about the the other kind of line of thinking would be we want to make things as easy as possible for developers to be building um because all developers they really want to do is focus on building things and we can just handle the rest of it to make that infrastructure as scalable as possible and I think that's going to be the approach that results in the most developers coming on if you make it as easy as possible for developers to build on that ecosystem so that's that's the approach that we're leaning towards right now to just make it as seamless for developers as possible okay yeah so who's building like I I was on your website and saw that there's like an ecosystem page and there's like tons of applications here um but yeah yeah so many teams building on

say yeah yeah so we originally got started with the project earlier this year maybe we launched our initial um testment and then around August time brand new frame is when we launched Jordans on device testnet um at this point we have over 80 teams that are building on say a half minute um and these were originally teams that just got started building dexes that are making use of the order matching engine but now it's a lot of different types of applications that are building um we have some nft marketplaces that are interested in building as well we have a lot of core D5 Primitives getting built and we are now starting to see some more native teams that are trying to build um I guess unique applications don't say they're not getting really built

anywhere else um so yeah over 80 teams building right now we also recently launched an ecosystem and liquidity fund uh so this is a 50 million dollar fund that market makers and investors are uh have put money into that uh will basically be used to provide liquidity to exchange its building on today it'll also be used to invest on projects that are building on today so once we announced that it became much easier for Native teams to start building because there is a pretty clear path for them to be both getting um liquidity and also getting uh funding and yeah so we're starting to see a lot more middleware type application so one of the projects that announced recently is Cargo um and that is a prediction markets Middle where they're just building

Homestay so basically other projects can come and build their own prediction markets on top of it and it becomes very easy to um have geographically specialized prediction markets getting built um okay interesting yeah folks should go to say network.io ecosystem is a whole list of apps here so I see you have like a derivative text was a synthetic Stacks you know obviously things like axlr um are are integrated here so people can Bridge their tokens in and out if they're not using IVC you have cargo this like kive [Music] um yeah so I mean I had the kive team on a

couple weeks ago and um I was curious what is the yeah what's this partnership that you guys have done with kaiven um what's the uh what's the play here how is Kai providing like their infrastructure to say yeah so one of the so we have a native um Oracle that is built into set the way that type would be helping would be providing one-off price feeds that that Oracle doesn't help with so the way that the native Oracle works is validators they will be required to submit price feeds for governance approved assets um if the validators submit a price feed that is um wrong or if they submit a price or they just don't submit a price feed they'll be getting slashed so we

anticipate that this will be really good for certain types of assets but if you're running a prediction markets for example and you want to get the outcome of a tennis match it's not really appropriate for the native price Oracle to be supplying that information um so rather than doing that we're we're working with kaive to help facilitate those kind of um price feeds or um outcomes for different events so that is one way the Clive is going to be getting involved with say okay that's cool yeah I really like this this project I think it's super cool I mean I'm a big fan of permanent storage stuff and um I just think yeah like they're just they're just killing it um yeah very cool um yeah before we wrap up here like what's the long-term Vision because one of the like when you first got on the

say website it's like okay this infrastructure powering powering uh Capital markets and you guys want to be like a decentralized NASDAQ and you know there's the the the narrative feels to be I mean I I don't know if this is this is what you're looking for but there feels to be there seems to be this kind of institutional attract like you're trying to attract folks that are looking for a very professional chain perhaps even institutions um is is that the case and you know if if so like who's who are you targeting with this chain what kind of applications do you hope people will build there uh Beyond you know year-round in the middle kind of D5 dgn app yeah so I mean our our mission is to

build build the best possible infrastructure for exchanges um our long-term goal is to have say be the primary place where on-chain trading activity happens um and this is not just restricted to retail we want it to be the primary place where other types of uh players also are primarily trading so for example institutions um but realistically though like institutions are never the first movers um it's usually retail and power users that come over first and once it starts to be organic retail volume that's when institutions start to come over so what I anticipate will end up happening is there will initially be the more Degen power users to come over from other Cosmos change to come over from Solana and ethereum like d more uh on chain native folks that'll be the first Toronto people to come over

um afterwards I anticipate that there will be applications on say um that become very popular for retail to using um for example prediction markets could be one of them or it could be perps or something else um that'll result in more retail users coming over and then afterwards we'll start seeing more institutional adoption so I don't think it's going to be like a two-month process or anything I think it'll be definitely a pretty long-term process but um I think long term that's the most likely way that there will end up being a lot of content to be happening cool well um yeah thanks for thanks for doing this thanks for coming on and uh it's been really interesting diving deep here and um I'm really I'm really curious where this whole twin turbo consensus stuff goes and if it gets if it gets sort of

added into uh into the cosmos SDK stack and you know I think that would be really beneficial for the for the entire ecosystem and yeah also looking forward to seeing what other kind of applications uh get built on say um yeah what's the road map and where can people go to learn more and what's your call to action yeah so call toxin would be join our uh follow say Network on Twitter so that's s-e-i-n-e-t-w-r-k um that's where we're going to be posting a lot of updates afterwards you can also join Discord to get more involved in the community um in terms of the roadmap right now we are in an incentivized testnet and we're giving away one percent of the total token supply for incentivized tested participants so anyone that's listening

to this um if you want to get involved with say you will be awarded for doing so as well um so definitely check out Discord awesome yeah check out the Discord for more information on that um and yeah we're planning to have a mainnet launch happen sometime q1 of next year uh so stay on the lookout for that as well we're code complete from the say lab site at this point we'll get the code audited and then afterwards um there'll be a decentralized launch that happens sometime next year great and final question who do you think I should have on this podcast uh you were mentioning the Nitro team so I definitely think you should have them on I can make an intro to you afterwards as well if you if you'd like okay cool all right Jay thanks so much for coming

on awesome thank you so much for having me on sir and to our listeners thank you for tuning in we're a couple of people in the live stream today so uh thanks to you guys and thanks to the specifically I want to thank those who are coming in like every week you know because I I see you guys a lot in the chat and um yeah just want to say thank you to those who've been following this process this process and helping me grow the channel um please make sure to subscribe hit the like button and the notification Bell to get notified because we will live every Thursday and we got another podcast lined up next week and the week after that and week after that so all kinds of great content coming out here on the interop as we wrap up the year so thanks

so much for joining and thanks Jay once again and we'll see you next week