**A** (0:00):
All right, everyone, welcome back to another episode of Bell Curve. Before we jump in, quick disclaimer. The views expressed by my co host today are their personal views and they do not represent the views of any organization with which the co hosts are associated with. Nothing in the episode is construed or relied upon as financial, technical, tax, legal or other advice. You know the deal. Now let's jump into the episode.
**B** (0:26):
I actually don't think people are users of Ethereum. I think they're users of applications, but also more importantly, they're users of MetaMask. I think the lock in isn't actually Ethereum. The lock in is Metamask. And today what makes an Ethereum L2 like Polygon easier to use than Cosmos, like Osmosis, is that you don't have to download a new wallet. Right? Because you already are already have MetaMask installed.
**A** (0:53):
All right, buddy. Episode one. Miles. Excited to do this with you, Ben.
**C** (0:57):
Yeah, me too. I'm, you know, we bring on Sonny and Dimitri. I think these are two of the leading thinkers of the space and just a great way to kick off the season.
**A** (1:05):
So maybe why did we, you know, this is obviously intro to season one. We're going to be talking sort of big picture. Although honestly, the interview did get a little bit technical at points as well. That's part of the good thing about Dimitri and Sonny. But why do we pick these two to sort of kick off. Kick off the season?
**C** (1:19):
Yeah, I think with Sonny, he is probably, you know, the builder of the most mature application specific chain in the space right now in terms of Osmosis. And I think he's really been one of the leaders in trying to push this, I would say reorientation from thinking about decentralized applications, thinking about blockchains really from an application first standpoint rather than a chain first standpoint. And I think we'll hear him really kind of dig into that over the course of the episode. And then on Dimitri's side, he's coming from the perspective of an investor and he's thinking about, okay, if we do believe that applications are going to want their own block space, what is the spectrum of the different versions of this look like? What does the end state market structure look like? And I think he's done a great job exploring that in the past.
**A** (2:16):
I totally. It's actually always good to get sort of a builder and investor because they, they're both very smart, but they kind of come at it from different angles. And I think when you get the two of them, you get some Some pretty special. Yeah. Some pretty special content. Well, this was, this was a fun one, I think. Without any further ado, let's just, let's dive right in. Welcome to the first episode of season three of Bell Curve. Very excited to be joined by my new co host for the season, Miles o'. Neill. And we've also got Sunny Agrawal of Osmosis and Dimitri Berenson of 1KX to explore the app chain thesis. So guys, welcome all to the show.
**D** (2:49):
Thank you. Good to be here.
**A** (2:50):
Maybe we could start from just. Since this is the first episode of the season, just sort of a 10,000 foot view and Sunny, maybe I can pick on you a little bit here. But if we could even just start with something as basic as, you know, what are app chains? When we talk about app chains and if you had to put the broad contours around kind of the app chain thesis, why do people sort of get excited about that term?
**B** (3:10):
Yeah, sure. So the what app chain, it's short for an application specific blockchain. I think what we get maybe to talk about the app chain thesis before we even go into app chains. I think there's. I have to make a pitch for why applications are valuable and that then will later lead into why app chains. You know, why applications are valuable. You know, so in crypto there seems to have been this like prevailing thesis that has been around for the last about five years, ever since the like infamous Union Square Ventures like blog post about it called the fact Protocol Thesis. And it's been around this idea that like, hey, you can build this like generalized L1 and you just get other people to build stuff on top of it and. But all the most of the value accrues to the like L1 token. And it's like, and that's been sort of this like primary thesis that's been driving this like L1 driven investment over the last, especially over the last bulls, like this last bull cycle where like, you know, most of the investment flowed into like your avalanches and Solanas and stuff. Where it's like, oh, look at these generalized platforms. A lot of builders on top of it. And this is sort of like a bet on infrastructure, right? It's like, okay, if you can build the rails that everything runs on, that's what's where the value accrues. And this bet has been made before in the 90s, right? Where like, if, you know, we're in web three now, if you look at like the original web people were as, you know, the dot com bubble was happening. And you know, the Internet was really heating up. People were like, oh, how do you bet on the Internet, this growth of this new thing. And a lot of people, those are like, oh well you bet on the pipes, right? Like you bet on CompuServe and AOL, they're building the pipes that the Internet is running on. And you know, as the Internet grows, that's where the value is going to accrue. Now if you look back in retrospect, we have 30 years of background. Looking back now, it's like no, those actually weren't the right bets to make. Copy Server AOL kind of died off effectively. Really the two best bets you could have made in the 90s on the web were Google and Amazon. And those two were applications. And the thing is, applications really in my opinion are where value accrues. And like, you know, because they, because of a number of reasons, right? They, they're like much more stickier and they're not, they're non commoditizable, they have like a direct relationship with users in a way that the pipes don't. And so you know, today I actually would argue that people aren't necessarily Ethereum users, they're Uniswap users or they're AAVE users. And as these applications go multi chain or as I suspect will go app chain, you know, the, the user's relationship with the actual blockchains, what kind of gets like it, it's intermediated through the applications and the, and that's why the applications are really where this value accrues. And how this now then relates to the whole app chain thesis which is like, you know, look at today now actually the two biggest Internet services providers are actually Google and Amazon as well, right? Like you know, you have AWS and Google Cloud because it turns out the people who build the applications have the best knowledge of what's needed from the infrastructure to build the best applications. And that actually enabled them to build the best infrastructure layers as well. And that's kind of almost a claim of app chains as well that by like, you know, the app developers actually know better of what, how to build proper infrastructure than these like pure infrared builders. And that's why these app chains are going to sort of win out and like, you know, we can design the infrastructure for the needs of applications in a way that generalized blockchains can't. So I know I talked for a little bit, I'll let maybe someone else jump in with some, but that was a little bit of background on how I see value Accrual in blockchains.
**D** (7:46):
I have a, like a different world view of like how to cut it. I mean I agree with everything you said. I guess to answer the question, like I define an app chain as a blockchain that dedicates its block space to a specific application, which is like a very simple way to, to describe it. And that definition also is quite broad in the sense that you could consider Bitcoin to be an app chain or you could consider arweave to be an app chain as well. I think the concept itself is not particularly new in that like it's been implemented in many ways. I think there have been projects like Cosmos, Polkadot that have generalized that idea, but it's actually been around for a while. I view it also as like a scalability thing and an evolution around realizing that there's a general like with blockchains there is a product market fit for block space. You know, I think of block space as effectively like a market for trust. And over the years we've seen more and more demand for these trust minimized markets in a way that no specific instance could scale. And so we've seen that around like the, I guess around like 2020 where you look at super high gas fees. A lot of this we've seen on like Polygon. And that kind of prompted the development for other ways to scale. And a very basic idea was that hey, instead of stuffing everything inside of like one state machine, what if we just like have like very specific like little like pockets where applications could do their own thing. And I think that's like a interesting paradigm. The last thing I'll mention is that I think we're talking about app chains in, in the context of like a full stack solution. So just like to frame it. I think a lot of people when they think about app chains they, they think about a cosmos chain where it's like from like all the way down to the consensus level. I think that also exists along a spectrum. I actually consider like application specific roll ups to be an app chain as well. You know, I kind of look at a roll up as like a trust minimize blockchain with a two way trust minimize bridge. So there's other terms you could start to introduce and I think we have already too many in crypto, but like a roll app or like an app space concept. So I also want to like talk about the notion of app chains with this idea in mind where like I like, I'm bucketing roll ups in, in that spectrum as well.
**C** (10:52):
Yeah, and I think that Spectrum is really something we want to dig into today and really for the rest of the season as well I guess for simplicity. And I'll throw this to Sunny first. In the context of a full stack app chain, what would you say are the most compelling reasons to build an application as a full stack app chain? What are the things that you can do when you vertically integrate and maybe some examples, whether it's osmosis or other app chains that you've seen, you know, of some of these benefits in action.
**B** (11:23):
Yeah, but I would say I completely agree. I actually, you know, roll ups are, you know, application roll ups are just blockchains that use like different security. Like you know, where how a security mechanism works is I think almost a side concern and when on whether something's an app chain or not. And I think like the way security is going to look even on Cosmos is going to be like very different than it does today. Right. Like you know, as we move towards mesh security and like, you know, validity proof based like ibc, like, you know, all of this is going to look very different anyways. So yeah. So why would someone choose to build an app chain in general? One of the biggest reasons. Okay, you know, I think there's a different reason, right. One is, you know, you just want to have more ownership over your block space. Right. And that, you know, this is really valuable when you're running on a generalized blockchain. You know, you are basically like competing for that block space. And you know, a suddenly a really popular application could come up in which their users are less price sensitive towards gas and then you know, drive up the price of your block space as well and like this just leads to a really bad UX. Remember like I remember the meme back in like 2017 was like, you know, know how are we supposed to pay like you know, you know, you can't do your groceries with on Ethereum because every time there's an ICO there's going to be like, you know, gas price doing a transaction cost $50. Okay. Back then it was ICOs. Maybe now it's like NFT drops. But you know, there's always these like one off events that cause random like unpredictable spikes in demand for block space. When you have your own app chain where there's like nothing else happening in that app chain, you, you know, you don't have these unpredictable spikes that are like out of your control of your application. And the other thing you can also do when it comes to block space gas kind of related things is like do application Related subsidies of computation. Right? Like there are things that you might want to do in a blockchain but that like because it's an application specific blockchain, there are like public goods for that blockchain that are subsidized. So like in example, this is what pre compiles and Ethereum effectively are where they're like for example, like doing a Shaw hash in Ethereum or verifying a signature in Ethereum is actually that that computation is actually subsidized relative to what it actually should be. But it's because it's like, okay, you know, we need to provide this because it's necessary for things to most things to work on Ethereum as an app chain. You can make more pre compiles for different things. Let's say you are an AMM based blockchain app chain which you know, osmosis is. And it's like, oh, why don't we build a pre compile? You know, we have to do this like heavy AMM computation math to like do stuff. Why are we not just like subsidizing this? Because this is like, you know, a core part of the protocol. We can actually like, you know, make it so we don't actually have to run this in a vm. We can run this as pre compiled code. There's all this sort of like benefits you can do there that give you all these benefits on the block space level. So that's like the block space argument for app chains. There's also like in my opinion, just like the, the innovation side of app chains where when you're building a application on a generalized blockchain, you're, you're often very constrained by the limitations of the platform that you're building on and you have very little ability to change them. Like, you know, here's a new limitation of the EVM that I just encountered yesterday that frustrated me which is I can't as an, as a EOA account, as an I can't send eth and weth in the same transaction. These have to be two different transactions. And that was like this is mind boggling, right? And it's like, well, on an app chain I can go change how my blockchain works to go allow myself. I want to be able to do that. I can go change the code to be able to do that. I want to go. And a place where being able to go change stuff at the protocol layer is very interesting, especially if you're doing new cryptography. I think it's interesting to note that not everyone but almost every interesting project that's doing something interesting with privacy is building on Cosmos and building an app chain. Right. Whether it's, you know, a noma penumbra, a secret network, like, you know, because you really do need this like sort of low level control in order to like really on the cryptography side of things, to innovate. Like just think about how many debates today our time is spent debating on like, which EIP is going to get implemented next in Ethereum. And it's like, okay, yeah, you know, this one's going to be slated for two years from now. As an app engine, you don't have to participate in these debates because you can just be like, I'm going to go change my blockchain to do the things I need. And that's sort of one of the things. One of the big bets of Osmosis is your uniswaps of the world are going to be constrained by the platforms they're built on. Osmosis, we don't control just the application, we control the application, we control the blockchain. And, and it just so happens that our team also builds the Kepler Wallet, which is like the primary wallet for the Cosmos ecosystem. So we have this like extremely full stack control that enables us to innovate. It's the Apple thesis, right? Apple's whole take was like, okay, we're going to build the phones, we're going to build the software, the os, we're going to build the most popular apps and now they're even going to go build their own chip. Now they are building their own chips and hardware, but their bet is that they can build this like highly vertically integrated stack that provides the best UX and performance to users.
**C** (17:22):
I think that makes a lot of sense. And you know, I think we can peel back whether this applies at the roll app layer or not. But what are the, some of the things you can have your validators actually do for you when you, when you control the set? You know, which is kind of a lot is spoken about about the, you know, the downsides of needing to bootstrap your own validator set. But I don't think a lot is really talked about in terms of, you know, what you can ask your validators to do. What if they are, you know, dedicated to just your application?
**B** (17:51):
Yeah. So a cool thing that you can do is, yeah, you have this set of nodes with stake behind them that are basically voting on every block and this actually gives you an opportunity to ask them to add more data along with their votes. And so some of the things that we want to do is like one of the things that we're really focused on is this thing called threshold decryption. It's an MEV resistance strategy. But part of what makes the threshold, there have been proposals of like, oh, we can add threshold decryption using meta layers on top of Ethereum. But the problem is you actually run into all these issues with how you deal with reorgs and stuff. You actually want your validator set of the consensus layer of your blockchain to also be your threshold decryption set. So that way as blocks progress, decryptability of transactions is atomic with finality of blockchains. You can't decrypt a transaction unless it's finalized and added to the blockchain and you can't finalize a block without having it be decryptable. And so having the same set be doing both of these things is really valuable. Another example of what you can ask them to do is Oracle updates. Right? Like, you know, almost every, not every single one, but I would say a vast majority of DEFI applications today do rely on some sort of Oracle. And for so many of them we've just come to rely on like chainlink as our, like, okay, this is our Oracle source, but really that's kind of actually pretty centralized and more importantly, it's not atomic with block production. Right. You have no guarantee that chainlink Oracle updates will actually enter the chain in a timely manner. Meanwhile, instead, if you had it so your validators were the ones providing the Oracle updates, you actually have a strong guarantee now that Oracle updates are, are arriving in a timely order and you can depend on that. So, you know, it's probably not the most popular topic, but this is actually something Terra did pretty well. Right. Like they're, you know, during the entire crash process, their Oracle worked extremely well, almost too well. And like, and like. And that was possible because of the fact that it was the validators who were atomically providing the Oracle updates during the block production process.
**C** (20:20):
Yep, that one. You know, we don't like to talk about it too much anymore, but that really was kind of the first example of what we've seen there. I think DYDX and SEI are another example where we'll see off chain order matching so you can run the order book actually on the validators themselves. Yeah, I think we've also seen, especially with osmosis, a lot of benefits to the UX between custom V models, custom transaction ordering. And that kind of also leaves to the value accrual side. So not just MEV mitigation but also potential value accrual. So I don't know if there's anything you want to add there.
**B** (21:00):
Yeah, I can talk about. Those are good two points. Custom fees. I think that's a really important one. One of the biggest, I don't know, pain points I've always felt with almost every blockchain I've interacted with today is like the way that it demands fees be paid in a, in a specific token. I remember like the first time I tried to show a friend how to use Ethereum many years ago. I like made him open a wallet, I sent him some dai and I'm like, cool, now try sending it back. And we realized, oh wait, he can't because he doesn't have any eth. This is fucking stupid. And so, you know, one thing that we were, you know, frustrated with this one thing that we were able to do in osmosis is we're like, hey, we want people to be able to pay fees in any token they want. We have keyword prices from our dex because it's an app chain. So we can use those as a way of like allowing people to pay fees in any token. And that's like, you know, you can, and you can do other cool things with fees. You could be like, you know, oh, imagine you have like a specific nft, you get some sort of fee discount, right? Like you can, you can get really creative with the way that fees work in your blockchain. Or maybe you could be like, oh, if this is a trade transaction, we can allow the swap fee that someone is paying to also like count towards how much their gas fees as well. You can, you can be very creative on this kind of stuff. The other thing is how like transaction ordering works. So like semi related to like Oracle, you know, maybe you want to be like, oh, I want all Oracle updates to go to the front of the block. Your execution layer doesn't have to follow the rules of like what order transactions are included in a block, right? You can be, you can, you're, you can be smarter to actually scan through the transaction in the block, categorize them and be like, hey, I want to execute them in a different order. So as an example, as a dex, right, you know, we have liquidity ads, we have trades, we have people removing liquidity from the pool. Maybe what we want to do is like say, hey, okay, first what we're going to do is look through all the transaction block, execute all the liquidity ADS first. Then we're going to go ahead and execute all the swaps, maybe we batch them and then we're going to execute all the removals of liquidity. This prevents anyone from doing like, you know, rugging of liquidity from underneath the trade. It prevents a lot of like the liquid, the liquidity sandwiching that's happening because it's like, okay, all the liquidity gets added at a fair time. You can actually allow your app layer to be smarter of how you don't have to just let the vm, the generalized blockchain, choose the order of. I was at this retreat where we were talking about a bunch of MEV stuff and what are MEV mitigation strategies that Uniswap could build based on Ethereum? And what we've realized after talking for hours was there's really not a lot they can do unless they have more control over the blockchain itself.
**C** (23:58):
I think that makes a lot of sense. So yeah, I think we've covered whether it's a couple of things. Under scalability, we have increased better UX through things like custom fees and transaction reordering and really user protection. And Dmitry, you also wrote about value accrual in a great piece on AppChain, so a couple weeks, a couple months ago, I'm not sure when it came out, but is there anything you want to speak to there on. On the value accrual side?
**D** (24:26):
On that side, I think if you use the thought experiment of. To say like, if. I mean, we kind of see it with osmo, I guess, but if there was like a uni chain, like do they need to turn on the fee switch? And I would argue maybe not if the transaction fees are paid in their native uni token, which also serves as a security model, because that's another implicit way to accrue value. It's not that you need an implicit fee switch, it's that the demand for the application turns in turn results in demand for the native token because you need that to actually transact on that chain. So that's like a more crypto native business model that a lot of depending on the developer, they. They need to think about another dynamic is that a app chain could effectively fork other protocols and monetize within their own ecosystem. I think we've seen some interesting analogies to kind of what Axie did with Ronin, where they have their own decks, they have their own marketplace, they're able to capture value from the usage of that. And they have users because they provide an application with content that is able to amass a large user base of players. So a lot of these defi protocols, like, it's just code, right? Like, you could take what you need, package that into a verticalized application, and as long as you're providing value to your end user, it's a way for you to keep that within your ecosystem system. I, I think the last part we kind of alluded to, Med, you know, like, I'm, I haven't spoken with like the DYDX team. I don't know if they're doing this, but you could have, like, it's a round robin consensus, you know, like you could have, you know, like if you get every market maker to be a validator on the DYDX chain, that's their business model there too. You know, it's a round robin consensus for, like, who for block inclusion. And so you have a way for market makers to pay for the cost that they have for validating the chain.
**A** (27:16):
So just to kind of sum up where we are so far, because I want to get into eventually some of the arguments for why this might not make sense or what are some of the detractions against the app chain thesis. But Sunny, we kind of started with this high level observation that and this is a dynamic that exists in plenty of traditional markets outside of tech, value tends to accrue to the, the layer that's closest to the consumer. Right. There's that whoever is closest to the consumer, be it an app in web2 or like a financial advisor in finance or whatever it is, they tend to have a lot of leverage. Right. And then they sort of exert that leverage down the chain. And that implicitly challenges some frameworks that I think a lot of people have in crypto, which again, kind of goes back to that Joel Monegro piece, you know, fat protocols. So if you kind of start with that, then you talk about some of the. Dimitri, I think that you group these advantages into three really nice groups, which is sort of performance, which is this idea of like app specific versus general block space. Right. Like even like the other side, Landmint, that shut down ethereum, not in 2017, but last year. Right. So there are still huge challenges for performance in generalized blockchains. There's also value capture, which Demetri, you were just sort of talking to. Then there's customizability, which Sunny, you were getting into with basically the advantages of having validators that only are on your specific network. So these are all like huge benefits. Right. But walk me through, like, what are some of the Downsides necessarily of running an app specific blockchain as opposed to like bootstrapping on Ethereum.
**D** (28:38):
Yeah, I could talk to a couple and the, the issues that are present today, I guess just to preface are not insurmountable. I think that there are ways to, to kind of go about solving some of these and it is also different within the ecosystems as well. I think the biggest one that comes to mind is like limited composability and having, making it more difficult to do atomicity across different chains which is like you, like you want an all or nothing execution of a transaction. I think there are ways to, to get around that but it does add some additional like developer friction. There's also a UX friction. You know, if you have, if, if you require a user to bridge funds onto some other chain or some other roll up. I think that is something that we need to solve to make sure that it is as fluid as possible. And I think the bridging experience today is not particularly accommodating to new users of chains. It's a pretty scary thing for people to do. Another is like the, like the thought experiment if you use, you know, if every application today like on Ethereum were to create their own app chain and they said you know what, I only want permissioned write access. I want to control who gets to do stuff on my app chain. How is that different than the world where we came from where it's like it's permissioned now and now we're just recreating that set of permissioning for the goal of value capture and I guess scalability and all of that other good stuff. And that's an ecosystem wide question I don't quite know the answer to how you balance that. Maybe there's a case that it might make sense for certain flavors of companies, maybe more like enterprise Y companies want their more strict permissions on write access and maybe there's benefits to actually like opening it up for other projects. So that's a couple, I think like the liquidity fragmentation part is also an issue if you have you know, 10 different AMMs on 10 different like I don't know, Cosmos chains or Ethereum roll ups. Like, like how does that affect the, I guess like performance or, or like capital efficiency of the system as a whole. And, and, and, and how do you solve for cross chain cross roll up liquidity pools in a way where, where you're, you're, you're preserving that experience for end users. So there's a bunch of things there, I guess I'll Stop to see if Sunny has any other things to add.
**B** (32:32):
Yeah, I think that was a really good rundown. I can talk about some of what I see as biggest current issues with app chains and then a little bit of what we are doing to help solve those issues. So, you know, one of the first obvious ones that I think we actually ran into was, you know, for a long time the Cosmos SDK was very like almost anti vm, right? We were like, oh, you know, everything will be done in the Cosmos SDK and native go code and you know, all your app logic is there. And then we realized that there's actually things that people do want to customize, right? Like, you know, every time someone wants to create a new type of multi sig or something like that, right? Like, you know, there's an argument that app chains aren't extensible enough, right? And like, so what we realized, and you know, maybe other people want to build integrations into your application, right? Osmosis is a Dex. People wanted to build extensions on top of the Dex, right? People wanted to build a dollar cost averaging system where people wanted to build like a market making vault or something like that. How do you let people build extensions onto your system? And the solution that we kind of came but was, well, okay, well first step one was like, okay, well let's add a vm, right? So there's a VM called cosmosm exists on the osmosis chain. But it's like, okay, then how do you. Did we just become a generalized smart contracting chain at that point, right? So I think what the balance that we figured out was actually Osmosis does something a little bit unique in blockchains where we have a smart contracting system, but the uploading of new contracts has to be permissioned by. Is permissioned by governance. So you have to make a governance proposal to add contracts. So it's like, you know what this does is it kind of keeps it like an app chain where it's like, oh, okay, we're only going to allow things that extend the functionality of our core feature set, which is the decks. We're not going to approve a competing DEX to be deployed on the same blockchain for sure. But we're not going to. Someone wants to go deploy a game or something. It's like Osmosis isn't the right place to do that. Go build another app chain for that or go deploy somewhere else. We want to focus our thing on, keep our block space for the things that improve the Dex experience by having that permission system that's one way we've solved that extensibility so sort of issue and another one is like composability. So you know, Mitri mentioned like, okay, this like lack of atomic composability between things. And you know, one thing I push back on is this notion that composability is means atomicity or synchronicity. Right?
**D** (35:29):
I think it does, yeah.
**B** (35:30):
Yeah, it's like, you know, if you look at the web, the web is relatively pretty composable, right? Like you can have APIs that talk to each other, but like all of the web is built off of asynchronous programming, right. Like, you know the entire web is not running on a synchronous server, right. It's like the entire web is based off of people making asynchronous calls into other services and having callbacks and stuff. And yes, it's more annoying, but it is what is necessary in order to like build any sort of like scalable system. And, and the composability thing isn't really even in my opinion an argument, an app chain specific thing. Even if you had many roll ups or something that were generalized blockchain, you still need to deal with asynchronous composability. If you have a contract on optimism that's trying to call a contract on arbitrum, you still need to build in the same asynchronous composability like building blocks. And so I would just say that I think the Cosmos ecosystem, the IBC stack is probably the furthest along when it comes to building any of these like asynchronous first building blocks. So you know, that's, that's another one. Another big kind of issue that we run into is like standardization. It's almost ironic because so you know, like I said, our team actually builds one of the most popular wallets for the Cosmos ecosystem. And sort of part of this whole pitch to of app change is like, hey, you can come customize everything you want. You want to go change how you know your staking module works, go for it. If you want to go change how governance works on your chain, go for it. You want to change how transfers and work on or cryptography works on your chain, go for it. But then being the wallet developer, as we're like, guys, please don't change too much because like it sucks every time we need to go make a custom integration and like, oh, you change the cryptography, okay, we gotta go build a customer integration for that. You change the how the staking module Works okay, well our staking dashboard doesn't work for that anymore. And so it's like this, this. So yeah, this like tooling based issue is actually sort of one of the biggest challenges that I'm not actually sure I have a great answer for today and is actually one of the biggest almost not threats but you know, big open questions on how we deal with app chains going forward. Right. Like you don't want a world where every time someone builds a new app chain that like it's too different than everyone else. Oh, does that mean they have to now go build their own wallet? Or does that mean that like you know, your favorite staking dashboard doesn't work with it or something like that? So how do you balance these things? I think that's a big, big thing that does sort of need to be figured out I would say. Yeah, I think those are some of the big ones. I have a couple others as well. You know, security, you know, scope creep I think is a big issue as well. Like you know, even osmosis, you know it started off as this dex but now we have this lending protocol building on top of it. We also have like, you know, a couple other. It's like at what point do we actually start to over evolve and let scope creep turn us away from being an app chain? And like at that point what is the depth? What do we even mean by app chain when we have this sort of like sort of little ecosystem of other projects building on top. So I think that's another big thing.
**D** (39:00):
That yeah, like just to follow up on a couple of those points for so atomicity, atomic composability. One area where it's probably particularly useful is in the defi sense around like market efficiency, around flash loans. Like that's probably a special thing where it particularly benefits in the roll up space. I think you might be able to pull this off if you have like a shared sequencer set across different roll ups. I haven't seen that done in practice and we don't have an example of a decentralized sequencer yet. But I can imagine if there's like a, like a roll up that has an AMM and another roll up that has a money market and both are the same sequencers then then they might be able to actually like do those transactions atomically. I think the idea around like tooling is super important because also for a like an app chain needs a couple of components that will let like let it function out of the box which could include like a block explorer, an rpc Provider, an indexer, an oracle. To your point Senate, you could internalize like some of these things and bake it in if you have something that's as customizable as like the Cosmos SDK. But if you were to maybe like fork optimism and just like launch like a roll up like you like you probably need to find ways to add those additional components for your like users and developers. So that's like an additional lift around like overall like developer lift that you need to, to think about. And I, I guess a final interesting observation is that like with com with customizability, it probably depends on the Persona of the developer of like how much composability or customizability do they want or need. I kind of get this feeling that for many developers it could be overkill to customize like everything. Like maybe it's just a game that wants their game as like the native gas token token and like they probably don't know about mev. Like they don't really care about like, like transaction ordering. Like that's all they want to you know, make number go up. So, so for them maybe they just want like a more like a simple out of the box solution. And, and I think like that is probably a UX challenge that needs to be solved for this more like I don't know, mainstream developer.
**C** (41:59):
I think that makes, that makes a lot of sense. You know we've heard about like the bootstrapping costs. There was one thing I wanted to kind of double click in here and that was on the permissioning side because I think a lot of what we've talked about is when you don't have control over your block space, when you can't curate your block space and you become very successful and you attract a lot of users, you're going to have a lot of random stuff that just starts popping up on your chain, right? Whether it's an NFT project on a would be defi app chain or a game on a defi app chain that takes up all the block space. This can be kind of defeat the purpose in some ways of an app chain. And so would you guys just. Do you think that permissioning, governance based permissioning is actually a prerequisite to, to call it an app chain? Under the definition of an app chain.
**B** (42:53):
I think it's important to sort of protect the app chain is especially to protect the block space. Especially like the other things maybe it doesn't matter so much. It's almost like a part of the other reason that we, you know, the permissioning is important not only to protect the block space, it's also it protects your innovation rate as well. Because in my opinion, I think part of the reason Ethereum development kind of goes so slow is it has to deal with the interest of the 10,000 applications built on top. And we've had situations in the past where Ethereum has broken people's smart contracts, right? I remember like back in one of the hard forex like a bunch of the Aragon contracts broke because there was a change in how gas gas co. Like gas pricing worked. And so it's like you know, we, and you know, Vitaliki had a talk at etc this rare where he was almost like oh, you know, prepare to have things break for, for your developer, you know, your contracts break. Which is kind of weird because on one hand we're like pushing for immutable contracts but it's like okay. On the other hand we have to be prepared for these contracts to break potentially. And so when you deal with an app chain with osmosis, before we added CosmosM, the only people we had to talk to at least on a contract, on a builder, on the chainside builders is like ourselves, right? It's like okay, and we have to go talk to some integrators, have to go talk to block explorers and stuff like that. But on the, on the actual chain development side that we only have to talk to ourselves today if we have to go change something in how something works on osmosis, right? Let's say threshold decryption comes alive and but you know, the way that people generate transactions has to change today we only have to go talk to about 20, maybe maximum 20 projects, right? Because like there's only 20 other builders building on top of the osmosis chain and that, that is a feasible thing for us to do as opposed to like Ethereum where there's no way for them to like they, they basically can't innovate because they can't break anyone built on top. And so I think that's one of like the big benefits of the permissioning is that we, we, we protect our liabilities here to, to external developers.
**D** (45:32):
So that's interesting. I'm trying to find another argument here. I guess if you look at it from like a free markets perspective, I wonder if you could bake in like incentive mechanisms and actually like the design of the app chain to just make it either more or less attractive for other contracts to deploy. If you have, if you adjust the opcodes to like if you change the pricing in the op codes to make it like very cheap to swap and like very expensive to do other things. Then you've kind of set up your chain to be, to work better with applications that have to do with that core mechanism. And then you could kind of say okay, like, like we're permissionless, like deploy if you want here, but it's going to be really bad for your users because it's going to cost a lot to do the thing that you want to do. So, so I wonder if you could like get these benefits by having, by, by, by baking your opinions into like the actual like design of, of like the block space.
**B** (46:49):
Yeah, so this I imagine will happen actually. So you know, eventually what we want Osmosis to do is batch all trades, right? Like all trades that happen in a block should be batched together and get equal pricing, which works easily in a world where all trades are executed by users. But in a world where some trades are executed by contracts, things actually get a little bit more complicated and messy. Right. Because what happens when a trade, you know, so what we actually end up having to do is, you know, thinking about how do we architect a block is what we actually have to do is take every transaction that like it's got hit by a contract, we've first run the contract. So one thing that's worth noting is the way cosmosm is designed is it's actually designed to be asynchronous, non atomic by default because it was really designed as a cross chain contracting system. So it's like, oh, you know, you want to be able to have one Cosmos contract, call the Cosmos and contract on a different chain almost as easily as it calls a contract on the same chain. But so what will happen when Osmosis implements the batching system is we actually run the first part of our contract. If it executes a swap, we basically hold that swap, run everyone else's contracts, then we take all the dispatch swap swaps, execute them at the same time and then we go and run the completion of everyone else's transactions. This is such a different paradigm to like normal smart contracting today where you know, you expect your transaction to like run beginning to end before going to the next person transaction. But that, but you know, it's like no, we're designing the way the block space works to be optimized for what the needs of the DEX is and it's the responsibility of the things built on top to sort of adapt to that.
**A** (48:49):
I want to get a sense from, from the two of you like again almost like maybe zooming out and looking A little bit towards the future. You know one, one topic that we wanted to get your guys opinion on is this idea that you know, let's with caveating the understanding that there are other communities outside of Cosmos that are necessarily just pushing for you know, app chains. Right. As an idea but we're going to focus largely on Cosmos and then there are other you know, layer ones outside of Ethereum that are kind of providing like broad based security and data availability and all that kind of stuff but just using those as the two sort of canonical starting points for a similar problem, which is how do we scale and get billions of people using applications and then have them secured and write the appropriate architecture underneath. Like how, how do you guys kind of see like just to use these two ecosystems as an example like Cosmos and Ethereum kind of coming together. Right. Like there's a whole bunch of different spectrums of how this might play out. But like how do you see these two communities like sort of evolving and interacting with each other over the next sort of coming years?
**D** (49:52):
Yep. I think from my perspective it's like an order of operations. I think there's almost like a, a question that is based on the maturity of the app. I think like an interesting observation that I've seen for D5 protocols and some others is that on Ethereum they are launching on L2s first. I, I, I think that's an interesting reverse of the operations because usually a application would launch on Ethel 1 first. Super expensive, but maybe they need like the security and that's where like the users are. So they would launch their application there, gather some feedback and then say hey, like these fees are too, too high. Or, or we could do more things with their application. If like gas fees are lower, maybe it's cheaper for the Oracle updates. So then they move to a L2 and then if they are successful then they, they start to say okay, we have more users, we need more scalability, maybe we need more customizability, then what do we do? And I, in my view that's where the, the decision tends to be like very relevant around the crossover where they might say hey, do I launch my own dedicated L2? Do I just fork Optimism? Do I launch assuming this is built out as a L3 on Zksync or Starknet or is that not sufficient? And for a lot of the reasons that Sunny mentioned, do I need my own full stack Cosmos chain? And there are other options too like do I launch my own like Avalanche Subnet? Do I go on my own like, like Polkadot Parachute. I think that that decision for, for teams becomes more relevant the larger they get. And I think like we've, we've seen that with Axi, with Ronin and dydx. I think like as you get more scale so and, and like, like this is a very, I mean it's probably like more controversial but like my, my view of chains for, for, for successful Cosmos app chains might be more mature error based applications that need more customizability, dedicated block space, things like that.
**A** (52:46):
That's kind of an interesting framing because, you know, at the risk of being overly reductive, you could almost view Ethereum as like a launch pad for dapps. And then once you get a DAP with six, you know, critical mass or whatever it is, and it decides, okay, we haven't really talked about this dynamic of Ethereum being distribution and where the users are is a reason for it being attractive. Right? Um, but maybe dapps kind of start there and then when they get to some point when either the, you know, the pain of not being able to, you know, customize the way, you know, users interface with your app, or maybe you just want the economics and you want to vertically integrate, but whatever that like sort of threshold is, you pass it. And the most successful in that paradigm, it sounds like some of the most successful dapps actually end up moving off Ethereum. That actually sounds a little bit, it could be, could be bearish, right? You don't hear people often say something like that, but I don't know if that, that was the right way to take how you just said that. Dimitri.
**D** (53:40):
Yeah, I mean, I think, I'm not sure if it's bearish in the sense that they will still have options on, on a lot of other factors like for example, security, you know, like, like what, like what are your security guarantees for like your own like settlement layer versus using like Ethel 1 as a settlement. Like that's a very important question for potentially like DEFI protocols and how much are you willing to pay for that security? And even if you do subsidize that with token rewards, is that a sufficient security level that you're getting from Ethereum block space as being like a settlement layer. So I think it's still very application specific. It might be harder to, to make that case for like a DEFI protocol that like that has, you know, billions in TVL maybe. But I think you're like, your point around distribution is an important one because if you're going to like a separate island, like you want to make sure you're able to like carry all these users that you're providing like a valuable enough thing for them to like, like move, you know, like to buy that ticket to like go to like the other like to, to go on the island. So, so I think like that's why it's, it's a harder case for a lot of applications because in general I don't think we have like that much critical mass for, for a lot, for a lot of users today that actually like transact we're probably in like the hundreds of thousands maybe for like defi protocols, maybe more for like play to earn games with a certain example of like Axie. But I think we have a long way to go for there to be enough users with any application for them to make the case that hey, I want to move to like my own like my own dedicated app chain like off of Ethereum. I think that it's, it's going to be a more and more relevant question over time. But, but I don't think like the, it's as clear cut as saying oh like I got, you know, I'm big enough now time for me to like pack my bags and like go to like a different ecosystem. There's like a lot under the hood like behind that decision to the original.
**B** (56:12):
Question of like, you know, so I would say that like, okay, the Ethereum ecosystem versus Cosmos ecosystem is almost like an independent thing of app chains versus generalized chains, right? I think it's almost actually like a quadrant because within Cosmos you have both app chains and you have generalized blockchains, right? You have app chains, you have Osmosis, you have Stargaze, you have Akash, you have all these app chains, but you also have generalized blockchains like juno and Terra 2.0 and Archway and Evmos, right? Some of them are EVM based or you know, there's actually multiple EVM based ones, right? There's Kava, there's Canto, you know, there's like there's actually. So we have this within the Cosmos ecosystem and then within the Ethereum ecosystem you also have. Let's talk about roll ups, right? You have both generalized roll ups, you have Optimism and Arbitrum and you know all this stuff. Then you also have application specific roll ups, you have dydx and you have of, you know, Loop, Ring and Ronin. I would consider application specific kind of a lot of starkware stuff is really targeted at building, you know, very app chain focused roll up. So you know, I think this is almost like a quadrant. So you know, I think we've Talked a lot about like the app, the app chain versus generalized stuff. So on the Ethereum versus Cosmos, if I, if you have to like put like. I think there's two sort of main differences here. I would say that we're kind of actually heading towards the same direction right now. I think we, I think the Cosmos ecosystem had to pull Ethereum in the right direction a little bit. I think like you know, today, you know, you have to keep in mind like today, oh, the world is multi chain. You know, this seems so obvious. Five years ago when we started working on Cosmos it wasn't, this was like a radical thing and no one believed us. And now everyone's like oh yeah, you guys are right. And you know, I think there's other, you know, I think the same thing is going to happen with app change. You know, people still believe in these, you know, everyone's like oh, generalized roll ups, you know, multi chain. But it's like no, you guys are wrong about that. So I think they're going in the same direction. I think the two big change. One of the big changes between the focus of Cosmos versus of Ethereum is Cosmos. We kind of took a lower emphasis on the security relationships between these chains and decided to focus our efforts on the application layer composability between these chains. We said that like you know what, we can, we can hide, we can bootstrap using sovereign security. You know, every chain can have its own validator set. Let's focus, we'll solve that. That problem does need to be solved at some point. How do we scale security? But we can solve that. We have time before we, we run into the bottlenecks there. Let's focus on like how do we build really good cross chain composability? How do you have a contract on one chain? Call a contract on another chain? How do you have a Dex on one chain or how do you have like a lending protocol on one chain? Do liquidations on a Dex on a different chain? Right? These are things that like in my opinion the Ethereum ecosystem just has not been thinking about at all. Meanwhile with the Ethereum ecosystem has been thinking most of spending most of their mental energy on is on that security relationship side. Right. I, you know, they're the farthest ahead on when it comes on developing validity proofs and fraud proofs and like roll up architectures and stuff. And like I think both sides are starting to work on other, on each other's expertise point. You know, I think we're maybe I haven't seen too much of it yet. But I'm hoping, like, people are starting to think a little bit more about composability on the, on the Ethereum EVM to EVM world. I know in the Cosmos world we're definitely starting to think about security. How do we like, scale security, whether it's going through things like Celestial for data availability, you know, shared security systems, you know, we propose this idea of mesh security. So, you know, I think, I know in Cosmos we definitely are starting to think a lot more about it. And I guess the thing is, one of our exploration points is that unlike Ethereum, where there's like one chain, one. One chain to rule them all, one token at the center of its security system, which is like eth. Cosmos, there's no one token at the center of it. Right. Like this whole mesh security paradigm is really focused around this idea of like, oh, we have all of these many Cosmos chains. How can they sort of like pool their security together? I call it like the empire model versus the NATO model. Right. An empire has a single military and it provides security for all of its colonies, while in NATO you have a bunch of sovereign countries. They all have their own militaries, but they form alliances where they have like, you know, pool their economic strength together to provide like a larger security umbrella. So I think that's sort of like the main difference, I would say, between the Ethereum model of the world and how security works and how the Cosmos model of the world works. Yeah, I want to also talk about like this, the user onboarding stuff, but maybe you guys chat about that, what I said first so far.
**C** (1:01:28):
Yeah, no, I think that a big part of the thesis for this season is really that Cosmos and Ethereum are on somewhat of a collision course in that sense, but coming from very different starting points. Right. Cosmos really taking an interoperability at the application layer first approach. And we can start to see the power of things like interchain accounts. Right? That's, that's more or less recreating the level of composability that you would see between apps built on the same chain. And then on, you know, on the Cosmos side, we're also starting to see, you know, the introduction of things like mesh security and you know, the consumer chains that are renting security from, from the Cosmos hub. I would say, you know, do you see, see, for this future to play out on the Ethereum side, there need to be some equivalent of ibc or is it more going to be. I think, Demetri, you referenced shared sequencers between apps that commonly Interact with each other. Do you see it, you know, everybody sharing one standard like you do on the cosmos side or do you think it's going to be more kind of bottoms up, you know, sector specific sequencer, you know sets that help, you know just particular types of apps Interop but you know, perhaps a gaming roll app on Stark where we would never be able to you know, talk to this sort of defi, you know, sector of roll apps.
**D** (1:02:58):
It's a good question. I think the pace of the Ethereum development makes me think it'll be more like like bottoms up like solutions. I think there is ways you could get close with Interop. I think like you have like the shared sequencer set is one way to do it. I think using L2s as a sediment layer for L3s are, are pretty interesting with the use of like recursive validity proofs. There's also ways you could.
**B** (1:03:35):
But that solves the security problem. That still doesn't like saying that we can use L2S as a settlement.
**D** (1:03:42):
So, so, so one way you could do that. So if you have different L3s, post posted data that's needed for the proof onto shared DA layer then then you could have the L2 use, use the data from that DA layer to effectively do the bridging. So like one example is like how Slush, like there's a project called Slush. They're they're trying to implement this on, on Starknet. So, so you could effectively use like a shared DA to do, to do the bridging across different L3s provided. Yeah, like you have like, like the data you could also post if it's like an optimistic roll up you could post the like like the actual data that's needed for a fraud proof onto shared DA. You could also do that with an L1. I mean like that's how implicitly like like bridging is done between say like different, like two different like ZK roll ups. It's using like the L1 as that DA layer. So, so I think we, we haven't like really seen implementations of this but I think that there are ways you, you could get to sufficiently strong levels of composability. With the exception probably being for atomic composability you might need that shared sequencer set or like some overlap potentially between like if you're, if you have like a decentralized sequencer set across different roles.
**C** (1:05:19):
Do you see actual interoperability providers playing a role here? You know we laugh, maybe they all share a common standard but I Think you know, some of you might be familiar with polymer, right? Who is trying to you know, kind of introduce IBC to the EVM side. Do you think that you know, that reliance on a provider, you know, project like that is, is something that's scalable in the long term or is it mainly going to be you know, based off of the security of the actual roll up itself? Kind of like IBC where you're, you know, you get, you inherit the security of the chain really for the bridge?
**D** (1:05:58):
Yeah, I think it might depend on if we're talking about like intra or inter and I think what we've seen recently with like Avalanche, like shipping their own like messaging system. I think chains probably realize this is like a very risky thing, you know, and, and, and maybe it's better for, for users, you know, like, like, like Polkadot did this with what was it called X XMP like years ago. Like maybe it's this realization like hey, if we're within our universe, maybe we should do it ourselves. It, it doesn't solve the issue of like cross domain like look like once you're hopping like, like between like, like different ecosystems, I think that's probably where you'll still need some kind of third party. In the very happy case you find a way to do scalable like client bridges where you're validating consensus on every chain that you're bridging to and from but that's not very scalable and you have some ideas around snow snarking the consensus and validating a proof on the destination chain instead of the actual light client. The issue there is extensibility. How fast can you build this for all the different permutations. So it's a really tough problem to solve but I think there will still be a role, I think 100% for third party bridge providers as it relates to cross domain interop. And then jury is still out how individual ecosystems which could include AL2 like how Zksync or how Starknet wants to think about Interop or how optimism Bedrock is thinking about it.
**A** (1:07:54):
So guys, you've both been super generous with your time here and I think as we start to wind down, you know, we've covered a lot of ground. I think you know, kind of talking about this idea of like fat or I know some of you like to refer to them as tall apps specifically and where value might accrue. Talked about some of the pros and cons of app chains as opposed to other sorts of architectures and this sort of collision course idea between Ethereum and Cosmos. Just if either you guys have like sort of ending thoughts or something that you want the audience to walk away with when it comes to app chains, could be thoughts about like, you know, where they're headed in the future or even next 12 months. Just anything that you want to sort of bookend the conversation with.
**B** (1:08:32):
I just wanted to add one last point about the like user thing that we were discussing a little bit ago as well about like, oh, you deploy on Ethereum or on the Ethereum ecosystem, whether that's L2S, because that's where the users are. You know, like I said at the beginning, I actually don't think people are users of Ethereum. I think they're users of applications, but also more importantly, they're users of MetaMask. I think the lock in isn't actually Ethereum, the lock in is MetaMask. And today what makes an Ethereum L2 like Polygon easier to use than Cosmos, like Osmosis is that you don't have to download a new wallet, right? Because you already have MetaMask installed and the process of switching things on the wallet is actually becoming easier and easier. Right? So you know, this is, and I think you can actually, I think that this is something that we're starting to realize in Cosmos. Like, you know, we probably should build better integration support with existing Ethereum tooling that people are comfortable with if we want to make the switching costs lower. So for example, with Osmosis we are like Injective does this. For example, Injective is a Cosmos based dex. They don't actually use Kepler as their primary wallet, they actually use MetaMask as their primary primary wallet. And same thing with Evmos. And so one thing we're working on, Osmosis is making it so that you can use, you're bridging assets from Ethereum, you can just start using it with your MetaMask, right? It should feel like any other Polygon or any other Ethereum EVM chain, right? Even though it's not an EVM under the hood. So that's like one big thing that we're doing. But at the same time, you know, we do need to balance this with like, you know, there's a reason we build our own wallet called Kepler because we have like views on like how crypto custody is supposed to work and stuff that, you know, we don't want to be. The same reason that we have an app chain that we want to be able to innovate at the application layer, at the blockchain layer. We also have our own wallet because we want to be able to innovate at the wallet layer. But I think so it's a little bit of both. You know, how do we get people to on board with MetaMask and be like, okay, cool, now you're using osmosis. By the way, if you want to use all the coolest features of Osmosis, you should switch over to using this other wallet instead. But yeah, so I think that fixing that onboarding flow with the wallet will be a big part of bringing people from Ethereum into Cosmos and any app chain. Really.
**D** (1:11:06):
Yeah. I think on my side, I don't think there's a right answer. I think we've been researching for that and I think the board boring answers like, oh, like there's no one right answer, you know, like it's not for like every developer and I think there's a lot of trade offs, you know, from a, a developer perspective that they need to, to, to think about around like what's your security source? Like what, like how do you want to deal with permissioning? Do you need finality? Like what do you want to do with like, like your gas token? How much composability do you need? Do you need EVM support? And I think these are all questions that different applications and different developers might answer in a different way. So I think this is all along a spectrum and I think there's a multi year play out in the market structure that, that we're going to see. So I don't think like we have the answers now. I think there's interesting projects coming out that are providing SDKs for, for developers to launch their own app chains which could be ZK rollups using Celestia as DA Sovereign roll ups, Sovereign Optimistic rollups that use Celestial as a da, Ethereum rollups that use Eigen Layer as a da. So I think we're gonna see a lot of these solutions come out and I think we're gonna start to get some of the answers just through like observing what developers will do. So I think it'll be interesting to revisit this in say like 12 to 18 months and actually see like what we got right or wrong about the market structure.
**A** (1:13:05):
Guys, this has been fascinating. You've given us and our audience a lot to think about. So thank you both for helping Miles and I kick off season one. And, and if, and if folks want to find out more about you or follow the work that you're doing or what's the best way to sort of get More information on the two of you.
**D** (1:13:21):
D Barrons and on Twitter. D B E R E N z.
**B** (1:13:24):
O N Sunny A97 on Twitter and you can follow Osmosis. Osmosis Zone.
**A** (1:13:32):
Awesome, guys. All right, thanks so much. We'll have to check back in 18 months, see how much if we sounded smart or way overly optimistic. But I'm feeling optimistic myself. All right, partner, Episode one of the books. What do we think?
**C** (1:13:44):
Thought that was great. I thought, you know, I think Sunny did a great job in the future beginning of just running through the most compelling reasons to build, you know, an application on an app chain or as an app chain. You know, I think as well we'll dig into later. We'll. We'll see how many of these benefits still apply when you start to make that, you know, tall app less tall. Maybe it's, maybe it's an app specific roll up and that only allows you to do, you know, 75, 90% of the these things. Maybe it's less. I think that's still pretty unexplored and also depends a lot on, you know, developments to interoperability and basically the things that kind of mitigate the con side that Dimitri dug into and covered really well.
**A** (1:14:30):
I agree with you. It's fun. Like I really liked his sort of opening, you know, even before getting into what is an app chain, having to make the case that applications matter, which is such a funny know caveat to have to include. But I think I thought his observation was completely right that, you know, Joel Monegro wrote this post, FAT Protocols, you know, FAT Protocol thesis a long time ago, you know, before, you know, at a time when crypto is way less developed than it is today. And I think a lot of the industry implicitly believes that, basically. And that's why you have these large and really engaged communities around, around Bitcoin and Ethereum and some of the layer ones. And also to the industry's credit as well, if you were trying to analyze returns, the L1s have been by far the best performing asset class or sector within crypto. Even like on Ethereum, the apps denominated in ETH is like down only, right? They basically launch and then it's down.
**C** (1:15:30):
Exactly, exactly. But yeah, for framing it in terms of, okay, you know, actually these aren't Ethereum users. These are Uniswap users. These are OpenSea users. These are Metamask users. Right. That's the value of Ethereum, right. Is is based off of the amount of activity and the applications on top really determine how much activity there will be. Right. And so as these apps get more users and more traction and, and more leverage, frankly to take their users where they want to go because the apps are the stickiest layer, you know, it will be, it'll be very interesting to see if these, you know, how many migrate to Cosmos to get more of these benefits that Sunny's talking about versus how many of them migrate to their own app specific roll up or, you know, maybe sector specific roll up. But really, you know, reframing the conversation back to the applications and back to where the users are, I think that's kind of the whole point of, of this, of this season. Right.
**A** (1:16:25):
I would even call it like it's a reorientation in a lot of people's minds. Right. Which is like this sort of maybe you were starting from this point that you didn't even realize, which was, oh, these are the rails and values going to accrue here. And then there'll be some interesting apps to like, ultimately people use apps. And you're right that, that phrase that Sonny used right at the end there, I love the way he, I love the way he framed that because it's actually how I felt as being a user and defi. And for those of you who are listening, Miles has been in some ways my sort of guru shaman, you know, Sherpa on my own on Chain Journey and you've helped me a lot. But you know, I've had the, you know, I've had the feeling when I'm using these apps like this, this is not the end state here. Right. Like me messing around on like Ethereum main chain is like not what we're building towards here. I'm not the natural user of this. Right. So.
**C** (1:17:12):
Right.
**A** (1:17:12):
I totally agree. You want to use an application, be it a game or an NFT or something that doesn't even necessarily exist yet, but you know, the way people operate and view themselves as an ETH user and you're doing all this stuff that's not going to be the end.
**C** (1:17:26):
Yeah, yeah. And I think, and I think today still there are far more users of centralized. Right. Crypto services than there are of decentralized crypto services. And I think, you know, Osmosis stated mission is to build the binance on chain. Right. And in order to recreate that user experience, the performance, you know that that is the reason why they're building as an app chain. They think that it is and it also user privacy, all these little things. Right. And so I think, you know, that reorientation is really helpful in understanding why anybody is building as app chains when, you know, ostensibly they kind of live on an island and make people jump through a bunch of hoops at the moment just to onboard. But, you know, the best version of them probably is the closest thing we can get to these centralized, you know, products. But you don't have to deal with all the trust of centralized products.
**A** (1:18:20):
And one word that we didn't, we didn't really use during that interview, but you and I sort of use in a somewhat joking way. But it's kind of this idea of like product maximalism, right? There's been no shortage of maximalism and crypto. Crypto, but usually that centers around like an L1 ecosystem, like Bitcoin or ETH or something like that. Whereas this kind of. And Cosmos, I think, even though they don't really call it this, they sort of pioneered this idea, right, which is like a relentless focus on the product and the user experience. And I think that's going to be a theme that's going to run through, you know, hopefully all of these.
**C** (1:18:50):
All of these, yeah, yeah, exactly. I mean, that's where you and I are coming from. We don't have, you know, any ideological bias about which chain it should be built on. We frankly don't care. We just care that there are products that people actually want to use, and that's what's going to drive the mass adoption of decentralized applications.
**A** (1:19:09):
If you start from that high point of product maximization, ultimately we want apps that hundreds of millions, eventually billions of people use. Then underneath that there's a whole bunch of things that need to happen.
**C** (1:19:22):
Right?
**A** (1:19:23):
You could call it kind of the architecture of like an app chain underneath, or you can call it the security model. But ultimately, if you're, if an app is very focused on kind of the execution environment at the top, then there's like data availability, there's consensus, there's a whole bunch of stuff that needs to happen underneath. And that was sort of where we were getting into the Ethereum approach or starting point versus the Cosmos starting point 100%.
**C** (1:19:46):
And that's really where the Spectrum Alto that Dmitri was talking about plays out. Right? Because at the end of the day, I do agree with this definition of an app chain is just an application that owns its dedicated block space and it can curate that block space and optimize it for its own application. And I think there's going to be a lot of different flavors of these app specific environments. And that's peeling back kind of of the the current trade offs to each specific flavor of it is something we can dig into this season and also thinking about, okay, in one or two years based off of what's being developed to kind of mitigate some of the trade offs of that. What, what could this look like? Right. And so, yeah, I think, I think we'll, we'll, we'll further explore that as we go on the season.
**A** (1:20:36):
One thing that was sort of stuck out to me not, you know, was, was this idea that capture happens not at the Ethereum level, but at the Metamask, at the wallet level. So Jason, Jason's been really digging into this idea of like the wallet, the wallet wars. And actually it's funny because I can't, I can remember when I was first getting involved in crypto, you know, it was the rollover of the 2017 bubble, so everything was going to be useless. But the two things that people were very bullish on was custody and wallet wallets, which is kind of the same thing. Right. But like one of those ended up playing out big in like Bitgo and Anchorage and you sort of saw the rise of these like institutional custodians. But the retail wallet, it like never really took off. Like maybe because bear markets are not a period of time when, when a lot of new retail users sort of come in. But it always kind of amazed me that, yeah, like, the wallet level is so critically important and doesn't get a whole lot of time.
**C** (1:21:31):
No, no. And something we haven't really talked about because we've been talking about, you know, vertical integration going down from the application level. But, you know, we'll see with Uniswap and to some extent with Osmosis already. Right. Applications that also want to own the wallet. And how does that, you know, I guess having a, you know, better ownership of the customer. Right, by owning the wallet. And the touch points, how does that play out against the friction of making the user create a new wallet? You basically have to own those customers to begin with or else you're adding another layer of friction that just might be too much. And so we haven't really talked about vertical integration going upwards, but that's something to definitely explore as we chat about it with more folks on the season.
**A** (1:22:23):
When it comes to vertical integration as well, there's like two sort of big benefits to keep in mind that we kind of like touched on both, but just like highlight it for people who are listening. There's the economic reason why you'd want to vertically integrate. You want to be able to, you Know, extract more fees basically from every layer in the stack. But then there's also, and it seems like this is more important to Sunny, which is you want to be able to control every part of the, of the user experience, right? From like the wallet to the exchange, etc. The, the downside of that, right, is that it's more surface area for, for governance. I know. So.
**C** (1:22:56):
Yeah, that you've made. Yeah, exactly. We didn't really get into that as much today, but I think we did get into the permissioning side. Right. Which is great because you can curate your own block space and it's still decentralized because it's through governance. But you know, to Sunny's point, what happens when govern governance decides that they no longer just want to be an app chain anymore, right. And you start to get into some challenges around scope creep. And I thought Dimitri brought up some really interesting examples of how, you know, you might be able to abstract that away from governance or, you know, ossify this sort of, you know, curation into the protocols dynamics by treating fees differently for different sort of chains. So I thought that was another very interesting piece because, yeah, the scalability of governance is definitely a big question here.
**A** (1:23:47):
Sunny at one point drew his quadrant, right. Like his quadrant example, which I think. And now something is kind of clicking. Before we recorded this, had a talk with Dimitri and he was describing how he thought it was inappropriate to basically call it app space. And I think of big a way that I'm now kind of thinking about this is there's like generalized blockchain space and app specific space. Right? And like that's actually a more. Because there's so many words now, dude. There's like roll ups and roll ups and L2s and L3s and like, honestly, maybe the most appropriate delineation is just like how far away you are from the settlement layer and then whether or not it's specific, specific dedicated to one specific app, to type space and then. Or general sort of a blockchain space.
**C** (1:24:34):
Exactly, exactly. Because you could, you, you couldn't say like Cosmos is just app chains, right? Because, you know, to Sunny's point, all these things exist, you know, and that's. That life cycle, I think, is where for, for every effort, every application is where this becomes very relevant. Right? So at what point are you in. In your own life cycle and, and where does it make sense as a starting point based off of that? Is it on a general purpose? You know, L1, any sort of smart contract platform, general purpose, L1, L2. Right. And then as you grow, you know, are you going across that spectrum and getting closer to having your own dedicated app space and maybe expand vertically even more with your own app chain? But yeah, I did, I did like that spectrum or I guess the cross here between general purpose and app specific.
**A** (1:25:21):
You pulled out a super interesting point in that as well, which is the permissioning argument. That was when Dimitri kind of framed that as like, you know, how do you. Okay, so it's all very well and good to say this app, this specific block spaces for this app, but how do you actually enforce that? Right, because people might, you, you might, as the creator, right, of the, of the block space, you'd be like, I want to only use for this specific thing, but in a lot of sense permissionless. So people could just start using it for other things. And how do you enforce that exactly?
**C** (1:25:51):
Interesting question. Kind of defeats the purpose. And you know, I think just to touch on again, I see three general approaches here. There's the governance, you know, gating from that, permissioning of contracts and permissioning for chain upgrades. Obviously there's sort of implicit gating that we were talking about just now in terms of treating maybe disincentivizing certain types of activity with higher fees. Then there's of course just non, I would say almost enterprise roll ups. And like we see this with like so rare or some of the other stark net roll ups that this is basically one company that's, that's saying, okay, you know, you're getting most of those benefits of security from Ethereum because it is, is a ZK roll up. But at the end of the day, right, this is, we're kind of in charge of this and you're coming here for a specific reason, right, to trade NFTs or you know, to trade on DYDX. But how important will it be for them, you know, to actually decentralize that sort of permissioning and, and just how effective is it through governance versus other ways?
**A** (1:26:59):
All interesting questions. Anything else that you found particularly interesting? You wanted to find highlighter?
**C** (1:27:04):
I think that, that, that mainly covers it. I think we're going to get, we're going to dig into the, the interoperability piece quite a bit more over the course of the season because I think it's mainly a question of, you know, okay, if you see this is kind of the direction Ethereum is heading. What, what needs to be built in order to get there, what sort of standards need to be established, right, to enable that same sort of Async composability that you can get with IBC on Cosmos. Is it you know, going to be a top down approach where Ethereum says okay, you're going to have this built in standard like we talked about or is it going to be bottoms up where you have, you know, maybe applications that know they interact frequently with each other are going to, you know, kind of have the same sequencer set. Right. So it's a little bit more frictionless but very much so within just little sector of apps and no one shared standard like you see on the Cosmos side.
**A** (1:28:00):
And for folks we know this was like a slightly technical episode but one way that helps my 5 year old brain understand standards, right is you can have, there are all sorts of different cars out there, right. Like you know, tens or however many different car brands are. You could go to any auto shop and they know how to change your tires because there's a, an agreed upon set of standards in the automotive industry, right. That you don't vary by you know, use you know, a couple different sets of screws or it could be a couple different sizes but ultimately like that's what makes that work. Right. So you can, that basically unlocks, you know, auto repair shops and aftermarket businesses and all this kind of stuff. So that was what Sunny was talking a little bit about. It's like hey, we haven't like agreed on any sets of standards so we as the developer of like Kepler Wallet, everyone's like trying a whole bunch of new innovative stuff but it's like guys, we need to, there needs to be guardrails around it.
**C** (1:28:53):
Right.
**A** (1:28:53):
Essentially.
**C** (1:28:54):
Right. So and that will, that will need to be an application, you know, based push for Ethereum. Right. Which it's, it's not been kind of the typical course of development for Ethereum. You know, they've not been building just to cater to a certain set of apps. But I think that we could see that change as the apps, you know, gain more leverage over I guess the chain itself. Right.
**A** (1:29:14):
You know, else is funny just in close this is so much in crypto gets reduced to like a technical argument. But also a huge component of this is just different communities and their priorities and like the culture that gets set. You know what I mean?
**D** (1:29:27):
Yeah.
**A** (1:29:28):
Like 100. Cosmos as a community just focuses on this, right. And the leaders who are in Cosmos. Actually it's, it's almost too bad we didn't get this. Sunny made this point after we, you know, left. But there's a big difference within the Cosmos community of the core devs also being application builders versus in Ethereum, the core devs and app are completely separate. Right. So that is a cultural thing. Right. That's not. There's no technology that makes that the case. But, like, that's a huge cultural difference in between. It's just funny to pick apart.
**C** (1:30:01):
Yeah. Maybe just a give. Give a sense of what he was talking about there. This would be the equivalent of, you know, if the next EIP for Ethereum, the next major Ethereum upgrade, was really developed by, say, the Uniswap developers, the AAVE developers, the maker DAO developers. Right. Those. Those application developers are the ones really dictating where the base layer goes and what standards they introduce. You know, that's definitely not the case today. And in fact, they really try to say, separate each other out, not to give any application some sort of special privilege. But I think, you know, it's a big question to see if that will change over time.
**A** (1:30:36):
All right, buddy, this has been a really fun one. Just to give you guys a sense of what we've got. Coming up in episode two, we're going to be talking with Sam Hart and Zachy Manian about. We called it Fat apps. Maybe we should change it to Tall Apps and aggregation theory. But getting into even more detail about this idea that value may accrue at the app layer as opposed to, you know, further down the infrastructure stack at the protocol layer. So this has been a fun one. And yeah, buddy, I'll see you. See you next week.