**A** (0:03):
You know, I started. So I was studying computer science and political economy at Berkeley. And so when I got there as a freshman, I was just looking at a bunch of different things of what seems interesting. And I found this bitcoin club that they had there. And I'm like, oh, this is cool. You can combine computer science with political economy to do cool stuff. And so I joined this, like, bitcoin club. Didn't really fully understand what was going on, like, you know, but, you know, I felt smarter just by being in the room and just like, I, like, eventually I'll absorb the stuff that everyone else is saying and I'll get it at some point. And so for me, the best what we did was we started teaching. So I guess technically I was a university professor at some point because so there's this cool program at UC Berkeley that students can teach a course. As long as you have the, like, backing of a actual professor, then you. You can have students teach courses. These are called Decals. And so me and two friends, we taught this blockchain decal. It was Don Song was like the professor that docked us and stuff. But yeah, so she. Yeah, so we did that and then started this. You know, that's how I kind of learned about crypto. First place is teaching this course. We started this club called Blockchain at Berkeley, grew that. And then like, you know, 2017, that summer I was interning at Consensus, I was like. Because for two years we were like, all like, very bitcoin maxi. And so I finally, I finally was convinced by someone that, like, hey, I should take a look at this Ethereum thing. And so I remember I would listen to a lot of Epicenter podcasts and stuff that summer, and I was just like, reading all the proof of stake white papers I could find. And out of all of them, Tendermints just seemed the simplest and the most practical and easy to take to production. And we're like, oh, wow, we could just do this in six months. Turns out it took us a while longer than six months to launch it. I kind of quit my internship. Consensus. Something about just working on Ethereum stuff, I don't know, it never excited me for some reason. And so with Cosmos, I reached out to the Tenderman team. Brian was there at the time and started working with them. Dropped out after, you know, at the end of the summer, Dropped out from the university at the end of the summer and started working at Tendermint full time. Worked there for three years, went helped launch Cosmos Hub, Cosmos SDK. And then when Gore 2020 happened. The great organizational restructuring of early 2020, where, you know, their tendermint company kind of imploded. You know, we all found new roots, a home in the cosmos. And so I spent some time thinking about what I want to be building. And then at some point, you know, after a couple of misdirections, we eventually landed on osmosis. So I don't think it should have too much impact on cross train mev. They seem to be pretty orthogonal things with the assumption that like we're. That the MEV solutions are happening off chain. The reason is because mesh security. One thing I think that came off a little bit incorrectly in my cosmoverse version of the talk was it talked a lot about like validated set overlap stuff, but that's actually not how mesh security works. There's no. It doesn't look at actual validated set overlap at all. It. I was trying to like in the talk, I was like talking to like, okay, this is one thing you could do, but this is bad because it'll lead to like validated centralization. You'll only have a few entities like Chorus who can maybe manage to run on 50 chains and then they'll get. It compounds their thing. How mesh security actually works is using something we call it cross staking, but it's basically the same thing as restaking in ideal. And given that that terminology has sort of gotten more traction, I think maybe we'll start calling it. The reason we didn't call it restaking the first time was because we already have like redelegation in Cosmos SDK and so we didn't want it to be confusing. But yeah, so like, yeah, so mesh state, mesh security all happens via a restaking protocol similar to eigenlayer, but it exists on every Cosmos chain and so it doesn't affect validator set overlap at all. And so it shouldn't really have too much impact directly on MEV stuff, cross domain mev, other than it might make communities more incentive aligned to allow for cross domain mev. Because one of my takes is that cross domain MEV is only possible if the chains are the ones that opt into it and agree to it. Because for osmosis what we're doing is building these top of the block auctions, where in the protocol in the state machine it's auctioning off the top of the block. And so the nice thing about this is that valid, it's not up to validators to choose what's the top of the block execution. It's up to the state machine. And so you having validators on multiple chain chain like you know, a skip style, a flashbot style, validators on multiple chains. It doesn't help because that doesn't help you win the on chain top of the block auctions. And so the only way to make the on chain top of the block auctions atomic is if the two state machines, the two chains governance systems agree to an atomicity system like interchange scheduler or something like that. So let's talk a little bit about how we're planning on doing concentrated liquidity incentives. So we are doing. So we have a couple of ideas with. The one that we're going to start with is sort of a simple one where it's very similar to the one that Dan Robinson wrote for Uniswap on like it's on the Paradigm blog. And so what it's basically saying is that for within a tick, if you know, whatever the swap is, we're basically going to say like hey, we're emitting this much OSMO per block for each of the for this pool, right? And what we could do is say like okay, well within a ticket take, okay, if you made up 5% of the liquidity, you get 5% of the rewards or that thing. The one thing that we add relative to Uniswap is this idea of uptime incentives. So what we're trying to avoid is so what what it will do is it only gives you the incentives if your liquidity has been on the, on the liquidity book for a minimum amount of time. And so we have like I think four supported. We can do one one minute, one hour, one day or one week. So you basically personally, I think the one minute kind of stuff is actually where it's most useful. But because that helps you prevent one the thing where someone moves the price somewhere else to a high liquidity region and wash trades on it because they can't just do it in a single block. They'd have to keep the price at this high liquidity region. And the idea is someone else would come and arbit back. And it also prevents the just in time liquidity. Some people think that the just in time liquidity is good because it's adding more liquidity, but it's removing liquidity that would have otherwise been sitting on the deck. And it's like making more less information available on the market which is like net bad. You want people to put their liquidity on chain rather than use this just in time liquidity. So I did take a look at the proposal and I think I left some just like small technical comment feedbacks I think, I think my main thing is they don't seem to like enough quote my notes, like what I wrote for it. But I feel like they didn't figure out how to like deal with like DOS issues here that. Okay, I could find my notes. Thoughts on builder API? Yeah, there's a. Isn't I have my notes. Isn't there a DOS attack where a builder can always top bid but never reveal? Yeah, so, so their whole way they designed the whole like bid reveal sort of system didn't seem to make sense to me. So. But you know, zooming out the, but that, that's like a fixable thing. You have to fix that. Zooming out though, like I, I, I'm happy for that to exist. I just don't think it should be part of the core Cosmos SDK module, like code base. That's what they were pushing for. It's fine for them to keep it as a separate code base and then encourage chains to like adopt it. But you know, like I said for osmosis we, instead of going for this off chain builder API stuff, we want to, we're working with Scip to build the on chain top of block options instead. So you know, I think by, or I think by putting one MEV solution like baked into the SDK is a little bit not right and Chain should have the ability to choose which solutions they want to use. I mean like I said, Scip has many products, right? So protorev is one very osmosis specific product. Top of the block auctions is mostly being built for us because we are the ones who are asking for it. But it is something that can be used and many chains can adopt it. And I assume that once it exists, most chains are going to want to adopt that instead. And then you have the MEV Tendermint, which is like the off chain, like sort of the builder API style solution that the Skip team is running. And so yeah, I mean they've gotten quite a bit of traction on the like, I think like evmos and Juno and stuff have like adopted the mev Tendermint stuff. But yeah, like I said, I think that, I think that once they have the top of the block options that's going to be a far more like, interesting thing for many of the projects to use. I think it'll be popular because there's a lot of revenues to be captured from it. Right. Like especially in like on osmosis, especially like okay, if you rewind like you know, nine Months ago when volumes were at their peaks, right. There was like significant daily volume happening on Osmosis and that a lot of the fees, like yes, there's some value to be captured from trading fees, but a lot of it's also just from like being that people will pay to be the ones to arb osmosis against centralized exchanges. When the price of Adam moves, when the price of ETH moves, people want to the. It'll turn into an auction system and there's a ways of capturing that value to OSMO stakers. So I imagine like DYDX will probably also want to do something similar any, any anywhere where there's like this like cross domain arbitrage opportunity. They probably will want to use like some, some tooling similar to Skips. To be honest, I think M is probably one of the best when it comes to like taking like very technical topics and like breaking them down in a simple way to understand. I think like, I think all of that presentary hosts have like a different sort of skill set. Frederica is very good at grilling on like, you know, grilling on stuff. But I think, I think here is like ability to break down technical stuff is what was one of the things I made. Like I think it's such a popular like onboarding podcast for many people. Yeah. So we. So the story of Osmosis, like the founding process was I was like really good friends with like the Flashbots team and stuff. And so we were all like, so this is like summer of 2020. We were spending a lot of time, summer, fall of 2020. And we were spending a lot of time researching MEV and got really interested in that. And then they then like Tina and Phil and stuff, they wanted to start building this auction system. And I was like, wait, I thought we're going to be trying to like eliminate the MEV from like mitigate it, not auction it off. I think auctions are good, but you want to first mitigate the harmful types. And so I went to Dave and was like, hey, how do we design something to prevent. Yeah, let's. Well, first of all, the first step was like, you know, we were like just doing open core dev work from SECA or Validator company. We're just doing Cosmos SDK core development stuff. But we were like, hey, let's start working on a project. And so we started doing a lot of research on like threshold decryption. Spent like a lot of the fall designing that. And we were like, we weren't sure what we were going to build with it. Yet. And we realized, well, this is like a feature, not a product, you know, okay, what's the product going to be in? One thing we were thinking about early on was like, I guess there wasn't a terminology for it back then, so it was hard to explain to people. But today it's, it's what we would have called like a shared sequencer. And it was going to be like, hey, here's this like shared sequencer chain that like uses threshold decryption and acts as this like data availability style protocol. So that was like what we were thinking of doing and then, but then at some point we just realized, you know, like, I don't know, we wanted to work at like our worries. Like, it's commoditized very quickly. Like, I don't know, it didn't. There doesn't seem to be much value in a shared sequencer when, you know, every roll up will just actually go ahead and take the code and just run it themselves. So, you know. Yeah, so we didn't really find that actually to be a very compelling product. So then we were like, okay, what do we start doing? Meanwhile, on the other side of the world, Josh and Tony from Kepler, Tony at a hackathon built the first version of Osmosis for one of the hack atoms. And so it was like a month long hackathon and he basically reimplements balancer on console SDK. And so we were put in touch with them with Josh and I was put in touch with Josh via Jim Yang. And we were, and Jim was like, hey, you know, they built this thing on a hackathon. You want to help them like launch it and take it to market and stuff. And so Dave and I started working on Osmosis, but under the presumption that just like, oh, they would be the first customer of our threshold decryption, like sequencer product whenever we build it. And so then we started helping them launch Osmosis so we have a first customer. And then at some point after like a month or two of working, we were just like, okay, let's just like go all in on this Osmosis thing. Make that be like a selling feature of the Dex product itself is this MeV resistance stuff. So yeah, that's the story of how Osmosis started. Yeah, I mean, you know, to be honest, regulatory stuff is not really my forte. We, we do have a new chief legal officer who just joined the Osmosis team last week. So hopefully there's someone more qualified now making those. A lot of all these analyses but my, my. I don't know, my general take is that there's, there's like a strong overreaction right now from like a lot of the federal authorities just because they want to not look bad after the whole FTX thing. And you see this after like, you know, you saw this even after like 2008, right, with like Dodd Frank and stuff where you have these like overly punitive, like reactionary measures that get put but then slowly get eroded away. Right. Once they realize that they are a little bit too, you know, too, too restrictive. Right. And so I think right now the, the feds are sort of just going through this like reactionary phase and it'll actually calm down. And I, I think, you know, what we'll probably do is they'll probably start to go after like some of these centralized exchange stuff first. Like, you know, they're kind of going after Binance right now a little bit through BUSD and stuff. And so far they haven't really been coming after like of defi yet. I am legally not allowed to run for President. I was not born in the United States, just Congress. One day, you know, I, It'll take, you know, not for a while. It, it'll be many years in the future after osmosis is the biggest exchange in the entire world, not just crypto exchange. Then I'll, then I'll, I'll consider it. Yeah. So, I mean, I do think Avalanche is really cool in general. Like even just the consensus protocol. I've always been like a really big fan of it because it's very fascinating. It's like not. I, I don't think it's actually a very good thing to actually use in production. It seems kind of unnecessary. You don't have good finality, you don't have like good light clients. There's a lot of stuff you miss in like in avalanche consensus. But I think it is very academically interesting, right? It's like very fundamental. It's a very different family of consensus protocol than like Nakamoto consensus or classical BFT consensus. So I find it academically interesting. I do find it. One reason I find it very academically interesting is like, I think I've always been really interested in this idea of can you do a web of trust based consensus protocol rather than a proof of stake based one. And I think that there's a way of doing it with Avalanche consensus. So that's like interesting on the subnet side, you know, I think the subnets are, they seem more, they seem very similar to like how Cosmos Hub v2 like ICS v2 is supposed to work where you don't get a sovereign staking token and stuff. When you use Avalanche subnets you kind of have to. It only allows you to use Abax as the staking token for the chain and you have to stake a minimum number of Abax in order to able to run this subnet. And so you know, it's a cool mechanism but it's still more in line with you know, this like long class of things we've seen like ICS or Polkadot style stuff. And so I think it's, I think that some people might go use that but I think that like the benefits, you know, of having a sovereign chain and not having to pay rent or if you are going to pay rent, use something like mesh security because then you are paying to multiple people and you can't get like you don't have these like lock in things where one chain can suddenly like start charging like crazy for a security problem. For security, the, the Avalanche like the, the messaging protocol seems pretty cool. Like it's, it's the. For talking between subnets. It's interesting. It's more like. It's not like people have compared it a lot to ibc, but it's actually not similar to ibc. I think it's actually more similar to the XC TP or whatever Polkadot's one is called because how it does because instead of. Because once again the problem is Avalanche doesn't have like a system of light clients. It's like there's no light clients for Avalanche consensus right now. And so you can't actually have subnets talk to each other and do proofs to each other. But what it does is it relies on the fact that all Avalanche validators, subnet validators also have to be validators of the Avalanche like beacon chain or whatever it's called P chain maybe. And so it you post all cross chain messages to the beacon chain and then they get like move sent to like another subnet and it works because all the values are observing the same map chain. So that's much more similar to how XTP works. I'm not sure how scalable it will be but it's like really only helpful for intra subnet communication and it doesn't help you talk outside of subnet. That's where like, like you know, the whole IBC for Avalanche stuff kind of comes in. I don't know. That was a bunch of different things. I don't know if I answered the question or not. I, I have not played out with the Hyper SDK yet. Luigi sent it to me, but I haven't played around with it yet. So it depends on what a hub means, right? I think there's many things that like, I feel like call it like what this whole term of hub in Cosmos, it's a very overloaded thing. There's many things that we could be talking about. There's things you could be saying, oh, this is used for routing, routing IBC packets. I think that was the original intent, but that just hasn't empirically taken off yet. You see that actually every chain does direct IBC connections to each other. And then we're making the UX better with that where we're launching these packet forwarding middleware. So you can send token. Let's say you have Atom on Juno. You want to send it to Osmosis, you need to first under the Cosmos hub and then send it to Osmosis. We make that all happen in like a single IBC packet. So it hits the Cosmos hub and automatically generates the right packet forwarding the new IBC packet sent to the to Osmosis. So the need for routing hubs I think is actually a lot lower than people sort of think. The other term for what a hub could mean is more on this whole security style thing. And so I think that even with mesh security, you'll definitely have some chains that are more popular for getting security from. Right. I think even in a mesh security world, I think Atom and the Cosmos Hub is going to be a place where a lot of people are going to want to get security from because it has this like super high market cap. The nice thing about mass security versus ICS is at least that it gives you the options to do something else. But like even then I do think Atom will likely be a popular default. Obviously our goal is to make it so. Osmosis is also a popular default as a popular choice as well. Especially for a lot of the deep applications that have like high dependencies on osmosis that have. Getting them to like tap into Osmosis security network is definitely a goal. And I guess that's kind of like leading towards this thing of like. I think the. I think a hub is not. Is rarely a binary thing. It's usually a, you know, I, I use things have hubbiness to them, right? Like and how hubby they. Everything in the world has power. Like any like free market system has power laws to it and like things that are on the one side of the power laws Those have higher hubbiness. And so if it's from security provisioning, okay, which chains are used like 90% of the time? Maybe those are hubs, right? Or user activity. Right. If like, if 80% of user activity is happening on one chain, does that make it the user hub or the Liquidity Hub? If 80% of liquidity is on that one chain. So I don't know, it's not a binary thing. It's just this, it's really just more of this like meme that like, you know, we're trying to fit back fit stuff into like for example, like we look at like things of what are the most common things people do with like with their rewards. And you know, there's actually a big worry that oh actually a lot of the, a lot of them are getting like sold. But it actually turns out actually no, a lot of them actually just getting RE LP'd and rather than sold. And so that can inform us of what kind of stuff we want to do. Another thing that we learned is that apparently a lot of the user activity transactions on osmosis are from staking rather than actually interacting with the decks. And so that has led us to plan on building a staking dashboard into the osmosis website. One of our goals of how we, one of the things we want to do with the Cosmosis website going forward is like, you know, have a less emphasis on liquidity providing alone just because, you know, it is something that I think becomes more professionalized once you have concentrated liquidity. But building almost this like sort of earn page in the, on the site that shows you these are the assets you have. These are opportunities you can have to earn with them. Whether it's staking or lending it or lping it or giving you these options of what you can do with the assets to earn with them. And so yeah, building this as like a, and then also like, you know, sort of a. The goal is to build this like mesh security centric, like staking dashboard on the osmosis site. Because our goal is how do we keep people on the osmosis site as long as possible and then you know, eventually they do some trades. Probably computer science. I mean, I don't know, I think I like building things. I don't know, I definitely hated doing proofs and stuff. I, I don't know, I never found that fun. I, I, I prefer more to like just hack on stuff and build stuff. To be honest. My favorite class in, in college and high school and everything was always history. And so I don't know, I'm definitely not the kind of person that like admittedly I'm not the kind of person that like nerds out over like a lot of computer science stuff. Like I don't get like super excited about like I don't know, programming languages and stuff like that. It's to me it's like mostly a means to like you know, more interested in the history and political economy. And then like computer science is a mechanism of like creating is the tool to like impact that kind of stuff. So I think there's a couple of things, right? So one is we could. One thing that we definitely want to do is use a multi asset shielded pool at the base layer of osmosis so people can do like private trading from it right? Today when you trade on a Dex or leaking your entire trading strategy we want some sort of like you trade from a shielded pool. So you just know someone in the shielded pool is executing trade but you don't know who it is. Right. To be honest, like I, after the whole Tornado Cash stuff we were like okay, let's not focus on. There was a team that was building this on osmosis called Void and then they kind of got spooked away from it. So right now what we're doing is actually working with Namada to part. So the Namada sort of go to market is going to be like they have their shielded pool chain but they're going to allow you to execute swaps on like IBC swaps on osmosis. So that kind of you can use Namada as a shielded pool for trading on osmosis. So that's you know, I guess that's one thing but I think you were also talking more about like, like not on the privacy side but more on the verifiability side. And yeah, I think that you know, I think we would want to be able so, so rather than putting the entire state machine in like being able to generate validity proofs today, like you know, yes, the end goal of everything is that we want everything generating like zero knowledge proofs for all state machine transitions. But in the reality of is it's like you know that writing, you know today the best way to do that is use like starkwares like Cairo and stuff which is like it's gotten quite a bit but it's like not, it's still not anywhere close to writing like in Go or something like that right? And like so it'll take a long time before like we have something that as developer friendly as Cosmos SDK is able to generate the zero knowledge proofs. You know, maybe if like risk zeros, like stuff works out, then that will be possible. I think what is more doable in the short term is like this stuff called like zketl. So oftentimes, so one of the biggest challenges that you have right now is like you can query data from the chain and you get some sort of like light client proof. You can do light client proofs to query data from the chain, but oftentimes what you want a node to tell you is not just what's purely at the state, but you want it to do computation over some data. And so it's like I want to, let's say the governance tally process. Right. That is something you, you can't just while the vote is going on, you want to know what percent is? Yes. What percent is. No, that's not something you can just like query via like client security. You have to query all the votes, run this computation over them and then tell the front end this is what it is. And the idea is like, how can we move more of those computations that you need to like apply to data that you query from the chain? Can we start building zero knowledge proofs for those? And that will make it so like a lot of these, that will make it so that you can get all of these queries to also have the same sort of like client security as like you do when you're actually querying chain change state directly. So I think that's, I think that's probably, that's like the direction we'd be more interested in. Like that has a higher impact in a shorter time frame. There's, I think there's like two teams out there working on ZKETL stuff. One of them is called Proxima and the other is, I don't remember the other one's name. To be honest. I haven't been following much of Cosmos Hub stuff Since like Atom 2.0 really. So I don't know what the more recent stuff is. But you know, how do you fix that? I don't know. The problem is, is Jay has too much Adam and fan base that like it's hard to push anything that's like too controversial with Jay. Like, apparently that's the reason that like ICS has like, is based off of social slashing now rather than like actual fraud proofs. Which is kind of sad because Jay was like, oh, we're going to reject that. So I don't know how to solve that problem right now. I think that's one of the main reasons that building, you know, part of the reason why the whole Gore 2020 stuff had to happen where the ownership of that was just not decentralized enough. But okay, so what are things that we can do to improve Cosmos governance in general, the conscious SDK governance? I think there's a lot. One is I think we need to categorize governance proposals. Osmosis is on proposal number 300 or something at this point. And it's just like way too much governance overload. And that's like not. It's. It's. It's getting very difficult to like, for me to like keep up with every type of proposal. And so what we need to do is have different categories of proposals and then let different categories have different processes for how. What the. Like how they execute. Right. Like, you know, some, some proposal types should have maybe shorter voting period. Some and some have longer voting period. Something like, let's say like, you know, I think like half the proposal on Osmosis are like just to update according to the mechanical like incentives upgrade process, right? We have this algorithm that we update incentives and it's just like to do that. It's like, well, why don't. Instead of having to have everyone vote on it. I think a valuable way of would be, is like let's have a committee that like that is supposed to do that update and they just post it and anyone can like veto that governance proposal. So governance has the chance to veto that proposal in, you know, before that, you know, while that waiting period is there. So it's like almost like an optimistic governance like proposal, right? Where like someone passes it, knowing it will pass because they follow the algorithm and it's like it only needs to be vetoed. Or another one would be like, let's say like a contract upload proposal, right. Maybe that should, you know, can go through governments, but it also has to go through a second house which includes like some smart contract auditors, right? Like Oak Security is on retainer by the osmosis grants program. And it'd be maybe like they should have to do like a signature like also approving contracts to be deployed or that, you know, they, they've audited these contracts. So in general, I think just like breaking it into different types of categories will definitely help solve a lot of the governance overload problems. Other issue, the other one main thing I would probably fix as well is I think right now validators get way too much voting power. The fact that they inherit 100% of their delegators votes is a little bit too overpowered in my opinion. What I would like to do is have something where it's like the validator inherits like let's say 25% of their delegators power but if the delegator comes and votes themselves, they use the full hundred percent of their, their power. So this is an incentive. This is nice because it incentivizes even if you agree with the way that your validator voted, it still incentivizes you to come vote yourself as well. So it like uses your full voting power, not just 25%. So I think that will help. Now the, the, the, the flip side of this is if we depower the validators, we're worried that it just makes the whales more powerful in governance then and it's like, I don't know, you have to look how to parameterize this to like meet the right trade off right now on the margin. I think that valid does have too much power and governance. So how much to decrease it, I don't know yet. So Osmosis Labs. So we have like our Osmosis foundation that has a bunch of like you know, the subsidiaries or contractors and just a way of some people go from the name of our company in the US is called Osmurica. So and, but yeah, so the, I mean how do we work? We have about like you know, 40 people, close to 40 people now working on sort of all sorts of different things. One thing that I think people don't realize is like Kepler is actually separate than Osmosis. Like so the, you know, Josh and Tony, they had this company called Chainapsis and that's the one that sort of built and maintains Kepler and Chainopsis is a core dev entity of Osmosis but Kepler is a separate entity and not owned by Kepler is a separate product line that's not part of Osmosis Foundation Osmosis Lab stuff. So there are people on chain apsys that work on both Kepler and on Osmosis, but there's also people who only work on Kepler or only work on Osmosis. So the organizational lines sometimes get a little bit blurred just because some people are spending time working on both. Splitting their time. But yeah, so that's one thing is Kepler is actually not part of this umbrella. So yeah, what do we do? We focus mostly on the chain development front end. We have a data team as well that provides all the info page but then it's also what's used by Coingecko and Defi llama and any integrator if you want to get your asset listed on Coingecko, you need to provide a price. And so we worked with them to make sure that Osmosis Dex data is valid and can count for that. Yeah, and we've been spending a lot more time on Cosmos developer tooling, building up more of a Cosmos team internally. Historically our team had been very Cosmos SDK proficient but not so much on the CosmosM side. But in the last six months we've been sort of what we've realized is that we want to do more and more of our development in Cosmos rather than the SDK and like some core modules that like treat the SDK as kernel code, use it when you need it, but like more and more stuff can be written in Cosmos. So we've been building up that team. Our team is fully remote. I don't think we have more than three people in any one city other than maybe Seoul. But yeah, so that definitely makes things harder. But what we try to do is meet up in person once every three or four months and try to do more sub team meetings as well. So we just did this front end team retreat in Taiwan in January and there we kind of like it was good to have some in person time. We were able to knock out a lot of design work on where we want to see the osmosis front end going from here and stuff. Especially on the contrary liquidity design stuff. A lot of mission alignment is a big thing. Right. I think our team was very remotivated after the FTX collapse to be honest, because there was a period there where it was like, oh, is FTX just doing everything that DEFI does but doing in some magically regulatory compliant way and stuff. But I think that know after seeing the whole FTX collapse that has definitely like reinvigorated a lot of the team of like oh, this is why we have to build DEFI stuff. And then I think, you know, we, we, we, we do a lot of like sort of learning sessions and stuff. Like you know, a lot of our chain development team, like we're really focused on like we're doing a lot of like zk. We're all going through this like zero knowledge course together. Like this MOOC that's available online. We try to do these like white paper circles on like a monthly basis. Yeah, I mean admittingly it is hard to build a company culture when everything is so remote. And so this is why like you know, we try to, whenever we do meet in person, try to try to foster that as much as possible. Like so like another thing like you know, we would do like we have an office in Berkeley that like we don't often use but what we try to do is like do like month long retreats there. So like we, our entire team, like chain dev team would go to Berkeley for like a month. And that's where we just started. Like the goal was to not to knock out a lot of concentrate liquidity at that time. But then the whole dragonberry stuff happened and that kind of got in the way. I think step one is get metamask usable with osmosis. So there's a way of. So if you look at how like Injective does it, they kind of do this where you can use MetaMask as the wallet for interacting with Injective. And it's like this like we actually built a version of it as well like a while ago, but we just never shipped it at the time. Got busy with other stuff I think. But yeah, so, but yeah, make it so people can, there's ways of hacking it so you can make causes SDK transactions with MetaMask and I think make getting rid of that onboarding step of having to have people install a new wallet just to start using the system I think will massively like reduce that overhead. And so and then the idea is like okay, when you want to get the premium experience then you should switch to using Kepler. Like our approach to wallets is to take this like T strategy where it's like let's support many wallets but then like make sure we have really proper integrations with one of them at least. So that way you know, you can use it, start using with anything. And then if you want the Premiere experience you should switch to the, you know, one that is, you know we spent the most time doing proper support around. So yeah, that's one the stuff we're working on with Axelar to like make, make bridging faster. Like there's this thing called for call that instead of you know, waiting 15 minutes for the eth transfer to arrive, what can happen is you can send, let's say you start bridging your ETH and there's a 15 minute finality period on Ethereum. What can happen is any market maker can say, hey if you want to speed up that, you can say a market maker can send you eth on osmosis and then when your ETH arrives over the bridge it goes to their address instead. So it's sort of like this like liquidity time preference market that's built but e into the bridge itself. There have been a couple of people who've tried to build, like, liquidity time preference markets, like outside of the bridge, like connect. Tried to do this first, I think, but I think when you build it into the bridge, you actually get a lot of, like, benefits. So, yeah, you know, this is sort of a design that we came up with that the Axelar team is now implementing. Yeah, I think those are sort of some of the main things. Hopefully we'll be able to do, like the cross chain swaps as well for from Ethereum. But that's like we're starting with from Cosmos chains right now. And then if that works well, then next step would do it. We're doing it from. From EVM chains.