Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Rebecca Liao: Saga – Bootstrapping Chainlets in the Multiverse

Episode Date: February 24, 2023

Building a blockchain from the ground-up is a daunting task in itself, one that should not be a concern when designing an end-user application. Moreover, as Web3 aims to move away from centralized vertical scalability towards a multi-chain decentralized environment, horizontal scalability and cross-communication should represent a standard. While Cosmos solves the latter, deploying application-specific blockchains has not been a streamlined process. Saga aims to address this by providing automated means of deploying application-specific blockchains, called chainlets that use the validator set of Saga. This leads to a simplified user (and developer) experience, presently much needed in the Web3 gaming and entertainment industries.We were joined by Rebecca Liao, co-founder & CEO of Saga, to discuss bootstrapping app-specific chains in just one click, leveraging the scalability & security of Cosmos, thus allowing developers to focus more on the product and less on the blockchain infrastructure.Topics covered in this episode:Rebecca’s background & building SagaLeveraging Cosmos SDK, IBC & ICS to bootstrap other chainsChainletsSaga validators & tokenomicsIBC & elastic scaling for chainletsICS & Saga’s tech stackChainlet customizationPartnerships & use casesChainlet ‘Musical chairs’ auctionTargeting gaming and entertainment industriesMulti-chain future and inter-chain communicationEpisode links: Rebecca Liao on TwitterSaga on TwitterSponsors: Omni: Access all of Web3 in one easy-to-use wallet! Earn and manage assets at once with Omni's built-in staking, yield vaults, bridges, swaps and NFT support.https://omni.app/ -This episode is hosted by Sebastien Couture & Felix Lutsch. Show notes and listening options: epicenter.tv/484

Welcome to Epicenter. The show has talked about the technologies, projects, and people driving decentralization and the blockchain revolution. I'm Sebastian Quichu, and I'm here with Felix Luch. Today we're speaking with Rebecca Liao. She is the co-founder and CEO of Saga. It's a project that 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. Omni is your new favorite multi-chain mobile wallet. Omni supports more than 25 protocols so you can manage your assets in one place. But what's really special to Omni is what you can do inside the wallet. If you want to get yield, Omni allows you to get the best APIIs with zero fees in three taps. You need to swap while Omni aggregates all the major dexes and bridges, so you can bridge and swap across all supported networks in one transaction directly in the wallet. If you love NFTs, Omni offers the broadest NFT support of any wall.

so you can collect and manage your favorite NFTs across all chains in one place. Omni is truly the easiest wallet for Web3 and it's fully custodial, which is really important. And you never have to trust anyone with your assets other than yourself. And they also support ledger, which is great. I've used Omni 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 Ethereum chains, it's not often that you find a mobile wallet that support the ledger. So give Omni a try at Omni.

Rebecca, thanks for joining us on the podcast today. Thanks so much for having me, Sebastian, Felix. It's great to see you guys. Up the center is regular listening for the entire team at Saga. So I really appreciate you having me on. Nice. Well, I hope, I hope, you know, you can return to favor by teaching us a few things today. Absolutely.

And so, you know, we'd love to learn more about Saga and what you guys are building. And I think it's, you know, for me, it's an interesting, also thought experiment to try to figure out where this sits in the broader app chain, interchain security, modular chain, mesh network thesis. There are a lot of products right now that are trying to implement different security models. And 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 Saiga. Yeah, absolutely. I'm happy to dive into all those topics. That's what we spend all of our time thinking about at Saga. 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. So I'll tell you about my journey before then. Saga is actually my second crypto startup. My first one was skew chain. Co-founder there was Zaki, Manian, who's one of the original builders in Cosmos. We've known each other a long time. And Skiu-Chene was focused more on the D-Fi space. So it was providing short-term liquidity to small, medium-sized businesses. And I was co-founder of COO there for four 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 four years. The project is on its way.

I would love to see if there's a new adventure. And I've always been involved in politics. So I was part of both the Clinton and Biden presidential campaigns, both in 2016 and 2020. And in 2020, we actually won. So I began to think to myself, maybe I should. should go into service and join 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 bureaucracies, no surprise after having done startups for a long time. So I called up Sochi and said, 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 developers needed an easier time, basically, of building in Web 3, that they didn't have the full tool set that obviously Web 2 developers have, which has been built up over several decades, so no surprise there. But we felt that there were much easier ways that we could make developers on ramp onto Web 3 in a much faster and convenient manner. So that's how we co-founded Saga.

But my first startup ever was an AI, actually. So it's interesting to see it come back as a big trend. So it was a company called Globality. I was part of the early team there, headed up business development, founded and ran their Asia operations. And we got back by SoftBank within a year and a half. So I got to unicorn status pretty quickly. But then I fell in love with crypto and exited to do my own startup.

I started my career as a corporate lawyer, actually. So that's the last piece of this. I was a lawyer for about five, six years before jumping into startups full. time. But yeah, that's how I found myself at Saga. And it's been about a year now that we've been hacking away at this project. Cool. What was this other project you did with Zaki skew chain? It's like, it's a bell. It's so it's SKU chain. And it's the name is the play out of the fact that a lot of the business that we did actually involves 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 primary use case that we were going after. Okay, interesting. Well, yeah, let's let's talk about, and let's move into Saga. How did this journey from skew chain merge and to, you know, building Saga, what, 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 were at Ski chain together for, for a few years, but then Zaki 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 milestones. So when the SDK was launched, also when IBC was released. So I knew that this was a really amazing protocol, really great developer mindshare as well. I could see how popular it is with engineers. So I've definitely been a big fan of Cosmos for a long time.

What we realized at skew chain was, at skew chain, as you can tell from how I'm describing it, it was a defy application. So we set at the application level. But what we discovered quickly is, you know, the infrastructure, the underlying infrastructure for Web3 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 Cosmos chains really proliferating, you're looking at monolithic chains. So things like Ethereum, for instance, classic examples, Salana, et cetera. So really these chains that mandated high invariable gas fees for their end users.

there was congestion because you're sharing the block 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 a 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 at skew chain that Cosmos solves a lot of this. But Cosmos opens up a whole host of other problems, which is, well, 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 ease some of the lift? And all the co-founders at Saga, including Jin Kwan, former executive at Tenderman, and our chief strategy officer Jake McDormann, who is our co-founder of CTO, designed the entire system. Bogdan, who's our co-founder and BP of Engineering. We all felt the same way that it was time that development. environment in Web 3 were as easy to use as development environments in Web 2.

And that is what the Saga protocol reflects. Right. So I guess you already mentioned in 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 a way? Yeah, absolutely. So Saga The easiest way to think of Saga is we are a chain 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 permissionless. 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. It usually makes it easier for their development.

But then on our side, it's a security layer between their application and the rest of the system. So the developer will take this VM and through command line, they're able to automatically deploy it onto that dedicated chain, which we call a chainlet. Now, how do we achieve that? It's through interchained security. So we are Cosmos chain. So we use the Cosmos SDK. And within that, interchained security is one of the newer features.

So interchained security in its current iteration, what it does is it allows one chain to replicate its security model onto another chain. And so we have the Saga Mainnet secured by a set of validators. Whenever a developer requests a chainlet, then that same set of validators is going to fire up that chainlet and has the exact same security model as the Saga Mainnet. it is secured by the same set of validators.

And that's how we're able to proliferate these chainlets. 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 app chains, side chains, roll-ups, et cetera. But at a base level, that's how the Saga system operates. So can you describe this chainlet concept? So you described it as a VM, but I think most people are familiar in the chain security.

The security actually secures a sovereign chain. Well, sovereign to the extent that there are some parameters that are still left to the validators of the parent chain or the provider chain. But in the concept of a VM, it's a bit, yeah, it's a bit of a new concept to say that, validators would implicitly secure that VM and that it, yeah, how is it different from just running a Cosmosin contract? And also, is that a Cosmwasan VM or is it a different VM? Yeah, so many questions. So what the validators are doing is they're taking that smart contractor application and then putting it onto its own dedicated chain. So a chainlet is a chain in its own right.

The main difference between a chainlet 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 main net. The token that secures the entire system is the Saga token. And so there's no need for this project to have its own staking token. You can have your own native token. That's part of our token economics. However, you don't need a staking token, which means that in addition to not having 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 chainlet and a fully sovereign chain. But when a developer brings an application to our system, so it may be contained within a virtual machine environment, but what they're being deployed on 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 mean net, such that when a developer asks for a chainlet, provided that they have enough Saga tokens to pay for that chainlet to be alive, they get that chainlet. So that's the flow. The VM is really just to ensure that there's a security

layer between whatever the developer is deploying and the rest of our system. The first kind of VM that we support is the EVM because we see how popular it is in Web 3 in general. But our goal is to be VM agnostic. So cosmolasm is the next kind of VM that will support because it's very popular within the cosmos ecosystem. We have people building on Saga already who are working on Solana VM that's compatible with tendermint, a MOVE VM as well. That's becoming more popular in gaming and entertainment.

I think Agorik has a JavaScript VM that's ready to use. So our goal is to give developers a choice. 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 chainlets in Saga tokens. I guess, can you expand a bit how that works? I guess, yeah, generally we have, I guess, token, like the application-specific chain has their token, gives staking rewards. but I assume in this case, you're somewhat different.

So I guess 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 Web3 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 where, honestly, 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. The Saga token secures the entire system. And that is what all the inflation is staking and the entire economy is based off of. The Saga token is only used to pay for the chainlets.

So think of it like an AWS instance. in a way. So we treat the saga chain that's like those instances. And in the same way, for all of you who are developing on AWS, you 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 cost, 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 S-Pro account, basically. It's our fee deposit. And for every month that they're keeping the chainlet alive, then we're going to be depleting Saga tokens from that fee deposit. Now, that's settled 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 Ethereum or they're used to being on Solana, for instance. And then they'll charge gas fees in that native token instead. So they'll be charging gas in ETH or Sol.

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 that. All we care about is that the developer continues to pay the Saga tokens necessary to keep their chainlets alive. This is really interesting because you know what this conjures up is conversations with Jay Kwan around Adam 2.0. And I don't know if you guys followed that. And there was some conversation around having chains that were using interchained security align on protocol economics.

Now here we were what was proposed as a two token system where Adam would secure the cost. the Cosmos Mainnet and then there would be this second token, this photon token, that would be the payment token by which, you know, chains would pay for security and there was this kind of burn mechanism that allowed consumer chains to, to swap Adam for this token. It seems very similar. There's there's only one token here instead of two. I wonder if any of this research, or sorry, if tokenomics come from sort of similar discussions and research that had been, you know, actually Sonny 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 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 places. So I think for Adam 2.0, the whole idea of the project is, A, how do we, 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 Sunny, 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 day. We don't think that most people, when they are consuming an application, that they want to deal with more than one to make a handful of tokens at the most.

A lot of people who are coming into this space and really taking advantage of and liking Web3 applications for the first time, 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 accrue value to our system and make sure that all of Saga remains secure. So we came at it from more of a usability perspective. But I will say that.

So our token economics approach in general is keep it simple because the more bells and whistles that you put in there for market making or levers for ensuring the health of the price of the token, 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 does the token get supported? Well, in our system, the more chainlets there are, the more buying pressure there will be for 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 and a photon, that's where you start to, A, you start to dilute some of the value.

And once you implement that burn mechanism, I mean, that's a sort of thing where I think that, yeah, people will start to play tricks with that. If you need human intervention in that process, well then, I mean, that opens up a whole other can of worms. So we did not, yeah, we didn't want to go down that road. We came at it thinking, okay, this is what the user is expecting from what three applications going forward.

And this is how we can make it easier for them to onboard. I think the two token system, and I might be wrong here, was in order to prevent hostile takeover of the ad because the consumer chain stakes uh, token essentially. And this may be a little bit different with here with Saga, but they essentially stake tokens, uh, with the provider chain validators. The risk of having, uh, atom accrual at the consumer chain level was at a, uh, a massive unstaking event that would jeopardize the security of the chain where a

provider chain would essentially take over governance or take over, have too much power on the provider chain. And so I think this is where the two token model came into effect where essentially when you start securing a consumer chain, 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

swap back into Adam. Once you went into the photon you couldn't go back but then those ideas through discussion around Adam 2.0 and the conversations that were being had with Jay was that there could be a mechanism to go back into Adam but with time locks and such that

atom holders would be able to on stake if they saw that such an attack was coming. But in this case, chainlets are not staking any tokens. They are they are needing to acquire your saga token by some means that puts by pressure on the saga token and then they pay validators for that security. So there's this constant economic cycle. There's like a velocity of money happening in the system at all times. Exactly right. That's exactly right. So it should not be the case that any particular developer that has a chainlet is holding on to those chainlets for a very long period of time, if not indefinitely, because they got to keep the chainlet alive. So those tokens are going to find their way to the validators.

Every month when we do deplete that account of the chainlet fees for the particular chainlets that they have running, the Saga tokens are going from the developer to the validators. Now, in terms of, staking for the validators or if developers want to stake their saga and then just use the rewards from staking to pay for their chainlets. 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 is meant to really encourage that velocity of money, like you mentioned, Sub. Right. I think one interesting thing, it sort of reminds me, I guess also in AWS, you have like different instances, right, like different sizes, different, like, specs.

Do chain lands work like that too, or is any chain lead like the same? They're the same. They are the same. So every chainlet is the same. They are priced the same. But we do believe in elastic scaling, which means that our anticipation is that most developers are not just going to have one chain lit. So when we started off, and I think in some ways the hub is still conceiving of it this way, we thought it would be one application per chain lit. 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 least three environments, so dev, staging, and then their production environment for the actual application. On top of that, once the application starts to get appreciable traffic through it, one chainlet is probably not going to be enough. You're going to need multiple. So in order to ensure the same level of performance,

you're going to need to, quote, spill over into additional chainlets. And that's how we encourage the developers to scale. And that's why we're not doing customized chainlets, where some are bigger sizes than others, you're getting chainlets. And if you need more chainlets, then 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 few chainlets, that's that's seemingly possible as well. The goal is to commoditize this system so that we make it as easy and thoughtless, frankly,

as possible for developers that they need an environment to build. They can pull one up very quickly. Maybe I guess, yeah, now if we think of an application that maybe runs on multiple chainlands, can you talk a little bit about how composability would work in such a system? Or do you need to like split apart your application in a certain way that this model can work? Or how does Saga sort of allow you to do that? So Saga runs only because IBC is available. So you keep in mind that everything in Saga is independent of what.

one another. So there's a Saga mainnet. And then all the Saga chainlets, again, are 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 Saga main net will orchestrate these chainlets is through IBC. So in order to make sure that people are keeping the chainless alive, according to the SLA contract, that they are paying for the chainlets as they need to, that the chainlets are actually being spun up, automatically. All of that's coordinated via IBC through messaging back and forth between the chainlets and the Saga main net. Now, the chainlets also have IBC because they're all cause, they're all cosmos chains in their own right. So they also communicate with one another. And right

now, IBC is mostly used for the transfer of assets back and forth, but I think with interchain 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 we're reliant on. And your website talks about this IBC plus. Can you explain what that is? Because I'm not familiar with this particular premium IBC that you guys are spinning up. Yeah, yeah, yeah. No, so it's not really a premium version per se, but it's it is a unique trait of our system.

I would put it that way. And what IBC Plus refers to is the fact that, so IBC is needed to run our system, period. The communication that happens between the chains requires IBC. 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 sets are completely different. And so you need to like clients on either side and then you achieve IBC compatibility and 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 we are putting forth some innovations in IBC just to make it run faster and to hopefully make it run a little more cheaply for the validators as well because we will require them to run relayers. And so in order to just make this 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 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, 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 chainlets are using the same security model, 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 ICS1 or whichever version, the first version. But that starts to break apart once you have different security for different chains. That's right. That's right. How do you maintain then IBC compatibility with other IBC chains? Is this 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, but I guess you need IBC when any of the chainlets wants to talk with, say, osmosis or some other external chain. Yeah, that's exactly right. I think we want to preserve IBC in its current iteration as much as possible, but just making optimizations for the fact that we have the same validator set across all chains, because we do anticipate that that will happen very quickly, that our chainlets are going to talk to other chains.

within the cosmos ecosystem. And then we see also, this is also a bet on IBC itself as a messaging standard that will be applied across more blockchain ecosystems. So we hope that other ecosystems like an avalanche, for instance, will take up 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. It is reliant on IBC specifically. So yeah, 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 realize it's not super clear to me yet, but like this chainlet.

In a blockchain stack, you have execution, settlement, consensus and data availability, what parts of that are the chainlet may? Is it just settlement and execution? All four. Is it also? No. They're all changed. But the consensus is happening on the saga chain.

This is where. No. Consensus is happening on each of the individual chainlets. Yeah. The saga main net exists to orchestrate. So to stand up, make sure that the validators are behaving. Because in an interchained security system, how it all stays together is if a validator is not behaving on any particular chainlet,

then according to the mechanisms of the protocol, they get slashed. And that slashing really happens on the Saga Maintnet. So Saga Maintiff is really there as an administrator. It is not there for consensus or settlement. All four parts of the blockchain stack live with each individual chainlet. Okay. So in the same way that with interchained security,

Cosmos 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 chainlets that they're validating. And so this is where, okay, then my question is, okay, then this stack, I want to talk about the tech stack, where the client that they're running.

Is that a Cosmos SDK-based client? And then VM, are you guys, is it, is it Etherment? or like what's the because it's EVM, right? So can you describe the tech stack? Yes. Yeah. No, that's exactly right. So every chain is running CosmosS SDK. That is not because any of the developers deploying on Saga have touched CosmosststK necessarily.

It's just a stack that we automatically spin up. For the VMs, they do have to be compatible with tendermint consensus. So it's not like, you know, people who have already worked on a salon of 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 Etherment. Yes, they've done the work, which we really appreciate for making the EVM compatible with Cosmos. When we move to the next kind of EM Cosmo, that's going to be a little easier as this Cosmos native.

But honestly, for the other kinds of virtual machine environments like a Salonovian, 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 VMs compatible with tendermint. But I think it's much better to rely on other community members who have spotted the opportunity there and provided these VMs 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 with tendermint. Right. And are you familiar with any of the work that's being done on the Cosm-Wasom SDK? And I wonder if, yeah, because Evmos is effectively, I think, going in the same direction with their EVMOS SDK. And by that, I mean, re-implementing the Cosmos SDK modules as smart contracts in Cosmwasum and solidity, I guess, or Rust in Solidity, but compatible with a Cosmwasum.

and the VM SDK, is that something that you see as a viable path for the future for streamlining, you know, since the applications themselves are not using, I mean, they're not going to be using these Cosmos SDK modules. They're 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 oversimplify this, a bit of 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, you know, it's so easy for a developer to deploy solidity 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 Cosmos, is that really the value you add that our particular ecosystem provides to Web3 in general. And I would say that it's part of the big puzzle, but really people come to Cosmos because they want their own space to build in.

And so I don't know if these sort of smart contract innovations alone can accomplish that. You need to be able to spin up space in as easy a way as possible. We're doing it an automated way. But when we think of Cosmos, I mean, again, 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 smart contract innovations that we hope to help bring to market through our ecosystem and our implementations and our adoption. But at the end of the day, why do people come to Cosmos? What is Cosmos known for? It is that sovereignty. So we're looking to provide that space. This is where, yeah, we're attacking the developer problem

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 that all chainlets are sort of the same, at least in terms of like the size and spec. What exactly can you still like sort of customize, 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 chainlet? Yes, you can set your own block times.

That's totally fine. And what we're starting to do is we're making the system into a modular stack in its own right. So you have the Saga chainlets or the plain vanilla version. You can tweak block times for any Saga chain lit. 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 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 a developer basically get as close as possible to that one click. So when they want to spin up a chain lead, 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 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 application, for instance, then you're probably going to need the multi-chain wallet right away because, I mean, you're probably multi-chain to begin with, and you want to be within the entire saga ecosystem. You probably need a game launcher and the SDK that comes with that. And so that's a group of services will be bundled into that sort of implementation.

If it's an NFT 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 D5, for instance, or other use cases, then it'll 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 chainlet for this particular use case, these are all the services that you need. But other than the base chainlet, 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 just adding services on top of chainlets anymore. I mean, when you work with somebody like a Celestia and certainly somebody like a Polygon, they have their own stack. And so that becomes a separate offering on Saga altogether where we're using some very key parts of the Saga stack. But at the same time, you know, it's going to be Polygon Edge Code, for instance. It's going to be Celeste enrollment 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. But the whole point is to build a platform.

Right. So you already took away, like some of our next topic, obviously, the partnerships. I mean, like, first of all, congrats on, like, scoring so many, like, names there, I guess. Like you mentioned Polygon and Celestia, I think it would be cool to sort of go into how that works. These partnerships, you sort of mentioned, right? They're using Saga for certain elements in their stack. So I think with Celestia, there's this concept of like sequences as a service. And in Polygon, you're working with the supernet.

So maybe can 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 Felstian Polygon, I think what our CTR recognized was, wait a minute, when you look at the Saga system, so far we've just been talking about Cosmosap chains.

So every chainlet is a Cosmosap chain. What if we were able to generalize that, such that we think about it not so much as an app chain necessarily, but just as dedicated block space. Because I think as blockchains have to start to think about scaling more seriously, there are so many names for the same kind of concept. You know, there's the app chain, there's a side chain, there's a roll-up, etc., etc. But is there a way that we can generalize? Drive chain.

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 offer that across all these different dedicated block space offerings? And the answer was yes. So both with Celestia and Polygon, I'll go into the specifics of each shortly, but what they have in common is we realized, you know, the Saga system, if you don't think about the validator set for a second, so you don't think about the Saga validators, you focus. only on the fact that we have this interchained 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 general idea that as long as you have some sort of 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 the common theme that both Celestia and Polygon have. So how does that manifest itself in Celestia?

So with Celestia, they obviously have very strong data availability. In terms of the roll-up piece, I think they were trying to figure out how do we make this easier? Because right now, what you have to do for a roll-up is you've 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 set? 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 Celeste 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 malactivity on any of the validators working on the Saga side, that will get communicated back to the Celestia system via day. 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 Polygon, Polygon is a different stack. So they are not only Polygon-Etherian-based, but they are Polygon-Edge-specific. So Polygon has an app chain

solution. It's called Supernets. And the team that developed it is Polygon Edge. If you go on their GitHub, you'll see that the entire stack has been customized, according to Polygon Edge. So what they were doing was they were, you know, similar concepts. They were taking Madic validators and saying to their customers or clients, hey, we can stand up a chain for you. You can pick among our validators set. And once the validators have been gathered, then we'll construct the chain for you. This is a very long manual process.

And that's why to date, there are no super nets that are actually live. So 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 Madic validators don't want to be, you know, sideline in this deal. Obviously, they want a piece of all the supernet action. So saga validators were no longer going to be used to automate these chainlets. Instead, what we're going to do is the supernets are still going to be secured by thematic validators.

and in terms of making sure that those Matic 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 yet, but the way that we price our chainlets is through an auction mechanism. We'll go into more detail about that later. But it is a pretty big innovation in validator pricing. So making sure that the Matic validators are adhering to that auction and all the other 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 IBC, but still going to be Matic validators. So if you want to think of it a certain way, it's that the Matic validators that are participating in super net security, they are adopting parts of the Saga stack. So that's how those two partnerships work. It's provided a lot of detail, but if you want to think of it in a very sort of simple way, it is that a Celesteer Roll-up is now a Saga chain-lit. A Polygon Supernet is now a Saga chain-lit.

How we make that all work is primarily due to IBC, but the point of these partnerships is to generalize the automated deployment of dedicated block space. Okay, interesting. So you're saying a Celesteer Roll-Roll-up is now a Saga chain-lit. 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 it would be like a fuel roll up or something like that. Exactly. So it's just specific to the roll up piece. And also to be clear, this is now an offering that both Celestia and Saga will make available. But if for whatever reason you went to Sestia and said, I love their data availability. But, you know, 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 Polygon super nets. If any developer said, you know, I want to go through the process of selecting my ownmatic validators and customizing this chain completely for my own purposes and I want to make it permissioned, et cetera, 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 that's currently is get some stake and then you get the rewards, but rather more engaged, I guess, in terms of on the validator side. So curious why you came up with that. how it works obviously. So yeah, maybe you can expand on that a bit. Yeah, absolutely. So I think that we had two goals really with respect to this mechanism that we came up with, which is the musical chair as auction. Thanks to be like. Yeah, that is our name for it. I'll explain why in a second. But on the developer side, we wanted to give them as predictable and commoditized a pricing as possible for chainlets 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 chainlets as the developers are requesting as long as they can pay for them. So even if a validator says, yes, you know, please give me all your chainlets, it is obviously a huge undertaking in terms of the hardware and the maintenance and 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, this was also going to be very helpful. So this is how we designed the system to make sure that we were taking care of both parties. So for validators, every epic, which is about a day, they enter into this musical chairs auction. So musical chairs, you all know how it works, it's a party game.

You 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 epic, validators enter into this musical chairs auction and they post their price for what they will accept to secure a chain lit.

Now the lowest set of prices is a 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 chainlet price that 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 get 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 a nice additional profit for you. So that's the winning set of validators. Now, if you bid higher than the winning set, then you are out of that active set of validators for that particular ethic.

And that is one way in which we're trying to encourage the validators to really bid their true value in terms of what they would accept for securing a chainlet. And yes, the whole point of this mechanism is to get that price down as much as possible. And that's how it benefits the developer's side. For the developer, they need to know. exactly what they're going to be paying for each particular ethic for keeping a chainlet 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 it is going to get cheaper and cheaper as hardware improves for validator services as our validator set expands. And as we start to do some sort of optimization in the system, then I think that's how we'll get the cost down for all these validators even further, and then hopefully that will drive the price down for chainlets overall. That's how the mechanism works. Right. That's cool. I think actually I think Suey actually has some sort of auction too 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 their case, it's the gas price. So it seems like validators will have to become a bit more involved in this sort of like economic setting, which is interesting if that will work. 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 to allocate your stake to certain subgraphs to optimally get the right 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 chainlets would pay. And then that pool of the money from the chainlets will sort of be redirected to the validators

as a sort of part of their earnings. Yes, that's exactly right. 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 rewards will also go to validators. So the chainlet fee 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 you're a place in that 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 valid. 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, you know, there are consequences there. But yeah, that's, those are, yeah, some of the corner cases that we started to contemplate with respect to validator behavior. So it's sort of also like, I guess, a bit of a civil resistance thing that you charge a fee for the chain lead, right? I guess there's some sort of, is there a limit, how many chainlets there can be? Are you setting this at Saga, like main chain level, sort of, okay, we can only have a thousand

chainlets or is it sort of let go wild? Yeah, yeah. You can stand up as many chainless as you like as long as you pay for them. That's the criteria. You got to pay for them. So for somebody who is looking to stand up a chain let, 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 chainlet and that chainlet is 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 chainlets. Their payment is due pretty immediately. So that's the way that we prevent the system from getting attacked. But in terms of Sibyl, 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. 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 win these auctions consistently, then we open ourselves up to civil. But yeah, it's definitely something that we've thought a lot about

when designing this. Yeah, I think super cool. I guess we could like talk about for another half an hour probably, but I guess we want to also sort of talk a bit about, again, some more ecosystem things maybe and sort of the two to slowly wrap up, like more, yeah, 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, Defi is sort of dominating in, in, in crypto, like, as a primary use case, but obviously many people think gaming was, is supposed to be the one that, that break out? Like, can you explain sort of why you're focusing on, on that

kind of area and like how, how Zaga is like uniquely placed there to, to service those use cases, I guess? Yeah, absolutely. So gaming and entertainment, you know, we noticed at the time that Saga was found, this is early 2020. too. We noticed that gaming entertainment was already on the uptick, that there was a lot of growth in this area. But as a startup, we definitely have to ask ourselves the hard question of, okay, you know, 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 urgently need it as opposed to, you know, it's a nice to have. So I think for

DFI, dedicated block space on demand like this is a nice to have. It's not, existential because, I mean, defy has lurched without it. In 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 gaspies because the value of your transaction is already pretty good to begin with. Now, you flip that over to gaming and entertainment, this is all about the user experience. As someone who gains myself, if I have to pay for something, I just, I really got to 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 Web3 realized, okay, we have to solve for that or else people are never going to really migrate from a Web 2 kind of gaming environment to a Web 3-1. And so when we sat 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 block space. I think for everyone who's building in our ecosystem, they have come up against the issues with building on monolithic chains, even a Solana. Solana can be fast, but the chain 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 some.

something to service the users. 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 like a sector in crypto that I haven't really been convinced yet. I don't know why. There seems to be an entire part of the industry that's just super focused on this use case.

And for me, I just don't see it yet. Yeah. Yeah. So I would say this. I would say that the play to earn model is probably going to not die out because there will 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 somebody like an Axi, for instance, everyone tried to replicate

that model. You know, how can we generate a token for the game? And then when people play the game, they earn 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 Web3 actually has something very significant to offer. I wouldn't say it's necessarily in the economic piece. Again, most of us who game, we game for the fun, for the dopamine hit, for the community of being part of a guild of players.

And so 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 storylines. your own characters, maybe your own assets, and rather than go to riot or Microsoft and you know, just scream and plead 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, et cetera, et cetera. 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 at. It's not in, you know, please give me more axi tokens. Okay, that's really interesting. Yeah. Well, I guess,

Maybe I need to look at this a little more deeply. Yeah, before we wrap up, you know, I wanted to ask you, we talked a little bit about this earlier, is there are so many narratives around block space security. And so we have the modular narrative, we have the app chain narrative, we have the interchange security narrative, we have the monolithic chain, you know, every smart contract is on the same chain

Although that one probably is sort of on its way out. And then there are many variations in between that. There are different ways that one can implement Celestia with sovereign roll-ups and settlement roll-ups, etc. What does this all look like? What's the end game here? And where is this all like, how do you reason about all of these different security tradeoffs and configurations and Yeah, how are users and development, more importantly, how a developer is going to want to reason about these things as the next wave of application innovation comes, you know, in maybe two to three years.

Yeah. So I think from a developer perspective, I mean, you are looking to not think about this piece because I think most developers, particularly are 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.

It gives you a whole host of other problems, but at least 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, they can just focus on that application. And I mean, that's a huge part of Saga's 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 stack 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 IBC, Polygon Celestia would not have been possible. There would just there would not have been a way for our interchange security orchestration automation stack to be able to communicate with these other ecosystems and then automate the dedicated block space for them. So IBC was key in that. I think even for the projects that are building on us as part of our innovator program, you know, these are small to mid-sized gaming and entertainment projects. A huge part of the value ad for them is IBC. And the fact that, for instance, a Solana 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 game 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 in terms of scaling out their particular game, they have focused on that communication piece. So I think, you know, this is why I always say that for Cosmos, you know, Cosmos SDK,

the ability to stand up your own chain, that was a really great innovation. But the signature achievement of this ecosystem is IBC because what IBC allows you to do or what it has allowed Saga to do, it has allowed us to take the unique offerings of our stack with respect to scaling and it is allowed us to plug it into other stats that have nothing to do with Cosmos. And that really is the power of it. So I think that, I mean, 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 the reason why we bet on this space, 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 the IBC is the signature achievement of the Cosmosac is pretty spot-on as far as I'm concerned, I think that it is probably the thing that out of the cosmos experiment will be the most long-lasting

and will spread across the broader ecosystem some more than anything else. I don't think about it in this in this who which which will win perspective. I think about it more from a developer perspective in terms of the tradeoffs they have to make between security, scalability of well, it's like security and sovereignty, I think. So if you're building an application that, I look at Web 2 as the Web 2 stack as an analogy, and from the stack, I mean really like 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 and hardware, vertically, fully, vertically integrated and all of the levels in between, you know, from, you know, building on AWS or, you know, these very large platforms and having high levels of sovereignty, but high dependency on those platforms. And then, and then there's, there's, there's offerings all the way down, you know, to, to the, the least sovereign and the easier to use. I, I see, I see this is more of a linear, more of on a linear scale than on a, yeah, 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, you know, consensus and data availability and execution and the sovereignty tradeoffs there and the dependency on those on those platform tradeoffs, et cetera. So yeah, I think I think these things will start to make more sense and we'll start to line up over the next, over the next few 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 this 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, et cetera? 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 mindshare because they recognize, hey, in terms of ease of development, 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, it's sophistication 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 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 you. tell us a little bit like where, 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. So feel like Sebastian, thanks so much for having me on. This has been an amazing discussion. I think this particular podcast, you go much deeper into the technical details than most other podcasts out there.

So it's been a lot of fun in terms of our roadmap. So we're going to have an announcement at ETH Denver in terms of our next big release. And that'll be a true change to launch chains. 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 EVM-compatible chainlets. But the chainlets are with a smaller validator set. Once we get closer to summertime, that's when you're going to see the validator set be expanded. It will be far more decentralized.

And a lot of the feature side that we talked about on this 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 test nets between then and main net launch, which is slated for Q3, Q4 this year. So Saga is going live this year. That's a, yeah, this is a busy year for us. And in terms of what we have to, you know, look forward to and where you can find more information about that, So all of the information is available on our website, Saga.xyc. It's also available on our Twitter.

Twitter is probably the place where we make the most up-to-date announcements. So you can find us on Twitter at Saga, XYZ double underscore. And then for me personally, you can find me on Twitter at Becca Leow. 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 will be a fun year. Great.

Well, Rebecca, thanks so much for joining us for diving deep into Saga and look forward to seeing further developments and probably we'll see you in Denver as well because both Felix and I will be there. Absolutely. No, thanks so much, Sebastian. 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 podcasts. And if you have a Google Home or Alexa device, you can tell it to listen to the latest episode of the Epicenter podcast. Go to epicenter.tv slash subscribe for a full list of places where you can watch and listen. And while you're there, be sure to sign up for the newsletter, so you get new episodes in your inbox as they're released. If you want to interact with us, guests or other podcast listeners, you can follow us on Twitter.

And please leave us a review on iTunes. It helps people find the show, and we're always happy to read them. So thanks so much, and we look forward to being back next week.