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.
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.