Interwoven Rollups with Stan Liu & Ezaan “Zon” Mangalji of Initia

Transcript

as a product stack we think that initial rollups are the most flexible but also the most product ready fragmentation actually kind of arises not necessarily from the initial asset type or like the liquidity of the asset specifically I think it actually arises from basically like the underlying infrastructure right if it's difficult to move assets between different chains especially in like this app chain based World um you naturally will have some sort of like fragmentation I think a vast majority of rollups as a service they charge dollars to use their infrastructure and that's kind of not something that we want to do rather we're just trying to grow like the collective pie and create more value for inisha as a whole and its stakers which is incredibly

[Music] nice welcome to the interop today my guests are Stan and Zan of the founding team of inisha inisha is a new layer one chain that enables a network of interwoven rollups what I find really interesting about inisha is that developers can build applications in three VMS currently the evm cosm wasm and the mve VM maybe someday some other VMS but what's really interesting is that all of the applications regardless of the VM in which the application is written are compatible and interoperable

with each other there's lots to talk about about the infrastructure and also the product that they're building here but before we get started make sure to subscribe to get notified when new episodes drop every week and remember none of what we discuss here on the interr is investment advice if you enjoy this content please consider sticking with us we're validating on a handful of networks just look for interupt in the active set hey guys thanks for joining me good morning sir uh thanks for having us really excited to be here yeah really excited to be here as well thank you so first of all I want to ask you like how did you come to work on this problem at which point did you say you know we need another product that enables people to build

rollups right yeah that's a good question so um we'll walk you through a little bit of the the backstory here um essentially Dan and I we used to work in the cosmos ecosystem for a long time back during the last cycle um we saw basically the rise of it uh as well as the fall after the Terra collapse and I think Cosmos was always the most interesting text act to build in because it was the most flexible framework to build unique blockchains that is the case everywhere right anyone that's building something Innovative comes to Cosmos whether that be something like be chain or Celestia or things like osmosis the problem has always been within

Cosmos that a few different things the first was it's just difficult to bootstrap a layer one um you have to deal with the validator set you have to inflate your token Supply you don't really have control over all those parameters and then typically it's it's a bit slower than how rollups operate and it's just like a a heavy load for anyone to do but app chains have so many benefits to them you're able to control uh your own boundaries you can set what you want to exist on that chain you can change the way that transactions are ordered um there's just so many benefits but um within Cosmos there's just a whole slew of fragmentation and I think that has to do with ibc's

pairwise dependency problems but also the way that just the ecosystem evolved over time so many different teams tried to become the Hub um and now you basically have like tens of maintainers for the same pieces of infrastructure conversely we saw the rise of rollups happening on ethereum um this allowed teams to build chains really easily really quickly you can do in a click of a button with these Ras services but the problem is that you get a copy paste Fork of the exact same chain the only thing you can do is add a custom gas token so if you're trying to build something novel when it comes to like the actual architecture stack it's a whole custom build and that's like not an easy feat by any

means and these chains on ethereum as well they're still isolated they're still fragmented you still have to talk to third partyy Bridge providers get Oracle services and in a increasingly modular landscape um we think that this problem's only going to become worse and worse over time as you have tens of Da layers 15 interoperability Solutions um that all create new token standards like this problem does get worse and so ethereum's original scaling Vision was to use sharding so really never had rollups planned into the road map and uh now we're kind of in this rollup Centric future where we think there's going to

be thousands of them and so we decided that there needs to be an architecture stack that kind of knows that there's going to be a rollup Center future and is built for that in mind and so when we approached inisha we thought how can we rebuild this entire system combining uh what we learned from the cosmos side and its flexibility with the ease of rollups on ethereum and then piecing in modular aspects but in a way that doesn't break composability that does doesn't break fungibility that makes it still very easy for users to build um and we thought that the architecture stack itself is not the end game like architecture is is

built um to allow these applications to run but it's really important to have a good product stack and a good economic framework on top of all this we need to tie the entire ecosystem together in this new multi-chain world that we're essentially trying to create yeah interesting uh one one thing that I wanted to ask you guys I mean you guys are building essentially a framework for building applications or a platform for building decentralized applications what I've noticed is that we're I think safely now in a bull market in the beginning of a bull market I think a lot of people expect you know the cycle to go on for at least another year maybe into 2025 20 like late 2 um

and what I've seen is lots of infrastructure still being built a lot of layer ones um roll up as a service uh platforms you know modular Frameworks da layers uh reaking you know investors are are investing in a lot of infrastructure I mean as a fund we're investing in infrastructure there haven't been so far like except for meme coins and you know maybe some new nfts there aren't that many really Innovative applications I think um you know deepen is interesting but you know deepen has been around actually for a long time

it's just been kind of like rebranded now as deepen um when are we going to see the applications and uh what's inisha doing to really you know get get developers to start building applications instead of like building more infrastructure yeah I think um that's like a really interesting question um and I do agree that like the majority of the value CES on the application layer you know the applications are the parts of the like let's say infrastructure stack that actually directly interacts with the end users themselves right while we are providing a lot of this underlying infrastructure one of our biggest focuses here at Anisha is basically enabling these applications to be able to really reach out to their users have

an interesting product um to use and so that's why we've been spending a lot of time especially now that we're currently live on testnet with some of our initial Mantia teams um which are which have a bunch of different types of products across different verticals whether it be defi social fi Etc um making sure that they're able to leverage like the opportunity of um anisha's public test net launch to actually you know kind of test their product against these users who are getting interested in initia themselves and so we've been basically you know putting all of our like strength as well as a lot of our time helping these teams get ready to Launch we do actually launch on mainnet as well yeah cool we'll talk about the applications uh a little bit later you know there's one thing I wanted to to

ask you guys about like you know just kind of getting your pulse on this I think if if we you know we're talking about app chains now but you know app chains as we described them today I think I think Encompass something a lot broader than what we thought app chaines were maybe just you know three years ago or even you know during the time of Tera like an app chain used to be u a chain that runs well the cosmos SDK because mostly that that whole thesis came from there has its own validator set and like really controls every level of a stack from the security all the way to the application layer now you know people use the word app chain to also

describe uh applications that leverage other forms of underlying security so that might be um a cosmos CK chain utilizing uh replicated security or partial set security on Cosmos it might be an application on inisha uh that is leveraging Anisha validator set it could be you know an app using Ian layer reaking where the security of the chain is secured by ethereum restake eth you know is it useful to differentiate app chains in the traditional sense and this new sort of application that you know might control its execution environment and have a lot of control over that aspect of the chain but leverages someone else's Security in the same way

that you know you might say that you know a city um leverages like a city is not a nation it's not Su it's not fully Sovereign from the perspective that it doesn't um it usually doesn't like SEC um operate its own military um but a city state might you know I mean this not a Perfect Analogy but I think that analog has been used quite a bit in in Cosmos to describe like what um how chains are are secured yeah just open question for you guys um for the most part I think more terms is bad uh because for the end user or just like regular people who are trying to learn things really most of these things are very similar um in that

sense I think app chain is a very versatile term I think it refers to any chain that has one core Focus or one sole Mandate of what they're trying to build around um and so I think whether that be a rollup a sovereign rollup a zk1 a optimistic one one that has you know replicated security or its own validator set I think those can all be considered app chains just fine um I think on Anisha we view these app chains if you want to go back to your citystate analogy as like more so like a state within one country so if you imagine initia is like the the US um we want to

build the like the federal level as an Isa so we control things like the transport layer as well as like some of the monetary policies but each state is still its own state they're able to work towards their own goals but they still have the underlying uh Collective of the entire nation to fight for and that's what some of our economic mechanisms that we've built directly do because I think that has been a big problem for app chains uh like systems of app chains in the past if you look at Cosmos I think one of the biggest problems is that Adam was never really pushed into these other states and because of that um you have all this tribalism and no

one really cares about the Hub conversely if you look at rollup stacks and rollups on ethereum everyone cares about eth a little bit uh everyone cares about Sol despite being different applications and so how can we create mechanisms that do the same thing across a thousand rollups in the future on adiss yeah I think that's a great uh that's a great analogy so like the federal and state level so so from that perspective you know I think what I'm what I'm taking away here is that application application change should be defined more by their output function so like what is the thing that this app this chain or this app does uh as

opposed to its level of control over the stack and so there therefore you know things like the cosmos Hub or salana or like these infrastructure chains um are not app chains and in in themselves since they are not like producing a singular application but rather like a multitude of applications I don't think it has to be a singular application but I would say it having a singular goal or like a something that they're striving towards so the cosmos Hub is an app chain because its goal is provide security to other application chains um yeah that gets murky though I don't

know I I get that we shouldn't add more terms but um it's like saying AWS is the same thing as Facebook I don't know like you have like you you have applications and then you have infrastructure but anyway I think this is like a whole de that uh that maybe we can have it some other some other time um you know you guys have talked a lot about fragmentation I've heard you guys talk on other podcast about like how Cosmos is fragmented and you know I think not having a singular token that acts as the money for the entire system is one of the reasons why that is like I just watched Sunny give a a talk I think of like the I can't remember which podcast but you know he's talking about how you know Bitcoin should be one of the monetary assets of of the cosmos

ecosystem and how like bringing Bitcoin and I think I think that actually makes a lot of sense and would really help the cosmos ecosystem um yeah what's your view on fragmentation you know how do we get here and like how do we solve it because there are there are more application chains that are going live and I'm not talking about the you know the rollup initial uh variety I'm talking about like full-fledged application chains that have their own staking token and that you know continue to uh to bring more fragmentation to the space so how do we address this yeah so I think fragmentation actually kind of arises not necessarily from the initial asset type or like the liquidity of the asset specifically I think it actually arises initially from basically

like the underlying infrastructure right if it's difficult to move assets between different chains especially in like this app chain based World um you naturally will have some sort of like fragmentation and then you'll have like like a very difficult time choosing what is like the canonical asset for a specific ecosystem right um it it's a little bit easier for things like if eum because like ethereum existed much longer before like these rollups started appearing right so then you know ethereum just became the canonical choice but if you go to like a cosmos like ecosystem like the initial goal was to have a bunch of these like different chains right with the Hub and spoke model um so everybody's just they have like political interests right everybody's trying to fight for the exact same thing you know we want to be the money like the money for this

ecosystem itself um so I think like the first problem to solve is allowing these assets to move really freely across each other in different types of chains and I think like Cosmos in some sense has done that to a degree um through IBC and other like messaging protocols and messaging layers the problem is like you know IBC is path dependent so if you go from chain A to B and from B to C you get a different token than if you just sent directly from a to c and so those are like some of the Annoying problems right you'll get like different wrapped versions I think like salana and like other chains see these problems as well with like usdc with that that's wrapped with like different Bridges as well and so I think that's what hampers a lot of the ability to to like reduce this like

liquid liquidity fragmentation um so that's like one of the main problems that we want to solve and we are trying to solve at Anisha um basically removing like this wrapped asset standard framework having like a canonical standard of assets across all different rups as well and that's like kind of why our L1 exists because it's like the orchestration layer um basically serves as like the data pipelining or like the infrastructure pipelining for all these um l2s or Minas um and so once you have that basically kind of you know resolved to some sense um then you're able to work on like what is the canonical asset where do we store this liquidity for this canonical asset is it on maybe one of these l2s or is it maybe on that L1 layer right um and so I think like one of the advantages of having L1 with this

whole L2 system um is to be able to house like all these assets as well as the liquidity for like the main asset in like a credibly neutral manner right so like it's not on one specific chain um it's just on the base chain yeah makes sense um let's let's talk about the product so can you describe the the uh the product stack and what are developers getting when they build with an Isa so there's a few different things um on the architecture side of the product um if you come in as a application chain developer you have firstly uh your layer twos are essentially a full-fledged Cosmos chain so you can change everything about the rollup itself on the cosmos SDK side um

whether that means you want to integrate skip block SDK change the way that transactions are ordered or if you want to add osmosis Dex modules or any other go module you can do that just fine and then we've integrated three different VMS that we call the interwoven VMS on top of this that being evm move VM and wasm VM fundamentally we believe that VMS are tools whatever tool works best for you in your application is the one that you should use and then ensuring that these VMS don't create fragmentation So within initia framework you can do cross rollup contract interactions you can bridge between them you can move from a move coin to an

erc20 to a cw20 just fine and all stay funable um and then as a rollup you are given almost everything that you would get on a monolithic chain directly to through the layer one so that being native usdc and CCT access uh oracles that are streamlined to the layer tws and are automically fetchable from every one of those chains wallet infrastructure so that you don't have to build it out yourselves your users can connect to any evm wallet any Cosmos wallet in app wallets despite being in whatever VM you want um a bridge widget that Aggregates all the

flows from any evm chain move chain Cosmos chain the on-ramp directly into your rollup so as a developer you don't need to say hey bridge to the initial layer one then bridge to my Layer Two um you get a block Explorer and then you get things like the initia app uh which are kind of just like HR places on the layer one so as a product stack we think that initial rollups are the most flexible but also the most product ready you can really just focus on building your application and everything else is just solved for you from day one when you launch is deploying an application on

initia permissioned or is it fully permissionless it's fully permissionless so anybody can come and deploy whichever you know app chain they like or like whichever L2 rollup they'd like and with all the underlying tools so the VMS the specific Cosmos modules Etc right and so since things are permissionless and and but then at the same time you have this high level of you know compati ility and interruptibility and composability between between applications like to what extent are applications segmented or uh from other applications uh because like is there an opportunity here for uh for apps to launch onisha that might be vulnerable that could affect maybe like other

applications uh built on the platform so I think like the apps themselves or specifically like apps built on these rollups or minias themselves are kind of isolated from each other unless they're built on the same same rollup or same initia which is definitely possible um so in general I don't think that's a risk there may be some you know concerns or worries about like liquidity so from one like assets from one L2 versus like assets from a different L2 um so we do have like a wh listing process on the L2 or on the L1 itself and this is through the L1 governance um to basically support some of the higher level tooling that is available to these Minas once they're you know bootstrapped a little and a little bit off the ground okay so you're saying at the L1 level

the tooling there is subject to to governance but anybody can build an L2 that that doesn't require any wide listing or governance yeah so anybody can I guess like build their own L2 admina itself they get all the access to the tooling itself um but for example if they want to be part participating in like a reward system which we call VIP um then that has to satisfy certain like basic requirements like the chain as well and then go through the L1 governance to get white listed interesting so you mentioned also that oracles are included uh in initia now that's something that in a cosmos chain is becoming like easier to do now with skip where validator can run uh

essentially like the Oracle for for a chain how does that work in inisha like are you guys running skip at the L1 level and sort of like producing price feeds for any chain or are you using some other system yeah that's essentially right so we've baked in skip Slinky module directly into our layer one so our validators feed new prices to the layer one um every block that there is so that there's fresh price updates and then we have a relaying system that relays these price updates from the layer one to every Layer Two that is within this Whit listed set um and use the block SDK on those layer 2os so that these Oracle updates are prioritized and

they come in as the top of the block when they're relayed to the layer 2 so about every 3 seconds these layer tws you get fresh price updates uh and what's nice about having um these layer twos be full Cosmos SDK chains if they decide that they want um Oracle frequency to happen every 500 milliseconds which is the speed of the layer two blocks instead of every 3 seconds they can just throw the slinky module on the layer twos as well we've already integrated it they just need to basically Kickstart the side car and um then that would be perfect for things like uh Perpetual products but for the most part things like lending products anything else the 3 second updates are are totally

fine okay so a couple of questions here um at the on the asset aspect so is does governance then decide which price feeds the Oracle at the layer one provides um because like an application might need some you know some like totally out there asset price feed you know like if they're building like a perk or Dex or something like that right which might not be at the provided by the L1 uh Slinky and then if yeah so maybe answer that first so uh skip recently introduced this new thing called the market map module um this is essentially just like a very flexible module to Slinky that uh

enables uh some administ Traders or some multisig basically to just like add new price feeds that they support instantly um and once that's added to the market map uh it'll start instantly feeding and then that same module exists on the layer twos and so they can essentially trim down the number of price feeds that they want included on their layer to so if there's skip Slinky support for that asset we can totally ship it to these layer twos um if it's something that's totally out there they probably would have had to make a custom Oracle system anyways to include those prices so they might have to do the same right okay and you know you mentioned earlier that uh

l2s can uh integrate the skip module directly if they want faster uh update times so the way I understand Skip and like we've had magar on the podcast and so like the validators run the the skip module and the side car and provide that price update um now that makes sense you know at the layer one level because you guys have a Valor set those valers are running those side cars so for the L2 who's running that side car and is it sufficiently decentralized sure um yeah so underneath every one of these layer twos is Comet bftt actually so we already have decentralized sequencer sets so you can have like five 10 sequencers whatever you might want and

they can stake any asset whether that be like a a dummy asset to create like essentially a multi or whether that be your own native token or the init token or something else and essentially those sequencers that are running comment would be running the side car and pushing those price updates on chain okay so the l2s also have to run their own sequencer that's not provided by the L1 no any L2 has to run a sequencer that's the same on any rollup framework they can choose to run one sequencer or they can choose to Run 10 that part is to to them okay and are you guys providing kind of like you know some kind of like software to binaries for

all of that is it's pretty easy to do and then we're also working with a couple of Ras providers um so you can just like go deploy with one click so we've already launched with new metric um they power a lot of Cosmos chain RPC and LCD infrastructure now so I think they do most of neutrons products as well as like astroport Mars those sorts of things and so on new metric platform you can go click what type of evm what type of VM you want um how many validators you essentially want on your sequencer set for the layer two and then deploying initi roll up on demand okay this is an aspect that I'm not super familiar with right so like sequencers and l2s what's generally the best practice um in terms

of like run like how many sequencers is of considered to be sufficiently decentralized and are there marketplaces where rollups can essentially like hire nodes to run a sequencers like yeah maybe a so at the moment um I think almost every rollup is a single sequencer arbitrum optimism all of those um I think it's a a process of decentralization first you typically start off as a single sequencer then you might upgrade to a decentral set that is using a multi style approach and then you upgrade to one that has slashing abilities with some additional stake um I think that's where reaking also comes

into play essentially allowing you to create these external validator sets to create slashing conditions around like maybe one sequencer instead uh so those are kind of like workaround mechanisms um but on initia we already have jumped to the the final step in that process that I mentioned um so you can have these decentralized sequencer sets we typically suggest somewhere around five um whether that be through multi style approach or through um stake with slashing is kind of up to you and then we're working on some reaking stuff as well so that you can potentially expand that security to a much larger

set right again so what's at stake here is mostly censorship um right so like if you're running a s single sequencer I mean you you could censor transactions but you wouldn't be able to like run off with funds or something like that yeah and I guess there's also the tradeoff of basically like the more sequencers you have or like in some sense validates you have right like um I think like performance drops off to some degree like a very small degree it's that's just like naturally what happens with all Communications um so like in general latency and things like that um but yeah yeah okay so H how well does inisha scale then I mean like how many rollups can inisha handle um before you know scaling limits we start to reach scaling

limits so it depends on uh how much activity is occurring on the layer one versus the layer twos uh what's nice about vertical scaling is that essentially um and this is what makes rollups very different from interchange security is that the layer one validator is essentially don't need to do anything for these layer twos they're like completely separate processes they only get tapped in when there's something like a fraud prooof challenge um that they need to come to consensus on so for the most part you could have thousands of rollups on Anisha just fine um bottlenecks can start to occur if there's like an insane amount of traffic going through the layer one uh but for

the most part this should be a problem that we see maybe in a in a long time and I think once we start to approach that problem we're doing something right and so the the layer one um has like in addition to the Oracle um has some kind of enshrined protocols there so I think there's like a deex and maybe some other things so what's the what are the the kind of services that are provided at the L1 level in terms of being able to like Bridge liquidity from other ecosystems you know being able to swap between different assets Etc so the first is we've built a de directly into the chain it has both um

weighted pools as well as uh concentrated liquidity pools um so this is the initi aex and we've also then built something called it what this mechanism is is essentially we stake in it X token directly with our validators on the layer one we've built a new staking uh module called the the M staking for multiple saking um and you can essentially stake Whit listed pairs so init eth init Tia init usdc and this builds a hub of liquidity for major assets that is easily accessible for every Layer Two on the Chain but also uh it acts as an inter Manisha router so if you remember the you know there's the

pairwise dependency on Cosmos IBC uh the way that we handle that is that um all Layer Two to Layer Two interactions essentially go through the layer one so that the source path for any IBC transaction is from the layer one so through the layer one and because those paths go through the layer one that liquidity there is like a prime venue for things like swaps so you can send eth from one roll up and get usdc on another and you're not going to face High slippage because there's just a chunk of liquidity waiting for you um the second is we've included this forwarding module on the layer one that was introduced by the Noble Team and

what this essentially does is just automatically forwards um assets or IBC transfers this was uh invented because with cctp what happens is you have a cctp request from say ethereum it comes and it lands on Noble that cctp message can't have a memo field and because of that you can't in instantly initiate an IBC transaction section from Noble to some destination chain and so with the forwarding module that cctp transfer deposits funds into a uh forwarding module account it says I'm going to automatically route this to some other destination and so by introducing that foring module on R layer one as well we

can essentially do cctp transfers with one signature on ethereum directly into a roll up on Anisha um which is really cool for ux uh cctp is like not a thing that you can easily get on a rollup because you need Circle to actually come and launch on you but with the forwarding module as well as IBC we can just do this pretty easily um which is pretty awesome and then there is initia VIP which is essentially our reward structure to incentivize the usage of the init token across all the layer twos on inisha build novel use cases create that idea of in it is money as well as

give these layer 2 teams additional means to attract users where they don't have to use their own tokens and do it in a long-term sustainable fashion so we have uh quite a few different interesting mechanisms on top of VIP that we can't share just yet but it is pretty awesome for long-term reward structures that we built out after seeing like tens of Grant systems um and how those have turned out a couple things here so the um interoperability between rollups is IBC used at this point here I mean or is that just sort of like internal token transfers on the layer one IBC is used so we've uh put in a packet forwarding module on the layer one as well and so

essentially you can send an IBC transfer from a given Layer Two include some messages in there to go to whatever other Layer Two you want and then perform Contracting directions and what's cool abouts it works also for other message passing like uh functions that IBC supports not just token transfers you can send correct contract calls across contract calls nfts uh tokens basically anything and what's really cool is that we've been working with skip uh and their API so whenever a new minisha is whitelisted and added to the initia registry it gets Auto indexed into skip API and now you basically have like the full powers of

skip API directly on your rollup instantly when you launch very cool so then you can use like ic. fund to bridge in like any token into a a Mina and it has like all of its routing properties it has all of its liquidity Management Properties so I can say through skip API on a given Layer Two that I want uh to go by osmosis um or go buy stars on osmosis buy a a sloth on stargaze and then bring that to a different minisha maybe an nft minisha and that can all happen through just their multihop forwarding very cool so so IBC I guess

uh I'm familiar with how IBC Works between Cosmos chains and km wasm uh contracts but how do you get IBC to work between like an evm contract and a move contract so IBC typically what happens for these cross these contract interactions is there's just um basically a message in the memo field that is saying like Okay run this when you land on the chain and so you can just do the same thing and we've just allow you to put move messages in there or evm messages in there the big thing about these VMS was how can we ensure that there's no like dual asset layer is like something that you've seen with EVMS on cosm for a long

time um and we did that by a pretty unique architecture by basically replacing our bank module for our move mines as well as our evm mines with like a a bank interface essentially from cosmos's side of things it still thinks that there's a bank module there but from the evm side of things it doesn't know that there's a bank module there and in that way you create like a seamless border between the evm and the cosmos side so you can directly send tokens that are made as erc20 is on the evm side out to another Cosmos chain just fine and you can send uh Cosmos tokens into the evm side just fine

without there having to be like special things called right and so they appear on the other chain as like a cw20 or like what like a move token uh natively and when they go out it's in ic20 okay inter interesting and so you've had to do a lot of custom work I guess on the cosmos SDK side for this to work um I mean this and like I'm sure like other things what what other kind of custom work have you guys done you mean you mentioned this m staking module are there other modules you've built I think for the most part the big ones were there's a lot of things that we did with IBC and packet forwarding to ensure that cross all these rollups you have the ability to hoop between them um

and then a lot of work on the VMS for both move and evm to integrate those fleshly uh and then also just uh some of those modules like the multiple staking but otherwise it hasn't been too hard Cosmos SDK is pretty good and flexible so we haven't had to like fork and Patch our own version but just um create some of those modules and then build a lot of good product around this that Taps into those systems and so specifically for evm uh and and move I guess for evm are you using um ether men no we've built our own evm called initiate evm okay and does it have any other kind of improvements over just simply you know

working with the cosmos SDK like are you doing like a paralyzed trans um execution or stuff like that not just yet I think we're going to approach that later on um but right now essentially because all of these chains still use Cosmos SDK underneath they are Cosmos chains just the VM that they're using is different and that means uh like you're not running full go ethereum you're just using it as a run time essentially to run these transactions okay and you've also created your own move VM for the cosmos SDK right so similar thing done there um it's more similar to atos's move than

seis because uh seis requires some special interfaces for their consensus mechanism um but Aptos is is a bit more standard vanilla like move and that can be easier integrated with Comet BF you guys have this whole stack I guess we've been kind of describing this this stack called the op init stack um this this is essentially what we're describing here is like all these components that uh sit on the cosmos SDK that make initia possible so the op in it stack is basically are implementation of the op optimistic rollup framework um and it follows similar design principles to optimism's bedrock um spec specifically

um so you can kind of just view like the op inet stack or like the op init cosos modules specifically as like the rollup modules that allows for these l2s to have optimistic Bridges has um like the optimistic Bridge contract etc those types of things okay how similar is it to to the op stack or different like what's the main difference there the main difference is that it's built in Cosmos SDK um it follows the same interfaces uh because we wanted it to be as easy to use as possible and so bedrock and and op stack are the most used one and so we follow those ones but underneath it's a bit different um so essentially there is a host module that host module sits on

our layer one and then there's child modules that sit on each of the rollups on initia and then there's just like a a process that needs to be done to link the two and after you do that you create this trustless bridge um between a layer two and a layer one and what that allows you to do is essentially you know escrow tokens on the layer one have those be minted on the layer two and then have the uh withdrawal window on reverse with all the verification that needs to be done um so we have both essentially the optimistic bridge that lives between the layer twos and the layer ones as well as is IBC so right now you guys support three

VMS kmom evm and the move VM uh I noticed that the salana ofm is missing um why did you choose these three and you know are there any plans to integrate the salon of VM uh sometime in the future or other VMS for that matter yeah um I don't think there was like any explicit reason why we didn't do this I think like obviously it's pretty obvious that you know there's CA and was which is native to Cosmos um and then you have like Evan which is one of the basically has the largest developer mind share right um and then we were also like internally very big fans of move we think it will be like one of the Next Generation languages for use for for smart contracts as well um it's rust

based language and I think like a lot of our devs have experiened in that area as well um so that's why we kind of like included these three um we haven't like necessarily gone into any technical specking about building like a salana svm implementation or anything like that um it's not completely out of the books perhaps when were maybe you know a little bit Freer once we've like launched public main net or so but yeah like that's like something we're definitely still actively exploring um something that we definitely do need to do more research with yeah okay cool I I guess like yeah I mean like in terms of developer mind share I'm a huge fan of movement too of move um as well like we invested in movement and like really um

also think that the move VM will play a huge role in attracting developers and um and I think it's just like a net benefit for the space right as a very like secure formly verified VM um but uh but you know Sal VM also has like tons of developer mind share and might be interesting to also you know bring more attention to Cosmos from the salana side right it's it's difficult to say because you know I thought the first smart Contracting language I Learned was kmm I thought it was incredibly based that's very easy framework to understand it's fully using rust um has incredible security properties but then we saw the adoption cycle of it over the last cycle and it was slower than I

imagined um I think the the same thing is occurring with move right like it's an awesome language it's by far the easiest to learn um it essentially unlocks objectoriented programming but we have not seen explosive growth of it yet so I think there are reasons why we think of VMS as tools rather than like this is the one that should be used because there's trade-offs for all of them whether it just be like mind share ease of use security um and that's a reason why we would want to include more and more VMS over time because I think that's the most interesting layer to customize on because it changes the types of applications that can be built uh things like different da layers or interoperability Solutions I don't think

those move the needle as far and that's why within our architecture system that we've built here we've just like chosen one really good partner for each of these whether that be like Celestia for da or IBC for messaging and just integrated those very well so that once you come into inisha it's now the Garden of Eden and you can change the different things that you want about your rollup um change whatever VM you want but everything else just kind of works out of the box and uh the choices over some of those other components I don't think are like very valuable side from am I going to farm the next airdrop for this other da layer yeah I think that makes sense I mean like I one one thing I was

thinking about is you know currently if you're a developer and you're you're choosing which environment to build on it's it's mostly a function of which ecosystem you want to be a part of I think you know if if you want to go get eth liquidity you're going to build you either on ethereum or potentially on an ethereum roll up uh if you want like move liquidity you'll go build on movement or on aptose uh if you want Cosmos liquidity you know you'll like build some roll up on Celestia or like go build your own app chain um but but here those considerations kind of go away because you're using the underlying layer one you're benefiting from all the developer tools all of the uh the the

the inine um applications like the the Dex the Oracle uh the inine liquidity that's on the1 and then it's mostly just okay like which language do I prefer to write in or you know which uh existing uh code or like um repos might I want to use like existing contracts might I want to use for my for my app are there other things that developers should be considering like building an evm application on inisha does that also enable an application to be closer to the ethereum ecosystem or the evm ecosystem generally even though they are part of like the initia ecosystem yeah so I think like the goal of these rollups and the reason why we

call them interwoven rollups um that are being built on initia that regardless of which VM you choose right you'll be able to connect with like the outside ecosystem right so if you're you know and if evm based rollup you'll be very easily able to connect with like ethereum or like other ethereum l2s um and then through like the underlying Cosmos SDK itself you're you're able to connect with all these other rups that may be may have different VMS itself but yeah like I think like in general when rollups choose like which VM they want to use and for their application it's a function of just like ecosystem alignment right like we are ethereum aligned or we are Solana aligned Etc um and then it's a little bit less so for like the actual Tech itself there may be some specific cases where you know you

want like parallelization or something like that um or specific use cases but in general we just kind of view these VMS as tools you know just choose whatever fits for you you want to you you choose your VM and then you're interconnected with the rest of the ecosystem whether that's initial or like outside of the initial ecosystem yeah how do you guys compete with other rooll up as a service products um you know Saga Dimension alt layer I mean there's like a whole bunch of them um how do you differentiate and what is the the thing that people should take away from this podcast I think a vast majority of rollups is a service um they make money by essentially charging fees right they

charge dollars to use their infrastructure and and that's kind of not something that we're uh we want to do like these rollups are permissionless to deploy and they don't cost very much either and so rather by owning this layer one layer two entire system um we don't have to be that middleman that's just trying to siphon money uh rather we're just trying to grow like the collective pie and create more value for inisha as a whole and it's stakers which is incredibly nice uh when you look more so at some of the other ones that are less like just Ras providers I think we differentiate on a few different things firstly I think our Tech stack is like

the best one that there is uh secondly I think we have a huge emphasis on product ecosystem and incentive design I think like yeah architecture is great but the everything else is built to hide the architecture because that shouldn't be like the biggest reason why you choose to build somewhere it's like you know table Stakes at this point um you need to you should have good architecture and so the product the incentive the focus on building the ecosystem is really what's going to take inad to the next level and and set us apart if you have had a chance to play around with public test net You' probably been able to see the inisha app what our Explorer looks

like how you connect to wallets what bridging is M um all of the Integrations are just very seamless and those are all just like additional tools that these rollups cannot worry about and just launch with the second is the incentive mechanism design so initia VIP I think is the secret sauce that kind of ties everything together and if you're not thinking about like the long-term way to grow these layer 2 applications and you're just thinking about the layer one you're going to lose the reason is we win by having layer 2 is on initial win this is why any ecosystem wins right we are infrastructure developers but it's the apps that are going to drive the users and the demand you look at any

good ecosystem arbitrum was things like GMX maybe like magic Dow optimism synthetics and V Drome like you want to put your best foot forward to have killer apps and all you should be doing is trying to support them as much as you can whether that be on go to market Tech marketing uh incentives like that is our entire goal for teams building with us and I think that um user focus is like what sets our team apart as well um and I think that is seen by the ecosystem that we've already built like we just launched testet earlier this week we launched that with three live layer twos built by external teams that are insane

as well as three additional ones that are coming over the next couple of months like these are also not just like little univ V2 Forks like they're building new interesting things right there's Blackwing they are building essentially Dex abstraction um as well as through their Perpetual product so through their Limitless pool design with intense as well you can essentially do leverage on any asset on any chain with no risk of liquidation or Oracle risk which is just like endgame for how perss should be done um there's another product called contro they're building and they invented this thing called the

glob gradual limit order book like that's some some big brain stuff that I can't understand but it is uh like what is supposed to be used to create really fair markets slow down the time of them and is perfect for like prediction markets and prediction markets can be expanded to so many different things I think they have a a massive T then we have things like Milky Way which is the first reaking protocol or staking protocol on Celestia they're also building out some new interesting things for security and I think that's going to be a killer layer too and so I think the ecosystem that we've just been building over the past few months in

closed test net before being live is better than many existing chains already and I think that's what's going to really help us win in tandem to the product St focus and the product infrastructure very cool yeah I mean so what can people do on the test net uh so you launched uh I guess as we're recording this earlier this week what are some of the things that people can do to engage with inisha to you know maybe get an airdrop at some point in the future or some special perks yeah I think like the initial um initia public test net is basically just some time for like these applications that we've been working really closely with as long as well as us um to

basically test their products right with a bunch of new users get users trying out these new products themselves basically trying to get a feel for you know the interwoven let's say modular ecosystem experience like how you move assets between different chains or different l2s and mishas um how like bridging Works how we envision like how a modular like a really fragmented world can be fixed using our infrastructure um we have a XP program where you basically you know do different tasks around the initia ecosystem get XP points um use those XP points to basically um get food for your dog which is called which the dog is called Jenny um and you kind of level up the nft over several weeks

during the initial during the test net itself um so we kind of like made it a little bit fun a little bit gamified um there like a leaderboard to see who can level up the fastest and who has the most XP Etc um yeah just basically trying out like you know level up your dog while trying out all these different types of ecosystem projects it's also I think way cooler than how Stan made it out to be like there's like layers on the onchain Jenny system it's basically onchain tamagachi right you have to like decide what type of food you're going to buy her there's like all these different Lottery machines that have different um you know randomness of what food you're going to get you have to figure out when you're going to feed her because you can

only feed her once per week so you don't want to skimp um and then there's a really just pushes our users into our layer 2 teams so that they can go check those out and grow those projects because like I said like the way we win is by helping our layer twos win so we don't care about having our test net users create like a thousand random rollups that are like useless rather we care about like let's get our users into the hands of these layer 2 projects um and incentivize that and so now on public test net we have had I think we're about 72 hours in now we have over 260,000 unique wallets that have played with this um over 4,500,000 transactions on the Chain over

seven networks live including the initial layer one um and this is this is all with like a incredibly difficult faucet experience so I'm pretty sure these are real people yeah I I tried it and I can tell you the faucet experience was was a bit cumbersome I was not able to get my uh my in it tokens uh but I will prevail exactly so the Bots are certainly prevented so I'm pretty happy with the results so far and things are looking really good we've been getting some awesome feedback um and it's just amazing to see because we've been working on this for about a year and a half um we haven't showed anyone like the products that we were building and I think that's a lot of the

stuff where we shine um so incredibly grateful to the entire inisha militia for for hanging out with us and playing with the initiation cool guys thanks so much uh where can people go to build their Jenny and uh get involved in the public deset everything is live on inisha doxyz so just go to our homepage and then that will link you to the application itself and then everything is explained on the application excellent well uh everybody should go to inisha XYZ and yeah break their servers uh and uh try try to get these faucet and it's um cool guys thanks so much for coming on thank you so much for having us appreciate it sir