Welcome to epicenter, patrollers talked about the Technologies
projects and people driving decentralisation and the
blockchain revolution. I'm suggesting with Joe and I'm
here with Felix Couch. Today, we're speaking with
Rebecca allow she is the co-founder and CEO of saga.
It's a project that's It seeks to enable developers to
seamlessly provision, their own dedicated application, specific
blockchains. So before we talk to Rebecca,
I'd like to tell you about our sponsors this week on me.
Is your new favorite multi-chain, Mobile Wallet only
supports more than 25 protocols, so you can manage your assets in
one place. But what's really special Omni
is what you can do is either wallet.
If you want to get yield on the allows you to get the best AP
wise with zero fees in three Taps, you need to swap.
Well, I'm the It's all the major indexes and bridges.
So you can bridge and swap across all support networks in
one transaction directly in the wallet.
If you live in if T's Omni offers the broadest NFC support
of any wallet so you can collect and manage your favorite
activities across all chains in one place.
Omni is truly the easiest wallet for have three and it's fully
custodial. It's really important and you
never have to trust anyone with your assets.
Other than yourself and also support Ledger, which is great,
I've used on Me a little bit and I really like it and I really
like the fact that they support The Ledger because for a mobile
wallet on a theorem Chains, It's not often that you find a mobile
wallet that supports ledger so give only a try at Omni dot app.
Rebecca, thanks for joining us on the podcast today.
Thanks so much for having me Sebastian, Felix is great to see
you guys. Epicenter is regular listening
for the entire team at Saga so really appreciate you having me
on nice. Well well I hope I hope you know
you can you can return the favor by teaching us a few things
today. Absolutely love to learn more
about Saga and what you guys are building and I think it's for me
it's an interesting also thought experiment to try to figure out
where this sits in the Our app chain, interesting, security,
modular chain mesh Network thesis, you know, there are a
lot of products right now that are trying to implement
different security models. And, you know, it's interesting
to try to reason about where they fit in the broader
landscape before we do that though.
Please tell us a little bit about your background where you
came from and how you came to be the CEO at Saga?
Yeah, absolutely. I'm happy to dive into all those
topics. That's what we spend all of our
time thinking about, it's all good.
Oh, so no shortage of things to discuss there, but in terms of
my background, how I found my way to Saga.
So this was late 2021 and I'll tell you about my journey before
then. So I was actually my second
crypto startup. My first one was called steel
chain. Co-founder there was sake, man,
who's one of the original Builders and Cosmos, we've known
each other a long time and scutum was focused more on the
defy space. So as providing short-term
liquidity to a small medium-sized businesses and I
was co founder CEO 0. Therefore Years.
Grew the platform to about 5 billion in annual volume and
early 2021. I started to think to myself,
okay, I've been here for years, the project is on its way.
I would love to see if there is a new adventure and I've always
been involved in politics so I was part of both the Clinton and
B in presidential campaigns, both in 2016 and 2020 and in
2020 we actually won. So I began to think to myself
maybe I should go into into service.
Us and joined the administration for a little bit.
So I actually went to d.c. for a few months in early 2021 and
went through the interview process, waiting for nomination.
But I quickly realized through that process, that I'm not
really suited for federal bureaucracy, no surprise.
After having done startups for a long time.
So I called up sake and say, hey, I think I'd like to stay in
crypto so he introduced me to our co-founding team at Saga,
because we all believed that. Or as needed an easier time.
Basically, a building in web three that they didn't have the
full tool set that obviously web developers have, which has been
built up over several decades so no surprise there.
But we felt that there was much easier ways that we could make
developers on ramp onto with three in a much faster and
convenient manner. So that's how we, that's how we
co-founded Saga. But my first started ever was an
AI actually. So it's interesting to see a
comeback as a big Trend. So it was a company called
quality. See, I was part of the early
team. They're headed a business
development, founded and ran their Asia operations and we got
that cry SoftBank within a year and a half.
So I got two uniform status pretty quickly, but then I fell
in love with crypto and as it Ed to do my own startup.
I started my career as a corporate lawyer actually.
Let's the last piece of this. I was a lawyer for about 56
years before jumping into into startups full-time.
But yeah, that's how I found myself at Saga and it's been
about a year now that Been hacking away at this project.
Cool. What was this other project you
did with exact e scue chain? It's like yeah chain it's so
it's SKU chain and it's the name is the play out.
The fact that a lot of the business that we did actually
involve supply chain so it involved the movement of goods.
And oftentimes when these businesses are looking for
short-term liquidity, what they really want is to optimize their
cash flow cycle. So, if they are producing Parts,
they Want to expend that cost after they've already taken
money in and that's the Gap that needs to be financed.
So, yeah, that was the, the primary use case that we were
going after. Okay, interesting.
Well yeah, let's let's talk about and let's move into Saga
me. How did this journey from
skewed? Chain merge into, you know,
building Saga. What did you take away from that
experience that allowed you to you know have sort of better
grasp of what the problem space was that Saga is is now
addressing Yeah. Absolutely.
So Zaki. And I so we rescue chain
together for for a few years, but then sake stopped out to
start building Cosmos. And so I've been aware of Cosmos
for a very long time and knew the thesis behind it, I tracked
their major Milestone. So when the SDK was launched
also an IBC was released. So I knew that this was a really
amazing protocol, really great developer mind share as well.
I guess see how popular it is with engineers.
So definitely been a big fan of Cosmos for a long time.
What we realized is you chain was, you know, SQ chain is, you
can tell from how I'm describing.
It was a defy application. So we sat at the application
Level but what we discovered quickly is, you know, the
infrastructure, the underlying infrastructure for web three
really, isn't there yet to support the full functionality
and growth of a really great application.
So, with most of the infrastructure prior to Kozma
strains really proliferating you're looking at model with a
chain. So things like if you're in for
instance classic example. Falana Etc.
So really these chain side mandated hind variable Gatsby's
for their end users. There was congestion because
you're sharing the walk space with all these applications that
really don't have anything to do with you.
And ultimately the chain environment is controlled by
somebody else, it's controlled by the core team by Foundation.
If anything should go wrong with the chain.
There's nothing that you can personally do about it.
So, The way I'm describing all these different issues.
It came to the conclusion as you change that, cause us solves a
lot of this. But Cosmos opens up a whole host
of other problems, which is how do you get onto your own chain.
That is a big lift for most projects out there for most
individual developers out there. It's a non-starter.
So how do we get all the benefits of giving people their
dedicated block space. But he's some of the lift and
all the co-founders that Saga, including Jin Kwon former
executive at Enderman and in our chief strategy officer Jake
mcdorman, who is our co-founder sitio designed the entire system
Bogdan who's our co-founder and VP of engineering, we all felt
the same way that it was time that development environments in
web three were as easy to use as development environments in web
to and that is what the Saga protocol reflects.
Right. So I guess you already
mentioning Cosmos and I guess Saga is sort of also part of the
cosmos ecosystem. Maybe can you sort of explain to
us a little bit more? Like how what Saga actually
does? And I guess also how it
leverages Cosmos in away? Yeah, absolutely.
So Saga, the easiest way to think of saga is we are chained
to launch chains. So we are a layer one protocol
in our own, right? So we are our own chain but the
whole purpose of this chain is to launch other chains.
So how it works for a developer flow is usually the developer
will deploy a smart contract or an application into a virtual
machine environment. And the reason why we require
the VM is the whole system is permission list so you can
deploy anything you want onto a dedicated chain.
However, that poses a security risk to the rest of the system.
And so we asked developers to deploy in a VM because that is a
controlled environment for them usually makes it easier for
their development but then on our site is a security layer
between their application and the rest of the system.
So the developer will take this p.m. and through command line,
they're able to automatically, deploy it onto that dedicated
chain, which we call a chain lives.
Now, how do we achieve that? It's through, entertain
security. So we are Cosmos change.
Use the cosmos SDK and within that interchange.
Security is one of the newer features.
So, entertained security and its current iteration what it does,
is it allows one change replicated security model onto
another chain. And so we have The Saga of
maenette secured by a set of validators, whatever developer
requested chain lit. Then that seems that a validator
is going to fire up that chain lid, it has and has the exact
same security model as The Saga maenette.
It is secured by the same. Set of alligators.
And that's, that's how we're able to proliferate these chain.
Let's so that is how the Saga protocol actually works.
And we can go deeper into why we think gaming entertainment as
the primary use case, and how we've been working with other
providers of obtained, side chains, roll ups, Etc, but at a
base level, that's how the Saga system operates.
So can you describe this chain, let Concepts OU, you described
as a VM, but I think most people are familiar.
Interesting security. The security, actually, secures
a sovereign chain, well, Sovereign to the extent that,
you know, there are some parameters that are still left
to the the validators of the of the of the parent chain, or the
provider chain, but in the concept of a VM, it's a bit.
It's yeah, it's a bit of a New Concept to say that validators
would implicitly secure that VM and that is how is it different
from just running a kazim? Awesome Contracting.
Also, is that a thousand wasn't VM?
Or is it different VM? Yeah, so many questions.
So what the validators are doing is they're taking that smart
contract or application and then putting it onto its own
dedicated chain. So I chained like is a a chain
and its own right. The main difference between a
chain ledge and a fully Sovereign chain is that there is
no staking token so because you are borrowing this, well you're
not borrowing, you are replicating, the security model
from The Saga maenette, the token that secures the entire
system is the Saga token and so there's no need Need for this
project to have its own staking token.
You can have your own native token.
That's part of our joking. Economics.
However, you don't need a staking token, which means that
in addition to not having that that token.
You also don't automatically have governance so you can have
governance if you elect it but it's not just a matter of
running the chain. So those are the main
differences between a chain ledge and a fully Sovereign
chain. But when a developer brings an
application System. So it may be contained within a
virtual machine environment. But what they're being deployed
on is is a chain. And so the validators are
securing that chain. The validators don't need to
think about what the actual VM is or what the application is,
or they don't need to concern themselves with that.
It's a fully automated process that is orchestrated by our Saga
me, net. Such that.
When a developer asks for a chain ledge provided that they
have enough Saga tokens to pay for that chain, but to be alive.
They get that change lives. So that's, that's the flow.
The VM is really just to ensure that there's a security layer
between whatever the developers deploying and the rest of our
system. The first kind of VM that we
support is the ebm because we see how popular it is in what,
three in general. But our goal is to be the M
agnostic. So cause Mausam is the next kind
of beyond that will support because it's very popular within
the cosmos ecosystem, we have people building On Saga already
who are working on Solana BM. That's compatible with tender
moment, a movie. Mm as well.
That's becoming more popular in gaming and entertainment.
I think a gorik has a JavaScript p.m. that's ready to use.
So our goal is to give developers a choice, you know,
whatever development environment, you're most
comfortable with go ahead and work within that.
And then we'll take care of the rest.
In terms of deploying, you onto a chain Yeah, I think what was
interesting, like you just mentioned that the developers
pay for the chain LEDs in Saga tokens, I guess.
Can you expand a bit? How that works?
I guess. Yeah, generally we have I guess
totin like the application specific trait has their token
gifts taking rewards but I assume in this case, somewhat
different. So I guess that's that would be
interesting to hear how that works.
Yeah, yeah. So we have a two-tier token
structure. We think that one of the
stranger parts of web three. Is that when you have a layer
one protocol the fees, the transaction fees for operating
on that protocol are given directly to the end user.
So the end users have to pay for the infrastructure costs and
they are aware of what those infrastructure costs are.
That is not a great user experience.
And certainly when you start to get into things like gaming and
entertainment, we're honestly the the payment part is kind of
a nuisance. You just want to play the game
and have fun. It becomes something that you
have to do away with. So, how our system works is
there's a saga token in Saugatuck and secures the entire
system and that is what all the inflation is taking.
And the entire economy is based off of The Saga, token is only
used to pay for the Chain LED so think of it like an AWS instance
in a way. So we treat the The Saga Gene,
let's like those instances. And in the same way, for all of
you who are developing an We understand that you pay for
those instances to stay alive every month or so, you
understand what that cost is as long as you pay that that cost
then then Amazon will keep those boxes alive for you.
So same idea with us, the developer has to have a certain
amount of saga tokens in an escrow account.
Basically, it's our feet deposit, and for every month
that they're keeping the Chain little, I've then we're going to
be depleting Saga tokens from that fee deposit.
Now, that's Metal directly between us and the developer on
the front end. We are invisible as long as the
developer wants us to be. So for most developers, they
want to offer their applications for free actually and then
figure out what the monetization model is going to be.
Some of them will just charge for in-game assets.
Some of them will have their own native token, they want their
own token, which is totally fine.
Some of them will have users coming from other communities.
So they're coming from aetherium where the used to being on
Solana for instance and then they'll charge Gatsby's in.
That native token instead. So they'll be charging gasps and
he's worse, all it doesn't matter to us.
Everything that a developer earns from their application,
goes into a wallet that is controlled entirely by them.
So we don't see any of that. We don't interfere with it.
All we care about is that the developer continues to pay the
Saga targets necessary to keep their chain.
Let's alive. This is really interesting
because you know what this condos up is conversations with
J-Kwon around, had a 2.0. Yeah, and I don't know if you
guys follow that and there was some conversation around around
having chains that were using interesting security aligned on
protocol economics. Now, they're here, we were the,
what was proposed as a to token system, where Adam would secure
the cosmos. Annette and then there would be
this second token. This Photon token, that would be
the payment token by which Supply Chains would would pay
for security. And there was this kind of burn
mechanism that allowed consumer chains to to to to swap Adam for
this token. It seems very similar.
There is there's there's only one token here instead of to
wonder if any of this research or sorry, if the token Comics
come from sort of similar discussions and research.
That had been actually Sunny wrote a paper about this whole
token model. If you go back and look at like
the cosmos GitHub, you'll find this paper that he wrote in 2017
or something about this. Yeah curious.
Where that we're those were those ideas came from if they
have similar seeds. Yeah, so I think for all of us
came to similar conclusions, but from very different starting In
places. So I think for Adam 2.0 the
well, the whole idea of the project is a, how do we elect?
Well, they also wanted more people to be building in Cosmos,
but they also wanted to find use cases for the Hub.
And they definitely wanted to ensure the health of the atom
token. So that's the angle that they
came from. And then for Sonny, I actually
have not read that paper but I'd be very curious to hear what the
motivation was for thinking about a two-tier token
structure. I think for us it was all about
usability at the end of the We just we don't think that most
people when they are consuming an application that they want to
deal with more than one to meet a handful of tokens at the most
a lot of people who are coming into this space and really
taking advantage of and liking web three applications for the
first time you know they're not going to have a wallet that
holds like lots and lots of assets and they probably will
never want to get there and so our thinking was okay, how do we
make it easier for them? But nevertheless, a crude value.
To to our system and make sure that all the Saga remains secure
are so we came at it from more of a usability perspective, but
I will say that so are talking economics approach in general,
is keep it simple because the more bells and whistles that you
put in there for market-making or you know, levers for ensuring
the health of the price of the token.
The the more honestly the more traps that there can be for
things to go wrong and so We were thinking, okay we need a
solid business model which is you know how how does the token
get support at well in our system the more chain looks
there are the more buying pressure there will be four Saga
and therefore the price will continue to be supported that
way. Doing a two-tier token where we
have two tokens so like an atom in a photon.
That's where you start a you start to dilute some of the
Valeo and once you implement that burn mechanism, I mean
that's the sort of thing where I think that yeah, people will
start to play tricks with that if you need human intervention
and that process will then, I mean, that opens up a whole
other can of worms. So we we did not.
Yeah, we didn't want to go down that road.
We came at it thinking, okay? This is what the user was
expecting from what? Three applications going
forward. And this is how we can make it
easier for them to onboard. I think the to token system
might be wrong here was in order to prevent hostile takeover of
the at As the consumer chain Stakes taupe Stakes tokens
essentially. And this may be a little bit
different here with with Saga, but they essentially stake
tokens with the provider chain. Validator is the risk of having
Adam accrual at the consumer. Chain level was a massive on
staking event that would jeopardize the security of the
chain wear that A chance. A provider chain would
essentially take over governance or take over, have too much
power on the concern, on the, on the provider chain.
And and so, I think this is where the two token model came
into effect. Where essentially, when, when
you start securing at any a consumer chain, you you lot, you
lock into this. Other token that token and then
there would be mechanisms to swap back into Adam.
Originally, I think also, the idea was that you couldn't, Hop
back into Adam once you've went into the photon, you couldn't go
back, but then those ideas through discussion, right?
I'm 2.0 and the the conversations that were being
have with Jay was that there could be a mechanism to go back
into Adam but with time locks and such that, you know, Adam
holders would be able to unstick if they if they saw that such an
attack was coming. But in this case, Chain.
Let's are not staking any tokens.
They are. They are needing to acquire your
Saga token. By some means puts that puts by
pressure on the Saga token, and then they pay validators for of
that security. So, there's this constant, the
economic cycle, there's like a velocity of money happening and
it's in the system at all times. That's exactly right.
That's exactly, right. So it should not be the case.
That any particular developer that has a chain lid is holding
onto those chain LEDs for a very long period of time, if not
indefinitely because they got to keep the chain let alive.
So those tokens are going to find their way to the validators
every month. When we do deplete, that account
of the chain lippies for for the particular talents that they
have running the The Saga tokens are going from the developer to
the validators now in Terms of, you know, staking for, for the
validators or developers, want to stake their Saga and then
just use the rewards from staking, to pay for their chain.
Let's, that's also possible. But I think the way that we've
designed the system deliberately avoids, that particular
scenario, where someone's just going to hang on to this
concentration of economic power. And then it's kind of like an
atom bomb that they can well no pun intended but an atom bomb
that they can set off at any point, right?
So yeah, it's it is meant to really encourage Edge, that
velocity of money. Like you mentioned sub.
Right. I think one, one, interesting
thing, I, it sort of reminds me, I guess.
Also, in AWS, you have like different instance sister.
I'd like different sizes. Different, like, specs to
challenge. Work like that, too.
Or is any Chain LED like the same.
They are the same. They are the same.
So every chain let is the same. They are priced the same, but we
do believe in elastic scaling, which means that our
anticipation is that your most developers are not just going to
have one chain lid. So, So when we started off, and
I think in some ways, the Hub still conceiving of it, this
way, we thought it would be one application per chain light.
So in the true sense of the app chain application, specific
chain, but what we've come to realize with our system is it is
so much more powerful. If we allow it to scale
elastically, if we allow it to scale horizontally.
So what do we mean by that? A developer will probably need
at at least three environments. So Dev staging and then their
production environment for the actual application on top.
At once the application starts to get appreciable traffic
through at one chain letters, probably not going to be enough,
you're going to need multiple. So, in order to ensure the same
level of performance, your knee, you're going to need to conclude
spill over into additional chain.
That's and that's how we encourage the the developers to
scale. And that's why we're not doing,
you know, customized chain. Let's where some are bigger
sizes and others, you're getting chain lights, and if you need
more chain, let's than you, you can purchase more.
If you are scaling down your application, Or you've put up
too many development environments and you need to
close down a peach. And let's that's that's
eminently possible as well. The goal is to commoditize the
system so that we make it as easy and thoughtless, frankly as
possible for developers that they need environment to Bill.
They can pull one up very quickly.
Maybe I guess. Yeah.
Now if we think of an application that maybe runs on
multiple channels, can you talk a little bit about how
composability would work in such a system or do you need like
split apart your application and certain way that this this model
can work or how the Saga sort of allow you to do that?
So I'm Saga runs only because I DC is available and so you keep
in mind that everything in Saugus independent of one
another. So there's a saga maenette and
then all the socket chain. Let's again our chains in their
own, right? So everything is independent of
each other in order for this whole system to work at all.
We need IBC. So, the way that the socket may
not orchestrate these chain, let's is Thrive, you see?
So in order to make sure that people are Keeping the the chain
that's alive according to the SLA contract that they are
paying for the chain LEDs. As they need to that the chain
links are actually being spun up automatically, all of that's
coordinated via IV see through messaging back and forth between
the chain LEDs and the saga mean that now the chain, let's also
have IBC because they're all cause they're all Cosmos chains
and their own rights. Some, they also communicate with
one another and right now, IBC as mostly used for the the
transfer of assets back and forth, but I think with
Entertain accounts. We can relax and expand the set
of messages that can go back and forth between chains.
So for composability, it's really IBC that were reliant on.
And your website talks about this ID, C plus you explain what
that is because I'm not familiar with this particular premium.
IBC. That you guys are splitting up.
Yeah, yeah, I know it so it's not It's not really a premium
version per se, but it is a unique trait of our system.
I would put it that way. And what I bc+ refers to is the
fact that so IBC is needed to, to run our system period, the
communication that happens between the chains requires IDC.
But what we realized was okay how do we sort of maybe
streamline this process here for IBC?
Because usually IBC assumes that you have two chains that have
nothing. To do with one another, the
validators. That's a completely different.
And so you need to like clients on either side and then you
achieve IV compatibility in the messages.
Go back and forth for us. On the other hand, the validator
sets are exactly the same for all of the participating parties
and so where we are putting forth some Innovations and IBC
just to make it run faster and hopefully make it run a little
more cheaply for the validators as well because we will require
them to run re layers. Yes.
And so, in order to just make the system, much more efficient,
we are going to tweak the current iteration of IBC but
whether this can be used for other systems.
I'm not so sure. I mean the the main assumption
here that makes it all work, is the fact that we have a common
validator set across all of our chains.
Right? Because with IBC and you are
assuming different security models between chains.
This is why you need the light clients to verify the other
chain here. Since all the chain, let's are
using the same security model that that overhead isn't
necessarily required. I guess this would also be the
case for ICS consumer, chains that are leveraging.
The Entire Cosmos Hub, active set, and are not leveraging
their own validators. I guess that's IB IC s 1 or
whichever version at the first version, but that starts to
break apart. Once you have different security
Malin different security over for different chains.
Uh-huh. That's right.
How do you maintain then IVC
compatibility with other IVC change?
There's this is IBC here because I mean it sounds like you don't
really need IBC. You might need parts of it but
like the IBC protocol as a whole you don't really need much.
I guess you need IV. C 1, any of the chain.
Let's wants to talk with sales Moses or some other external
chain. Yeah, that's exactly right.
I think we want to preserve IVC in its current iteration as much
as possible but just making optimizations for the fact that
way the same validators that across all chains.
Because we do anticipate that, that will happen very quickly
that our chain, let's are going to talk to other chains within
the cosmos ecosystem and then we see also.
And this is also a bet on IBC itself as a messaging standard
that will be applied across more blockchain ecosystems.
So we I hope that other ecosystems like an avalanche,
for instance, will take of IBC. And then at that point, if we
have sort of optimized ourselves out of compatibility there,
that's not great. So we want to make sure that
we're still working with those future iterations.
And then for some of the larger Partnerships that we have
actually for people outside of the cosmos chain environment and
it is reliant on IVC specifically.
So, yeah, any anything that we do has to remain compatible with
how others are using IBC at the moment.
Maybe just one other question here on this because I realized
it's not super clear to me a butt like this chain.
Lit it in the in the in a blockchain stack of execution,
settlement data, availability, consensus and data.
Availability, what parts of that Arc are the chain-link maze.
It's just six. Is it just settlement and
execution? I'll far also know they're,
they're all consensus. Is that okay?
So what the consensus is happening on the Saga chain,
this is where Yeah, consensus happening on on each of the
individual chain lights. Yeah, the saga mean that exists
to orchestrate. So, to stand up, make sure that
the validators are behaving because in an interchange
security system, how it all stays together is, if a
validator is not not behaving on any particular chain ledge.
Then according to the mechanisms of the protocol to get flashed
and that slashing really happens on the Saga of meat net.
So Saga, Mina is really there as an administrator.
It is not Out there for consensus or settlement, all
four parts of the blockchain stock live with each individual
chain lid. Okay.
And so in the same way that with interchange security, Kosmos,
Hub, validators are going to have to run clients of the
consumer chains. They are validating Saga.
Validators are going to have to run clients for each of the
chain lets's. You're validating, is that?
This is where? Okay, then then my question is,
okay. Then this this stack, let's I
want to talk about the the TxTag where the client that they're
running. Is that a cosmos sdk-based
client. Uh-huh.
And and then VMR, you guys do. Is it is it is it ether meant
like what's the cause it's easy Em, Right so yeah, can you
describe the text back? Yes.
Yeah. Now that's exactly right.
And so every chain is running Cosmos SDK That is not because
any of the developers deploying on Saga have touched Cosmos.
SDK necessarily, it's just a stack that we automatically spin
up for the VNS. They do have to be compatible
with tender moment consensus. So it's not like you know people
who have already worked on a salon.
A VM in the salon ecosystem we can just take their work and
then plug it into our system. It's not going to work that way.
So our evm implementation is either meant yes, they've done
the work which we really appreciate form.
Making the evm compatible with Cosmos.
And when we move to the next kind of VM Cosmos and that's
going to be a little easier as this Cosmos native.
But honestly for the other kinds of virtual machine environment
like a salon IBM, I mean that's something that Eclipse which is
one of our innovators is doing and because it is a bigger lift
our team could undertake making all those beams compatible with
with tender man, but I think it's much better to rely on
other community members. It was spotted the Opportunity.
They are and provided these vegans themselves.
But, yes, in terms of the stack, whatever VM we make available or
that a developer uses to deploy on us, it's got to be compatible
to temperament, right? And are you, are you familiar
with any of the work that's being done on the kazim, wasum
SDK. And I wonder if Yeah, because
I've most is effectively, I think going in the same
Direction, with their Atmos SDK, and by that, I mean
re-implementing the cosmos SDK modules as smart contracts in
Cozumel Azam, and, and solidity, I guess, or rust and solidity.
But compatible with a, cause a Muslim in EDM SDK is that
something that you see, as a viable path for the future for
streamlining, you know, since since application since the
Occasions themselves are not using, I mean, they're not going
to be using these. Cosmic SDK modules are just like
interacting and building an application using the VM
component. Yeah.
So it's I think at the end of the day not to sort of over
simplify this a bit of us a philosophical question as to
what is the most viable kind of business model for a protocol
moving forward? So is it more in providing that
really easy to use developer environment in which to deploy
on. So essentially what these
efforts are trying to replicate is your was so easy for a
developer to deploy. Slutty smart contract on
ethereum and get going right away.
Can we replicate the same experience in Cosmos?
And I think that there's definitely a place for that kind
of development effort here. But the question becomes is that
the core competency of Kosmos is that really the value, add that
our particular ecosystem provides to web three in general
and I would say that it's part of the the big puzzle but really
people come to Cosmos because they want their own Is to
built-in. And so, I don't know if these
Source smart contract Innovations alone can accomplish
that, you need to be able to spin up space and as easier way
as possible, we're doing it in an automated way, but, but when
we think of Cosmos, I mean again it's I'm full of puns today,
unfortunately. Sorry guys, but when you think
of Cosmos you think of space, right?
You think of your own space and I think that's what we've
decided to really focus on is other, people are making all
these more Contracting. Ovations that we hope to help
bring to Market through our ecosystem and our
implementations and our adoption.
But at the end of the day, what why do people come to Cosmos?
What is cause most known for it is God's sovereignty.
So we're looking to provide that space is where yeah we're
attacking the developer problem from from multiple different
angles. I think they're all necessary at
the end of the day but this is why we've chosen our path.
Right. I think, I guess, maybe taking
it back to the sovereignty. Now, we sort of discussed it
all. Chain LEDs are sort of the same
it at least in terms of like the size and spec.
What exactly can you still like sort of customized?
I guess the VM which right now is just evm but what else?
Like can you tweak the block times?
Do you like what else can you sort of do on your channel?
It? Yes.
You can set your own blog times that's totally fine.
And what we're starting to do. Were worth were making the
system into a modular stock in its own, right?
So you have the Saga chain, let's or the plain vanilla
version. You can tweak log X for any Saga
chain limit. And then on top of that we have
a bunch of services. So we've been talking about AWS
this entire time, but really AWS and just your cloud service in
general, I don't think they would have really gone anywhere
without something like a Heroku or Heroku, like Services
supplementing that. So that's something that our
CTO, frankly spending most of his time on Right now is
figuring out what are those services?
That will help developer basically, you know, get as
close as possible to that one click.
So when they want to spin up a chain love, what are all?
What are all the services that we need to bundle as a part of
that in order to make that experience, as seamless as
possible for them? Now, some of that is, is going
to be common across, most implementations.
I mean, one example of that is the Explorer.
Everyone needs an Explorer, but if you are a gaming, a Station
for instance, then you're probably going to need the multi
chain wallet right away because I mean you're you're probably
multi-chain to to begin with and you want to be within the entire
Saga ecosystem. You probably need a game
launcher in the SDK that comes with that.
And so that's, you know, a group of services will be bundled into
that sort of implementation. If it's an mft project where you
don't have the same requirements, then it's probably
a more streamlined set of services when we start to really
focus on things. Like If I, for instance or other
use cases, that will be another set of services.
So our goal is to really make this into a platform where we
think that in order to successfully launch a chain
lead. For this particular use case,
these are all the services that you need, but other than the
base chain, like you can take things out, you can add things
in as you like. So above that protocol, based
protocol level, there is actually quite a lot that you
can customize. And then with some of the newer
Partnerships that we have, it's not Adding services on top of
chain. Let's anymore.
I mean, when you work with somebody like a Celestial,
certainly somebody like a polygon, they have their own
stack. And so that becomes a separate
offering on Saga all together, where were using some very key
parts of the Saga stock, but at the same time, you know, it's
going to be polygon Edge code. For instance, it's going to be
Celestia romant and data availability.
So those are far more specialized Stacks that
developers can also choose and if they want to customize in
that direction, then that option is there for them.
Them. But the whole point is to build
a platform, right? So you already took away like
some of our next topic, obviously, that, that the
Partnerships. I mean like the first of all,
congrats on like, scoring so many, like names there, I guess.
Like you mentioned, polygons and Celestia, I think it would be
cool to sort of go into how that works.
These Partnerships, you sort of mentioned, right?
They are using Saga for certain. Immense in their stack.
So I think with with Celestia there's this concept of like
sequences as a service and in Pulley got your working with the
super dead. So maybe you like sort of,
explain a little bit both of these Partnerships and how Saga
sort of helps the developers in these ecosystems.
Yeah. Yeah.
Absolutely. So towards the end of last year,
as we started to mature these conversations with lesstm
polygon. I think what our CTR recognized
was wait a minute. When you look at the Saga
system, you know, so far. We've just been talking about
Cosmo, stop chains. So every chain let is a cosmo.
Stop chain. What if we were able to
generalize that such that? We think about it?
Not so much as an AB J necessarily but just as
dedicated block space because I think as As blockchains have
just started to think about scaling more seriously.
There are so many names for the same kind of concept.
Yeah there's the option there's a side chain.
There's a rollup, etc, etc. But is there a way that we can
generalize right. Exactly.
But is there a way that we can generalize across all of this?
Because we do have a very unique offering and that is the
automation piece and the ability to share security.
So, is there a way that we can? For that across all these
different dedicated block, space offerings and the answer was
yes. So both with Celestia and
polygons I'll go into the specifics of each shortly but
but what they have in common is we realized you know the Saga
system if you don't think about the validator said for a second.
So you don't think about the Saga validators.
You focus only on the fact that we have this interchange
security that has been Optimized in a certain way to make the
whole system permissionless and has also had all these Services
built on top of it for that Heroku, like, deployment, that
in and of itself is quite valuable to all these different,
dedicated blocks, Based Services.
And then there is the possibility of communicating
between somebody else's ecosystem and our ecosystem to
access those Services through IBC.
So that that General That is long as you have some sort of,
you know, controller chain. If you will, if you have some
sort of chain that can act as communication between our
services and that other ecosystem.
And there is IBC, then you get access to that automation.
So that's that's the common theme that both celestion
polygon has so, how does that manifest itself in Celestia?
So with Celestia, they obviously have very strong data
availability in terms of the role of peace, I think they were
trying to figure out, how do we make this?
It's easier because right now what you have to do for Roll Up
is you got to get your own sequencers.
Most of these Roll-Ups as a service projects are putting out
centralized sequencer sets, or single sequencer sets.
And so how do we get to a decentralized sequencer said,
how do we automate that? How do we sort of negate the
need to recruit and to have your own token.
So that's where we come in. So we have in the celestial
case, we're using our own validator set and the Sequencer
selector or scheduler on the Celestia side, they're the ones
who are going to be selecting the sequencers for particular
Roll-Ups. And then if there should be any
fraud or email activity on any of the validators working on the
Saga side, that will get communicated back to the
Celestia system via data availability.
And that's how we're able to orchestrate Roll-Ups as a
service in a decentralized way. So that's how it works with
Celestia with polygons polygon is a different stack So they are
not only, you know, polygons at the Aryan based but they are
polygon Edge specific. So polygon has an app chain
solution is called super Nets and the team that developed it
as polygon Edge. If you go on there, get Hub.
You'll see that the entire stack has been customized according to
polygon Edge. So what they were doing was they
were use similar concept, they were taking Matic, validators
and saying to their customers or clients.
Hey, we can stand up a chain for you.
You can pick among our validator set.
And once the, the validators have been gathered, then we'll
construct the chain for you is very long manual process.
And that's why to date. There are no super nuts that are
actually live. So, how did, how do we actually
use the adoption of this? And that's when automation
really became a serious conversation.
So there that was a trickier one because Maddie validators don't
want to be, you know, sidelined in this deal.
Obviously, they want a piece of all the super net action so
Saga, validators were no longer going to be used to automate
these chain LEDs. Instead, what we're going to do
is the super Nets are still going to be secured by the
mattock validators. And in terms of making sure that
those magic validators are behaving in the right way and
that they are still undergoing that auction mechanism.
Sorry. I don't think we've talked about
the auction mechanism start. Yeah.
But The way that we price our chain lets it through an auction
mechanism, will go into more detail about that later but it
is a pretty big innovation in validator pricing, so making
sure that the mattock validators are adhering to that option and
all the other sort of services in orchestration.
That come with the Saga. Stack that again is going to be
communicated back and forth between their system and hours
via ABC, but still going to be mad at validators.
So if you want to think of it a certain way, it's that thematic
validator, is that are participating in.
At security, they are adopting parts of the Saga stock.
So that's how those two Partnerships work.
It's a provided a lot of detail, but if you want to think of it
in a very sort of simple way, it is that a Celestial role of us
now is like a chain lit. A polygon supernet is now a
saga. Chain lit.
How we make that? All work is primarily due to IDC
but the the point of these Partnerships is to generalize
the automated deployment of dedicated block space Okay,
interesting. So you're saying I select a
Celestial roll-up is now a saga. Chain Latt.
Uh-huh. That that kind of blows my mind
because I mean, you're not talking about like Celestia's
data. Availability layer.
You're talking about the execution environment.
Yeah. Right.
So you're still be like a fuel roll-up or something like that.
Exactly. So it's just specific to the
role of peace and also to be clear that this is now an
offering that both Celestia and saw the will make available, but
if for whatever reason you, you went to celestine's that, I love
their data availability. But yeah, I have my own
validators. I want to do a roll up of my
own, that's totally still an option.
It's the same for polygons. Super Annette's.
If any developer said, you know, I want to go through the process
of selecting my own mad. Ecology haters and customizing
this chain completely for my own purposes.
And I want to make it permissions, Etc.
You can still do that, but we are probably going to be the
easier option for developers to go with.
Right. I think I guess you sort of
touched on it maybe we can go back a bit to the the innovation
of like sort of how you price validator seats.
So this auction I think it's called musical chairs.
I remember reading the white paper a while ago so yeah I
think yeah, super interesting Concept in terms of yeah, going
a bit away from like the model. It's currently is get some steak
and then you get the rewards but rather more engaged.
S in terms of on the validator side.
So curious why you came up with that and I guess how it works
obviously. So yeah.
Maybe you can expand on that of it.
Yeah absolutely. So I think that we had two
goals. Really, I'm with respect to this
mechanism that we came up with which is the musical chairs
auction things. Feel like yeah that's that is
our name for it. I'll explain why in a second.
But on the developer side, we wanted to To give them as
predictable and commoditized, or pricing as possible for chain
LEDs because I mean, that would greatly help with the
development effort, on the validator side, we understood
the burden of having to instantaneously validate, as
many chain LEDs, as the developers are requesting, as
long as they can pay for them. So, even though validator says,
yes, you know, please give me all your chain LEDs.
It is obviously a huge undertaking in terms of the
hardware. And the maintenance and the, all
of that. So this was a way to help out
the developers and make sure that they were getting what they
expected out of the system. But in terms of metering for the
validators, and this was also going to be very helpful.
So this is how we designed the system to make sure that we were
taken care of both parties. So for validators every Epoch,
which is about a day they enter into this musical chairs
auction. So musical chairs.
Y'all know how? It works.
It's a party game. Y'all have a set of chairs and
you stand up. You walk around the circle of
chairs. Music is playing this whole
time. When the Music Stops.
You got to sit down and find a chair.
If you don't have a chair, you're out of the game.
So it's the same idea here. Every Epoch validators enter
into this musical chairs auction, and they post their
price for what they will accept to secure a chain, like it.
Now, The lowest set of prices is going to win that auction.
So, all the validators who posted those lowest set of
prices. They are in the active set now,
which of those is the actual Chain LED price.
It gets quoted to the developer. It is the highest price in that
set. So if you are that validator,
that bid, the highest price you guys exactly what you asked for.
If you bid lower than that then you get additional margin on top
of what you would have already probably baked into your bid and
so it's Nice additional profit for you.
So, that's the winning set up validators.
Now, if you bid higher than the winning set, then you are out of
that act of set of validators for that particular ethic and
that is one way in which we're trying to encourage the
validators to to Really bid their true value in terms of
what they would accept for securing a chain lit.
And yes, the the whole point is of this mechanism is to get that
price down as much as possible, and that's how it benefits the
developers side. I'd for the developer.
They need to know exactly what they're going to be paying for
each particular epic for keeping a chain.
Let alive. But they also, I mean, obviously
everyone wants a lower price in that case, and this auction
mechanism is our way of trying to get to that as much as
possible. I mean, further down the line we
fully anticipate that is just is going to get cheaper and cheaper
as Hardware improves for validator services as our
validators that expands and as we start to do some sort of
optimization in the system. Then I think that's that's how
we'll get the cost down for all these validators even further
and then hopefully they will drive the price down for chain.
Let's overall. That's, that's how the mechanism
works. Right, that's cool.
I think, actually, I think Suey actually has some sort of
auction to where you actually set the gas price for an Epoch,
I guess, in your case, it's more, what the validators get
paid but in this in their case, it's the gas price.
So seems like validators will have to become a bit more
involved in this sort of like, economic a setting which, which
is interesting if that will work.
I'm, I mean, we've been running like the graph for a while,
which also has, like, sort of the system of like, oh, you have
Have to allocate your steak to certain sub graphs to optimally
get the ride rewards. I think it's interesting to see
like that this sort of becomes a differentiator, or like thing
that validators need to do. But yeah.
Okay, so that's interesting, but there's still sort of Delegation
and commission rates for validators, but essentially,
you're deciding like what all these changes would pay.
And then that pool of the money from the train lines will sort
of be redirected to the validators as Sort of part of
their earnings. Yes, that's exactly right.
So, and so, all usual ways in which validators get compensated
in a proof of stake system, those will still hold.
So there will be delegation to the validators.
There is a commission that the validators will charge in terms
of staking rewards inflation in particular those that those
rewards will also go to validators.
So the chain lift, B is actually on top of all that.
So we have anticipated scenarios where say you are a larger
validator and you just you want to guarantee your place in that.
At set and you have the economic means to do that.
Then you just bid zero, you offer that security for free and
you just rely on all the rewards that you're getting from The
Saga protocol for being a validator.
I mean, we have contemplated that scenario.
Now, of course, I mean, we do have the whole slashing
mechanism, so if anything should go wrong in validator
operations, then obviously there are consequences there, but
yeah, that's Those are young some of the some of the corner
cases that we started to contemplate with respect to
validate our Behavior. So it sort of also like I guess
a bit of a Sybil resistance thing that you charge a fee for
for the chain. Let, right?
Or I guess there's some sort of, is there a limit?
How many changes there can beat? Are you setting this at Saga
like maintain level? Sort of?
Okay, we can only have 1000 shallots or is it sort of let go
wild? Yeah, yeah, yeah, you can stand
up as many channels as you like as long.
Pay for them. And that's that's the criteria
you got to pay for them and so for somebody who is looking to
stand up a chain let's so we don't allow for that unless you
actually have Saga tokens in an escrow account on our system.
So we as soon as you instantiate that chain let and that chain
letters running, it's being kept alive, then we will withdraw
those Saga tokens from your account.
So you can't just, you know, come to our system and say, you
know, give me 10,000 chain LEDs, their payment is due.
Pretty immediately. So that's the way that we
prevent the system from getting a tag.
But in terms of Sybil, I think, the way that we spent probably
about six months on this auction mechanism, like designing, all
the ins and outs of it. Our current paper goes through
the whole mechanism, but in terms of the actual numbers that
we assign to all the various levers in the mechanism, that
that is taking a long time to come up with and we'll reveal
that soon. But the idea is we are very
cognizant that if we make it too easy for somebody to, you know,
win These options consistently then then we open ourselves up
to Sybil. But yeah, that's because it's
definitely something that we thought a lot about when
designing this. Yeah, I think super cool.
I guess we could like talk about this for another half an hour
probably but I guess we want to also sort of talk a bit about
again some more ecosystem things baby and sort of the two rules
slowly wrap up like more. Yeah about about this sort of
stuff instead of the architecture.
So I guess, first of all, we already sort of talked about it
that the focus is kind of the gaming and entertainment that's
probably like I mean I guess historically you know defy sort
of dominating in in crypto like as a primary use case.
But obviously it many people think gaming was, is there was
supposed to be the one that break out.
Like, can you explain sort of y-you're focusing on on that
kind of area and like how how Saga is like uniquely placed
there to to service those use cases I guess?
Yeah. Absolutely.
So gaming and entertainment, and, you know, we noticed at the
time that Saga was found as early 2022.
We notice that gaming entertain was already on the, on the
uptick that there was a lot of growth in this area.
But as a start-up, we definitely have to ask ourselves a hard
question of. Okay, you're building a really
cool product. This product could benefit
pretty much everybody in so many ways, but the way you actually
get to adoption, is you recognize that some people
really urgent? He said as opposed to, you know,
it's a nice to have. So I think for defy dedicated
block space on demand like this is a nice to have.
It's not existential because I mean d Phi is thirst without it.
And defy transactions, they tend to be slightly lower in volume
but very high in value and so when you have that combination
you don't mind congestion quite as much.
You also are more tolerant of those Gatsby's because the value
of your transaction. Is already pretty good to begin
with. Now, you flip that over to
gaming and entertainment, and this is all about the user
experience as someone who gains myself.
If I have to pay for something, I just, I really gotta love that
game, otherwise, it's not the money necessarily, it's the
interruption of the fun, it's the interruption of the
experience. And so I think that's something
that we had three realized. Okay, we have to solve for that
or else people are never going to really migrate from a web to
kind of Environmental web 31. And so when we stopped back and
said, okay, who desperately needs this kind of
infrastructure? It really is gaming and
entertainment there. You know, I mentioned with defy
transactions volume is relatively low transaction value
is very high in gaming entertainment.
The transaction volume is very high transaction.
Value is usually low to nothing. So that's the kind of
environment in which you need your own chain.
Essentially, you need your own blog space, I think.
For everyone who's building in our ecosystem, they have come up
against the, the issues with building on monolithic chains.
Even a salon as Lana can be fast.
But the chain, you know, occasionally goes down and
you're still affected by other applications and should anything
happen to your particular implementation and it's on the
Chain level, you got no one to talk to.
I mean, you could talk to the core team but you have no
control your own engineering team, feels a little helpless,
in terms of being able to do something to service that you
Others. So that's why we felt the gaming
and entertainment piece was a really great fit for our
infrastructure and that's why we're starting there.
Very cool. Yeah gaming is is it's like a
sector in crypto that I haven't really been convinced yet.
I don't know why because there's seems to be an entire Part of
the industry. That's just too hyper focused on
this use case and for me I just don't see it yet.
Yeah, so I would say this I would say that the play to earn
model is probably going to not die out because they're always
be people sort of looking for those returns but it just it'll
be a lot less prevalent. I think with a success of
something you like an acci for instance, everyone tried to
replicate that model, you know, how can we do?
Generate a token for the game and then when people play the
game they earned the token, that model definitely did not
withstand the test of a bear market.
So now we're getting back to fundamentals, which is how do
you just build a fun experience and that's where I went three
actually has something very significant to offer.
I wouldn't say it's necessarily in the economic piece.
Again, most of us who gained we gain for, for the fun, for the
dopamine, hit for the community of being part of a guild of
players and some And the same Dynamics are not just going to
apply to web 3. They are already in web 3.
I think the fact that we are so community-focused in web 3 is
actually why the crossover with gaming and entertainment has
happened. So what we're really excited by
at Saga is not so much play to earn, although we do have some
really cool games in that space. It's really in the decentralized
generation of content. So if you really love a game for
instance you get into it and then you want to develop your
own story lines here on characters.
Maybe your own assets and rather than go to Bright or Microsoft
and just scream and plea that you want this included in the
game, you can just do it because you're a member of the community
and then people. Yeah.
Well, then gravitate to that you build your own following cetera,
Etc. So how do we take a piece of Ip?
In other words, that brings a lot of people joy and then
democratize that across the community.
That's where the action is that it's not in you know please give
me more out, see tokens. Okay.
That's really interesting. Yeah.
Well I guess maybe I need to I need to look at this little bit
more more deeply. Yeah, before I wrap up, you
know, and I wanted to ask you, we talked a little bit about
this earlier, is there is, there are so many narratives around
block space security, and so we have the modulars modular
narrative. We have the app chain narrative,
we have The Interchange security narrative.
We have the monolithic chain, every smart contract is on the
same Cherry narrative. Although that one probably is
sort of on its way out and and then there are Many variations
in between that, you know, there are different ways that one can
Implement Celestia with Sovereign roll up.
Since settlement role as excetera.
What does this all look like? What's the endgame here?
And where is this almost? Like?
How do you how do you reason about all of these different
security? Trade-offs, and configurations?
And yeah, how our users and development.
More importantly, our developer is going to want to reason about
these things as The next wave of application Innovation comes you
know and maybe two to three years.
Yeah, so I think from a developer perspective, I mean
you you are looking to not think about this because because I
think most developers particular they're focused on the
application Level. That's what they're really good
at is the application logic and that's where they want to spend
their time building their project.
The traction on that application is how they're going to see
growth and so, That's what they want to focus on if they have to
think about the infrastructure piece, I think that's where they
start to get turned off. So the nice thing about a
monolithic chain for instance, is it does afford you the
ability to just focus on the application and it gives you a
whole host of other problems. But at least, you know, your
mindshare is devoted to what your core competency is.
I think for Cosmos, We Are Climbing that ladder of getting
to a place where a developer doesn't have to think about the
security piece, they don't have to think about the infra and
again the Let's focus on that application and I mean, that's a
huge part of sagas Mission. But you mentioned Sebastian,
when you look at the whole landscape of scaling Solutions
out there which one is exactly going to win necessarily.
I think it's not so much the stuck that you should focus on
when you're looking to answer that question, I think it's in
the communication piece, so we just look at our own experience
and we know that without IVC polygon Celestia would not have
been possible if there were just there would not have been a way
for our inner chain security. Orchestration automation stock
to be able to communicate with these other ecosystems and then
automate the the dedicated walk space for them.
So IBC was key in that I think even for the projects that are a
building on us as part of our Innovative program, you know,
these are small to mid-sized gaming and entertainment
projects, a huge part of the value, add for them is IDC.
And the fact that For instance, a salon a game for the first
time, they are able to come onto Saga.
So, they have an instance of the game on Saga.
And then there's a polygon gain that is staying on polygon, but
they also have an instance on Saga and it's through IBC that
they're able to communicate with each other.
For the first time, they're able to transfer those assets back
and forth and that's a huge benefit for their Gamers.
So intense, in terms of scaling out their particular game, they
have focused on that communication piece.
So I think this is why I always say that.
That for Cosmos you know Cosmos SDK the ability to stand up your
end chain. That was a really great
Innovation. But the signature achievement of
this ecosystem is IDC because what obviously allows you to do
or what it has allowed Saga to do it it has allowed us to take
the unique offerings of our stock with respect to scaling
and plug it is. Allowed us to plug it into other
stats that have nothing to do with Cosmos.
And that's, that really is the power of it.
So, I think that, I mean that that is a strategy that will
prove quite fruitful, it has worked for us so far.
I think we're going to continue it into the future, but it's a
reason why we bet on this face because it really is in that
ability to communicate that you can actually have these stats
work with one another Yeah, I mean I think that you know,
saying that IBC is the signature achievement of the cosmos is
pretty pretty spot-on for as far as I'm concerned, I think that
it is probably the thing that of the cosmos experiment will be
the most long-lasting, and will have will spread across the
broader ecosystem, more than anything else.
I don't think about it in this. In this who, which will Irwin
perspective. I think about it more from a
developer perspective. In terms of the trade-offs they
have to make between security scalability of well yeah, it's
like security and sovereignty and I think, right?
So if you're building an application that and I look at
look at web to as the web to stack as an analogy and and the
from the stack I mean really the infrastructure stack where you
can build a Squarespace website and have only control over the
application and virtually no, control over any of the
infrastructure at the other end of that, you have Amazon and
Google building data centers, undersea, cables Hardware,
vertically fully vertically integrated, and all of the
levels in between between, you know, from, you know, building
on AWS or, you know, these Very large Cloud platforms and having
high levels of sovereignty, but High dependency on those
platforms and then there's, there's there's offerings all
the way down, you know, to the, the least, Sovereign and the
easier to use. I see, I see this as more of a
linear more of on a linear scale than on a, yeah, that's that's
kind of the way I think that the ecosystem will start
compartmentalizing. These things is based on the
application needs. And finally, you know, some
types of Applications are going to stick very well to one flavor
of of consensus and data, availability and execution and
the sovereignty trade-offs there and the dependency on those on
those platform, trade-offs, Etc. So yeah, I think I think these
things will start to make more sense and will start to line up
over the next over the next two years.
Yeah, Yeah no especially because I mean developers are they're
not just good in terms of the coding and the software
development I think most developers in the space are also
entrepreneurs and so they think about does this make business
sense? In terms of what it's costing
me? You know how many users am I
actually getting onto my project Etc.
So they're making all these calculations and they'll vote
with their feet in terms of which environment is best for
them. I think there's a reason why
Cosmos has so much developer mind.
Share and because they recognize hey, in terms of ease of
developing? Yes, there are some significant
things that Cosmos without further Innovation would ask me
to do but at the same time, in terms of robustness of the
technology, its specification of the stack.
It's yeah. There's a reason why it's quite
popular. Awesome.
Yeah, thanks so much Rebecca. I think we're ready to wrap up.
Almost I think maybe. So, thanks for coming on but
also I guess as As a final question, we would love to hear
a bit like, you know, now we talked a lot about the
architecture design, the reasons, I guess can just tell
us a little bit like where are you at right now?
In terms of like the roadmap of saga and you know, where can
people find more find you and learn more about Saga?
Yeah. Yeah absolutely.
I'm so feel like Sebastian, thanks so much for having me on
this has been an amazing discussion and I think this
particular podcast you go much deeper into the technical
details than most other podcasts out.
There has been a lot of fun in terms of our roadmap.
So we're going to have an announcement at East Denver, in
terms of our next big release and that will be a true change
launch teens. And so the validator set will be
smaller but it's the first time that you're seeing that
orchestration. So what it'll allow developers
to do is launch ibm-compatible chain.
Let's but you're the chain. Let's are with a smaller
validator side. Once we get closer to summer
time, that's when you're going to see the validator said, be
expanded will be far more decentralized and a lot of the
teacher said that we talked about on the show.
So IBC, for instance, the full implementation of shared
security that'll be a part of that test net.
And then we're going to run multiple tests nuts between And
and mean that launched, which is slated for Q3 Q4 this year.
So Saga is going life this year. So, yeah, this is a busy year
for us and in terms of what we have to look forward to and
where you can find more information about that.
So, all of the information is available on our website Saga to
XYZ, it's also available on our Twitter, Twitter is probably the
place where we make the most up-to-date announcements and so
you can you can find us on On Twitter at Saga XYZ double
underscore. And then, for me personally, you
can find me at on Twitter at Becca Liao.
So, look forward to hearing from everyone.
We always look forward to hearing from our community
across all of our social channels, whether it's Twitter
or a telegram Discord. But yeah, this this will be a
fun year. Okay, well, Rebecca thanks so
much for joining us for diving deep into Saga, and look forward
to seeing further developments and probably will see you in
Denver as well. Because both Felix and I will be
there. Absolutely now, thanks so much
avastin. This is a great discussion.
Thank you guys again for having me on and yeah look forward to
seeing you all in person soon. 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 podcast. And if you have a Google home or
Alexa device, you can tell it to listen to the latest episode of
the epicenter podcast, go to epicenter dot TV /, subscribe
for a full list of places where you can watch and listen, 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, guess. Or other podcast listeners you
can follow us on Twitter and please leave us a review on
iTunes helps people find the show and we're always happy to
read them but thanks so much and we look forward to being back
next week. Or other podcast listeners you
can follow us on Twitter and please leave us a review on
iTunes helps people find the show and we're always happy to
read them but thanks so much and we look forward to being back
next week.