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.