This is Epicenter Episode 504 with guest Avril Dutile. 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 cohost, Mayor Roy. Today we're speaking with Avril Dutile also known as Spade with the General manager of Neutron.
Neutron is the first consumer chain secured by the cosmos via interchange security and is focused on providing secure interchange defy via cosmos and smart contracts. Welcome Avriel to Epicenter. 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, how you got into crypto, how you got to where you are today. Yeah, for sure. I think there's 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 in society and in the current technological stack that 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 unmediated 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 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 conveys
or something. But then, you know, life happened and I kit and I got back to things around the time where defi summer was a thing that sort of brought me back into into the ecosystem because now it wasn't just, hey, yeah, 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 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 train and in like what 3 communities, Some on Ethereum, like Lado, but also some on on on Terra with a bunch of the protocols that were there.
I ran some AMA. Well, I helped with some Ama's of Anchor protocol, the infamous back in the days. But in any case, that eventually led me to, you know like pretty random thing, right? Which I was that, you know, later on Tara 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 on DMS, right? And so I did. And so we started having like
calls and stuff in 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 the software functions like business development, marketing and all these things like nobody wanted to do it. That's not what people were good at.
And so from community manager, just like managing social medias, I started doing more and more of these things basically became. I guess head of marketing, so 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, did you want to actually lead the team, which is what I do now and what I've been doing for for quite some time
now. So it's, you know, 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 on Terra and then that fell apart and or was it like you switched to Neutron? Was it already its own team or how about that? Yeah. So like our team built the architecture, the code that ran Lido on Terra in the past.
And The thing is, like while we were doing this, like Lido on Terra 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 that was a big part of the work we were conducting like on boarding phases for validators and such. So like that that was a big part of the work.
But it like aside to this right there was the fact that the protocol was really big on 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 first stage chains in Cosmos, like the ecosystem is made of them. It made a lot of sense to try and allow the protocol to 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 the model was like flawed right.
We there needed to be another sort of like playbook for how you actually do crushing applications in in Cosmos. And so that's sort of the the research that led us to develop neutral in at 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
if any protocol really was. Going to be tremendously successful and attract a lot of like TBL it would turn into a target and potentially you know help justify attacks against the block in itself which is you know not ideal let's say.
So security was an issue. The lack of crossing infrastructure for Cosmos and 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. Where very unwieldy to use and for small contracts you didn't have any bindings for 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 cosmosome layer so that you essentially rebuilding the entire infrastructure. And while you know that 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 architectural perspective like. Why should every DAP basically end up recreating the infrastructure that they need to to to to do crushing stuff Basically like that should have been part either of IDC or like sort of like the 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 Terror 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, We're high and sort of the other way around as well, right? Like Cosmos primitives were tricky to adopt on the terror 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 so like ecosystem alignment by default was something that was also important. And so that's those are kind of like the early premises that let us develop neutron the way it is today, whereby of the three problems, security, crushing infrastructure and credible alignment, one in three are actually solved by replicated security. We have very high economic security from the box, thanks to 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 if you're a part of Cosmos, you probably have interest in the Cosmos Hub remaining or leading blockchain, a very strong blockchain and sort of like the shelling point for the ecosystem. And so replicated security solves one and three and then the crashing infrastructure was
the remaining problem. And so that's why we focused on this one and we implemented interchange transaction module which is. Essentially a way to make it very easily accessible for small 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 Inter Chain Queries module which allows you to retrieve data directly from the storage of other blockchains right over IBC. So we. And like replicated security solves two of our problems and then we developed 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 valuable 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 in theory where where we go like maybe three or four years in the future and say OK 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 life today and and what it what it can do in primitive but it cannot. Demonstrates the point. Yeah, that's a really good question.
So. I think like there's a like depending on the type of protocol you're building, your architecture is going to be different. I think a pretty good example in general is, you know we talked about later a bit, but let's say let's imagine like rushing liquids taking, right, because that's sort of like where the idea for neutron 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. A set of small contracts, 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 through either governance or through a multi sig or what have you.
You could accept the 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 and on board that blockchain to liquid staking basically. And once that's done, so that's like. You know, expanding 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 doesn't and then 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 stay. Probably they're O2 detected by their wallet. Eg let's say I connect to that liquid sticking protocol. I have Atom it propose.
Like it can offer me to take that atom, but if I also have Osmar and that chain has been onboarded to the liquid sticking protocol, it order 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 Osmar. There's essentially two ways to do it. Like the way that liquid sticking protocols like STRIDE for example do it currently is that they essentially build the transaction that allow 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 like that's very easy to do actually, especially with 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, right. 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, 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 performances, various metrics of the validators and just like moving state according to its validator set like management policy. So basically all of this works are brushing, and then from the user's perspective, it's actually really easy. It's 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 1-2 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 1 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, and 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 the way 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 inter chain account? Where?
If you have like blockchain A and blockchain B, you can imagine an interchange account on blockchain B as just being a normal address for blockchain B. It looks like a normal address to blockchain B. But if that address is not controlled by 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, like, 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 small 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 this start, if you think like Bitcoin, then Bitcoin normally if you have like a very early Bitcoin address, it was an address controlled by 1 private
key. Then in Bitcoin came the next generation, which is like the multi sake where it's like okay, it's one address by but controlled by three or five or seven private keys. And then it's idiom kind of like generalize that to say that OK, 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 and that's controlling like that an address at this this is like kind of like a further generalization of that. Maybe not generalization, maybe did not right 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 smart contract on another blockchain, yes. Or by a smart contract on another blockchain, So kind of
like. 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 you can imagine that this kind of like the generalization of basically single sync address, multi sync 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 really 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 people are used to the idea of a custody service, right? So. You want to go to a custody service and have the custody service generate some private keys and manage your private keys and then the custody service will kind of interact with various apps on your behalf.
And So what kind of a COSMOS chain like in the chain accounts or COSMOS chains fundamentally allow you to do 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 on multiple networks. So this thing that imagination also works. 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, you know an app chain that focuses on doing this entirely. And in which case you would be able to, I mean, in both case you would be able to, you know, build some safety mechanisms and such and 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 process. I'm doing exactly that. So that's like to tie this back to Neutron is 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 kind of orchestrate assets on multiple Cosmos networks via 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 shared liquidity AMM, the
SLAM. Basically what it sort of like the soft process that they had there is that they were looking at you know like UNISWAP and initially 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 you know as much liquidity for that on another network, you'll need to, you know compensate for the change in trust assumptions for for the efforts required with moving that liquidity extra extra so that the Lp's 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 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 deck 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 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 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 know, plenty of opportunities for arbitragers to come in and basically are the pools and take the value before the the protocol itself has the chance to rebalance itself as a
whole. Right. And So what what that led is that basically the impermanent loss becomes extremely dramatic for Lp's and that sorts of killed 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 like bad trade off of you know like losing liquidity to arbitrage. And what they came up with was the idea that you could have a decks 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 interesting 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 like 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 honor a trade. Or you're approaching some threshold or such. So that at the end of the day, you're minimizing the cost of the entire protocol by not having to have like token transfers and such too frequently. And you're maximizing how close you can get to the to the ideal scenario of 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 architecture like infrastructure like what Neutron provides, it actually becomes a lot more manageable to build stuff like this. And so I think you asked me before about what's a good example to understand what you can do with this. The liquid second 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 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 the 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 one body rather than separate segregated deployments. Yeah, that's 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 shape, 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 would be important in 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 crushing experience that doesn't feel like a crushing experience,
right? Because no, no one likes to be changing the chain, 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 like you don't think about TCP IP when you're using the Internet, just should be the same for I,
for IBC, right? IBC wins when we're able to make you know from like like consumer facing products that are completely you know removed from the actual intricacies of the of the crashing infrastructure that underlies them, right.
So basically, you know Neutrons 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 keen 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's also flips the
switch in that we actually need other projects and other app chains to be successful so that there are markets to interoperate 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 of like some other part of my protocol, let's say I want to do sealed bid auctions or private voting.
Perhaps I can just deploy an enclave on like secret network and then anonymize some of the traffic going into my application so that I basically leverage their features without 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 longer constrained by the market size, eg the amount of value on Neutron and the number of users on Neutron. I can now also 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 interchange accounts or like IBC, but you can tap into this entire ecosystem for resistance to signal. Which is, yeah. Or I see specifically, yeah,
there. There are some dependencies in Cosmos though, like Ica's are pretty well adopted. A lot of a lot of chains have the like Ica's have sort of two sides to that. 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 but most of them actually have the 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 are the like, what are the benefits if you're the controller chain, like yes, it's 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 wanna expand crashing will want their small contracts to actually control
some of these things, right? So it was a requirement rather than really your choice, but for other applications you may want to use it. For example, let's say I'm a lending and boring 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 liquidity on an AMM or such. And so 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 the auction of 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 guess gets the bonus essentially. So you know, there are tradeoffs 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 ABC like latency is going to become more of a friction point. And so there will be more of an incentives for change to sort of like improve in this front in my opinion. So I expect block time to trend lower in Cosmos cuz 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 you me, 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 ABC transfers to the UMI blockchain, just by sending to an account that they control on Neutron and then just moving and depositing the 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 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 a neutron and you know it can have a UI that allows you to use it as if it was a Dexam neutron or other small contracts can interact with that small contract to basically send calls to the
osmosis blockchain, right. So if you send it to token to do your 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 API for osmosis essentially. So there's a bunch of models that that that applications can take right from the most heavy outbursts, kind of like Mars.
What Mars is doing, for example, on osmosis where the collateral actually lives on the blockchain where the outburst is to the leaner models where like which osmosis or Cosmos 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 talked 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 interchange security. So I guess we can dive a little bit into your or like interchange security, what is interchange security? You probably start there and we can get into like how you adopted it, how you leverage it, but maybe you start simple and then you can sort of explain.
What interchange security is our replicated security? We also hear it called sometimes. So yeah, maybe give our lesson is a bit of the basics of interchange security here. Yeah, for sure. So interchange 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
profile sections. And it's a flavor, let's say it's a category of family that is specific to Cosmos, right, because it leverages IBC, So Inter chain, Inter chain 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 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 that setup, except instead of having every component on one chain, you have them sort of like distributed on 2 chains. I think it would be interesting to kind of 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 polka dot. So in polka dot there's like a relay chain and then there are
like para chains. And then the the validators that are running the relay chain and polka dot are the same as those that are kind of running the para chains. So in replicated security at. At high level looks very similar. There's a set of validators that are running the Cosmos Hub and then now those same validators are also running the neutron chain. So it looks similar like what's the difference between? Is it just like Cosmos Hub, just copying what polka dot 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 of Paul Kadot, so we just decided to to apply the playbook. No, I mean like 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 it it as you said like there are very similar in sort of like the the structure of that technology with I guess one well I I would say like two major differences. The first one is that in polka dot it's this mechanism is it's required to join the polka dot ecosystem. If you, you know, if you don't get your power chain attached to the relay chain, you basically
don't have a polka dot 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 you know Atom economic zone. The sort of like you know like I guess you could say the Adam economic zone is to the Cosmos Hub what polka dot is to the Relay chain, right. It's the ecosystem of chains around it.
And so like that does the first thing right. Interesting security is not required to launch in in Cosmos and in fact the vast majority of chains in Cosmos today don't leverage like in security at all. And the second thing is in polka dot you have a. Mechanism for the onboarding of new chains that is very, very formal, itchy. There's an option and whatever gets the most dot you know locked into that option is what gets a power chain slot in Cosmos, for better or for worse.
There is no formal mechanism, right. So it is I guess as usual in Cosmos it's, it's done through governance, right. So there is sort of like public negotiation process and that has you know trade-offs. On the one hand it's less clear, you know that's the it's, 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 there's sort of three main tools that you can sort of like put into the the balance to get listed on like to get on boarded into replicated security today Obviously there needs to be something in in it for the hub for that, for the hub and its community to vote for your change to be on boarded. 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 Cosmos hub, right.
That's the very straightforward sort of like kind of the second one is if you, 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, that may be fees on specific operations like for example for deck swap fees or what have you. It can be me revenue, it can be 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 the basically impossible to quantify and so it's very difficult for to take that into account into the thought process is sort of the strategic value to the hub and to Adam as an asset that adding the project may have
right. So for example you know like one of the one like some of the projects that are looking planning to on board to replicate its security in the in the short term are liquid sticking 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 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 protocol actually handle and manage a large amount of atom, which is crucial to the security of the COSMOS hub 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 like 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 intrusion 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 3 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
trade-offs. EG1 approach that we sometimes hear is that the hub should launch as many consumer trades as possible, because this way it has, it optimizes its chances of having 1-2 or three unicorns in in the batch. In which case that's a really good outcome and it can just trim off the the projects that fail over time. You know, that's one way of doing things.
But the the problem, the limiting factor here is that while that's probably technically possible economically speaking, that implies that validators now have to run you know 20-30 forty 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 of in growth of the number of chains on 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 but there's quite a few teams like duality a whole bunch of validators corresponding included 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 for like 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 try and find a stable economic equilibrium for this. Basically now I'm like maybe long term I'm pretty optimistic that this will be found.
And especially because the current flavor of 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 like later. But basically all of the validators of the Cosmos hub have to run every consumer chain that is widely listed by governance and with a few
caveats 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, right? In the 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 the situation where the voting power on that consumer chain is basically likes 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 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 cost which would allow them to stay stable in the set, which basically like would protect the hub from sort of like 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 weren't, they wouldn't be able to to support that, that added cost basically. So that that's sort of like the the, the limiting factor to replicated security. And as a result of this, I think strategically and sort of like programmatically as well, what's likely to happen and to be the best scenario for 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 replicated security 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 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 like the the, you know, the change of 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 Adam economic zone itself, right. Whereby instead of competing for growing the pie of the Adam Economic Zone, the project would be basically fighting for you know the whatever is available to them like Adam liquidity and such beyond them. So like between themselves, right. And that's that's sort of like negative AV for for everyone
involved. But if you know with that strategic approach of like carefully vetting and being selective of of projects initially before we have better technology, better frameworks for assessing the economic value propositions of the various projects. I think like the technology is a tremendous potential, right. And I I think that it does like having pioneered this has been I think very significant for Neutron as well.
So maybe like to to recap, right, like is it fair to say that on a high level both Replicated Security, the Atom Economic Zone and Inca dot, they are going after the the same broad concept which is let's build a good validator set and then get that validator set to. To 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 phone call dot 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 the very detailed design of
the city and all of its suburbs. And then then basically like 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 tried to optimize the decision of all of the subcomponents so that the overall city and the kind of suburbs and also work well.
I think it like in their view, whereas sort of like what the approach Cosmos Hub has taken is more evolutionary, the first kind of. Let's build a, let's build an app chain, let's build map chain and a framework to build app chains. So that comes first and then that's standard in Cosmos as the case. 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, OK, how do these app chains communicate? So that's IBC. And turns out many of these app chains start to communicate. And now, kind of like the Cosmos Hub is taking the third evolutionary step, which is OK, how can you duplicate the validator set across across two chains with the Cosmos Hub being the provider of the validator 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? Well the neutron kind of gets on boarded. What's the economic model for it? Nobody knows. With the economic model end up centralizing the value you said. Nobody knows. It has the messiness of of evolution. But it potentially may have the benefits of evolution as well that we might the ecosystem might end up discovering categories of solutions to problems that. Centrally plant city may not
have even considered. So you see that as kind of being any good description. I think there's some truth to that. I mean, I would push back against, 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 just at random. Like we figured 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 discoveries and improvement over time like this. I I I agree.
I think is actually closer to the Cosmos philosophy anyway And I think the one of the 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 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, you know, having a less, you know, systematized mechanism and just building so like 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 bulk cut
out has been. And I think that's true for replicated security as well, right, whereby the the system to onboard to bulk cut 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 some chains, right Like for example, I think you know like one of the assumptions of the of the auction model of Olka dot is that there will be significant crowd enthusiasm for the project because the crowd is what usually has to actually bootstrap the amount of dot 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 cosmos have been 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 it's as long as its value is justified to the Commons, right. So sure that would be added cost to the system but if if the benefits of having that are demonstrated then we can have it basically that that's not a like sort of like economic blocker to to get that into the into the overall system. So yeah, I would agree.
I think like your your analogy is is pretty good actually. Right. Yeah, it's very interesting. And 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 gonna solve for that since I think. You know, there's also no clear path right now.
How do you actually off board a consumer chain especially like without a there is it is very clear how that works. It is very clear how that works. There is there's I would say there's like sort of like 3 layers of politeness that you can have in the of boarding of the chain. The base layer of politeness is not the issue here, which I wouldn't argue for, but it is technically possible. It's just 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 that you said is dictated by the hub, there is no way unless the composition of the hub changes that that chain will start running again, right. So that's that's a pretty strong signal that hey we're not running your chain anymore. Like you can fork it and become your own sovereign chain if you
want, but but that's all right. In general that doesn't seem like a very good model to 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, is going to be a barrier or hurdle to the adoption of ICS,
right. And ideally what 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 that is
probably not the right approach. The, 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 adopt because you have this like 2 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 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. Eg you know there's some like social consensus going on and if you know the the the cosmos of social 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 month period during which the consumer chain should either come back with sort of amended security 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 word is a signaling proposal and it materializes social consensus so that what was Twitter noises and and conversations on Telegram become something that's actually measurable. Of the voting power of the Cosmos Hub, 65% think that that change should be aborted in three months unless they come back with a better agreement. And then it gives the the consumer chain community a time to actually, you know, reflect
upon this. Are there alternatives that would be better suited for the 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 changes become the sovereign up chain secured by its own token, for example, And these like, it gives at least enough time to consider these seriously and for a few governance proposals on that chain as well to to happen,
right? And then you have the confirmation vote that basically sort of like signals it like that sorts of like does the temperature check again. But because there's so much time in between, you know what like if the first proposal was triggered by something that is more emotional in nature or like market conditions, then at least you have some some time to recover from this before it actually leads to to drastic consequences. And the the overall process is a lot more civil.
So that if that's the sort of like commitment on the social layer of the Cosmos Hub, then consumer chain projects know that, you know, worst case scenario they'll they'll get that signal that, hey, they need to sort their shit out or the Cosmos Hub is going to offboard them, but at least they'll have time, whatever happens to, to react to it.
Yeah, I do. I do find it quite interesting that Cosmos have going like for this very governance based currently at least system and then polka dot is like sort of more a market based approach where you know you have that element of the dot being locked and so through that you sort of can signal these are the most valuable chains. Why we have limited slots? Let's fill them with the most
valuable chains. And and you have that lease and it sort of takes away a lot of this governance overhead that is coming right now for for Cosmos. So quite interesting to see how that can be. I agree. But I think it's very characteristic of Cosmos though like you know Cosmos basically baked governance in every suffering action that that actually launched into the
ecosystem. And so you know that's that's like one of the design patterns left Cosmos I guess whereby you know people are not completely removed from these computers I guess. So try to get like a compare and contrast with something that's harder, which is replicated security versus kind of like the modular blockchain stack which is represented by Celestia and Etherium. 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 like transaction A follows 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 Etherium and Celestia kind of like going down this part that is kind of cosmos in replicated security, it's like. Probably like very similar chain designs and the entire validator set is shared. You know, like kind of compare and contrast these two approaches and it's just strengths and weaknesses. Yeah, I mean I think it's it's a really interesting sort of like turn of events.
I mean, when the Cosmos Decay was produced, it like the Cosmos Decay is 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 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 funnily enough, Celestia is actually part of the Cosmos
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 like 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 the Cosmos SDK sort of like platform that intends to be a settlement layer for application specific roll ups, which is you know a very interesting idea.
I know that there's a whole bunch of projects working on similar things in in the ecosystem and that has now even sort of like leaked into Ethereum ecosystem with the op stack and hyper chain 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 like 1 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 action thesis that Cosmos kind of like has been riding 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 action thesis is everything should be a Cosmos SDK app chain. I don't think that that's true.
I do think that the app chain thesis in that there are significant benefits to be had by having infrastructure that is dedicated to 1 application. I think that thesis is true, but I think the fact that everything should be a Cosmos SDK app chain thus likes you 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 so like an ibridation between like roll ups and modular ideas with so like app change and horizontal
scaling. The question interoperability technologies that Cosmos has has born and such. And so I think sort of like to Zachy'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 variance 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 not 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, these ideas, Cosmos has been working on this for a long time.
And so if it can, you know, 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 that then it has a great chance in my opinion to, you know, 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, I think they're kind of like really interesting trend in the industry that are actually complementary to sort of like something. All right. Super interesting. We've been going quite deep into interchange 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. And we can take it back a little bit to neutral maybe and and cover like a few more things at the at the end since we've been going quite for a while and then wrap up. So.
And I think 1 interesting thing that we actually haven't really talked about is then sort of. Neutron like token utility and kind of the the things you're doing around governance since now given your running as an interchange secure chain, right of the token model that Cosmos sort of established where 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 doubts just come up like, OK, 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. Like beyond just our interest in in you know like playing around with the governance in general. The thing is like replicated security exists as I said of Cosmos SDK module that replace the modules that like 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 governance system like modules. Eg you're going to have a token that is not Atom, which is 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 validators actually, but they're governors and they 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 the as a small contract platform. A lot of the innovation that Neutral wanted to do was around empowering and leveraging the modularity of 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 Dow Dow 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 itself 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, eg 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 doubt framework is that not only does this allow you to have a functional decision making process, you can have like single proposals, multi choice proposals, you can have Turk inverting 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 Dow 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 right, the token voting assembly and then that has the power of creating new subcommittees that are dedicated to doing 111 task or 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 customizable limitations. Like for example, one idea for a grant style would be that hey, one person can give grants up to $1000 freely and then 10, like, sorry, two person can give grants together if they agree up to $10,000, right? So I like having these sort of
like customizable limits. And so 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 instantiated by that Agora is essentially when the sub dial is created, it has a time lock module which is so that when the sub dial makes a decision through a vote before that like, which can be pretty fast with their two main DAO governance proposals, like that's a matter of a few hours or days depending on the
reactivity of the members when that gets approved. If that gets approved, it's time lock 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 multisec that is independent from the main DAO but still accountable to the main DAO. And if you know, they betrayed the main DAO, essentially
they're not aligned. The main DA has mechanism to force them to fall back on the main governor's track so that decisions that are, you know, 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 light or actually here, right, like with the Lego and and some of the the things that are actually much harder I would say probably to do in Ethereum because you don't have that the customizability of Cosmos app chain. So I think very exciting. To have like things more codified in Neutron here that are maybe like more on the social layer essentially in 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 to Neutron. We did definitely talk about a lot of like higher level things, but I think you're you're the right person to do that. So I've been going for quite a while. So I think we were at a good spot to 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. 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, one last sort of like announcement
or whatever. You know, we talked during this this episode a lot about like the structure replicated security and 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 that we've teamed up with long Hash but also the atom Accelerator Dow in order to launch an accelerator program that is dedicated to that set 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 and convex zone and provide them with funding experience.
You know like 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 in a really good shape and being very successful. So if that's interesting to you check out you know Neutron or Long Ash or Adam Exlorator, Dow's Twitter and blog 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 appreciate you plays that shell here at the end you know. All right. Yeah, very. Yeah. Thanks everybody for coming on. And yeah, hope all listeners enjoy this this breakdown of interchange theory and then 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 Oregon Alexa device. You can tell it to listen to the latest episode of the Epicenter podcast, go to epicenter.tv, 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 guest 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. I want to do it.