**A** (00:17):
We are live. I'm Seb 3.0 and today I'm speaking with my friend and Epicenter co host, Sunny Akarwal. He's also the co founder of Osmosis, the greatest dex in the Interchain. And we're going to be talking about a whole bunch of things today, starting with mesh security and how it aims to radically shift the security model in the Cosmos. We'll also talk about the Osmosis ecosystem, permissioned Cosmos contracts, and Atom 2.0. Why he's not so bullish. Before we get started, make sure to subscribe, hit the like button and the notification bell to get notified when we do new live streams every week. My guest Sonny Agarwal is coming up next right here on the Inter. Hey, Sonny.
**B** (01:21):
Hey.
**A** (01:24):
Welcome. Welcome to the Interop for the first time. I mean. No, actually, I mean, you were kind of on the Interop at Cosmoverse, but yeah, but like actually properly doing you as an interview. So. Yeah, thanks for doing this and I think it's gonna be interesting. Thanks for the intro.
**B** (01:40):
I'm just gonna say in the intro, I never said I'm not bullish, Adam 2.0. I actually am bullish.
**A** (01:46):
We gotta get people hooked, right? You gotta make it spicy. Yeah. So what's going on? How you been since Cosmoverse?
**B** (01:56):
Good. Been getting back to reality a little bit. You know, took like a. Took a few days off after Cosmoverse. Just went, you know, around Columbia a little bit. And then, yeah, this week we're having. A lot of. Our team is here in Berkeley just grinding away on a bunch of stuff. Trying to get a lot of cool features shipped by end of year.
**A** (02:23):
Yeah, well, let's. Let's dive into some of those cool features. Yeah. By the way, I mean, like, what was your kind of takeaway from. From Cosmoverse? Like, you know, two. Two weeks, two weeks out now. You know, the dust has settled. What. What do you. What do you think?
**B** (02:40):
I think just, you know, a lot of really cool growth in Cosmos. Definitely a lot of people interested in, like, I think a lot of the projects that are building stuff on top of Osmosis are really, like, starting to get to the point where they're almost ready to deploy. Now you have like, Mars and Levana and, you know, a lot of these, like, A lot of these projects are like, really, like, you know, I think we're gonna, in the coming, like, month or two, we're gonna start seeing a lot of deployments happening really quickly. We're already seeing that some of the, you know, a lot more contract deployment proposals going on to osmosis these days, so. Yeah, so just excited to see those. And then otherwise, you know, I think just been a lot of interesting discussions around Atom 2.0 and stuff. I think like the. It. I feel like it more. It's a little bit more controversial than I. I guess I had originally expected it to be.
**A** (03:33):
Yeah, me too. Yeah.
**B** (03:36):
And then I think just in general, everyone seems really excited about mesh security as well, so. Yeah.
**A** (03:42):
Yeah. And I think it's interesting that we have really kind of two visions here that I think aim to achieve similar goals, but that are just in the implementation so different. And yeah, I do agree that it feels like Since Cosmoverse Atom 2.0 has just monopolized the entire. All of the attention in Cosmos, like, everyone's talking about it. We did, we did a podcast here like two days ago, kind of debating from the community side and from the hot side and lots of really interesting insights. And like, I see people, like, people are sharing, like here I'm gonna publish this blog post about Adam 2.0. Like, what's your feedback? And like, everyone's kind of like trying to position themselves about, like, how they. About their. Their opinions of the. Of the proposal. And I think, like, the main kind of takeaways for me is. And that maybe I. I think. I think the icf, like, okay, first of all, like, you know, this is a huge document. You know, like, a ton of work went into this paper. You can't discount, like, the amount of work and research and, you know, that went into this paper. So, like, you know, the, the authors definitely, like, deserve some, Some. Some praise for that. Um, I think where, where things failed maybe. And you know, I want to say, like, in true ICF fashion is like, the communication around it wasn't great. And particularly I think that they. I think. I think they kind of failed to make it clear that this was a signaling proposal and like, this was meant to spark a discussion rather than like, this is a thing that should be taking at face value and then we're going to implement it. Like I was saying on the podcast, like, Zaki's talk should have had like, draft written all over it, and the paper should all have, like, draft written all over it. And it should have been like, this message should have been just like hammered. Like, hey, this is. We're putting this out there now we're going to talk about it, which is exactly what's happening. But just like all of the kind of, you know, negative Feedback and pushback I think comes from. Yeah, this, this kind of weird, you know, feeling people have, I think in regards to the ICF and like how, how it communicates and it's not so transparent. And you know, I really hope this changes, but I feel like that was kind of a missed thing, you know. Yeah. Anyway, so, yeah, let's talk about mesh security. You guys implemented it or at least you implemented like, well, a, a, a, a, a preliminary version of mesh security at the, at the hackathon right after cosm.
**B** (06:23):
Yeah, very proof of concept.
**A** (06:24):
But yeah, but there's a repo, there's code, there's contracts and people are contributing to it. Yeah. What's mesh security? For those who missed the talk, we'll link to the talk, but give us a high level.
**B** (06:38):
Yeah, Mesh security is this, it's kind of the entire point of how Cosmos shared security was designed from the get go, which is like, you know, we want, you know, we've always been building up this world of sovereign app chains and now it's time for, you know, we need to get more secure. You know, everyone, every time we talk to someone about this app chain vision of like, hey, you know, a dex app chain, a lending app chain, you know, gaming app chain, all these things are going to happen. And then people are like, what about the security of these? Like, you need an L1 for security, you need base level, ethereum level of security. So that's always been like a question of like, oh, how is that going to happen in these app chain world? And the answer now that we have is, well, all these app chains are going to secure each other. Any one app chain might not have the same security as an L1 with base moneyness and stuff. Right. But all the app chains together will have enough security. So, you know, the example, you know, I gave was, you know, if you look at like the market cap of the highest money asset, it's gold, right? It's like $11 trillion. But the market cap of the 10 biggest companies, like stock market caps added together is actually more than $11 trillion. So this like the, the sum market cap of all the app chains companies is higher than the money, which is gold. Right. And so I think that we can get higher economic security by all these chains pooling security together in almost like a NATO style model. Right. NATO is like sovereign countries. Like, you know, France doesn't go intervene in, you know, the UK's internal politics, but it's, it's a mesh of security alliances that if any one country gets attacked they all rush to each other's defense. And so this is kind of how chains will work as well, where they all are sovereign, have their own governance systems, but they should all be like sharing security with each other in a mesh system. And not necessarily all chains share security with everyone else. What happens is chains share security with the ones that they have economic dependence with. Right. And so an example would be Osmosis and Axelar. So Osmosis makes up over 70 of Axelar's entire TVL right now. Meanwhile, four out of the top 10 assets on Osmosis come via Axelar, ETH, DAI, USDC and WBTC. So it's like, okay, these two things are so economically intertwined, it would really suck for osmosis if Axelar got like attacked. Right. So it is in Osmosis's best interest to help provide more security to Axelar in the same way that it's in Axelar's best interest to help provide more security to osmosis. And so these two chains will want to do shared security with each other. And so our entire view here is that like these economic dependencies and reliances are what's going to lead to security alliances as well. And then obviously, which chain in cosmos does almost everyone has some economic dependency on is osmosis. So obviously, you know, from osmosis perspective, we're hoping that there's ways to turn the, our economic relationships with all these chains into valuable security relationships as well.
**A** (10:14):
Yeah, okay, but Sunny, these are all just fiat economics. You know, this doesn't really secure anything. All the validators are the same.
**B** (10:25):
I mean, that's a good thing, right? That, that shows that like, hey, the teams here are like, you know, there's high overlap in communities and like economic stakeholders. Which gives more reason why there should be like a mesh of security systems across these chains. Imagine a validator does something malicious on one chain, they should probably be slashed on all the other chains as well. Probably want validators to be correlating their identities across chains. And then, you know, the goal here and the fiat economics are important, Right. Because how do you take over a chain as you buy up enough of the tokens to do a 1/3 attack or a 2/3 attack or something. Right. And you know, if you increase the economic cost of buying up that one third of tokens, that's, that is how you know, this fiat security is literally, that is what proof of stake is. That's the entire point.
**A** (11:12):
Yeah, I was being facetious there, trying to trigger you a little bit, but you've been through this before, I think. Yeah.
**B** (11:22):
So I've only some of the proof of stake as concept for the last six years.
**A** (11:26):
Yeah. So what are some of the non obvious like properties that emerge from mesh security? Like what are the things that, the edges that emerge that you know, maybe just like looking at it here we're not you know, really seeing. But if mesh security does become sort of the norm in the interchain and we have all the chains securing each other, what kind of other properties you think might emerge?
**B** (11:56):
Positive or negative?
**A** (11:58):
Both.
**B** (11:59):
Okay. Positive. I think it will increase the ease of interacting between chains. So instead of having to think about oh, what is the security threshold of different chains? Part of the whole claim of like Ethereum. Oh, it's easier to compose. It's not actually easier to compose from any technical level. What makes what, what they mean is they say it's like you don't have to think about the economic security levels of different roll ups because they all use the same security system. First of all, that's not really true, but like that's the claim at least. And so the idea is by having this mesh system, it's sort of like, you know, make the economic security levels of all these chains much more closer to each other and that will make it easier to do like more trust free or not trust. Yeah, more carefree I guess. Cross chain composability. So that's like one of the benefits a con that you know what we've so you know like the like informal team had actually been working on like stuff that kind of leads to this. But they kind of actually paused on like interchange security B2 and B3 because they ran into some roadblocks in the architecture, especially things around validated centralization and chain takeovers and all this kind of stuff. And so what we had to do was like figure out solutions for these things. And so it's still an open question of like hey, will this lead to too much validator centralization where it's like, it makes it so like the few validators that know how to run on 50 chains will get like unfairly benefited from mesh security or you know, how do you make sure that a giant chain doesn't just come and entirely take over a tiny chain and stuff. So I think there's a lot of like open questions and I think our mesh security design has like answers to those questions. But obviously these are theoretical answers that sometimes it's just hard to know everything until we put it into practice a little bit.
**A** (14:03):
Yeah, I think that the Validator centralization thing is the thing that I haven't really fully kind of wrapped my head around yet. So in your talk, and I've heard you talk about this in other places as well, where you say that we should stop thinking of validators as the fundamental unit, but we should think as delegators as a fundamental unit. I kind of get that. But at the end of the day, from a governance perspective, but a validator infrastructure company is an identifiable like capturable, you know, like by regulation or whatever entity. And, and also there's the, there's this idea of also like infrastructure centralization where like if you have, you know, most validators on aws, like practically speaking, if AWS goes down, the chains go down, right? Like delegators are not going down the same way that validators are going down. Am I missing something here or like are we operating on the same semantics here when you're talking about the fundamental unit?
**B** (15:02):
Sure. So I guess like mesh security is just like high level idea that chains should be sharing security with each other. But keep in mind there's actually different types of security, right? There's like economic security, there's infrastructural security, there's like, you know, and so like I think the validator level is more like infrastructural where you know, one thing you want to do is maybe get validators to start correlating identities across chains. And that way, you know, let's say one validator does something malicious on osmosis, they should get slashed on Juno and Axelar and UIDX and everywhere. Right? And that's like more in, that's more at the validator level. And I think that's a good idea. The worry is to get incentivized validators to do that. We need to give them some re incentive to correlate their identities. And if they get some incentive do that, that's what we're worried about, leads to validate centralization. Which is why we actually put that model of mesh security like on the side right now. That's not what we, that's not the version of mesh security we're building right now. I think we can build that. But like that we do have to answer these questions about validator centralization. That's why the version of mesh security we're mostly focused on is this cross staking model. Cross staking is this idea that like delegators, I can choose to cross stake my osmo on osmosis. That's staked on osmosis to Also help. I can stake it on a different validator on Juno. There's no benefit of like one validator running on multiple chains. In the cross staking model of mesh security. This is all just about adding more economic security to all of these chains. So that's why. So in the cross staking version of mesh security, there is no like, you know, notion of validators correlating identities across chains.
**A** (16:56):
Okay, so in this version of mesh security where validators correlated entities across chain. So the goal here is like, let's, let's create an on chain kind of identity where like we know that this address. So like InterOps validator on Evmos is like the same as this other validator over here. You know, like that might be obvious by just looking at the list of validators, but we want to make that like an unchained sort of representation because you might have like different validators that have different names. You know, if you're trying to obfuscate your identity, that might be the case. But we want to incentivize people and we want to incentivize validators to actually correlate their identities across chain. The, the idea here is that they would receive more, they would receive an incentive and financial incentive for doing so. But at the same time, like the, the risk is that like they get slashed or across different chains and chains need to coordinate around this slashing. In your talk, I've heard you talk about this before, but basically you're saying this kind of already exists. If there was a big enough attack by a validator, we would use governance or we would use some other mechanism to apply some kind of penalty. But here we're moving that penalty to an on chain mechanism that essentially just runs through consensus. Yeah, okay, yeah, maybe let's walk through how this works because you guys have a really good flowchart thing here and I'd love to get into technically, what are the different steps here. For those listening on the audio version, you should check out the YouTube video. So here we've got Osmosis and Juno and walk me through the different modules and different contracts that, that interact here with.
**B** (18:46):
Yeah, so for some context, this is actually what we built at the hack wasm hackathon right after Cosmo, after Cosmoverse. I'll be completely honest, I wrote very, almost no code for this. It was mostly Ethan Fry and Jake Hartnell who like hacked on this like three days straight and like actually got something working. So that was like super cool. That's really cool. Which is like, you know, this Keep in mind this mesh security thing is not an osmosis project. This is just like a idea that we came up with. And like the Juno and confio teams have been like stepping up to do development. More people have been starting to help the development of this. So what we helped with a lot was this architecture. And part of here's something interesting that we'll say is like, what people might notice is that the architecture of this is extremely similar to the architecture of superfluid staking. Because if you think about it, what is mesh security? Mesh security is saying, hey, the governance of my chain. Let's say, so who's the consumer chain? It's Juno in this example, right? The governance of Juno gets to say that like, hey, I want to opt in to let this other token, that's not my native staking token, count toward use governance to approve that, let it count towards staking power. But we need, but we need to be able.
**A** (20:26):
I think we lost Sunny. Let's see if this works. All right. Oh, here he is.
**B** (20:55):
Hey.
**A** (20:56):
Okay, we lost you there.
**B** (20:59):
What was the last thing you heard?
**A** (21:01):
You were talking about how basically you're allowing, you're allowing the other chain to accept your security.
**B** (21:13):
In trust staking. It's like the consumer chain is making decisions about which other. These other token assets, these IBC'd staked assets to allow to count towards staking power, be slashable, give rewards. Superfluid staking was the same thing, right? It was osmosis governance saying, hey, we trust these LP assets enough.
**A** (21:33):
Yeah.
**B** (21:35):
Decision about another, another token because paired with something say we trust this asset enough to let it count as part of our staking system, give it rewards and have it be slashable. So one thing, well, we are one of the reasons we were able to like, you know, architect this kind of quickly in like a day, in less than a day, was because it really was taking our superfluid staking design that we had spent like weeks, months on, and we kind of like broke it up into a number of contracts and have, you know, added this like IBC barrier somewhere. But like a lot of it was really the same design. So. Okay, so what do you want me to do? You want me to walk through this entire slide deck commuted? Sebastian, you're muted.
**A** (22:26):
Yeah. So I think that here, that what we can do is say, okay, let's start here where osmosis approves cross chain staking and enables this cosmosm meta staking contract.
**B** (22:38):
Okay, so here what happens is Juno is the consumer and Osmosis is the provider in this situation. Keep in mind mesh security. The idea is that we'll have this instantiation and we'll have the same thing going in the other direction, right?
**A** (22:50):
So this is one side and then we'll have another side at some point. All right? And so then at some point.
**B** (22:56):
Yeah, so Juno says, hey, they use governance to say we're going to let osmosis, osmo cross staking count and then they'll put some cap on how much maximum this is to prevent like the whole chain takeovers. So okay, they cap it at 10%. What it does is it deploys a contract on Osmosis that is like this. Oh, sorry. On Juno it's a mesh consumer contract. And then this mesh consumer contract basically deploys a corresponding contract on the other side, which is called a mesh provider contract. So if you go to the next slide and then this mesh provider contract, it has like a Juno, it has a special plugin to another contract which is like all the specific detail about how like you know about Juno, right? Because. And like this is to. So that we can add more consensus protocols, more types of slashing conditions and stuff over time. So this is called the slasher contract. And then, you know, it opens this trusted IBC channel between the contracts and what it does is it allows. I can't see the slides. Hello.
**A** (24:19):
The joys of being in the woods, man.
**B** (24:23):
Well, maybe it's, I don't know, I, I don't think it's maybe the best thing for me to walk through these slides right now. I think these, the walkthrough was available on YouTube and we can have some, have people walk there because it goes pretty technical. But the idea is basically, I think the general high level idea we wanted to show was that like, look, what it does is it allows you to take osmo on osmosis that is staked on osmosis, say, hey, I am going to opt into an additional slashing condition and back this validator on Juno. And then that information gets transmitted over IBC and the Juno system will accept that as voting power. And then if a slash happens, it'll send that information back over ibc. Or you can submit the double sign evidence directly to this contract on Osmosis. The reason you don't want to depend on IBC for the submitting of slashing is the whole point here is we're trying to deal with a Byzantine chain. Like what if Juno goes malicious and it starts censoring the evidence, right? So what we want is the ability for like Double signed evidence to be submitted directly to Osmosis. So it doesn't rely on the liveness of the Juno chain for slashing purposes.
**A** (25:42):
Yeah, yeah. Okay. And so when, when this is implemented, the, the provider chain. So who's, who's getting incentivized here like the validator, the delegator and also the chains are, or who's, who's making money from this operation.
**B** (25:57):
So the delegator, the cross stakers are the ones who are getting rewards basically, right? They, it's basically they get treated as stakers. So similar to how in super Fluid staking, right, if you are super fluid staking your pool one shares, it's counted as like, hey, this is being treated as this much OSMO worth of steak, right. And you're getting staking rewards as if you stake that much osmo, it'll be the same thing here where.
**A** (26:22):
Okay, but it's less, right? So with super fluid staking, you're actually making less.
**B** (26:26):
You take a little penalty. Yeah, you take a little discount on that, right? Yeah, that's good, right? You know, especially for cross staking, we want, you know, if you want to be maximally exposed to osmosis, you should be pure staking osmo. The cross staking Juno to secure osmosis is like a benefit. It's a nice bonus that Juno stakers get. But like, you know, you still do want people to natively stake the assets that, you know, let's say they're the most bullish on.
**A** (26:54):
Yeah, well, I'll link to this, this flowchart in the show notes. People can look at it also link to the repo. People want to take a look at the code and all the contracts. So when, when this happens, then Juno is benefiting from essentially having OSMO staked to secure Juno. So this, I think like the mind shift that people need to have is that they're no longer securing, they're no longer securing Juno with Juno, they're securing Juno with Osmo. What are the implications here for say chains that have less security? So you know, like in the interchange we have chains that are more secure than others and we have chains that are less secure than others. So how do we, how do we reason about the, the security implications that this has for chains that are maybe taking security from other chains that are like less secure.
**B** (27:51):
So like. Yeah, so a chain that's like less secure getting security from a bigger chain. I think the benefits are obvious, right? They get way more economic security, but a big chain, why would they want to take security From a smaller chain. Right. I mean, like I said, the whole point is it's not. You shouldn't necessarily have to think about it as a one to one thing. This is a mesh. Right. And so even if, like, let's say like a big chain, like Osmosis gets security from 10 smaller chains, you know, maybe that could meaningfully double its security budget. So, you know, it's often like, hey, people like, oh, why does the U.S. does the U.S. get anything out of NATO? Isn't it like U.S. is just the only one providing anything to NATO? It's like, yeah, sure. Like the U.S. maybe has, you know, outsized influence relative to any one other country in NATO. But like the sum total of NATO is like, you know, the US Definitely gets benefit from like the sum of all other NATO countries also helping secure the United States.
**A** (28:47):
Yeah. I actually have this here in my notes. NATO example, the US Is the biggest security provider.
**B** (28:54):
Yeah, but like, is it like more than. It's not 90% of the security budget of NATO. Right. And it's like, yeah, like, you know, there's a reason it's a. It's a security alliance, not a empire colony model. Right. Where the security still does flow bidirectionally, multi directionally.
**A** (29:13):
Yeah. No, this is cool. So what is the, what's the rollout here? Like, when should we expect to see this on Osmosis? And like, are there other chains that are already thinking of implementing this as well?
**B** (29:27):
Yeah, so I think like Juno and Eve, which is like notionals, like Canary chain that they're building. I think there's a number of chains that are like planning on implementing it. I mean, realistically, I was not expecting for development to even begin until January because like I said, we have, you know, at least from the Osmosis core dev team, we have like a road map that we have that was like, you know, planned until December. And we were like, we're like, okay, we're gonna pick this up in January. But like I said, people were just so excited by the concept that they're like, no, no, we want to start working on it this weekend. So I. I mean, I. Realistically, we're not gonna see anything live at least until next year for sure, right? Yeah, but at least I think the development has already kicked off and we. We're going to hopefully see it. I don't know. I imagine we're going to see like a prototype live definitely within like the first half of 2023.
**A** (30:26):
Okay, and what are the. So one thing I was thinking about.
**B** (30:30):
Here Is like, maybe I got to commit to shaving my head and maybe that will help move it faster.
**A** (30:35):
Yeah, let's do that here, here on the Interop. Sonny is committed to shaving. Um, so what are the implications here? If you want to do, if you want to do liquid staking, but you don't want to do it on Osmosis. So let's say you've got your, you've got your, you've got your OSMO staking over on Juno, but you want to use that staking position on Quicksilver, you know, to like generate some liquid stake asset on Quicksilver. Could you do that or is it going to be someone, Is there going to be like a lock in?
**B** (31:14):
One more time?
**A** (31:16):
Yeah. So you've got osmo. Yeah, madcat knows that you're going to shave your head, so he's our witness. If you've got OSMO that is staked on Juno, right, so you've got a staking position on Juno, but you want to generate a liquid staking token. So can you take that, that, that share, that staking share that's representing that Juno stake and like move it over to Quicksilver and generate a liquid staking asset? Is it, is it the same as if you had just had Juno stake there or, or is it sort of some sort of like already some sort of staking derivative?
**B** (31:52):
No. So, so, so keep in mind with staking derivatives, how they have to make it fungible, is it, they need to make sure that all of these staking derivatives have the same slashing properties, right? And so that means that like anyone who's, let's say you're holding Quicksilver Atom or let's say Quicksilver Osma or something, right? Like, yeah, they, everyone is holding that has to have the same distribution of delegation to which validators, right? It has to be like, okay, you know, 20% chorus, 20%, you know, 20% sicka, whatever. Right? But now it's like they're distributing the risk. Yeah, but now cross staking is also part of a slashing, slashing portfolio, I guess. And so we have everyone who has like Quicksilver Osmo. Now, you know, the Quicksilver system also has to make the decision about all the cross staking that happens as well with osmo. So that way everyone can have a fungible position. So you know, potentially this is going to increase even further, increase the like decision making power of these like liquid staking providers, which is, you know, a trade off.
**A** (33:04):
Yeah, yeah, I have to digest that. A little bit. Can you turn off your WhatsApp? It's, it's like chiming in here. I think it's WhatsApp.
**B** (33:17):
I, I think it's off.
**A** (33:20):
Oh, okay. Weird. I'm hearing, I'm hearing some WhatsApp noises. Anyway. Yeah, okay, so, so potentially we could see these cross staked assets as part of a risk pool for liquid staking. But they do need, they would need to onboard them. Like technically that's a little bit more cumbersome than onboarding just using like the staking modules, shares. Right. Is it feasible or is it like, you know, liquid staking will only work with natively staked assets.
**B** (34:02):
Liquid staking will work here as well. Right. It's just that all the, all the liquid staked OSMO will also have the same cross taking distribution as well.
**A** (34:13):
Okay, and what if I say, so what if you've got some Juno and like Juno Osmo liquidity pool. Right. And you've got some bonded, some bonded tokens in the pool. You've got bonded Juno on osmosis. Are you going to be able to stake those on Juno? Even like sort of like, like, like liquid, like some kind of super fluid staking. But that goes cross chain.
**B** (34:36):
Oh well, yeah, super fluid staking, cross chain. We had this exact idea. All right. So I would say even met even cross staking this idea we had in some proto version last year with interfluid staking. Right. So what was interfluid staking? Interfluid staking was saying, hey, we have this like let's say OSMO akt pool on osmosis.
**A** (35:01):
Yeah.
**B** (35:02):
And it's super fluid staked on osmosis. Why can't we also have that counterword security on a Kash network as well? And that was, that is cross staking. Right. But instead of cross staking for native assets, it was cross staking for super fluid assets. So interfluid staking was exactly this idea of like cross staking plus superfluid. And so it's kind of funny that we actually had this like I cross sticking idea for this more complex thing of superfluid. And then we're like wait, we can actually use this for the native assets as well.
**A** (35:33):
Okay, yeah, I had forgotten that we had already interfluid staking.
**B** (35:38):
Well, we don't have it live yet, but that was this idea that we had. And I think now like, you know, it takes some time, like you have all these ideas and then they all just, everything just starts to click and you're like oh, of course there's there's like one unified framework that explains all of these things.
**A** (35:56):
Yeah, no, this is super cool. I'm, I'm.
**B** (35:59):
I do think, like, interference taking is an important part of how osmosis is like, you know, makes itself more essential to a lot of these chains where it's like, hey, look, all you Cosmos chains, you already use osmosis for your liquidity and you have all of your tokens on our chain. You should be okay with using us for your security system as well. And so it's like, you know, I think there's this interesting relationship that's going to happen between liquidity and security.
**A** (36:29):
And do validators need to do anything different or are they just running the same software and they don't have to do anything different? Okay, and. But validators can't also opt out of being like, if they're staking on the chain that has, that has mesh security enable, like, a validator doesn't really have an incentive to opt out of it.
**B** (36:49):
No, it's just like, it's just like as if someone staked more on you.
**A** (36:53):
Yeah, right. Okay. Interesting. Very cool. Yeah, I'm looking forward to seeing this develop as, as you said, next year. When. When are you shaving your head?
**B** (37:07):
No more shaving.
**A** (37:10):
So, yeah, when we talked on, when we talked in, in Medellin, when we did this episode with cryptocito, you were talking about permission Smart contracts, like Permission Cosmos. And I've been thinking about this ever since and like, I mean, yeah, what's the idea here? And like, why do you think all the change should just enable Cosmos as a, like, default permissioned system?
**B** (37:33):
Yeah, because I think, like, Cosmos, like smart. So the Cosmos SDK is like, very powerful but very dangerous because you are writing native code, right? And this allows you to do a lot of really cool things, but it's dangerous. Meanwhile, Cosmos is this VM system, right? It's like a nice sandboxed environment that you can do. Like, it's way less. It's not as powerful as an SDK, but it's, you know, because of the sandboxing and everything you can, the attack surfaces are actually much lower for logic that's written in Cosmos, because if you write a new Cosmos SDK module, we have to do a lot of auditing to make sure it doesn't go screw with another module in an unexpected way and stuff, because it's all go code. They can all call each other. We built this object capability system to help, but it's not as good as the sandboxing system of VMs. That's why it's for new logic. It is just so much faster to hack on it and get a MVP and start building it on Cosmos. And more importantly it's so much faster to review it and feel comfortable adding it to a blockchain. And so that's kind of why we've come to the conclusion that how we've started to think about things more is that hey, let's treat the Cosmos SDK as like kernel level code, right? Like when you're like yeah, os, it's like okay, yeah, you need to do some kernel level programming. But then a lot of the like application stuff that stuff that doesn't need, you don't give pseudo privileges and to like things that don't need it, right? And that's like yeah, most things in CosmosM and then use the SDK where we really need to like how we do transaction fees and how we do like parallelism and how we do like, you know, all this like very interesting staking stuff like that can be in the SDK. But like a lot of let's move more of our logic into Cosmos and you know, osmosis we actually have now not in the next coming upgrade we're going to have our first module that's in cosmosm which is IBC rate limiting. And IBC rate limiting is a way of like, you know, we can say hey, we only want maximum of 20% of this IBC channel's TBL to like flow out into every six hours or something. So that way if there's ever a hack or something, it's like okay, we're capped at the amount of losses, right at 20% or something. It gives us time to pause the chain or whatever. And so it's like a similar situation here, but it's like okay, we're just going to write this in Cosmos. It's way faster. And if other chains want to adopt this IBC rate limiting module, well they got to adopt permissions Cosmos so they can add it to their chain, right? And like. And so we're taking them very much as like. And the same thing happened with Mesh Security where we're like hey, all these, all this Mesh security stuff that we wrote at the hack wasm, we wrote it all in cosmosm and I think what's going to happen is like more and more of especially this like whole interchange composability stuff is going to start to be written in Cosmos just because it's faster. Not, not faster from an execution perspective. Actually Cosmos SDK is more performant, but I mean faster from a development standpoint point. And I think the composability is just going to. And chains that don't opt into this kind of stuff, use permission. Cosmos, they're going to not miss out on all these cool things like rate limiting and mesh security and stuff. And I think it's going to be an incentive for change to all start to adopt some permission. Cosmos and Human, it should be permissioned because we don't want every chain to just turn into a generalized smart contracting chain. But it should be. Governance can add new functionality as, you know, as needed without having to go through. And the cool thing, another cool thing of Cosmos, you can add functionality just via governance proposals rather like than having to like do a software upgrade and upgrade the chain every time you want to change, add a little bit of new functionality.
**A** (41:38):
Yeah, no, I mean all that makes sense. So is there a point where, because, I mean you mentioned the performance benefits and obviously like writing a Cosmos SDK module is going to benefit from much better performance because it's closer to tendermint. It can interact with Tendermint directly through abci.
**B** (41:59):
It has native code. You have control over how your storage and database and everything works.
**A** (42:07):
Right. So is there a moment where say let's say mesh security, let's say mesh security gets adopted. It's widely adopted across the interchange and we realized that, hey, there's a benefit if we write this as a Cosmos SDK module. Does it then make sense or do we just keep trying to optimize this contract? When does this quickly written code become core enough to start building modules?
**B** (42:42):
Yeah, I mean that's a good question. I guess we don't know yet. We haven't hit those bottlenecks yet. But you know, I mean, there's two answers. One is we definitely have to improve the performance of Cosmos. Right? The Cosmos today. Like, honestly, to me at least the storage is a little bit of a black box. Like I don't know how it's. First of all, I know it's like JSON serializing things and like, you know, I don't know how the Merkle tree is working underneath and it's like, okay, you know, we probably should go and improve all those kinds of things things and like, I think we can get the CosmosM performance to be like much closer to the SDK. I don't think it'll ever be as good as the native SDK. We can get it much, much closer.
**A** (43:19):
Yeah.
**B** (43:20):
And then yeah, I think maybe some things maybe should be rewritten in the process SDK especially like things that happen very regular like that are extremely important. One cool thing about how Cosmos works that like is as a, they have this concept of pinning contract where what that means is like hey, a contract that's used so regularly governance can pin it. And what that means it'll store that contract in memory. And so that way it doesn't have to keep pulling from the every time that contract needs to be called. It like doesn't pull it from the contract byte code from the database every single time it's held in memory. Just like Cosmos SDK, you know, go code is always held in memory.
**A** (44:02):
It's like validators and node operators are holding this contract in memory.
**B** (44:06):
Yes, exactly. And so that way that will definitely help improve the performance and stuff. So yeah, long story short, I think there's a lot of work that we can do on like improving Cosmos and performance to get it closer to the SDK. And then there are if things really do need to be moved into the SDK and that is like the big win, we, we can do that as well. And our team has been working a lot on like improving this cold Cosmos SDK experience overlap because I think, you know, a little bit of what happened was there was this love dichotomy which was like there are some teams that know Cosmos SDK really well. And which teams are those? You know, everyone who like helps. Most of the teams know casual SDK pretty well, right? Like you know your region who like builds causes had forever only been doing stuff in causes SDK. Then you have some teams that know COSM wasm really well. Like the Juno team, right? They, I think they know Cosmos really well. The Confio team obviously, you know, they built the thing and they, they obviously know the causes SDK pretty well as well. But like all most, you know, the chains that they've launched like Juno and T Grade and all these things, they are like very thin Cosmos SDK chains. Not much customization there because they've decided to build all of their logic in Cosmos. Yeah, Osmosis. We're like one of the first few chains that we don't have a thin. We have a really complex Cosmos SDK stack. Right? All of our AMM logic and everything is currently in the Cosmos SDK. But then we also have this Cosmos thing. And so when we started doing stuff with Cosmos and we're like wait, so much of the cosmozyme developer tooling and everything was really assuming a very bare bones Cosmos SDK chain and Assuming that all the stuff is going to be built in Cosmos. And that's just not how we're building. Right. We're building like half in Cosmos SDK, half in Cosmos. And so we've had to spend a lot of time in the last few months really making that UX of like interacting between Cosmos SDK and Cosmos much, much better. So we've built this library called Osmosis Rust, which is like a general. Eventually this is all going to go into a product we're calling Beaker, which is like the. We intended to be like the hard hat for Cosmos. Hard Hat is like the tool that everyone in Solidity uses to do all of their testing and scaffolding and everything. Right. So Beaker will become that. So that it includes ways of Cosmos contracts, calling SDK modules. It includes a brand new Cosmos testing framework that we created because earlier it was weird. What was happening earlier was the popular Cosmobosm testing framework is called CW MultiTest. What they expected was every time you write an SDK module, you would effectively rewrite it in Rust so that you can test it. That's crazy. We're not going to rewrite our code twice. Once and go and once in Rust. Our new testing framework, we have it so we can actually test. We can write our contracts in Rust, but the modules and go and we can still test them against each other. Our team has been doing a lot of this work in making this two universes come together into one cohesive development developer experience.
**A** (47:36):
So. So this Beaker thing, you know, for. For those like me who are like, more used to like Web2 development, what would that be analogous to in Web2? Would it be like a React or more like a what? Like.
**B** (47:53):
Yeah, kind of like a react. Not more than. No, not really a react. It would be more like. To be honest, I haven't done like web development in a long time. But like, you know, it's the. I mean, look, if you've done cause SDK stuff, I just like Starport. But like.
**A** (48:13):
Okay, right, okay. So like kind of a CLI scaffolder framework. Okay, yeah.
**B** (48:20):
But also very importantly a testing framework. Right, Like.
**A** (48:24):
Right.
**B** (48:25):
So you have in Ethereum, people coming from Solidity, you have things like Hard Hat and Foundry or. Or Truffle was like the really popular one back in the day.
**A** (48:34):
This status also had one also. Yeah, yeah, interesting. Okay, so. So this is what you guys are building and this doesn't exist yet in Cosmos. Like there's no real.
**B** (48:48):
No. Yeah, it.
**A** (48:49):
Yeah, because I saw like Larry 0x. I saw him tweet this thing today. I wanted to ask you about it. It is this CW SDK roadmap he's tweeting about. Is this. Do you know what this is?
**B** (49:02):
Yeah. Larry has this idea that he wants to rewrite the Cosmos SDK in Rust. Okay. And he wants to, like, rip out all the go and just, like, make everything in Rust it's okay. You know, I mean, look, isn't Informal.
**A** (49:19):
Also kind of working on this or aren't they writing, like, big parts of Tenement and.
**B** (49:23):
Yeah, so they're rewriting Tendermint in Rust. Right.
**A** (49:25):
Okay.
**B** (49:27):
I, I, you know, I wish Larry luck. I think it's a fun project. I just don't think. I think the Cosmos SDK has been in development for, like, five years, over five years now. And there is just so much that goes into building an SDK. You have to, like, it's not just the execution state machine. Right. You have to build, like, signing systems. You have to build rpc. You have to build, like, you know, there's like, it's, it is a massive task that took, like, years to build. And, you know, we think that it's easy. And, you know, we're not saying the SDK is perfect. I promise you, it is not. There's a lot of room for improvement. But I think it, you know, I think it'll be much easier to fix the issues with the SDK than it would be to, like, try to write a new framework all from scratch again.
**A** (50:13):
Yeah, that seems like a massive undertaking. Yeah. I want to get some from. I want to get someone from informal on to, to talk about, like, this Tenement Rust thing. Yeah, sorry. To see if I can get someone. Yeah. One thing I, I think I tweeted about this, and I was asking, like, if you have permissioned Cosmos cosmosm on your Cosmos chain, and then you also want to have permission lists. Does that, Is that like the same namespace? Or should the permission stuff be kind of segregated and separated for security reasons or, you know, should the, should the permissionless stuff be able to call the.
**B** (50:54):
Permission stuff if you have permissionless? I don't see what, why you would have permissioned at all. Right, okay.
**A** (51:00):
But there's no security issues of, like, having these kind of core contracts, like, osmosis. Right. You've got like, you know, your Mesh security contracts and stuff like those.
**B** (51:09):
You.
**A** (51:09):
Know, like, if you're thinking of, like, software development, there's like, name spacing and sort of. Yeah, certain things.
**B** (51:18):
Yeah. It's like cosm that's kind of like what I meant by this whole like security permit. Like sandboxing of VMS is like VMS contracts are sandbox like are private by default and they need to expose.
**A** (51:33):
Right.
**B** (51:33):
Okay. Causes decay is the opposite. It's kind of like everything's a little bit public by default and you need to build in security systems, perimeters around things. So it's like, yeah, if you have a permissionless system, it's fine. You don't need to have a separate permission.
**A** (51:49):
Cosmos.
**B** (51:50):
Because every sandbox, every contract is already sandbox.
**A** (51:54):
Okay, so with Cosmos you don't have the same composability as with solidity contracts.
**B** (52:00):
No, no, you do. It's just that like, what I mean is like you. Let's say you have a Mesh security contract, right? You can't. It's not like any contract can just call in like, you know, it's easy for a contract to say, oh, I only want these contracts to interact with me. Okay, here's an interesting feature that is built into cosmosm. It's really cool. It's called a pseudo message. So what that is is it's a contract. It's a. It's a function in a Cosmos contract that can only be called by the Cosmos SDK. So you can't have another contract call it and you can't have an external. And so this is how IBC rate limiting works where you know, we have this like rate limiting contract. We don't want it to be called by any other contract or by a user. That's not what it's for. Right. So what we do is we use a pseudo message so that the IBC Go module in the Cosmos SDK, it can call this function in this rate limiting contract and only an SDK module can call that. That's a really cool feature that Fry had added into that Cosmos. That really makes it. That's what makes it possible to write, I would say core modules of the in cosmosm because you know, they can only be interacted with by other core modules from the SDK.
**A** (53:24):
Okay, that's really cool. I have no idea. Yeah, I mean like, I don't code Cosmos contracts. So it's helpful to be able to ask these questions and understand how it works. Compared to.
**B** (53:36):
There's a big lack of tutorials and for Cosmos, where there's a lot of tutorials that teach you the first 30.
**A** (53:49):
The hello world.
**B** (53:50):
Yeah, the hello world. Or a little bit, you know, the intro stuff the basics up. There's not a lot of tutorials that teach you the complex stuff like the.
**A** (53:58):
Pseudo doing this Cosmos Academy thing.
**B** (54:00):
Yeah, they are. So we'll see how, you know, I'm hope, hopefully that will. That will be like the thing that will. They do it. For me right now, how I do, how I learn Cosmos is I like, every time I get stuck on something, I read through the Mars cosmology contracts and the Dowdao contracts, I'm like, oh, okay, that's how they did it. I'll start doing that too.
**A** (54:19):
Yeah, yeah. I think that's probably also how I would try to. I mean, that's also how I learned to code back in the day. That and stack overflow. So, yeah, I want to, I want to talk a little bit here before we wrap up about kind of, you know, osmosis versus atom 2.0. We do have to make this a little bit spicy.
**B** (54:43):
Right.
**A** (54:43):
And Jim from your team posted this tweet, I think, late September, kind of basically describing and comparing the same tenants in Osmosis and on the Cosmos SDK. And so there's liquid staking, interchange security, MEV and bootstrapping. And both Atom 2.0 proposal and osmosis have very different views about how this is going to work. We've already talked about mesh security, but I think, you know, the, the and then like staking derivatives and superfluid staking. I think it's kind of easy to wrap your head around how. How are you guys looking at MEV and how. How differently are you approaching MEV compared to, like, this interchange scheduler that's proposed by Adam 2.0.
**B** (55:36):
Yeah. So, you know, one of the big things we're doing with mev, I mean, one, there's two things, right? So at. At the Nebular Summit, I gave my talk call on mev, right? And it was, you know, I think the takeaway of that talk was the goal is mitigate bad mev, internalize good mev. And so, you know, we've always been talking about this, like, threshold decryption stuff. I think I have so many talks on it. We've about like, you know, that's how we mitigate bad mev, Right. You want to stop the sandwiching and front running and all this kind of stuff, but what does it mean to internalize good MeV? So there's some MeV that the bad MeV is the one that's like, you're doing actions based off of someone else's transactions. You see their transaction in the mempool and you act upon them, and that's Like a privacy breach. And that's like why it's bad. But there's some things that you can do that aren't based off of reading other people's transactions. It's just based on reacting to the state of the world and just being the fastest, right? Like so for example, a liquidation, right, that's like, it's not bad. It's actually, if anything it's actually good for the health of the network. You want liquidations to happen, happen or even arbitrage, right? Like there's, let's say the price of Atom has moved on in external exchanges and like you know, someone needs to ARB the price of atoms on osmosis, right? And it's like that's not bad. It's not like no one's being harmed by doing this, right? It's like again, it's a good thing. You actually want prices to stay in sync. But there's still a, there's still profit to be made and it's a race to who can get that arbitrage profit it. And so these are like good MEV systems and what we want to do is make sure those that profit gets internalized into the protocol and gets like given to OSMO stakers. You have, what we're trying to avoid here is like not have systems like Flashbots, which are these like extra external to the protocol. Like these like. I mean, you know, I, I use this term called validator cartels in the sense that it's or minor cartels, right? Or it's like. And it's an off chain coalition of people who are like doing this when instead, you know, all of these auctions and stuff. So what we call them, what we're working on with. So this is where Skip comes in, where Skip is helping build tools for internalizing good mev. And so what that means is they're doing a couple of things, right? They're doing one the proposal that recently went up was about building an on chain arbor. So this is for, you know, there's pools on Osmosis and sometimes they go out of sync and then there's an ARB opportunity to resynchronize the pools, like do a circuit, you know, you, you sell OSMO for Atom, Atom for Juno, Juno for osmo. And you get a little bit more OSMO by doing that. And there's a lot of like off chain arbors who are playing this game right now to be the first to do that. Well, the protocol can do that itself and capture that revenue, give it to OSMO stakers. So that's like the first thing Skip is going to build. Then the second thing is like, okay, but you know that only works for internal arms. That doesn't help you arb against external markets. Right. So oftentimes there's a lot of value in being the first transaction in a block. And so we call this top of the block auctions, where you know, what we should do is sell off the rights to be the first transaction in a block. And that way, you know, people can bid on it on chain and if they win that bid, they'll be the top of the block and they can be the first to execute arbs and whatnot. So you know, there's like value in these things and building these in protocol is what Skip is doing. And like, you know, effectively you can argue that they're basically being the joint, they're like going to be a core dev of osmosis and building like functionality into the osmosis core protocol to do this kinds of thing.
**A** (59:33):
So this top of the block auction thing, then the revenue from that top of the block auction would go also to stakers. So when you're saying, when saying like internalizing good MEV or wait, are you internalizing bad MEV or good mev?
**B** (59:46):
Good mev.
**A** (59:47):
Good mev. So internalizing good MEV is kind of like leveling all, like covering all the bases and leveling the playing field at a protocol level and then capturing the revenue from that and giving it back. Because you can, right? Because with osmosis you can. I think with Cosmos and especially now with Interchange security, it's harder to see exactly what that stuff is because you guys have a specific osmosis, has very specific use cases and you can kind of target the MEV that you see there. Whereas with, with Cosmos there's going to be tons of chains there, lots of MEV opportunities. And so I think where the scheduler makes more sense here is okay, we don't know what those ARB opportunities are going to be. Let the market decide and let the market figure it out by having these future block auctions. Future aux base.
**B** (60:42):
So let's talk about the scheduler. Right, so there's two interesting things about the scheduler. One is this idea of it being a few futures market. That's an interesting thing that I haven't really heard of and it's one, one worry is it's hard to know like buy block space for a much a future block and like try to know how much MEV is going to be in it. It seems un. And then it seems that, you know, all the profit is going to go to this secondary market of like reselling future blocks rather than like more just in time sales when the value of the MEV is more known. So that's like a. I don't know, that's. That's an interesting thing. We'll see how that actually like plays out. But the general thing is that like this whole idea of the Interchange scheduler is it's hard to see which chains are going to opt into this, right? Like something like Osmosis. I don't see why would Osmosis opt into the Cosmos Hubs scheduler and give up instead of internalizing the MEV to osmos stakers, giving it to atom staker or even like interchange secured chains. Even them. Like, you know, I've been talking with the Neutron team and even they are like, yeah, no, we have. We don't plan on using the Interchange scheduler because you know, part of the value of the Neutron token was we're going to internalize the MEV into the Neutron token. And so it's like I feel that kind of one of the whole points of build. One of the benefits of building an app chain was to be able to internalize MEV and it's unclear why. Who's going to be the user of the Interchange Scheduler and like opt into not internalizing their own mev. So that's like a big question.
**A** (62:21):
Yeah, I think they need to, they need to clear up like what the incentives are here.
**B** (62:25):
Yeah, I think here's the most interesting question about how cross chain MEV is going to work. Maybe there are benefits to having a singular market. Okay, so there's two options here. Let's say every chain has its own top of the block auction, right? Let's say, you know, Osmosis has its own Juno. Has its own whatever, right? If you want to do an arbitrage between these market, like between Osmosis and Juno swap, let's say, right, you have to win both of the top of the block auctions and that's like harder and it's like more unclear like oh, what if you win one but not the other. Now you just, just wasted winning that bid and stuff, right? So that's, yeah, that's. I would say the, the null hypothesis, that's the default of what's going to happen. And I think that's probably how things are going to start off. But there is benefit, you know, maybe to what if like these auctions were joint in some Way, right? Like, what if you could say, I want to bid on. To be the top of the block of both Osmosis and Juno, and if I don't win both, I don't want to win either, because that's not worth it for me. Now, you know, the causal sub says, oh, okay, yeah, we'll do that. And the allocator, the scheduler module is like, okay. And then that profit goes to animals. Like, no, no. Okay. You know, everything's a mesh, right? So it's like, the question is like, okay, I think if. If it is beneficial for Osmosis and Juno to have a joint top of the block auction, they should do that, and the value should go to Osmo and Juno holders. But the question is, how is the revenue going to be split? Who has the. Is it going to be split? 50. 50? Is osmosis going to get a higher portion of the revenue than Juno will? Because, you know, I mean, the liquidity on. On us, you know, it's more likely that Juno's swap is being armed relative to Osmosis rather than the other way around. And so it's like, yeah, okay, how is that revenue split gonna work? Is there, like, a formalized model for how we define fairness in these, like, joint auctions and stuff? And, like, I think that is one of the most interesting questions. Questions and, like, open research problems that I think came out of Cosmoverse or, you know, I guess, like, I've been talking about it with the Skip people for a little bit, but, like, I think that we had this MEV panel at cosmoperse, and I think that was the first time we kind of, like, shared this open, big, open question publicly. And so, I don't know. I think this will be an interesting research topic for a while. How do you do revenue splits of joint auctions?
**A** (64:50):
Yeah, I think the MEV topic on Cosmos and so, like, interchain MEV is like, so interesting, and I've only just kind of started diving into it. I haven't paid much attention to, you know, I sort of like, you know, follow the Flashbot stuff a little bit, but, like, not that much. But then, you know, I had this interview with Braps a couple weeks ago, and he just, like, totally opened my mind to this and then, like, hearing you talk about it. So, yeah, I think this is something I want to cover a little bit more on the podcast here. Maybe I'll get to skip people on.
**B** (65:23):
Cool.
**A** (65:24):
Well, listen, I think we can wrap it up here. It's been an hour. We didn't really get to talk about osmosis ecosystem so much, but maybe we can save that for another time. I'd like to try something here. Maybe this could be a recurring thing. Who should I get on next?
**B** (65:42):
Who should you get on next?
**A** (65:44):
Yeah.
**B** (65:46):
Have you had Dogemos on?
**A** (65:47):
I have not had Dogemos on.
**B** (65:49):
Dogemos would be a good person. Have you had specifically about what just like Kepler and UX and how like building cross chain wallets and like it's all. Yeah, all this sort of. Okay. Mars team on.
**A** (66:07):
I have not. But it. So we were supposed to do it next week, but. But we're. I think it's going to be pushed back a little bit. But yeah, they're due to come on as well.
**B** (66:18):
I think Utopia is really cool. So I'll get them on as well. Who? Gitopia? It's GitHub.
**A** (66:26):
Oh, okay. This is cool. Okay.
**B** (66:28):
I know you would be looking stuff.
**A** (66:30):
Yeah, those are. Those are three great suggestions. All right, well, Sunny, thanks a lot. Thanks for coming on and hopefully we'll get you on again. I know we'll get you on again again for sure. Very sometime very soon. Thank you for listening to yet another episode of the Interop. We do live streams every week. Please follow this channel subscribe to this channel to get notified when new live streams go live. You can also follow me on Twitter. I'm at Sep 3.0. I tweet about all kinds of things related to Cosmos and the Interchain and sometimes some other stuff. Yeah. Thanks so much for joining and we'll see you next week.