Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Avril Dutheil: Neutron – Interchain Smart Contracts on Cosmos

Episode Date: July 14, 2023

Blockchains are secured through the economic incentives offered to their validators/miners. The more robust the network effect among validators, the more difficult it is for that blockchain to be compromised. However, building a truly decentralised and reliable validator set is not a trivial task. As a result, hub and spoke ecosystem designs like Cosmos’ (and even Polkadot’s), aim to share the main hub’s validator set and security to their ‘consumer’ chains (parachains in Polkadot’s case). Neutron relies on interchain queries, interchain accounts and interchain (replicated) security to deliver the most secure CosmWasm smart contract platform in the Cosmos ecosystem. We were joined by Avril Dutheil, GM at Neutron, to discuss Neutron’s smart contract platform and how it leverages replicated security (ICS) and interchain accounts (ICA).Topics covered in this episode:Avril’s background and the value prop behind NeutronPractical examplesInterchain accounts and different use casesInterchain securityAtom hub vs. Polkadot relay chain. Onboarding and security modelsOffboarding Cosmos consumer chainsReplicated security vs. Modular blockchainsNeutron’s token utility and governanceEpisode links: Avril DutheilNeutron on TwitterThis episode is hosted by Felix Lutsch & Meher Roy. Show notes and listening options: epicenter.tv/504

This is Epicenter, Episode 504 with guest Avril Duthael. Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization and the blockchain revolution. I'm Felix and I'm here with my co-host, Meheroy. Today we're speaking with Avril Duthael, also known as Spade, who's the general manager of Neutron. Neutron is the first consumer chain secured by the Cosmosa via interchain security and is focused on providing secure interchain defy via Cosmosum small contracts. Welcome Avril to Episandexecency. Hey folks, thanks for having me. Yeah, great to have you.

And congrats on the recent launch. I think very big milestone for Cosmos at large. And we're, as many people know, Epicenter hosts and people are quite hyped about Cosmos generally. And so, yeah, we're glad to have you on and would love to hear first as it's custom about your background, how you got into crypto, how you got to where you are today. Yeah, for sure. I think there's there's a few things, right? Like there's part of it was kind of random. Just a friend, you know, told me about, you know, hey, there's this electronic cash system called Bitcoin that, you know, that exists now and you should look into it. And at the time, I had been looking quite deeply into a lot of privacy related, like concerns in society and into current technological stack that we use for our day-to-day operations. And, you know, the like Snowden revelations and such had made me pretty wary and untrust, like I wasn't trusting established institutions and big companies tremendously. And so, you know, the fact that, one, it was an mediated value exchange and that it was at the time at least considered pseudonymous. And so therefore pretty good for your privacy were two of the things that initially drove my interest into it.

And so I ended up like reading the white paper and like finding it like finding it kind of fascinating, although, you know, I think at that time I was still in high school. And so just bought some Bitcoin at that point, I think on Conbase or something. But then, you know, life happened. And I got back to things around the time where DefySummer was a thing. That sort of brought me back into the ecosystem because now it wasn't just, hey, we can send this asset back and forth. It was also that we can make programmable, you know, applications that live on the blockchain entirely have the same properties. But the use cases are like way more diverse. And so that brought me back entirely into the space. And I basically started

having, you know, my day job plus my nighttime crypto job, I guess, of researching how these things worked and what could be built on top of them. That led me to become more and more active on chain and in like web through communities, some on Ethereum like Lido, but also some on Terra with a bunch of the protocols that were there. I ran some AMA, well, I helped with some AMAs of anchor protocol, the infamous, back in the days. But in any case, that eventually led me to, you know, like a pretty random thing, right? Which I was that, you know, Lido on Terra was going to do an upgrade and they posted about it in the anchor forum. And the last line said something like, Hey, by the way, if you think you have skills that we could use, just like get in touch with us on DMs, right?

And so I did. And so we started having like calls and stuff. And a few months later, I joined the team initially as a community manager. And our team at that time was very strong on the technical side. We had like a lot of very, very skilled and knowledgeable engineers. But we lacked a lot of like the software functions like business development, marketing and all these things. Like nobody wanted to do it. That's not what people, you know, were good at.

And so, you know, from community manager, just like managing social medias, I started doing more and more of these things, basically became, I guess, head of marketing, sort of like de facto and then head of growth, handling some of the business development for the project as well. And so that's sort of like how I eventually was asked to basically, hey, do you want to actually lead the team, which is what I do now and what I've been doing for quite some time now? So it's pretty random sort of life journey, but it has been, you know, an honor, but also something that has taught me a whole lot. So that has been really, really cool to go through.

All right. So basically, initially you were working mostly on Lido-ontera, and then that fell apart. Or was it like you switched to Neutron? Was it already its own team or how about that? Yeah. So like our team built Lido-O-Tara, like built the architecture, the code that, ran Lydo on Terra in the past. And the thing is, like, while we were doing this,

like, Lido-on-Tera was the second most successful implementation of Lido beyond Ethereum. It was, like, before the Terra crash, it was about a $10 billion TBL protocol. So it was like a pretty massive protocol, actually. And so, you know, that was a big part of the work. We were conducting like onboarding phases for validators and such. So, like, that was a big part of the work.

But aside to this, right, there was the fact that the protocol was really big on, on Terra, but Terra was, you know, in our head, you know, part of this wider cosmos ecosystem, but it wasn't very well connected with it. And because, you know, there's quite a bunch of proof of state chains in cosmos, like the ecosystem is made of them. It made a lot of sense to try and allow the protocol to scale and basically provide services for these other blockchains as well. The problem was that, you know, the, like, so we basically started doing a lot of research and like, hey, how do we expand this protocol and make it available across chains, basically?

And at the time, the sort of like easy answer was like, hey, you take the small contracts and you redeploy them wherever you can. But that doesn't really scale. And most of the cosmos blockchain don't even have small contract capabilities. So the model was like flawed, right? There needed to be another sort of like playbook for how you actually do cross-in applications in cosmos. And so that's sort of the research that led us to develop neutron at the end of the day, right? the three sort of like pain points that we were faced with was one, a lot of these blockchains lacked security, like economic security, and that meant that, you know, if any protocol really was going to be tremendously successful and attract a lot of like TVL, it would turn into a target and potentially, you know, help justify attacks against the blockchain itself, which is, you know, not ideal, let's say. So security was an issue. The lack of cross-chain infrastructure for Cosmosom Small Contracts was the other main blocker. whereby, you know, like token transfers were generally something that you could do at the time already.

But, you know, ICA, so interesting accounts, which had already released, were very unwieldy to use. And for small contracts, you didn't have any bindings for your small contracts. You actually leveraged that primitive. And so you essentially would have had to, you know, make small contracts that essentially port the code of ICA into the cosmosum layer so that you essentially rebuild the entire infrastructure. And while, you know, that may be fine for one team that has, you know, a lot of bandwidth and a lot of experience with these things, it just doesn't make a lot of sense from an architecture perspective. Like, why should every DAP basically end up recreating the infrastructure that they need to do crushing stuff, basically? Like, that should have been part either of IBC or like sort of like the platform that the small contracts were on. And then the last one was also that, you know, Terra had a very strong community.

was like, you know, like a lot of big blockchains like Solana and then Ethereum and such was pretty tribal. And as a result, it didn't really, it wasn't very homogeneous with Cosmos, right? And so if you had primitive going from Terra to the rest of the ecosystem, the chances that the immune system of the Cosmos ecosystem would actually repel that primitive, fight against it or don't want to adopt it too willingly were high. And sort of the other way around as well, right? Like Cosmos Primitives were tricky to adopt on the Terra ecosystem as well, right? beyond osmosis, which actually was eventually fairly well adopted.

So, you know, finding some way to have either one of credible neutrality or sort of like ecosystem alignment by default was something that was also important. And so those are kind of like the early premises that led us develop neutron the way it is today, whereby, you know, of the three problems, security, crushing infrastructure and credible alignment, one and three are actually solved by replicated situations. We have a very high economic security from the box, thanks to, you know, all of the stake and all of the validators of the Cosmos Hub. And we also have very strong alignment with the Cosmos Hub itself, right? And so, you know, if you're a part of Cosmos, we probably have interest in the Cosmos Hub remaining or leading blockchain, a very strong blockchain and sort of like the shilling point for the ecosystem. And so, you know, repugated security solves one and three. And then the crashing infrastructure was the remaining problem. And so that's that's why we, we. focused on this one. And we implemented interchange transaction module, which is essentially a way

to make it very easily accessible for smart contracts to use interesting accounts and more. So basically, you can register accounts on other blockchains, execute transactions, retrieve execution stages, and do callbacks as well. So you can have sequences of actions that execute across chains, and the interesting queries module, which allows you to retrieve data directly from the storage of other blockchains, right, over IBC. So, you know, we, like, replicated security solves two of our problems and then we develop the solution to solve the other one. And we think that this together basically makes sort of the ideal package to build crushing applications that can scale across the entire cosmos ecosystem in a way that's more viable than it used to be, let's say.

So for our listeners that may not have followed the cosmos ecosystem a lot, could you actually give an example of a cross-chain application? So maybe one example, like in theory, where we go like maybe three or four years in the future and say, okay, this is what a cross-chain application on cosmos could do. And then maybe one example more in practice, which is like, here's the top cross-chain application that is live today and what it can do. It may be primitive, but it kind of demonstrates the possibility. Yeah, that's a really good question.

So I think, like, there's a few, like, depending on the type protocol you're building, the architecture is going to be different. I think a pretty good example in general is, you know, we talked about a little bit, but let's say, let's imagine like crushing liquid staking, right? Because that's sort of like where the idea for Neuton came from, so might as well. So the way you could build it is essentially something like, it could look something like the following. You would have a set of small contracts on one blockchain, Neutron in this case. And that set of small contract, we could contain all of the business logic as well as all of the cross-chain management logic. Now, this product, like this set of small contracts could, you know, through either governance or through a multi-sig or what have you, you could accept a transaction that allows it to register a set of IBC channels and create a set of accounts on another blockchain so that it can start, like it can onboard that blockchain to liquid staking, basically.

And once that's done, so that's like, you know, expending to a new blockchain, instead of having you redeploy contracts and making changes and such, it becomes one transaction, right? You just trigger that happening at the protocol level and it does, and then that's, that's mainly it. And then once that's done, basically you can have the same UI for the user. You know, you have one UI that you go to that has whatever the protocol brand is, and they can choose whatever asset they want to stake, probably they're auto-detected by their wallet, e.g., let's say I connect to that liquid-staking protocol, I have atom. It proposes, like, it can offer me to stake that atom,

but if I also have Osmer and that chain has been onboarded to the liquid-staking protocol, it also detects that I can have this, and maybe I can stick both at the same time. But what happens in the background is basically, you know, if my atom is on the Cosmos hub or my Osmo or Osmar, there's essentially two ways to do it. Like the way that liquid-staking protocols like Stride, for example, do it currently, is that they essentially build a transaction that allows you. you to transfer all of this to their blockchain, and then they'll eventually end up doing the staking operations by sending them back to their native chains and staking them. With interesting

accounts and ICQs, you can do that. That's very easy to do, actually, especially with, you know, the improvements in UX and APIs that are available today in Cosmos, but you can also do it in a slightly different manner, whereby, instead of having to do an IBC transfer, the user would simply on the same blockchain, send the asset to an account that the protocol controls, and the protocol would be able to verify that it has received the deposit using an interesting query, basically. It could, that or just sending a message, or like, there's multiple ways to implement it, but the protocol is able to verify that, basically. And so as soon as the protocol knows that it has received custody of the asset that needs

to be staked, it knows, because it knows the exchange rate, how many of the derivatives, like the, sorry, the liquid staking tokens, it needs to send you. you, right? So basically, as soon as it confirms the deposit, it can send the token directly to the user's wallet, either on the chain where the main business logic of the protocol exists, or on the other chain where the user had their asset, right? That's something that the user can choose, basically. The protocol itself is able to just do the transfer itself if needed. Like, that's sort of like what happens in the background, right? You have one, the user deposits tokens into an account that's controlled by the protocol, and then the protocol can

verify the deposit and then the protocol can manage that collateral, for example, by staking it, and it can redelegate actively by verifying the state of the blockchain to know what are the performance, various metrics of the validators and just like moving stake according to its validator management policy. So basically all of this works across chain. And then from the user's perspective, it's actually really easy. I log into one website, I connect my wallet. It detects what assets I have there tells me which ones I can stake with that protocol. I select that, click it, and maybe there's one, two, or three transactions that pop on my screen and just confirm them, and then I get the derivative. So that's kind of like the whole point of this,

right, is that it abstracts away all of the need to move from one blockchain to the other that currently exists in Cosmos, although new apps are a lot better at this than previously they were. But it removes all of that crushing complexity, basically. It makes it so that there's one product if you want to interact with it, you just go to the website and connect your wallet. Yeah. So I'm kind of imagining this is one of the raw technologies that is kind of

that is not maybe even neutron specific, but is there because of the way cosmos chains can communicate with each other. Is this idea of an interchain account where if you have like blockchain A and blockchain B, you can imagine an interchain account on blockchain B as just being a normal address for blockchain B.

It looks like a normal address to blockchain B. But that address is not controlled buying a private key as such, but by the entire blockchain A itself. So it can be controlled by the entire blockchain A itself, or it can be controlled by some smart contract that's written on blockchain A. Both modalities are kind of possible. in Cosmos in general you don't really have the

opportunity for smart contracts to control one of these accounts, only the blockchain itself can do it, right? And so that's one of the things that we had to do for Neutron to enable a small contract to control an account. We did need, like basically the authentication logic

still lives in the blockchain itself, right? But now your smart contract has a way to tell the blockchain, hey, I want you to register an account on that other blockchain that I will control, essentially. So that's one of the things that Neutron brings to the table, basically. So, yeah. So, I mean, if you think of, like, you think of right at the start, if you think, like, Bitcoin,

then Bitcoin, normally, like, if you had an, like, a very early Bitcoin address, it was an address controlled by one private key. Then in Bitcoin came the next generation, which is like the multi-sake, where it's, like, against one address by it, but controlled by three or, five or seven private keys. And then like Ethereum kind of like generalize that to say that, okay, you can have an address

which now is called a smart contract. And then behind that address is not private keys at all, but rather some like code and data, like logic and data. That's controlling like that an address. And this is like kind of like a further generalization of that. maybe not generalizing, maybe they're not quite word, but a new type of interaction where

you can have an address living on a blockchain, but it's controlled by another blockchain altogether. Or by a contract on another blockchain, yes. Or by a smart contract on another blockchain. So kind of like interstate accounts. Yeah, it's even like you can have multiple accounts on multiple blockchains all being controlled by the same small contract on one blockchain,

which is kind of cool, in my opinion. Exactly. So like you can imagine that this kind of like the generalization of basically single sick address, multi-sick address, smart contract, interchain account is like a blockchain itself controlling addresses on other blockchains and then a smart contract on that blockchain controlling lots of addresses on other blockchains. So maybe like that's one way to kind of like think of an interchain account. Another way to think of an interchain account could well. be that sometimes like people are used to the idea of a custody service, right? So you,

you, you, you, you, you want to go to a custody service and have the custody service generate some private keys and manage your private keys. And then, uh, the custody service will kind of interact with various gaps on your behalf. And so what kind of a cosmos chain, like interchain accounts or cosmos chains fundamentally allow you to do is to, you map, is to think is to build a distributed custody service in a way where you can imagine like a cosmos chain is like a decentralized network but because it can create addresses on other networks and and you can load those addresses with with funds you can start to imagine like a cosmos chain or neutron specifically as like a distributed custodian of assets on multiple networks so just think that imagination also work

I think that works. I think you could build an application that does that on Neutron, for example, or I think you could even make an app chain that focuses on doing this entirely, in which case you would be able to, I mean, in both cases, you would be able to, you know, build some safety mechanisms and such into the code itself as well. So I'm pretty sure I've heard somebody at a conference recently talk about basically just like their thought processes, I'm doing exactly that. So, you know, that's like to tie this back to neutron, it's like, Neutron was not designed to do only this, but it would certainly provide tools that would

allow you to build this if you wanted to. And I do think that that technology can be used to build exactly that at scale, actually. So it's a pretty interesting, so like the thought experiment. Yeah. So, I mean, maybe you can imagine Neutron is kind of like this kind of like orchestrator chain where I can go and write a smart contract and I can orchestrate assets on multiple cosmos networks

by using these interchain queries and interchain accounts. One example that's particularly interesting here is an idea that was developed and published by Delphi Labs with what they call the share liquidity AMM, the slam. Basically, sort of like the thought process that they had is that they were looking at, you know, like uniswap initially it was, you know,

it's one AMM on one chain that has its liquidity there and you can trade through that pool, right? And then we had another generation of dexes like, you know, Curve, sushi and others that started launching on other chains as well, right? So now you have, you can be the same pool or different pools depending on what assets are available, but basically you have, you know, numerous pools on numerous networks, each with their own liquidity, right? And then the problem with that is that it's not particularly capital efficient, because perhaps you have a lot of liquidity for Ethereum on Ethereum, but if you want to have as much liquidity for that on another network, you'll need to compensate for the change in trust

assumptions, for the efforts required with moving that liquidity, extra, extra, so that the LPs are actually interested in providing that on another network as well, right? And so what you end up having is that you don't necessarily have a great match between the demand for various assets on each deployment and the liquidity that's available, right? Because that liquidity maybe it's in a pool in that protocol somewhere on some chain, but it, you know, there's no guarantee that it will be on the right pool so that you don't have a great degree of guarantee that just because that dex is liquid on Ethereum, it is also on the chain that you're trying to use it in. And so from there, there is sort of like another generation of dexes that tried to essentially have the Dex

function in such a way whereby you would have a deployment on each chain and all of these deployments would be connected in a way whereby each of them would behave as if it had the aggregate liquidity of the system as a whole, right? That's a very appealing perspective because now it's, you know, fully capital efficient. It doesn't matter where people are depositing their, their liquidity and such. Wherever you're trading, you're going to benefit from it, basically. The problem with that, though, is that because there is some latency between, you know, whatever rebalancing operations may occur between the various deployments, that means that there's, you plenty of opportunities for arbitrageers to come in and basically arp the pools and take the

value before the protocol itself has the chance to rebalance itself as a whole, right? And so what that led is that basically the impermanent loss becomes extremely dramatic for LPs and that sort of kill the primitive. And so Delphi kind of like, you know, looked into all of these and they postulated the idea that you could still take the idea of that improvement whereby you want to connect these deployments so that they provide the optimal training experience for traders and are as capital efficient as possible, but make it in a way where you don't get that bad trade-off of losing liquidity to arbitrage.

And what they came up with was the idea that you could have a Dex that has all of its deployments connected and then dynamically allocates its liquidity across pools, on the various networks based on demand, right? The easier way to do this is basically you actually physically move the LPs around, like the assets around via IBC or another bridging protocol, and you use sort of like a reactive algorithm so that you're, for example, using instruction queries

to observe sort of like the usage data on the chain, right? How many transactions are there trying to swap for X asset, or how many, you know, what's the volume, or all of these metrics, right? You can retrieve them with an ICQ, and then you can have an algorithm that just reacts to the changes in this usage

to basically reallocate liquidity accordingly. That's one way that you can do it, but the paper basically tried to show that if, you know, even if it's not going to be accurate 100% of the time, there are good chances that you can make algorithms that are actually good enough to most of the time predict accurately

where the liquidity will be needed. And so by using that as an input rather than just reacting to the protocol, you can essentially dynamically move that liquidity around. And another improvement that you can do is instead of actually physically moving the assets every time, perhaps you can just have a centralized accounting of what liquidity is in the system

and then allow the various satellites to essentially take on depth against each other and then settle with assets when required because there's not enough liquidity to do on trade or you're approaching some threshold with such, so that at the end of the day, you're minimizing the cost of the entire protocol by not having to have, you know, like token transfers and such too frequently, and you're maximizing how close you can get to the ideal scenario of, you know, the liquidity of the protocol is used on all things, right? So it's a compromise

towards that first version, but at least it's not vulnerable to the same attacks. And with, you know, architecture, like what Neutron provides, it actually becomes a lot more manageable to build stuff like this. And so I think, you know, you asked me before about what's a good example to understand what you can do with us. The liquid-sicking example is an easy one, in my opinion, because it's pretty simple. You have, you know, one account, you accept deposits, you send the derivatives. And then the slam, in my opinion, is a really good example of the change in experience that we may experience by, like in user experience that we may see by, you know, witnessing the appearance of like Russian protocols over the next few years, basically.

Whereas it doesn't matter where you're interacting with this protocol with. You can sort of get the best out of it anyway because it sort of manages itself as, you know, one body rather than separate segregated deployments. Yeah, that's really cool. So yeah, so essentially like the superpower that you can give developers is that they ultimately have to write a smart contract and deploy it on the neutron chain. But that smart contract can control accounts on a lot of different networks and it can optimize kind of liquidity across a lot of different networks, which could be important in like various

applications. So I think there's a few benefits, right? Like the first one is like, as you said, you can optimize liquidity across multiple networks. I think another one of the key benefits is that you can, you can provide a cross-chain experience that doesn't feel like a crushing experience, right? Because no one likes to be changing the chain in their wallet or stuff. Like all of these extra steps, they're just burdensome. They should be removed eventually.

For IBC to win, it needs to be completely, you know, like, you don't think about TCP IP when you're using the intranet. It should be the same for IBC, right? IBC wins when we're able to make you know, from like consumer facing products that are completely, you know, removed from the actual intricacies of the of the crushing infrastructure that underlies them, right?

So basically, you know, neutrons of infrastructure allows you to, well, first build crashing protocols, right? Which was a lot trickier before. And it allows you to do it without having to redeploy, like recreate a lot of like infrastructure because they come so like clean hand for you basically. You already have the bindings to use them. But it also, yeah, so UX benefits.

And I think sort of like the emergent property of this is that it sorts of flip the script of the playbook for how you make a successful small contract platform, right? Like traditionally, if you, you know, like I'm building a small contract platform, I want all of the liquidity, all of the users, and I want all of the apps on top of my network to be exclusive to my network because that's how I maximize the, appeal of my network to, you know, the broader audience and, and the potential user base, right? Now, with Neutron, because it allows you to actually create interoperable crushing protocols, it sort of flips the switch in that we actually need other projects and other app chains to be successful so that there are markets to interrupt, like markets and app chains to interoperate with, right? And what it does is that it basically allows, from the perspective of the developers, instead of having to choose a platform by virtue of its specific market and market size and its specific feature set,

it allows you to essentially deploy on neutrons so that you don't have to choose, right? So for example, if I'm really interested in fast execution for parts of my protocol, I can deploy on neutron and then leverage, say, for some of these interactions. If I'm interested in privacy for some other part of my protocol, let's say I want to do sealed bid auctions or price. private voting, perhaps I can just deploy an enclave on secret network and then anonymize some of the traffic going into my application so that I basically leverage their features without, you know, in a way that's not like exclusive, right? I can deploy on neutron and leverage the features of these multiple blockchains, but also

because it makes it easier for me to bring my application to market on these blockchains as well, I'm no, I'm no longer constrained by the market size, e.g. the, you know, the amount of value on Neutron and the number of users on Neutron, I can now also, you know, with the same deployment, I can also tap into the liquidity and user basis of other blockchains and other projects. Right. Yeah, but you are basically still limited by the support for interchain accounts or like IBC in like, but you can tap into this entire ecosystem versus just a single which is yeah. For IC specifically, yeah, there are some dependencies in Cosmos though, like ICAs are pretty well adopted.

A lot of chains have the, like ICAs have sort of two sides to them. There is the controller side, which allows you to register accounts on other chains, and then there's the whole host side. There's not that many chains that have the controller functionality enabled, but most of them actually have the host chain enabled, which means that neutron can register accounts on them. Right. Do you expect that to change? like many chains will become or will try to become sort of this controller chain since

if you already like what are the benefits if you're the controller chain like the assets like sort of go through you I guess you can sort of capture value there I think it really depends on the project right if you don't have a use for your protocol to be doing stuff on other blockchains or maintaining assets on other chains then there's no point in you having the controller functionality like in neutron's case that was important because you know the assumption is that developers building small contract applications that want to expand crash in will want their small contracts to actually control some of these things, right? So it was a requirement rather than than radio choice. But for other applications, you know, you may want to use it.

For example, let's say I'm a lending and borrowing protocol like Umi. Maybe I want to use, maybe I want to have the ability to send tokens to an enclave that I control, an account that I control on another chain to be able to liquidate through existing public. like liquidity on an AMM or such. And so, you know, I could use interesting accounts to do that. But now is that the most efficient way that I can liquidate? Well, that's not a given, right? Because IBC and especially today is still, you know, it's asynchronous and it's relatively slower than what you can do on one blockchain, right?

Because you do need to wait for multiple blocks to be passed for the entire sequence of events to unfold. So that may be a good solution, but potentially there's a better way to do it, right? And for example, like Umi currently, to the extent that I, to the extent of my knowledge, what they do is instead they auction off the collateral on Umi so that the cross-chain transfers are not handled by Umi, and they don't have to wait for that. They just, you know, they just do the auction and whoever is the fastest gets the bonus, essentially. So, you know, there are trade-offs here, especially in terms of speed today,

although I expect that this will become a lot less burdensome in the future because block time hasn't mattered so much in cosmos so far. but as more and more applications are built upon IBC, latency is going to become more of a friction point, and so there will be more of incentives for change to sort of like improve in this front, in my opinion. So I expect block time to trend lower in Cosmos, because there's a lot of low-hanging fruits in this regard. But now, you know, an alternative for what Umi might be interested

in having interesting accounts for is, for example, how about they allow users to deposit collateral from other chains, right? Like that's a lot more, you know, palatable for Yumi, because it basically provides easy access to the protocol from other chains that people might have assets and interest in, right? And so, for example, they could deploy an outpost on Neutron that allows folks to deposit into the protocol

without having to do the IBC transfers to the UMI blockchain just by sending to an account that they control on Neutron and then just moving and depositing the tokens at a periodic interval, for example. something like this. So that would be possible. And in fact, that's kind of the route that osmosis is going for. It's not necessarily like ICA specific, but basically they're going, they're working on this

outpost model where the outpost is what we call like a lean outpost. It doesn't actually hold any liquidity. So it's not synchronously composable, but it serves as like an interface, an API for protocols that want to leverage osmosis. So right, so you have the small contract, for example, on Neutron. and it can have a UI that allows you to use it as if it was a Dexon neutron or other smart contracts can interact with that smart contract to basically send calls to the osmosis blockchain, right?

So if you send it to a token to do a swap, it will take that token, send it to osmosis, swap that token as long as your slippage metrics are, you know, are valid, and the slippage didn't get out of hand and then return the proceeds to you, basically, right? So it serves as like an ADI for osmosis, essentially. So there's a bunch of models that applications can take, right, from the most heavy outposts, kind of like Mars, what Mars is doing, for example, on osmosis where the collateral actually lives on the blockchain where the outpost is, to the leaner models where, like, which osmosis or Cosmoswap are doing, where it's mostly an API. Right, yeah, super interesting. I think, yeah, we basically, you mentioned the three kind of core things that you wanted to. solve or that you saw the problems in the cosmos ecosystem, right? I guess we talk mostly about

the second one now. And you mentioned, I think ecosystem alignment and security, which are basically coming out of the box more or less through interchained security. So I guess we can dive a little bit into your or like interchained security. You know, what is interchained security? Probably start there and we can get into like how you how you adopted it, how you leverage it. But maybe maybe we start simple and then you can sort of explain what interchained security is. Our replicated security, we also hear it called sometimes. So, yeah, maybe you give our listeners a bit of the basics of interchained security here. Yeah, for sure.

So intrusion security is a family of technologies from the great category of shared security in blockchain, which is essentially how do we use the same asset to secure multiple broadcast chains? And it's a flavor, let's say, it's a category, a family that is specific to cosmos, right? Because it leverages IBC, so interchange, intrusion security. Now, the specific variant that currently exists in production is called Replicated Security. And the sort of like one-liner pitch for what replicated security is, is it is a technology that allows the provider chain, in this case, today the Cosmos Hub, to provide the same economic security that it personally enjoys,

like that the blockchain enjoys, to another chain called either a partner or, a consumer chain. And it does so by leveraging its validator set and its stake and IBC, right? So there's a connection between the two blockchains that allow them to exchange messages. And that allows the sort of like proof of stake set up of there's a reward for validators doing their job and there's a punishment for them misbehaving and we just, you know, track as we go. And as long as they validate properly, they get rewards and if they misbehave, they get slashed. It basically allows you to reproduce setup, except instead of having every component on one chain, you have them sort of like distributed on two chains.

I think like it would be interesting to compare and contrast, like, replicated security to other kind of models that are there across the ecosystem. For example, maybe we can start with like comparing it to PolkaDod. So in PolkaDod, there's like a Rene chain. And then there are para chains. And then the validators that are running the relay chain in PolkaDOT are the same as those that are kind of running the para chains. So, and replicated security at high level looks very similar. There are a set of validators that are running the cosmos.

And then now those same validators are also running the neutron chain. So it looks similar. And what's the difference between, is it just like Cosmosab just copying what Polka Not set out to do? Or is there a material difference between these two designs? No, clearly it's just a copy. You know, we were a bit jealous of PolkaDot, so we just decided to apply the playbook. No, I mean, like, the first thing is like that has been in the works for quite a long time, right? So I don't think it would be fair to say that it's just the hub like copying this.

but as you said, there are very similar in sort of like the structure of that technology with I guess one well I would say like two major differences. The first one is that in PolkaDOT

this mechanism is required to join the PolkaDOT ecosystem if you don't get your pirate chain attached to the relay chain you basically don't have a PolkaDot chain. You maybe have some code but you don't have a functioning blockchain. Whereas in Cosmos, like, all of the Cosmos technologies are available for you to use and in your own project, regardless of whether or not the hub wants you to be part of the atom economic zone.

The sort of like, you know, I guess you could say the atom economic zone is to the Cosmos Hub, what PolkaDot is to the relay chain, right? It's the ecosystem of chains around it. And so, like, that does the first thing, right? Interchange security is not required to launch in Cosmos. and in fact the vast majority of chains in cosmos today don't leverage like intrusion security at all. And the second thing is in PolkaDot, you have a mechanism for the onboarding of new chains

that is very, very formal, e.g. there's an auction, and whatever gets the most dot, locked into that auction is what gets a parochrain slot. In Cosmos, for better, for worse, there's no formal mechanism, right? So it is, I guess, as usual in Cosmos, it's done through governance, right? So there is a sort of like public negotiation process.

And that has tradeoffs. On the one hand, it's less clear. You know, it's a lot more flexible, but it's also less clear what should be expected from there. But at the same time, it also allows you a lot of flexibility because let's say there's sort of three main tools that you can, sort of like put into the balance to get listed on like to get onboarded into replicated security today. Obviously there needs to be something in it for the hub, for the for the hub and its community to vote for your chain to be onboarded.

And that in my opinion can come mostly in three ways. First one, it's either if you have a token, if your project has a token, then you can allocate some of these tokens either in one go or through streaming or whatever distribution mechanism you want to the customers hub, right? that's a very straightforward sort of like kind of the second one is if your protocol generates revenue in whatever way, then it can allocate a portion of that revenue. And that may be transaction fees on the network. There may be fees on specific operations, like for example, for a tax swap fees or what have you. It can be MEP revenue. It can be, you know, whatever you can think

of. If you generate revenue, you can share that with the hub. And then the last thing, which is, paradoxically, I think the strongest element early on, but also the one that is basically impossible to quantify. And so it's very difficult to take that into account into the fault process is sort of the strategic value to the hub and to Adam as an asset that adding the project may have. So for example, you know, like some of the projects that are looking, planning to onboard to replicate its security in the in the short term. are liquid-staking app chains. So beyond the fact that these protocols, through their financial services, generate revenue by taking cut on the liquid-staking derivatives,

so that's one of the things, right? Or maybe they have a token and they allocate some to the hub. That's another mechanism. One of the deciding factors is that because these protocols actually handle and manage a large amount of atom, which is crucial to the security of the Cosmosub itself,

there is a strong incentive to ensure that these chains are adequately secured so that they're not too easy to capture for somebody who would be looking to try to do, you know, like a governance or economic attack on the hub, right? Because if you compromise these chains, you're going to be compromising the mechanisms like the, you know, the interchion accounts

that control the stake on the cosmos hub as well. And so that gives you potentially a way to lever up on the damage that you could do to the hub, right? And so here we have like this third lever that comes into play whereby there's a strong strategic incentive for the hub to secure these chains, whether or not it's going to make a profit by doing so, right? So there's this sort of like three categories that apply in replicated security, and they're difficult to assess. There currently doesn't exist a formal model on exactly how to do

that the right way. And there's a bunch of tradeoffs, e.g. one approach that we sometimes hear is that the hub should launch as many consumer chain as possible, because this way it has, it optimizes its chances of having one, two or three unicorns in the batch, in which case that's a really good outcome, and it can just trim off the projects that fail over time. That's one way of doing things, but the problem, the limiting factor here, is that while that's probably technically possible,

economically speaking, that implies that validators now have to run 20, 30, 40 times more infrastructure, which means that that basically closely translate to 40, 50 times the the infrastructure cost, right? Running an additional blockchain in replicated security basically translate to the same cost as running another chain without replicated security at least today. And so, you know, that cost, that burden on the validators is currently the limiting factor to the adoption in growth of the number of chains on replicated security. And that's something that's actively being worked on by numerous teams. Like we did quite a bunch of work on this.

Like we were the first one to actually push for this to be modeled. But, but there's quite few teams like duality, a whole bunch of validators, chorus one included, are working on trying to push for a more sustainable or framework or model for replicated security. And there's a bunch of ideas sort of floating around, like having different commission rates on the various blockchains, having a stipend mechanism, having different types of emissions requiring like higher thresholds of revenue share or tokens allocations to the hub extra, extra extra to, you know, try and find a stable economic equilibrium for this, basically. Now, I'm, like, mid-long-term, I'm pretty optimistic that this will be found, and especially because the current flavor of

insurance and security that we're talking about, replicated security, is sort of like the first iteration of the technology, which enforces that all validators, with a few caveats, we can touch upon them later, but basically all of the validators of the Cosmos Hub have to run every consumer chain that is widespread by governance. And with a few maybe like again, but basically that means that there's no way for the validators to basically manage their exposure to the cost of consumer chains and the revenues that they or rewards that they may generate. In an upcoming version of that technology, which I think is dubbed opt-in security, validators would have the ability to decide whether or not they want to secure these

chains. That can create sort of game theoretical problems whereby if you had the first validator by voting power, opting in with just two validators from the bottom of the set, opting in, you would end up in a situation where the voting power on that consumer chain is basically more than 70% is owned by the top validator, and the other validators are basically irrelevant to the consensus. So there needs to be some guardrails in place to avoid such a situation from occurring. But that should make it a lot more manageable to onboard new chains to ICS, because now validators that are generating more profits

on their initial activity of securing the hub have probably stronger shoulders to secure more chains and enable the hub to potentially accrue value this way, whereas smaller validators could just opt out of some of these chains and therefore not incur any additional costs, which would allow them to stay stable in the set, which basically would protect the hub from sort of the main concern about replicated security and its economic.

model today, which is that if not addressed, it may create some centralizing vectors whereby the cost on smaller players would force them to either go bankrupt or drop out of the set because they wouldn't be able to support that added cost, basically. So that's sort of like the limiting factor to replicated security. And as a result of this, I think strategically and sort of like pragmatically as well, what's likely to happen and to be the best scenario for it. the hub in the short, medium term is actually to be very selective of the chains that it actually launches for two reasons. The first one is like there's this whole economic thing, right,

whereby you want every project that actually gets launched on replicate insecurity to be tremendously successful to actually make up for the initial cost that it will generate because there's a mismatch in time for when the cost and the revenue are materialized, right? The cost starts from day one, whereas the revenue sort of like gradually comes in, right? Like, that can change with token allocations, which can be pretty meaningful from the get-go, but still. So that's the first argument. The second one being that because you need these change to be tremendously successful, and you want them to have as much synergy as possible, and you want to be betting on the, you know, the change, the projects that will

move the needle the most. And so one of the scenarios that could potentially be a losing scenario is to actually early on, at least, establish competition within the atom economic zone itself, right, whereby instead of competing for growing the pie of the atom economic zone, the project would be basically fighting for, you know, the whatever is available to them, like atom liquidity and such, beyond them, like between themselves, right? And that's that's sort of like negative EV for everyone involved. But if, you know, with that strategic approach of like carefully vetting and being selected, of projects initially before we have better technology, better frameworks for assessing the

economic value propositions of the various projects. I think the technology is a tremendous potential, right? And I think that it does, like having pioneered this has been, I think, very significant for neutral as well. So maybe like to recap, right, like, is it fair to say that on a high level, replicated security, the Atom Economic Zone and Incadot they are going after the same

broad concept which is let's build a good validator set and then get that validator set to run multiple chains so people can like kind of like launch their own chain and have already a validator set that can

that can secure the chain easily On a high level, it's kind of aligned. But one of the big differences is that Poncaldot came with the design of a grand city right at the right at inception. I mean, if you go back 2017, there's a white paper detailing how that city will be built, how if you want to launch your own chain on it, what's going to be the process, how is security going to work. and then kind of they started with a very detailed design of the city and all of its suburbs and then then basically like in building the in building the relay chain and the para chain and the software there they had the grand vision of the city and its suburbs already and then they kind of try to optimize the decision of all of the subcomponents so that the overall city and the kind of suburbs

and also work well, like in their view. Whereas sort of like what the approach Cosmos Hub has taken is more evolutionary. The first kind of, hey, let's build a, let's build an app chain. Let's build a framework to build an app chain. So that comes first. And then that's tandem within Cosmos SDK. So that gets launched. Turns out that actually when that launches, a lot of people want to build these.

app chains and 50 or 70 of these spring up organically. Then the next step is okay how do these app chains communicate so that's iBC and turns out okay many of these apps start to communicate and now kind of like the cosmos hub is taking the third evolutionary step which is okay how can you duplicate the validator set across across two chains with the cosmos hub being the provider of the valetor set and some other chain, Neutron in this case be the consumer. At every step, it's kind of, because it's evolving kind of step by step,

it has the messiness of evolution where when Neutron kind of gets on boarded. What's the economic model for it? Nobody knows. The economy model end up centralizing the value of set. Nobody knows. It has the messiness of evolution, but it potentially may have the benefits

up evolution as well that we might, the ecosystem might end up discovering categories of solutions to problems that centrally planned city may, may not have even considered. So, do you see that as kind of being a good description? Yeah, I think there's some truth to that. I mean, I would push back against, and I don't think that's what you said, but I would push back against the notion that these things are happening sort of like, you know, just did at random, like, oh, we figure out that we needed to do this or like even like biological mutations, right, where it's like literally random. Like that, that's not the case. But you're right in that it has

been less of a centrally planned long-term vision that gets executed where every component is optimized for the interest of the sort of like system as a whole. And it's more of a iterative process of like components themselves or like conducting themselves and making this discoveries and improvement over time. Like this, I agree, I think is actually closer to the cosmos philosophy anyway. And I think one of the benefits of that approach, like, it's obvious the benefits of like the monolithic sort of like vision getting executed. The benefits of those are obvious.

Like on the other hand, the benefits of like cosmos's approach has been that it's a lot easier to actually on board because the system itself imposes fewer constraints over what you want to build, right? and it's very difficult to plan ahead for everything that people will want to build and how that will actually work. And so by having a less systematized mechanism and just building the tools that people can then use to do whatever they want to do, that has allowed Cosmos to be a lot easier to onboard on and fit into the grander scheme of the ecosystem than perhaps all cutout has been. And I think that's true for replicated security as well, right, whereby the system to onboard to bulk out is very formal.

And that may, you know, work absolutely perfectly for specific types of projects or even on average be very consistent and sort of like efficient for the system as a whole. It may not actually work with some chains, right? Like, for example, I think, you know, like one of the assumptions of the auction model of OlkaDot is that there will be significant crowd enthusiasm for the project because the crowd is what usually has to actually bootstrap the amount of that is required to secure the slot, right? But how about, let's say, you know, a chain that does a very niche but important piece of

tooling or infrastructure for developers, right? Like, that's probably very useful for the commons, but it's actually very difficult to drive so like widespread enthusiasm for that, right? So perhaps that would be kind of like one of the limitations of the model. Cosmosub and replicated security, on the other hand, are a lot less formal. And so that has obvious drawbacks of, like, it is possible to do things that don't actually make sense if we're not careful. But at the same time, it does also offer some flexibility whereby something that is purely

in infrastructure play could still happen pretty easily as long as its value is justified to the comments, right? So sure, that would be added cost to the system. but if the benefits of having that are demonstrated, then we can have it basically. That's not a sort of like economic blocker to get that into the overall system. So yeah, I would agree. I think like your analogy is pretty good, actually. Yeah, it's very interesting.

I think really only now many people start to realize what it means. I think actually also from our side, right, we were once that like posted about these implications of running like these many chains. I think there's a lot to come in terms of, you know, how are we going to solve for that? Since I think, you know, there's also no clear path right now. How do you actually offboard a consumer chain, especially like without it? There is. It is very clear how that works.

It is very clear how that works. There is, I would say there's like sort of like three layers of politeness that you can have in the onboarding of the chain. The base layer of politeness is not the issue here. which I wouldn't argue for, but it's technically possible. It's just like any other cosmos chain. If a third of the voting power stops running that chain, then that chain just holds. But because the composition of its value to set is dictated by the hub,

there is no way unless the composition of the hub changes that that chain will start running again. So that's a pretty strong signal that, hey, we're not running your chain anymore. You can fork it and become your own sovereign chain if you want, but that's all right. in general, that doesn't seem like a very good model to follow because it, you know, there's like no protection here for the consumer chain. And so what that means is that, you know, taking on that risk is going to be a barrier or hurdle to the adoption of ICS. And ideally, you want ICS as a feature and as a sub-ecosystem that you can be a part of to be as attractive as possible so that you end up having, you know, really, really, really strong

projects that you can select into rather than having just like, you know, whatever, whatever chain comes up and then just being forced into selecting these because otherwise there is no demand for it for the future, right? And so in general, that is probably not the right approach. The second approach is the Cosmos Hub could just make a proposal, hey, we're going to terminate your replicated security lease, right? It has the benefit of being a little bit more formal and to have a little bit more time for the consumer chain project to adapt because you have this two weeks period where like for the voting, it is governance decided, so maybe it's going to get rejected,

but it does send a strong signal. So it's already a lot more civil, let's say, and it does give the project a little bit more chance to be able to actually transition in time. Now, still not ideal because it's a very short timeline to be moving your entire security, like from basically being leased, by another chain to being, you know, independent or sovereign.

I think what's likely to be used in practice, what I would argue for, at least at this point, is probably this needs to be done by several proposals over a period of time, e.g., you know, there's some like social consensus going on, and if, you know, the cosmos subssocial consensus sorts of reach this tipping point where people are actually considering of parting that consumer chain, they should make a signaling proposal that says, hey, if this proposal is accepted, then it will trigger a three-months period

during which the consumer chain should either come back with amended security agreement that might convince the Cosmos Hub that actually it should stay on with these new terms, basically renegotiating the agreement, or it will be terminated after another vote down the line that would actually be triggering the removal of the consumer chain itself. And what that does is that the first vote is a signaling proposal and it materializes social consensus so that what was Twitter noises and conversations on telegram becomes something that's actually measurable of the voting power of the Cosmos Hub.

65% think that that chain should be awarded in three months unless they come back with a better agreement. And then it gives the consumer chain community a time to actually reflect upon this. Are there alternatives that would be better suited for the consumer chain? are there a way to salvage the relationship with the hub in a way that is more mutually beneficial? You know, should the change just become a sovereign app chain secured by its own token, for example? And it gives at least enough time to consider these seriously. And for a few governance proposals on that chain as well to happen, right?

And then you have the confirmation vote that basically sort of like signals it, like that sorts of like does a temperature check again. But because there's so much time in between, you know, what like if the first proposal was triggered by some thing that is more emotional in nature or like market conditions, then at least you have some time to recover from this before it actually leads to drastic consequences. And the overall process is a lot more civil so that if that's the sort of like commitment on the social layer of the Cosmosub, then consumer chain projects know that, you know, worst case scenario, they'll get that signal that, hey, they need to sort their shit out or the Cosmosub is going to off-board them. But at least they'll have time, whatever happens to react to it.

Yeah, I do find it quite interesting that CosmosHap going for this very governance-based, currently at least, system. And then Pocod is like sort of more a market-based approach where you have that element of the dot being locked. And so through that you sort of can signal these are the most valuable chains. Right, we have limited slots. Let's fill them with the most valuable chains. And you have that lease.

And it sort of takes away a lot of this. governance overhead that is coming right now for Cosmos. So quite interesting to see how that can be. I agree. I think it's very characteristic of Cosmos though. Like, you know, Cosmos basically baked governance in every software inaption that actually launched into the ecosystem. And so, you know, that's like one of the design patterns of Cosmos,

I guess, whereby, you know, people are not completely removed from these computers, I guess. So like to try to get like a compare and contrast with something that's harder which is you know like

replicated security versus kind of like the modular blockchain stack which is represented by Celestia and Ethereum potentially like a harder comparison to make but nonetheless interesting I mean just to recap

the modular stack is roughly the idea that you can think of what a chain does and you can decompose it into data availability, making sure transaction data is always available. Sequencing or ordering, where transaction E for those transaction B, and then kind of like logic and actual blockchain. And when you kind of divide across these functionalities, you can have systems where one chain does one part of

the stack and another chain does another part of the stack and both kind of like Ethereum and Celestia kind of like going down this part. Whereas kind of Cosnos in replicated security it's like obelior, very similar chain designs and the entire validator set is shared. You have like kind of compare and contrast these two approaches and it's just strengths and weaknesses.

Yeah, I mean, I think it's a really interesting sort of turn of events. I mean, when the CosmosisDK was produced, it, you know, like the CosmosisDK is a software development kit that allows you to build monolithic blockchains because, like, modular blockchains weren't a concept that was coined by Celestia later on at the time that Cosmos was created, right? Now, there is some sort of modularity in spirit in the first. fact that like the idea is that cosmos can scale horizontally, right? But indeed, you don't get the sort of specialization and, well, you do get specialization, but not specialization of the performance

specifically that you do get with like especially Celestia, which is purpose built for modular blockchains, I guess. And so that makes it a very interesting ecosystem. But, you know, funnily enough, Celestia is actually part of the cosmos's like ecosystem as well, right? So it's sort of like an app chain that specializes in being the base layer for other blockchains to leverage their consensus and data availability. Now, what I think is likely to happen is that these solutions are actually not exclusive. We're already seeing a trend where numerous projects in cosmos are working on bringing roll-ups to the cosmos stack.

You have like dimension, for example, I believe they are sort of like they're probably live or soon to be live right now. and they've sort of developed with a CosmosisDK or a platform that intends to be a settlement layer for application-specific roll-ups, which is a very interesting idea. I know that there's a whole bunch of projects working on similar things in the Seleshi ecosystem,

and that has now even sort of like leaked into Ethereum ecosystem with the OP stack and hyperchain from ZK Sync. So I think what's interesting here at the fundamental level is that the idea that you can have one distributed computer, like one blockchain being tailored for one specific application or use case, is actually finding some traction here. We're seeing this idea, which mostly started in Cosmos, kind of like grow into other ecosystems and being adopted and implemented

by various technological stacks now. So that kind of, like, I think that's a validation of the thesis, of the Appchain thesis that Cosmos kind of like has been writing on. But it's also like I also do think that there's a trap that a lot of folks in Cosmos consider that the Appchain thesis is everything should be a Cosmos SDK app chain. I don't think that that's true. I do think that the upshane thesis in that there are significant benefits for to be had by having infrastructure that is dedicated to one application.

Like I think that thesis is true. But I think the fact that everything should. should be a Cosmos SDK app chain, that's likely to be proven false over time. And so what I think we're going to see in the ecosystem is that we're going to have, sort of like an hybridation between, you know, like roll-ups and modular ideas with sort of like app chains

and horizontal scaling, the crushing interoperability technologies that Cosmos has born and such. And so I think sort of like to Zach's point in a pretty famous tweet now that he made a couple of weeks or months ago now, he said something to the, point of Cosmos Social Capital has about 12 months to do something unique and differentiated before it gets swallowed by Ethereum variants of Cosmos ideas, essentially, right?

And I think that's what we're seeing right now. We're seeing that the idea of an app chain, eG dedicated blockchain for a dedicated application, is actually now something that is being worked on outside of the boundaries of Cosmos, and that creates sort of an existential threat to Cosmos, because now that idea that has been like very fundamental to its development process is no longer exclusive to the ecosystem, but it also provides an opportunity because contrary to a lot of the other ecosystems that are now implementing these ideas, Cosmos has been working on this for a long time. And so if it can leverage the existing work that it has completed with like IBC and such

and make that sort of like the most suitable standard for these new type of hybrid blockchains that we're seeing, then it has a great chance, in my opinion, be successful at setting one of the standards and therefore becoming a much more relevant ecosystem to the entire industry essentially. Yeah, I don't see them as exclusive. I think they're kind of like really interesting trend in the industries that are actually complementary to sort of like someone. All right. Super interesting. We've been going quite deep into interchained security, I think, here and comparing it. But I think it's hopefully valuable to people that are not as familiar

and also very interesting to hear your viewpoints. can take it back a little bit to Neutron maybe and cover like a few more things at the end since we've been going quite for a while and then wrap up. So I think one interesting thing that we actually haven't really talked about is then sort of neutron like token utility and kind of the things you're doing around governance. Since now, given you're running as an interchained secure chain, right, often the token model that Cosmo sort of established where you have the staking function and that sort of, you have the staking function and that sort of gives your token utility,

you have to now come up with like sort of another model, essentially similar to, I guess, the problems that exist on Ethereum already where a lot of the Taoists just come up, like, okay, there's a governance token, right? I think you are also working like interesting things there with Neutron, with the modular governance, so maybe we can talk a few minutes about that.

Yeah, yeah, for sure. Beyond just our interest in, you know, playing around with governance in general, the thing is like replicated security exists as a set of Cosmos SDK module that replace the modules that outside of replicated security are used for staking and governance, right? So using replicated security removes both of these modules. So basically you have to, as a consumer chain, you have a few alternatives. One of them, the sort of like the default option that is proposed is usually to replace these by modules that essentially are staking, pseudo-govenance. system, like modules, e.g. You're going to have a token that is not atom, which is, you know,

atom would be used for staking on your chain anyway. But you would have another token and that gets used to, you know, calculate voting power and you can delegate it to governors. They're not validers, actually, but they're governors and they can, you know, wield voting power on your behalf. In the case of Neutron, it felt less sort of logical to go that route, given that, you know, as a small contract platform, a lot of the innovation that Neutral wanted to do

was around empowering and leveraging the modularity of small contracts, right? And so instead, what we did is we used a lot of the great work that had been done by the Dowdow team on, you know, like on building Dow infrastructure, basically, and we baked it into the Genesis file so that there's a set of small contracts that exist at Genesis that constitute this sort of like governance infrastructure and made it able to control the network parameters,

through something that's called the admin module, that's perhaps less interesting for this conversation, but so that you have like small contracts on the chain that govern the chain, e.g. they're able to trigger updates of the entire network. They're able to change network parameters extra, extra. And the interesting thing about having been able to work with the data framework is that the, you know, not only does this allow you to have a functional decision-making process, e.g., you can have like single proposals, multi-choice proposal, you can have token voting, multi-sig style things, so you can already sort of like customize the main chamber, but more importantly, your system itself, because there's like a library of code that can be

pulled by the main doubt at any time to instantiate new committees, new chambers, you basically have a governance system that is capable of like structuring itself. So you have the Agora, the token voting assembly, and then that has the power of creating new subcommittees that are dedicated to doing one one task of the other and they can have their own, you know, like committee or like voting system or selection mechanism, their own resources and the way that they execute changes to the rest of the chain can have, you know, customizable limitations. Like, for example, one idea for a grant style would be that, hey, one person can give grants up to $1,000, freely. And then 10, like, sorry, two person can give grants together if they agree, up to 10,000,

thousand dollars right so like having these sort of like customizable limits um and so that's that's one of the things you could do in general though one of the sort of like baseline limitations that we've created that can be instiated by that agora is essentially when the sub die was created it has a time lock module which is so that one the subdow makes a decision through a vote um before that like which can be pretty fast compared to main dial governance proposals like that's a matter of a few hours or days depending on the reactivity of the members um when that gets approved, if that gets approved, it's time locked for three days and it can be basically vetoed by the main DAO. And so what that means is that you can now have systems

that are either, you know, like very large committees or multis or stuff that is more akin to a multi-sig that is independent from the main DAO, but still accountable to the main DAO. And if, you know, they betray the main DAW essentially, if they're not aligned, the main DAO has mechanism to force them to fall back on the main governance track. So that, that decisions that are negative to the network cannot be executed without, you know, a significantly higher lift of just like capturing the governance system itself. Right, right. I can hear a lot of the kind of ideas or concepts that exist in Lido actually here, right,

like with the Lego and some of the things that are actually much harder, I would say, probably to do in Ethereum because you don't have that the customizable ability of a Cosmos app chain. And so I think very exciting to have things more codified in neutron here that are maybe like more on the social layer essentially in Lido, I guess. So yeah, really excited to see where that's going. I think we covered a bunch of stuff. I hope we did justice to neutron. We did definitely talk about a lot of like higher level things.

But I think you're the right person to do that. So we've been going for quite a while. So I think we were at a good spot to wrap up. maybe for final question. And you can talk a little bit about your roadmap, sort of the ecosystem things you're doing. There's been recent announcement around this accelerator. Maybe you can talk a little bit about that.

And then we wrap up. So from my side, yeah, thanks so much for it. Sure, let's wrap up all this, actually. Yeah, I mean, once again, thanks for having me. This was a really fun conversation to have. So yeah, I guess like one last sort of like announcement or whatever, you know, we talked during this episode a lot about so like the structure replicated security and how it creates kind of like a sub ecosystem that benefits from being very deeply aligned and collaborative. That's something that we believe has really the potential to be tremendously valuable for both the Cosmos Hub and the consumer chains. And so in an effort to sort of like further this, we've teamed up with Long Cash, but also.

So the atom accelerator Dow in order to launch an accelerator program that is dedicated to that sub-ecosystem, right, so that we can bring, like, we can nurture teams that are building projects either as additional consumer chains or that are building on Neutron to join the Atom Inconvict Zone and provide them with funding, experience, you know, like scaffolding in their sort of like development and strategy so that, you know, they get the best chances of hitting the market. in a really good shape and being very successful. So if that's interesting to you, check out, you know, Neutron or Longash or Adam Xloridur Douda's Twitter and blogs. You'll find the links to how to register there, how to learn more about the project and such. I think I'm, you know, I think it has a good chance of being pretty, pretty awesome for the ecosystem.

Thanks for giving me the opportunity to place that shell here at the end, you know. Yeah, very important. All right. Yeah, thanks, everyone for coming on. And, yeah, hope all listeners enjoy this, this breakdown of Interchange Security and learn more about Neutron in the show notes. Awesome. Thanks, folks. Thanks for the great questions as well. Thank you for joining us on this week's episode. We release new episodes every week. You can find and subscribe to the show on iTunes, Spotify, YouTube, SoundCloud, or wherever you listen to podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to

the latest episode of the Epicenter podcast. go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released.

If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter. And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.