CROSS-CHAIN STATE PROOFS (Ismael Hishon-Rezaizadeh of Lagrange)

Transcript

we're live my guest today is Ishmael hishan Reza he is the co-founder and CEO of LaGrange The Grange is a network for doing cross-chain State proofs and enables new types of interoperability that we haven't seen before I'm also dying to find out why he thinks interoperability is not a winner to all space and IBC is not the answer so before we get started make sure to hit the like button hit notification Bell And subscribe to get notified when I go live every week and remember that now what we discuss here on the interop is an investment advice if you like this content please consider sticking with us

we're live on Atmos Quicksilver and osmosis and you should also check out nebula's summit which is our developer event happening in Paris this summer it's on July 24th and 25th if you haven't got your tickets yet there's only a few days left to get early bird tickets and all the information and tickets are available at nimblew.builders my guest Ishmael is coming up next right here on the interrupt thank you

hey smell how's it going uh you're muted foreign good good it's always weird coming back to my home setup there's always like a bunch of little technical glitches and issues and uh it takes me a couple of times a couple of other interviews to get them uh kind of ironed out but yeah really glad we're getting to have this conversation um LaGrange is a project project that I've been following for some time now um and you know we've been in contact and I should just lose that um I'm an early stage investor in LaGrange so get that out of the way for listeners and also potentially

regulators and um and so it it's a it's a New Concept and Paradigm for doing blockchain interoperability or at least that's you know kind of the high level pitch I know that it allows and sort of opens up possibilities for a lot more than just interoperability um but we're gonna get in all the all that today uh but first before we get started like yeah describe it with your background how you got here and you know what's the Genesis idea for LaGrange and you know how do you end up starting this company well thanks for having me on Sebastian so I am an engineering manager by background and I was a venture capitalist for a bit after that um I started my career leading engineering for digital asset strategy

for large financial services company manual life John Hancock working on some very early embodiments of decentralized insurance products back before the the first D5 summer um after that I I was a venture capitalist I led data-driven investing in research for a small SF based fund for about a year and a half and then about a year ago I took the plunge into uh started my own company founded LaGrange with my co-founder um and we have been focusing almost exclusively on new forms of cross chain and operability that we believe expand the developer space of what can be built in the interchain and in the cross chain domain in general you know when we think of cross train there's existing

solutions that we think very highly of we think very highly DK bridging work of IBC et cetera but there are other problems faces that aren't well tackled and that's what we're going for with LaGrange cool well I just realized that all this time I've been pronouncing it wrong I've been pronouncing it like it's a z top song you just pronounced in French great um okay cool yeah and um yeah what's what's the Genesis idea here and you know how did you you know form your team and arrive at like yeah building this company yeah so you know when we were looking at the cross chain space at the foundation of LaGrange one of the things we realized was that there were a lot of hop-based

intermediary based protocols that relied on relaying of state and information between chains and when we think of these as traditionally one-to-one communication we have state on chain a and you have some uh intermediary protocol that takes a state from chain a reaches a consensus over what that is and writes that the chain B and that's a very effective Paradigm for programmable asset transfers and for um generally one-to-one message passing but it's not a very extensible Paradigm for certain types of cross-chain relationships right we have potentially thousands of different Roll-Ups someday we have 100 chains in the interchain right now and there are properties and relationships that form between these different settlement spaces that are Dynamic and fluid wherein you would want

to be able to prove Aggregate and mapreduce properties for example across series of chains on the next chain so for example you might want to prove across a vector of n chains n times M states on the nth one chain and that is some of the some of the work that we do so how do you prove large amounts of aggregated state and Analysis of large amounts of aggregated States efficiently between chains yeah I I guess that probably you know answers part of the question all right that that I addressed up in the inner in the intro is that you know you were mentioning uh before we were talking that you think the IBC Solutions like IBC and uh Axel are are not the the only

solution to interoperability you know what's your take here and where do you see interoperability going like this in the long term and you know do you see that you know one-to-one interoperability relationships between chains as an issue like a scaling bottleneck that will you know have to tackle at some point and like LaGrange addressing some of that I think I think when we look at Cross chain there's always going to be the need for one-to-one relationships but there's also going to be the need for solutions that that address more Dynamic end-to-one chain communication relationships and we think of IVC and axler and cross chain Technologies as the existing ones as a part of the solution we think on top of that there are opportunities in

particular with what we're doing with LaGrange to support more Dynamic forms of Crossing interaction acrossing relationships and when you think about some of these more complicated relationships pricing uh multi-train asset positioning cross chain cross margin accounts you have the opportunity to build things that simultaneously span and depend on the state that is settled on a whole bunch of different locations and that's some of the the exciting stuff we're doing at LeBron we're very much orthogonal is what we think of it oh Sebastian yeah so if we take a step back and look at the the different uh types of of bridging that we have So currently there

are you know the the predominant Paradigm is a sort of you know one to one um like chain to chain uh Paradigm where you know one chain as you described earlier you know like there's a state that's established here chain B verifies the state of that chain and then uh some uh some event happens on chain B uh typically it's like minting a token and locking token on chain a that's you know the way IBC Works um you know that will be expanded for more generalized message passing but you know that's sort of how it works now there's a there's a a sort of Paradigm that's built on top of that which is you know the axillar model where actual so it sort of sits in between all of these

different chains that may or may not have um uh the same um uh the same consensus uh mechanism and can't verify each other and so axel you know there for accident as an intermediary in a sense uh facilitating that um that recognition of the other chain state so you know setting tokens or sending messages from ethereum to to IBC chains for instance is a is a particularly good example of this you know I think you know chains like polymer or projects like polymer um act similarly you know that then actual Arlo maybe not um maybe less with less Trust on on the Chain itself since they do rely on zkp

but it's fundamentally different from the the Paradigm that LaGrange is operating in where you're saying here is like some some State proofs that um any chain can verify and that can facilitate you know many to many relationships between chains that isn't just like a one-way kind of bridge communication as we've typically seen it um you know when you when you talk about that people you know given that the mindset is current and sort of narrative is so uh highly tied to like the the latter um what what what kinds of reactions do you get from people and you know what kinds

of um new use cases or new applications does that open up that's a fantastic question you know one of the one of the things I I'd love to add as well is we we think very highly of beyond the layer zero team the polymer team the access team Etc and we think of what we build as very much orthogonal and very much the ability to create these net new products in the space that now depend on more complicated State like there are certain things you should not be using a relay based protocol for there's certain things you should be um and when we talk with people they often try to to draw the the similarity between what we build at LaGrange and you know what you build with excellent and you would say okay you know why

would I want to use LaGrange to pass a token versus excellent and the answer is well you don't want these lacrosse to pass the token if you want to price something on arbitrum based on a moving average of liquidity on dex's on ethereum evmos and Juno and you want to look at the the the the pricing of a pair of an asset across three different settlement spaces and use that as part of a composite analysis or aggregate property of that on let's say the N plus one chain that's what you want to use the wrong score when you have these these very fluid large data sets and you want to try to compute out trustlessly composite properties of that data on on the next chain

okay and so from that perspective you know LaGrange will be specifically tailored to these types of applications um and and and not like the the I said I guess like the go to market for LaGrange uh will be parallel to these applications and not so much you know the cross chain transfers or the types of use cases that you know IBC and axelr and others are going after exactly exactly okay and when we think of you know the the future of all this we think of all the places where State and data are going to settle you're going to need multiple types of interoperability to handle the different types of relationships that exist in that world I mean how does that how do you see that

playing out practically speaking do you think that you know applications will leverage uh different interoperability protocols within the same application um like yeah is that is that sort of the end game here where you know you'll have different interoperability protocols than you might it would be akin to saying you know like some types of traffic will go over TCP and some types of traffic will go over like some other you know data transfer protocol right it's but exactly I think I think we're going to see web free Stacks converge to some of the development paradigms that we've seen dominant in web 2. and I think we're going to see certain types of interaction transfer protocols

function for certain use cases now we're going to see the need for other pieces of technology in that stack to be directly suited for you know the the value that they're delivering so if you need to price something it's likely not going to be continued relaying of spot prices between you know a million Roll-Ups it's going to be these these non-interactive aggregated proofs but if you need to bounce assets between different settlement spaces then bridging is of course going to stay the dominant Paradigm or IBC or any type of of more direct transfer protocol okay all right well let's let's dive into some of the technical bits here I mean I think one of the predominant uh you know themes in this conversation is going to

be you know zero knowledge and state proofs uh you know I think a lot of folks are familiar with those terms but you know I think it helps just reminding people like what is a state proof and how it relates to a zero knowledge proof and uh just sort of setting those uh some some solid bases here so that we can sort of stand upon the way I love to describe stay proofs is in the lens of what consensus looks like you know I think a lot of people think of consensus as this this immovable aspect of crypto where you have chains that reach consensus and that is somehow this black box Paradigm and they don't really think about well what goes into consensus and how does

one prove it how would I prove to you with no assertion over over who I am over the trust in me some aspect of consensus on some different chain and that's in theory what you're doing with a state proof so the the simplest way I like to think of it is the way a chain is defined is by a Genesis block and then a series of rules under which states can be updated and mechanisms to amortize the agency to update that state so you have a Genesis block and a set of rules that Define how that's they can be mutated and who can mutate it and that those rules as long as they're correctly enforced allow you to recursively prove the validity of any block

starting with a trusted block so that could be Genesis it could be some other trusted block and then if you have that trust over that single block and you can prove the rules have executed properly to get to the next block you can prove the state and that's the the principle of ZK bridging that's the principle in some ways of like client bridging um that's the principle of stake proof it is how do I indelibly demonstrate to you property of the validity of a given block header based on a trusted assertion over some previous Blockhead that could be Genesis it could be it could be the the some Inception block but it it is that recursive relationship you're defining

now in the case of of Lagos does that imply like chain a at accessing some data on chain B does that imply that chain a needs to have uh some sort of a client that is reading the chain data because okay sure you can you can verify the state but you're you're not going to have access to the data itself where does that come into play um that's a very good point so what zero knowledge proofs enable is for you to offload portions of that computation off chain and execute that in a verifiable fashion and so without requiring the entire

consensus logic or verification of consensus logic to occur on chain in a language that's compatible with the virtual machine of that chain you can have a verifier contract wherein you can verify that in fact that that execution has happened properly off chain or been verified properly off chain and that there's a proof of the veracity of that verification or the validity of that verification and that is where zero knowledge proofs are very powerful when it comes to proving this type of of interoperability Paradigm and moreover the fact that zero knowledge proofs can be incredibly compact at proving a very large amount of execution gives the opportunity and

the ability to prove these large consensus relationships succinctly okay so can you explain that like let's let's bring it back from to the applications perspective you know yeah let's say you're you're a blockchain application right and uh you know you're running on on your node right um can you can you describe sort of the the steps required to interact with LaGrange and um uh very yeah well you know do this execution right uh perhaps with the use case you described earlier right like check like average pricing on another chain or the price of an asset um and and then ver and then verifying that data uh after you've done the

computation yeah so the great thing about what we did with LaGrange is we try to abstract as much of the complexity over verifying chain State and then verifying storage within with respect to given block headers from the developer as possible and I think the average developer should be allowed and able to transact with these complicated multi-chain State properties without having to understand the specifics of how one proves consensus in the zero knowledge context or how one through restoration zero knowledge context so what you would do with Legrand very simply is there is a contract on a given chain that allows you to verify that some group of storage slots with some group of block headers is in fact valid and some property can be computed across all of that

so for example you would say here are the 9 000 blocks that have occurred on a given hour for arbitrum but the 0.4 second block time um and here are two storage groups per block showing the price of an asset on two sides of index and now here's an aggregate composite property that can be derived across all that data and you can verify that proof very compact very cheap from a gas standpoint that can confer trustlessly that incredibly complicated relationship the developer just has to call our contract pass the proof pass the data and get back yes or no is it valid on the back end we handle all the complications over consensus proving and

and and rehypothecate collateral proving and and storage proving all that okay got it now but in in the case of a so in this case for instance with the developer have to say the developers is on osmosis right and they're uh they're wanting to uh verify some data over on our on our original right yeah um with that application logic also need to be pre-deployed on arbitrum or they're doing that off chain they're very they're executing those computation off chain those computations off change checking the LaGrange contract over on Arboretum providing the proof

and then receiving the the receiving the the sort of true or false whether the proof is valid or not that's right yeah so that in this situation they want to verify an arbits from the state of Osmosis yeah yeah so they would generate the proof um that would show the validity of the state of Osmosis over some relevant time points and then the computation that's executed on that that take the proof of all of that and they verify that an arbitrary which makes it very easy because we have a JavaScript library on the front end allowing you to derive all this without having to understand what goes on behind the scenes okay cool so let's let's dive into a little bit more of the you know the construction of

yeah like LaGrange and the architecture of the network because you know I think it's it's quite different from what you know what people typically think about when they think about it yeah you know a bridging protocol um can you describe the the network topology and the the different sort of deployments that LaGrange will have on on different change in ecosystems yeah um and the way the way we really think about it is when you are proving the consensus or when you're approving the validity of a blocked header of a chain or some type of settlement layer or execution layer what you have to prove is that at some point in time based on the predefined

set of rules that this is in fact the state and that's a very Dynamic question when you think about app chains side chains uh Roll-Ups and and general purpose computation chains or general purpose chains because there's a very specific set of rules across each of those that are defining what is considered valid what is considered final and so the the the way LaGrange thinks about it is very bespoke where the change that we support we have to think very critically um about what is in fact considered valid so one of the first products that we're building or what we call LaGrange State committees and LaGrange State committees are designed for optimistic um optimistic substrates and optimistic

environments where you don't have a provable validity of finality or approval finality beyond what is defined by Game Theory over a period of time where optimism has one block finality with respect to a validator who can execute the state transition between B and B Prime that are corresponds to transactions of that block and determine whether or not that state mutation from B to B Prime occurred properly and that has one block finality with respect to settlement on ethereum same with arbitrum same with base Etc but with respect to the Frog proof window and the ability to use that state cross chain it's historically been constrained by for example a two-week window because there is not the ability

to take that state and verify whether or not there will in some Future Point be the the game theoretic relationship that requires that state that that enables that state to be changed with respect to somebody challenging it and so with what our committees do is we use a large amount of rehypothecated collateral uh either through eigen layer or restate with rocketpool or Lido to allow independent validators to execute the state transitions between two optimistic blocks and to attest to their validity so for example you take your ethereum uh violator you or take your series with your values and you take a optimism

watcher or overtime Watcher and you use your keys from your your ethereum violator to sign the state that your arbitrary watch respect that is valid and across an entire network of ethereum validators you're signing that arbitrant state and what you can do with that is generate a proof of the validity of that state of the point in time based on the economic threshold enforced by the sum of the stake held by the ethereum values so you can use these these the settlement layer of these orus to define a finality that is before the game theoretic finality defined by the Frog proof window okay I see so um

what what this enables is effective I mean it effectively enables uh users to be able to interact say with arbitrim or like an optimistic solution without having to wait for this you know the settlement time uh this this dispute arbitration time that is typically you know uh part of the deal when when working with optimistic Solutions right exactly and in the case of bridging you can say about I'll Trust the bridge to to Define for me what is final arbitrary and by them executing it but when you're talking about you know 1000 blocks two thousand blocks ten thousand blocks of arbitrary state it becomes very difficult to allow the bridge to find that for every single block and you start wanting to now have time pointed

proofs of the state of arbitrum that's being defined that you can then execute computational okay so there there is a LaGrange Network so there is a blockchain that LaGrange is operating uh that has a validator set I I believe it's a cosmos SDK chain is that correct uh no we we actually don't have we don't have a blockchain so what we have is we have a a mechanism for for the LaGrange State committees where there are a series of nodes that use re-hypothecated eth collateral um so it could for example be restaked eth with eigenlayer or it could be rehypothecated these collateral through

through rocket pool or through Lido directly staking um and these nodes in essence have have a valid BLS key pair for ethereum consensus and they also have um a connection to a Oru client or are you validate they're running or some optimistic substrate environment um and they can use the the key pair from from their eth consensus Cloud East consensus client to sign the state of arbitrary optimism or base or polygon okay I think there's there's parts of this a little still a little bit

um a little bit unclear um is this something you didn't didn't you guys have like I mean maybe maybe this has changed because I know you you're still sort of um making progress on the product but wasn't there a chain with validators at some point uh we used to have a MPC based structure we would execute um we would use a non-interactive keyword distribution procedure across a group of nodes and we'd execute signatures the problem with a lot of the the mpc-based structures or the cosmos SDK or tenement-based structures and people are trying to build these intermediary chains is you cap out on the validator set size yeah where in your your capped at 150 or 175

for Adam if you're thinking about about tenderment or you're capped at like 250 for most of the the NPC schemes where you're now talking about potentially securing billions of dollars of collective cross-chain volume and cross-train assets and you have a very small number of nodes you're trusting to do that so when you think about these intermediary chains as you grow the number of connection points surrounding them you put an increasing pressure on the security of these intermediaries and you can increase the collateral of the intermediaries in near perpetuity but then you you create huge sensory centralization agency risk because you still have the compromise you know two-thirds of the mountains 101 nodes you shut off the whole thing and you can

potentially compromise billions of dollars in value so that's why we've moved to this Dynamic structure that is unbounded where you can execute these attestations let's say to to base finality or to the base based role of State settlement with um with you know 100 000 nodes if you really want to there's no cap or constraint on that and so you were talking about the ethereum validators um and and so their role are you leveraging the existing ethereum validator set yes we are yeah okay so you're leveraging the existing ethereum validator set as a way to kind of bootstrap this this verification Network

exactly okay got it okay so um yeah talk a little bit about like the BLS aspect here so yeah uh how how are BLS uh uh how how BLS signatures different from say like MPC what does that enable and you know how do if you're invalidator say like on board uh you know this this verification Network yeah so so I think the the way we like to think of the the value of this is really in the ability to create these unbounded side steps so if you want to execute an attestation to finality or something this this is also going through the case as you talk about Roll-Ups that settle on the cosmos because I think there's some teams who

are working on that right now when you have when you're going to have Oru settle on the cosmos you need to Define what its finality look like for example you have an Oru set on evermo um and in that situation you you want to take the collateral that settlement layer and you want to take as much of it as possible and put that behind the NASA station that in fact the state transitions that were that were purported by the the Oru sequencer are in fact valid um and so what we do with for example arbitrum is we'll take ethereum validator collateral with eigenlayer for restaking or with something like rocket pool or Lido in terms of lsds um and we'll throw that behind and allow

people to delegate that to attestations and so where that's different than MPC is typically with NPC you have a series of nodes signing and if K of n sign they reach this this public key they originally known public key and that allows you to have you know the redistribution procedure keeps the key the same as you continue to redistribute and change underlying finer sets but um the signer set is constrained in size BLS you don't reach the same signature every time because you can have a very Dynamic set of people signing but these signatures can be aggregated and you take one of these aggregated signatures across let's say 100 000 nodes and you can verify it very efficiently this is what you know ethereum does as part of consensus

um and so one of the innovations that we've done is you take these underlying collateral sets and you look at existing collateral so you look at well how does ethereum Define its like client where you have a randomly selected group of 512 nodes that execute signatures on ethereum State and implicitly signed a current committee who's allowed who is designated to sign this block as well as the next committee assigned the next block and then you know the next block is valid if the committee that signed the next block is in fact the same committee as what was described as next block in the previous block and so you have these sign-offs that are recursive where you can verify a given block by verifying what's correctly signed by the next committee nominated by the previous

block or described by the previous block and I can go all the way back to some start point and that's what we do we take that same principle of being able to have these large aggregated signatures sign off on current committing next committee and then data and we apply those to this almost extensible new form of like client for optimistic environments so so we you described how how this works for optimistic environments um how will this facilitate cross-chain communication between you know like the evm space and say the cosmos space like tenement or Solana or

or other ecosystems yeah yeah so the way we like to think about it is is that if you can prove the if you can prove the consensus of the given chain then you don't need to have any type of bridging or mastering protocol originating from that chain that doesn't just use the proof of its consensus and at some point you'll asymptotically converge to being able to prove consensus very quickly for any anything that's in fact rapidly provable even theoretically provable um and so if you're going from something like um let's say evmos to ethereum and you can prove the consensus of Atmos because the valuator sets at 150 and the signature schemes are

um capable of being proven within within as your knowledge context then you're not going to be able to need these large rehypothecated committees you can for example in this situation you can take the proof of the state of Mouse and you can take for example the proof of the state of Juno over a series of blocks and you can put that into the lagrant data processing engines and you can generate proofs of composite properties on top of all that data and then you can prove that as well as the proof that these blocks are valid on ethereum but let's say you're going the other way and you want to prove the state of an optimistic environment on a cosmos chain

what you'll typically need to do is to be able to have something that you're proven to say that this block header is in fact valid and that's where these State committees provide a great solution to do that um and so if you can prove it outright just use the proof if not then you need these alternative mechanisms so what kind of incentive structures do you have here well one you know for these um for these signers right that are part of this extensible uh prover Network and and also you know the incentive to to act uh to act honestly so what's the what's the game theory here with regards

to uh you know honest uh honest participants yeah so the the rehab authenticated collateral either resting with eigenlayer or directly with like a rocket pool or a um or Lido would be slashed in the event they execute a malicious signature and so that's the disincentive behind bad signatures right you you the there's a severe economic sanction behind doing that um behind the value behind uh how severe is it uh it would be 32 weeks okay so you'd lose the entire you'd lose your entire stake of your validator got it yeah so should probably not sign bad

Ruth um and yeah and so the the benefit of selling the correct route is you'll Collective whenever these proofs are used okay and um I mean for for any ethereum validator um you know let's say I'm running an ad-home validator what's what's involved in participating in Lagos or or you know is this is this more you know targeted towards sort of more institutional stakers it's actually super light and that's

what we like about it where all you would need is your ethereum validator or any number of keys you have for validating on ethereum and one chain that you want at least one chain that you want to execute do that to stations for and the code that you have to run is a couple thousand lines thing um the this complexity over the zero knowledge proof so the computation we do on our ends and these committees to be able to compute these these very large recursive sharks but um from the validator standpoint's very light and you run the code and what it basically does is it takes your ethereum key and then it executes the the necessary verifications on the arbitrary chain the signs that data and then it sends that data to what can

be thought of as a proof generation engine okay um now the so these proof generation engines are they are they on every node or is there like some other participant that is running these yeah so anybody can run a proof generation engine but what it does is just aggregate a ton of of these signatures um and then generates a succinct proof on them where it'll verify that with respect to the previous block or with respect to the previous block that had a current committing next committee and then data that the correct committee assigned the next block

and you know some people might be familiar with these types of sync proofs being used on ethereum um for just like client um uh like client verification but these are extensible in fact we're just designed to any channel or if a chain doesn't have approvable consensus and doesn't have a like client structure that you can easily verify in a stark you can then rehypotheticate collateral from either it or from anything it settles on and then now have very easy to prove mechanism okay now I know in your previous design there was a token involved is there still a token here in this updated design is this the when airdrop question no no I'm just just wondering you know if if

there's a yeah I I don't I don't do airdrop videos no disrespect to anybody who does airdrop videos but uh yeah is there is there a token here and if so yes there will be a token so you know we we we've talked a lot about um these Rehab off kit committees that execute at the stations I think the best way to think about the overall problem of LaGrange and what we solve is not related to these these extensible like client alternative committees it's really about being able to prove large amounts of aggregate state in a zero knowledge context between chains um and there are fees that are derived

from that and there are fees that are derived from the consumption of these proofs from the like client case as well um and collectively those will will be be part of what will be incentivized with the token and we'll feed back into the token where they'll be they'll be cash flows before I collected by the token Etc okay and and the token will live on which chain because as as I've understood here there's no there's no change so yeah so so we'll have to think about where we want to put the token um you know I I think the the question of of where a token is going to be put is going to become less and less relevant as time goes on as long as you have a token with sufficient rights

whoever LaGrange is deployed you'll you'll need verification contracts in every chain you'll you'll likely need um rather rather complicated computational substrates in order to be able to drive these proofs and then you'll need a place to verify them wherever they may be consumed and there'll be the ability to collect cash flows from that to Route those cash flows them to govern the cash flows and the underlying contracts and that's in inherent value that's created that at some point has to be decentralized because for this to truly be this extensible piece of infrastructure that the applications can rely on it will need to be governed by by users and only be governed by people who have

a vested interest and it's continued success we don't believe that comes from from a C Corp so you talked about deployments what's the strategy for deploying uh LaGrange to all these environments so obviously there's like an evm component where like LaGrange needs to be implemented as an evm controversy em contracts you probably need like cosmosm if you want to deploy on Cosmos chains you know uh Solana if you're going over there whatever so and then and then obviously like on on the on Cosmos some chains don't have an execution environment um that is open and permissionless for for folks to deploy there yeah yeah so

what's your deployment strategy and how do you plan to deal with those like you know most notably osmosis that don't have a permissionless cosmosm um you know implementation and are quite um that's a opinionated about you know bridging protocols that use the chain so you know I think I think the benefit of what we do is because we're not doing asset transfers or bridging all we need is for them to want to consume aggregated multi-chain States so if osmosis now says I want to have awareness of ethereum State trustlessly for large groups of blocks or I want to have awareness for for ethereum compatible chain States or I want to have awareness

for app role of states for a series of of blocks then it would not be able to get that data natively and it would not be able to bridge it over fast enough so in that case you would need to deploy something allows you to verify your post whether or not osmosis sees the need for that and I think there's always going to be app chains that don't need data that have a functional purpose that they can execute on um incredibly well and thereby don't need external data then we won't be deployed there but I would imagine that you'll you'll need to prove osmosis State other places and I I hope osmosis I hope Sunny will want to prove the state of other people there you can build some very interesting things that

uh that can be downside price protection and price manipulation protection if you're now looking at the prices of assets across series of other computational environments okay so you you talked a little bit about governance a few years ago where you hinged on it I mean the the idea of governing a set of contracts on different environments and having sort of a native token that is fungible across different environments without a you know Hub like thing that kind of sits at the middle of all of this yeah um there aren't many examples of this I don't think I mean I think that's what makes it fun to

build yeah so how do you like yeah how do you see like governance playing out and uh yeah what's your vision for how this is going to work yeah I think we've you know I think we've seen and hopefully this is not a controversial view that across the current embodiments of governance protocols there are some existing issues that have been somewhat public in terms of the ability to vote where rap tokens are held and have those votes enforced cross-chain in a trustless manner I also think when we look at some of these more intricate governance protocols where for example you have to actively use an asset for

liquidity in order to be given a vote it makes it very difficult to vote with an asset while simultaneously using it to provide liquidity or something we look at like what Sushi does with getting votes by being part of the the X Sushi to the east pair and so when we think of these more complicated governance models you need tooling that enables them to function in a trustless fashion trust minimize fashion and that's one of the use cases LaGrange actually cares a lot about from a product standpoint as well as one that we we we hope to adopt as part of our governance model eventually and from a product standpoint you know the the simplest form of how I think about it is you have a wrap token on 10 different chains Every Chain has independent governance contract you vote wherever you want and at the end you take a

single proof that sums the votes across the 10 chains like a LaGrange State proof that Aggregates the result of the vote and you can verify that in any one of the 10. and then you can change the contract there by proving that across the tenders core but but what does the orchestration happen I mean you would still need some sort of orchestration wouldn't you you don't because as long any party can aggregate the proof as long as the information that's being proved is an argument okay and that's where it's interesting because there's no assertion of trust over who submits the proof because any one of the chains who gets the proof can verify where it has originated from without having to trust the person submitting it which means that I can agree on my laptop you can aggregate on

yours morality people who can anyone can execute but it must have occurred properly across all types okay so anybody could then capture these proofs and send them to the other participants in in this sort of you know constellation of the LaGrange deployments uh it you know you're sort of relying on at least one person doing that in order for it to occur yes as long as one person takes the proof of the result of the vote on 10 chains and can packs that up you're good to go and you don't have to trust that person interesting um

okay yeah I mean I think where else would I want okay so yeah let's talk a little bit about um let's talk about the SDK and you know for application developers and the role of the SDK so developer experience is something that's top of mind for us I think when we when we look at the ZK space in general right now a lot of ZK protocols have tenuous developer experience invest where it is very difficult to interact with any type of computation down as your knowledge context without being able to understand what underpins it at some point that's going to go away and I

think one of the most natural places where that that separation should be created is between application Level developers who are you know experts Game Theory experts in mechanism design and the sdks that they rely on that provide them the ability to access trustless multi-chain data and that's where we're really drawing at separation so if you want to build an application that depends on let's say it's a yield aggregator and you want your yield aggregator to deploy its assets across six different chains and you want to track the performance of those and then trigger a rebalance whenever you know a money market on arbitrum is underperforming a money market on Juno you want to move the assets from Arbor from The genome in that situation in that case you'll need to be able to

prove the state of all of those in a comparative fashion and you'll need to do that without having to understand the consensus of all those chains with finality of all those chains or understanding how you would prove that as your own knowledge context or understanding how you would map an iavl trees inclusion proof to a particular treatment you that allows to incur in the background but you need to be able to trust that the computation that occurred is in fact verifiable and that's what the SDK abstracts away you can trust a computation happen properly you can verify the proofs independently you can verify them on chain and you don't have to understand the complexities that underpin heterogeneous

consensus and heterogeneous data structure inclusion okay so so what what I'm what I'm beginning to understand here and maybe this was made obvious maybe this was obvious before but it just kind of clicked is that this proof verification doesn't happen on the Chain application Level it happens on the user application Level so you know you're not building you're not you're not building like well so the verification but like the um the proving happens on chain but the the verification happens in on the user client side it doesn't happen in a contract no the verifier the verification happens in the contract you aggregate the proofs

you can compute the aggregated proof in your browser if you would like to verify in your browser to ensure that it's accurate before you submit the chain you can do that but then the final verification's in the browser right the computation happens in the browser to create the proof to create the proof and then the contracts are for each other okay exactly it makes a little bit more sense now and the computation can happen anywhere if you want to put the convocation on the server because you want to compute some giant proof you're more than welcome to right okay so you know we you talked about some use cases earlier um and another website has a couple of other you know use cases um that are you know like this did kyc use case yeah can you describe some of the some of the other use cases that you

guys have yeah are considering and you know maybe even going to Market with we're we're very excited about a lot of the great work being done in D5 building um anti-fragile applications that are able to be deployed on potentially low liquidity environments and still function as intended and I think when we think about let's say options protocols derivative protocols lending protocols that want to now support long tail assets there is an inherent risk behind between supporting an asset that is low liquidity from a collateral standpoint and not having your protocol Get Wrecked and that's because if you take let's say

a large amount of collateral that's a liquid on a chain that doesn't have sufficient liquidity to liquidate it and the protocol and the person defaults and you know the the loan value um Rises too high and the collateral value drops then you can't liquidate that collateral and your protocol is left for bad debt holding a bag and so when you're supporting these more long tail collaterals that you can't determine you can't ascertain with certainty a priority to to liquidation whether or not they'll be sufficient liquidity for you to sell it all you need to be able to threshold and support liquidity in the capacity that is um that takes into account the secondary factors of that chain how much liquidity is there what's the volatility of that liquidity what's the volatility of the price what's the moving average of those

what is the moving average sorry where is that liquidity located in the change there's five dexes which one has sufficient spot liquidity at the point of liquidation and which one has sufficient moving average liquidity to be able to to confidently support the liquidation volume you have to so if you're on uh uh an L3 selling on L2 that sells an app chain in three years how much liquidity is there for for wrapped algorithm collateral these are the kind of questions that you need to be able to understand as a D5 Builder and be able to answer trustlessly um that's one of them so collateral pricing for long tail assets and fundamentally there's other ones that we're very interesting as well in D5 such as multi-chain yield aggregators

um that depend on on multichman acid positionings um cross chain cross margin accounts where you can you can prove the assets you have in one chain or the positions you have one chain to cross March a different chain um we're very excited about things related to credit or long longitudinal analysis of on-chain activity that can be done trustlessly uh we're very excited about these more Dynamic governance models and we're also very excited about um the ability to prove pricing between chains for um multiple dexes where you can have dexes that almost implicitly share a liquidity pool where uh you can use at the point of transaction proofs of the

liquidity across a group of other dexes to show that there's in fact some aggregate volume for that liquidity and at the price that's Global is somehow different than the price of spot on a given instance okay so then yeah maybe let's just stay on this uh aggregate liquidity use case um can you describe how that would work so would These Chains need to somehow have previously set up like something in order to have that aggregate uh liquidity and and capture like that pricing data or would this be happening sort of on a on a third party application that is using LaGrange and

sort of creating this dynamic between Sexes I think I think at the end of the day the agency to decide how it's going to be used it's going to brush some developers but yeah you know the really simple example I like to give is let's say you have uh three different x's on three different chains and you want to ensure that each of these dexes has the equivalent amount of liquidity because you expect an equal swap volume all through them and so you want to preemptively ensure they all keep enough liquidity right now you would have to monitor off chain or you'd have to try to rebalance them somehow um and it it would likely not be able to be done in the trust inspection what you can do with a state proof is at the point of transaction you can include

the proof of the liquidity and the other two chains on the third chain or vice versa any one of the three and you can use that to trigger rebalances you can use that to price by being able to say you know are usually going to swap and a part of their swap they're going to include a price proof and the price proof is going to show across the other liquidity environments what to sum the global prices and as long as you have these proofs that are fast enough computation large data you can do that so you can have dexes on three different chains a price based on a t-wop that's averaged across all three okay it's very cool um so what's the um what's the road map what's next for you guys and yeah we'll

expect you to launch and when when airdrop here what the heck let me ask you the question love it we're one of the first components of our technology that we've that we talked a little bit about earlier the the state committees will be launching um privately in about months six weeks probably publicly in about about two months and that'll support state proofs on some new environments the optimistic ones we discussed previously that you could not currently generate State person um then the computation at scale of these very large complicated data relationships will have a lot more coming out of that this summer both in terms of test Nets and use cases and

early early demos and early early products as well as time frames to to unbounded general purpose computation on large data sets that is highly efficient and um where can because I know you're still kind of underst in stealth mode I think your documentation is still uh uh behind behind a password uh when can people expect to have a little bit more you know to to read and to sort of take in very soon very soon this summer without question um and anyone anyone who finds this stuff exciting and wants to to work with us feel free to reach out to me directly

on Twitter cool and I'll put your Twitter handle here in the show notes and I think you guys also have a newsletter sign up on the website so I guess people could also sign up there yeah I should probably also do that as well great uh Ismail thanks for coming on I mean I I think I feel like I've come away from this conversation um with a better understanding of uh you know what how LaGrange sort of is constructed and you know the different moving Parts um I'll definitely we'll definitely have to do this again in a couple of months when you guys have you know launched and have some some running code uh I'd love to and uh yeah thanks again of course thank you for having me in the show

Cheers Cheers