zkAcademy #4: Union Network's Path to Seamless IBC to EVM Integration, presented by Union Build

Transcript

[Music] [Music] [Applause] hello everyone my name is Carell kubats I'm the CEO of of Union we are an infrastructure company focused on ZK based bridging our initial stack is completely based around IBC uh which is a technology originally from Cosmos that allows any chain to trustless connect to

each other we were founded about uh eight months ago and have been focused on doing what should have been done a couple of years ago basically building infrastructure the way crypto is supposed to be used completely around Trust less technology completely around censorship resistent technology uh to avoid uh possib possible abuse by hackers to avoid censorship by the US government or any nation state or company and basically adhere to the original Bitcoin Philosophy for my talking points today um I'm going to keep it really high level uh and not dive too deep into the mathematics behind the ZK stuff that

we're doing uh I think in the rup that's been discussed a couple of times already instead we're going to focus very much on the fundamentals of trustless bridging focusing on exactly what we're trying to accomplish and what the algorithm looks like from a very high level I'm going to dive a little bit into why like ZK doesn't just improve this system from a security perspective uh and also allows for kind of new innovation to be built on top of this layer and kind of new applications and then we're going to dive into what I like to refer to as the really cool delusionally Tech stuff which is cented around for example proof of proofs uh which massively improves light line based bridging alog together and

obfuscated messaging which is about how do you keep bridging transfers completely private uh this is a very big issue for protocols that are automatically trying to interact with Bridges let's say uh a landing protocol or a vault that invests on different chains because as you can imagine when you do bridging you add massive massive latency for from a technical perspective 12C latency which allows uh a lot more M to be extracted and so keeping these messages private is actually key to scaling automated messaging uh between chains um to understand fundamental the fundamentals of twist bridging we kind

of need to understand uh what finalization is uh meracle proofs and state verification uh these are three Core Concepts that right now are 100% necessary to do this correctly H and basically every single chain supports this every single modern chain there's a couple of weird ones out there that for example don't store uh their state inside Merle trees which means that you can't really do header verification I believe Stellar is one of those older chains from 2016 or 17 that doesn't do this um so examples of uh protocols that are Li based are IBC which I already mentioned and telepathy by succinct Labs

telepathy is a bit of an outlier here because it focuses purely on consensus verification and kind of adds a message passing layer on top of that it's not really infrastructure or a bridging protocol it's also not what succinct Labs does they're mainly focused on consensus verification themselves so the first really important concept to understand is finalization which is uh basically the change process of ensuring that the block is never going to be reor or phrased differently when I look at a certain transaction that comes into my wallet when can I be sure that I really will keep that money so for example if I were to go to a store and pay with a credit card at what point does the shopkeeper truly know that the

transaction isn't going to be reverted because this is the moment they can let me leave with my goods for a credit card transfer finalization happens in about 3 seconds for Cosmos chains finalization happens every 6 seconds because we have single slot finality every single block is always finalized for ethereum this technically happens every 6.4 minutes times two because there's two rounds going on of checkpointing and for Bitcoin itself this technically never happens but some point you may be quite sure we can differentiate two fundamental ways of doing finalization one is for proof of work where creating each subsequent block has a certain

difficulty Associates with it and if we were to basically count up how much work has been spent on a certain block we can see that for the third block here uh 20 units of work have been spent which means that for this block to be reverted someone will need to spend at least 21 units of work well if one unit of work is $1,000 then for block number three you can be sure of $20,000 in value uh needs to be spent to try to reorganize this block so for transfers that are below 20,000 you can basically safely accept them now with Bitcoin obviously in proof of work the value is much greater for one single unit of work and

but this exed the confirmations that you see when you do an exchange transfer this basically the amount of blocks that we wait finalization for proof of stake chains there's a periodic checkpoint and this checkpoints can happen every single block or every X block so for Cosmos chains it happens every single block for ethereum chains it happens every what is it I don't know um every 100 blocks let's say so uh which involves the validators all doing a vote and basically putting a stake on checkpointing this block which if it is reverted later on they lose their stake so now we have a be mechanism for both chains to basically tie a certain value to knowing that the block is going to be

final and this value is key in being able to do bridging transfer because a bridging transfer is very much similar like the shopkeeper that needs to know that the transaction is going to be truly final a bir can really only send the funds to another chain once it knows that the deposit on the origin chain is never going to be reverted so if we can tie some type of monetary value to knowing that's not going to be perverted we can then have a risk model and say that there is a 0% risk or a very very small risk associated with performing an ATT test for stealing FS from the bridge the other key concept is meracle proofs um which basically entails uh creating a tree likee data structure

from the underlying data in the chain and being able to prove that some data is on the Chain now this is more a computer science concept which as a regular user you will probably never encounter you might encounter this because it's a mechanism that's used a lot in air drops uh used as a Merle distributor um basically the concept is that for the nodes in the miracle Tre we create extra nodes in between which are the hashes of the intermediate uh noes so for example A and B are hashed together C and D are hashed together and then finally the root of the tree is the hash of A B C D um in this case Merkel tree allows us to generate Merkle

inclusion proofs which can be uh if I have only the roots the top block of the tree which is a let's say 256 uh byte hash we can then create a proof and say a is inside this blockchain by providing the data from B and the hash from c and d and by hashing those together we obtain the same state root and that way we know that the data is present there now for this tree in particular here it's not a massive data saver for those that are doing the uh calculations on paper by hand you might notice that really what you avoid doing is transmitting one block of value so instead of need to provide a b c and d

we only need to provide B and the hash of c and d so just two blocks now for much larger morle trees this becomes a real data safer um and this is key to like line based bridging because we want to make a statement on what data is stored on the opposing chain and so by doing a really cheap small proof we paying a lot less gas for this inclusion imagine if you had to provide all of the data a through D or in case of etherium the full State itself you would need to send over gigabytes if not hundreds of gigabytes of data to be able to prove that one single piece of data is present on that chain now Miracle proofs are basically

used everywhere in blockchain it's I think one of the most fundamental uh data structures that we see used right now um if you look at a itself example here it has a block header which usually contains a state rout which is the Merkle tree root of the entire underlying state so A through Z for basically every account storage slot so that contains erc20 balances Unis swap pool data uh bridging data nft data ens Etc all of that is compressed into that single state route for most chains it contains a validator route in the case of course change for example which is all of the validator related data into

one single state rout now validator rout is incredibly important for light line based bridging because if you have this rout you can make statements about who the current validators are and who the next validators are and that's kind of key in the light cine based process other stuff that's included is the receipt route which is all the events submitted and for other chains there's a bunch of other Roots associated with it and then of course a block has a list of transactions usually there's a transaction route as well and that way with a single block header you can make proofs about any single transaction that's inside the block without actually needing to forward all of those transactions to another chain as an example as a light line based Bridge uh the main question when

you have a transfer from An Origin chain to a destination chain is am I allowed to Mint tokens or am I allowed to release tokens that's the question that the smart contract is asking and and for this smart contract accepts a certain type of proof for trusted bridging like layer zero or XLR or uh Wormhole usually a group of validators or multi-c participants create a proof which is then signing that a transaction should be allowed so uh in this case the light Cline proving mechanism is taken away and instead we have a proof of Authority for uh trustless Bridging the mechanism works very if uh assuming that we have

the previous block header already on the Chain we can forward the next block header to the destination chain and use the validator route to obtain current data from the validators using Merle inclusion proofs by that we can then show that this new block header is the new finalized header so what for might might for example show is that this new blog header has been signed by two-thirds of all validators in that case the light CLI smart contract will assume that this new provided block header is the next finalized block header itself there's some extra bookkeeping that needs to be done here for example you check that the block height is greater you check that uh uh a

certain amount of time has passed there's usually with live clients a whole host of rules regarding the protocol so in the case of ethereum you don't just check for two-thirds of all validators you check for a specific subset of validators called the signing committee and you verify that the current signing committee has signed this and then you can set what's going to be the next signing committee um after you've got the block header on a chain you can then use the stage routs to show that On the Origin chain someone has interacted with the bridging contract which usually entails doing a lock up of funds or a burn of funds by doing a mer conclusion proof of the state rout and showing that funds have been locked up the smart contract can then then make a statement and say

all right on the origin chain funds are definitely locked up with the intention of being sent to this chain hence I'm allowed to unlock funds or to M funds and this of course for bridging protocols leads into profit because uh now we've bridged over funds and we can charge a bpsv for that or uh do it for free uh as is more common IBC um but in Grand spectrum of things now we've reached our success State uh the way back goes exactly the same uh we take the blob headers from the destination chain and send them over to the origin chain and do the same proving mechanism so in the end all that uh all that light lines really do is track the

finalization of a certain chain um have all of these rules about this chain embedded into them and update what they consider to be the current header of a chain now lifetime based bridging is a lot more complicated than doing trusted bridging because it involves handling the different types of consensus per chain which can vary wildly out there and it also entails upgrading them as for example an ethereum hard Fork to a new consensus basically leads to all dependent light cines needed to be updated it u means that uh if there's a attack on a chain the light client needs to be able to detect this uh and usually

uh especially the attack detection portion is what takes a lot of the effort in building this um luckily for larger chains attacks are really uncommon uh for example to attack a tress Bridge with ethereum you'd need to be able to control 2third of the validator set of ethereum which is not feasible at all and if that's the case then to be honest Bridge hacks are the least of our concerns uh we would have a lot more concerns regarding Al defi happening at that time K life clients which is what union kind of specializes in in our IBC stack do this whole operation but instead of having a monolithic light client contract uh in solidity where we handle

all of these checks signature verifications uh inclusion proofs Etc we actually offload all of this computation to a circuit uh we add some extra bookkeeping regarding our bridging system uh here as well because circuit verification uh on chain always has a constant cost which means that more computation can offload the cheaper the bridging transfers really become now ZK light clients have a few issues with them one of them is that signature verification is notoriously expensive to perform uh the same goes for these Miracle inclusion proofs because usually they use sh to 56 which is very uh ZK unfriendly which ZK UNF friendly just

means takes a lot of effort to compute which leads to longer approving times um in the end uh We've now kind of reached the stage that ZK light clients are competitive with regular light clients especially in costs so for example right now for Union doing a batch of transfers which is uh infinite in size uh but usually it's about 100 to 200 transfers cost about $6 to verify in gas on ethereum uh which is kind of like the golden egg that we've been waiting for uh the end all solution to doing bridging correctly now um for uh this SL kind like I mentioned we keep track of all

validators we keep track of consensus changes we handle liveliness uh this is a portion that's very difficult to keep track of as well liveliness is the property that the finalization keeps ongoing or that the chain keeps producing blocks kind of depends and what you read online and how people Define it um but uh we've seen it actually happen before in ethereum where the beacon chain halted execution kept continuing but this means that light cine based Bridges end up being in a semi-broken state until the beacon chain is rebooted and starts producing blocks again uh right now for ethereum it's definitely a bit of a um I would say experimental stage uh I'm quite

confident that we're not going to see a lot more issues with the beacon chain but uh we'll we'll see what actually happens in the future um another issue is of course malicious validators uh especially with large parties gaining a control of the validator set such as Lio the actual risk of a malicious validator set becomes greater um I'm not saying that Lio as a DA is malicious but if someone were to gain control of their oracles and their multix they could use that to install a large set of validators on ethereum and then try to do an attack to gain control of the N network uh and there's probably a host more attack factors that you need to take into

account the great Advantage uh with this is that instead of the attack factors being lazarous attempts to get the multi that's being hosted by a single company they need to attack the entirety of ethereum so very much the same way that igen layer as a security mechanism has the entire etherum validator sets so do ZK light clients or light clients in general benefit from the entire validator set themselves instead of from a smaller company or subset that has a multisync now I briefly mentioned State verification um that is a little more experimental right now uh State verification basically entails that not only do we build live clients around ver

verifying the validator route we also run all of the transactions in a block in a zero knowledge circuit uh what this allows us to do is actually remove the complete trust dependency on validators for the correct execution of transactions and instead we just need them to finaly a block um why is this important validators could of course not abide by the rules of the evm um we've of course defined the evm that 1 plus 1 equals 2 but if 2third of the validators were to Fork their notes and make that three then the blockchain would still produce blocks uh still continue to do stuff but our brid logic would be completely off and we'd end up with

unback tokens some really cool projects here right now include uh Z or Z by risk zero which can do state verification for ethereum the downside is that this is still relatively slow the top of my head it takes about 17 minutes per ethereum block to do verification while uh for just regular light clant updates it's closer to uh somewhere around a minute to two to do full verification um the benefit of course of this system already existing is that we can do fraud proofs with this so the fast path for trusters bridging does not need to take State verification into account but offchain observers can do this and in the case that they detect

fraud happening they can construct the slower to construct ZK proof and do the state verification there and then allow the bridge to be bed shut down or for validators to be slashed so some of the cooler stuff because I think probably most of the listeners are quite aware of life clim based ping um they allow us to do a lot more stuff as well besides just as a transfer uh one of the applications I'm most pollish on that Union is working on a lot is share security which is basically can you for example build a sovereign rollup or a Cosmos app chain or a substrate Standalone chain and actually benefit from the I layer security set for this

you need to trust this connection uh between the two chains uh you could use a uh header Oracle the downside is that then not only do you tie your application logic to the Oracle protocol that you're using and so your your defi at risk you're now also tying your consensus to the Oracle itself um which means that if an oracle attack happens not only do certain protocols on your chain lose funds you lose your entire chain hence why if your objective is to increase the security of your chain for shared security you really want light C based bridging uh storage proofs a really cool application as well um longes has today just published an article on the uh application of IBC

with storage groups what this entails is using the headers that you have on the chain and the uh Pro Miracle inclusion proofs associated with the state roots to create historic proofs for a chain so for example the number of Trades that have occurred on Unis swop since Inception or the cumulative amount of uh impermanent loss on Unis swap of course you could try to record this with a t- web Oracle but the downside is t- webs can be manipulated plus they are relatively inaccurate uh now with storage proofs you actually get the data as is so it's true uh data from Genesis until now compressed into a single small

proof and so if you were to build an app chain that has a low block time for options trading you could still do a Litecoin based connection to ethereum and get high quality price data from ethereum without needing to use a chain link Oracle without needing to use a trusted bridging provider um and that way basically create your really nice uh end user application while benefiting from the larger ecosystem uh another big one is that lightel based Bridges can be completely permissionless especially if you add State verification to the feature set um permissionless isn't just that users can choose to use this bridge without being censored it also means that you can boot

up a new chain or a rollup and connect to the IBC Network without needing to do a governance proposal without needing to talk to the union team basically the same way as uh creating a server and connecting to the internet you don't need to actually uh go through a three-month process to open up your birging channels or find briging partner now this is actually what got me into briging initially this idea that I want to see a future where we have thousands of chains thousands of rollups and execution environments uh even for every single Bank every single financial institution and actually be able to connect them all to each other without needing to go through a long process as as I already mentioned censorship

resistance uh in the case of IBC and of Union even if Union Labs would want to take this whole system down that would be impossible uh people can still produce their own ZK proofs on my M2 it takes about two minutes on more production like sir for four to five seconds which means that uh it's truly decentralized so it's not a security you do not need to ban uh us uh citizens from using this system you can ban them you cannot ban them at all from using the system um and uh in the case that anyone would want to take it down you couldn't so as a protocol using this you're also not vender locked in you're not going to get worked at some point or

be tied to tokens from a bridge protocol that has failed and now all of your liquidity is in Nomad usdc um and these benefits to be honest is why uh we're in crypto to really make sure that we are completely self- Sovereign now proof of proofs uh kind of goes into like the more delusional stuff for the techies uh so once you start building out these live client based connections and you start booting up all these chains you start to realize that you create this very dense Network where for example uh blockchain B is connected to DFA and C which means that you're creating individual proofs for all of these networks sending them to all of

these networks and you're doing that for each one so as you start adding more networks here obviously the computational overhead starts increasing as well the verification overheads so for blockchain e to stay up to date here basically it needs to allocate block space to do verification for D A B C and F which means that now we're spending 90% of our block space on doing ZK proof verification which is not a deal because block space is expensive plus uh we want to save as much block space for end users at the same time e loves to be connected to all chains because we want to give our end users a really great use X when they do bridging and we want to

connect with as many protocols out there we want to get as much tvl into this chain as much different Financial assets a solution to this is what's referred to as the proof of proofs where we create a super ZK proof that contains light client data for all chains connected to the network now the computation still stays the same as connecting every single chain but the verification uh has a constant block space even if you start adding new chains to the set so basically what if we add chain X to this Bunch instead of connecting directly to every single chain we uh compress the proof aggregate it in the single proof of proof and

submit that to every single chain and now you've got kind of this one ultimate layer of bridging uh where you can make statements about any chain connected to the wider Network the downside of this technology at the moment is that for proof of proofs you need to do a lot of computation plus you lose the uh constant uh size ZK proes that you otherwise would benefit from so this is still I think about two to three years away from actually becoming a reality but when it does we kind of have the ultimate solution also offers some great benefits because if you have this single uh kind of entry point for bridging across all chains allows you to do coincident once allows you to do Integrations with offchain or private

chain order flow and it allows you to basically uh do better intent routing instead of users specifying that they want to go from A to B and then to e uh you can basically route the intent to this proof of proofs and then settle that automically across all chains and finally uh tidbit that we've been experimenting on together with quazar is OB fiscated messaging so uh a lot of cross-chain messaging happens by by protocols for example squid router Som quazar they use uh Bridges to communicate um objectives to their outposts on different chains so for

example uh perform a trade on this tax and send the fund spe to my chain or perform a trade and send it to a third chain and LP uh now these messages are relatively simple in the execution but the problem is since their chain itself is the uh calculator for these strategies they basically show their hands uh an me surger can observe their origin chain and realize what their rebalancing strategy is going to be and try to extract as much MV from uh this rebalance now ideally what you want is to actually obfuscate the strategy and the messaging such that an M Searcher cannot know at all what the uh actual

strategy is uh performed by the chain to to do off fiscated messaging uh we basically need to uh do a few different Technologies uh first of all uh on a chain like quazar we do our strategic calculation uh using a circuit as well that way we can keep the strategy a secret until it's actually connected uh obviously if we to still do this strategy in public on quar but then send out all the messages privately you could still kind of deduce what's going on and extract meev so a strategist uh does the calculation creates a new strategy the

strategy goes to the uh circuit the verifier and uh if it passes the verification it produces a set of transaction hashes or a set of um message hashes that need to be sent to different chains U this is what we refer to as a pre-image by the way um instead of actually uh settling this directly on ethereum we can settle these transaction hashes using proposal Builder separation or for now by using fles bolts that way we can already ensure that the transaction itself is going to be included in ethereum without actually showing what the data contents are going to be now once the block is actually

produced the content of the strategy needs to be shown but in this case it's no longer font runable so you end up with a system where uh in the and the chain still verify that the strategies are completely valid and by the rules set by quazer but uh you're able to include them in blocks on other chains without ever having an MV search and know what's going on um I just mentioned this so by sending the transaction hash to PBS directly you uh uh basically get the transaction included without making it funable at all uh this is kind of what's going to be I think The Cutting Edge of uh cross chain strategies so far we've already seen SoMo climb to I think the

number 10 or number nine yield aggregator on ethereum within the last three months uh and the whole reason that we see cross chain defi performing better than regular on DFI is that we're offloading computation away from ethereum and to its own separate co-processor chain uh which makes the ability to do much more complex strategies feasible uh so that's why quazar or Som can actually outperform uh let's say year uh simply because they can do much more computation on their strategy and as we see trus bridging grow and the yield opportunities on other chains become more available these cost chain strategies are only going to

become more competitive especially with these offis cated messages that allow them to do really any strategy than a regular Trader would be allowed to do as well so I think we're going to go to the uh Q&A now um for those interested in what we're doing uh check out union. bills uh on our website or on Twitter and uh feel free to give me a follow I regular tweet about this stuff and Link research articles I'm also always interested in discussing more Tech with people so feel free to reach out to me thank you so much that was awesome uh it's super cool to see uh from from your perspective uh basically you know with

the ZK background some of the answers to the questions that I've been trying to answer myself uh you know in in in this last week I've been doing a lot of uh just research and on Cross rollup communication and recently just put out a post about um whether or not we we need bridges in in the future where we're headed it was an interesting one and there's there's tons of different points there but um yeah I will uh pass the first question over to Rob unless he doesn't have one because I've got tons um um and I will take the back seat as I went first last time I I appreciate that yeah I I think we're totally I think we totally align on this vision of thousands and

thousands of rollups uh and interoperability across those those chains I think you laid out a very clear picture of how those chains could connect I I do have questions but I'm also curious about the point that Andy brings up about whether or not bridges are necessary uh with respect to cross in between these chains whether it's transfers or if it's data going back and forth between these chains so I'll kind of like I'll kind of POS that as the first question uh are bridges necessary when we have thousands of rollups so I think Bridges as we have right now are going to become unnecessary uh those committee based or multi Based Services aren't going to be necessary within the ecosystem what I do

think that we've seen is that initially rollups were seen as a scaling strategy for ethereum itself and over the last year we've kind of seen rabs go a lot more Sovereign and we've seen with the centralized sequencer networks with for chose rules really rabs being their own separate entities that just don't require a large validator set but are separate entities from ethereum itself and not just for scaling ethereum um and using like these new network Stacks that we're seeing you basically create what uh Bridges do right now but using a much more solid Network stack and that's actually why like Union decided to invest mainly in IBC because as a protocol IBC itself can also encapsulate

these new network stacks and provide a way where indeed like you don't have uh one single trusted bridging protocol but you do have a protocol for different rollup Technologies to communicate for different decentralized sequencer networks to communicate and the great thing then of course is what if this protocol also can do l1s right what if you just have this single layer of inoperability um I think that's at least for me as a de that wants to use this stuff the biggest prbe right now I hate having to use four different bridging Services uh to get the correct assets on the single chain to LP yeah yeah it's interesting take yeah we uh we came to some some consensuses

or some consensus as well with with regards to a similar kind of Outlook and and and I'll share that with you um I I I have two questions um one in particular to the slides and then also uh one in particular based on the the slides and what you guys are building with bringing IBC and ethereum together but first with with the slides there's two parts in in the slides here um and I think I I can actually push back which is super cool so this part off youc messaging and then um the uh ZK uh ZK light Glides right so um being being able to basically do uh off you skated messaging using ZK like clients or ZK

technology with crushing messaging or bridging it is is this a world where we get a more private defi experience is that what you guys are building towards is that what this is enabling by kind of uh using ZK or am I kind of missing the bigger picture as to why this is being built or or to kind of what the tech enables yeah so we start out by using ZK just for the scaling itself uh doing light clients with just regular solidity would be 3 to six million gas per light C updates with ZK it's basically 200k so it's just a necessity to make the system actually feasible from that moment on you obviously start realizing now that

you're doing stuff in ZK anyway that you have a lot more potential to do additional features on top which is where this off fiscated messaging comes in uh right now uh actually Sid router does a lot of traffic overall um and integrates I think with like 40 different dexas which you can only see the me Opportunity by monitoring what's going to happen with a transaction that gets routed over three chains and interacts with three different dexes on those chains a sophisticated M extractor that plays all three chains will basically always ensure worst possible execution for you when you arrive at your destination um if we don't want to go to this world of worst possible execution always then we do need A system that uh does privacy for us I

think that's a big mistake that people make right now they think privacy is about um avoiding paying taxes uh dealing with stolen money but that's not the case at all privacy is about getting best possible execution on your Defi and that's why like protocols like uh anoma and such doing private intents are so important yeah very cool um yeah that seems like more like a uh a feature enabled by the tech right um which is which is which is awesome I think there's an just keep going um the the IBC ethereum endgame is um I think it's it's it's definitely worth it to touch

on now but I've just got so many more questions too so you guys just went on on your test net basically enabling IBC and and ethereum quote unquote the endgame um that is enabled through this technology which we spoke about today uh and other various uh Technologies uh so yeah what is the state of uh the IBC and ethereum interoperability and how how uh did the technology that you that you talked about today or how does that the technology you talked about today um how is that going to impact uh this IBC and ethereum connection and kind of where you guys uh aiming to be yeah um so where's the technology right now um we were hoping to actually launch transfers

to over test net on Monday or Tuesday so uh keep your ears open for that most of the work we doing right now is actually making the rpcs a little bit more production ready so that when we launch this uh we're not going to go offline half an hour later um what is this going to enable so right now with these trusted bridging protocols the ecosystems around them although they are like browing they're very much centered around each protocol themselves instead of with IBC where we have part like skip TFM 42 Etc all working independently on top of the same protocol uh by bringing IBC uh to ethereum you immediately connect every single Cosmos chain um every single poker. chain as well as you

allow all these teams to independently continue building their products right so that's is like all important shared interface that we have it's kind of the same thing that allowed ethereum to grow right like the evm is a shared interface for protocols to in dependently build whatever they want uh without like needing to sit down you just check what the API is and you integrate with it and IBC kind of brings that same potential for new products to be built to uh cross chain bridging and messaging because you just have this one open standard without needing to go sit down with a certain team you can just do your full integration and build your company on top uh I think what we're going to see next is uh IBC to rollups I've alluded to enter new l1s uh and so what's the

case for Union here uh we're looking to take a market position on this fundamental Tech but uh the success of IBC isn't tied to the success of Union it's been growing very steadily uh over the last three years it's doing still massive uh transfer volume um and the tech itself is to be honest tremendously improving every month with the storage proofs changes uh icq Etc so I'm very bullish on this whole area kind of being ready for the next bull market to uh take the dominant position as trusters technology over chain links uh ccip Network I think those are kind of going to be two opposing factors one being fully decentralized one being centered around a single

company I think it's a it's a really compelling model that that you lay out and one that I think the the next bull market we all kind of like feel it coming but I don't know if it would actually happen without some of this technology because if if we don't have this interop across rollups in this world where there's thousands of chains I I think the user experience is quite lacking because there's no normies that are going to bridge themselves across four or five different modular chains with an interrupt solution like this I think it is possible to put all of that in the back end and provide users a nice easy user experience that can hopefully lead to to lots of adoption and and a flood of users entering the ecosystem

again like we saw in 2017 and then in in 2020 I I think this this solution is really really critical and I'm curious about the integration workflow um for any protocols that are watching this or hear about Union is there uh is there integration work that they can do ahead of time is it simply a matter of pointing to a different RPC like what what is the integration workflow yeah so U our public test net in launching in a couple of weeks so then basically they get the ability to do all Integrations they want the workflow really is only on chain uh it's contracts that handle uh sending messages sending transfers

reading State doing storage proofs as well as doing the refunds so in the case of IBC you cannot have tokens be locked up in limbo uh you either get them back or they arrive on the other chain but there's never an inet state so really it's very much designed from the perspective I'm a smart contract inside a sand box I cannot like integrate with an outside world or issue a ticket on Discord or whatever um kind of use case wise like what you started out with talking about um what we've seen so far interest wise is as well the lower bridging risk I think myself for the next bu Market um it's not even called Big players to be honest but there's plenty of players out there that have 100 million 200 million 300 million of s or other assets that want to earn

additional yields on it that have taken that from their client uh smaller users Etc that currently can't really bridge that over or do too much with it simply because we've seen the 100th Bridge gets hacked the risk profiles just too great but now with this Tess technology I do think we're actually going to reach the era where the risk is acceptable enough that we actually can make these assets do something useful which is a massive opportunity for protocols on rollups on uh app chain specifically dydx V4 Etc to actually take on a lot of this tvl uh so I'm thinking once the system is live we're going to see uh more institutional players do not for them large transfers

but for the def5 space itself definitely large transfers awesome quick quick like followup as to how I understand that from the perspective of like someone who might uh recognize this uh and is leading you know a a network or an ecosystem a lot of times like to get from chain a to chain B it takes three or four Hops and this could provide a direct hop from chain a to chain B and and that's before we open up to the world of app chains and thousands of rollups connecting with a direct hop from one chain to another chain I think is is a small scale problem now and it's only going to become a bigger and bigger

problem and Union here's the solution and the there's facilities here to handle all of it so even if it's technically multiple HS there's basically virtual channels if you go more into the IBC specification Etc so for the developers building out and integrating it's still seems like a single hop that occurs where the tokens can be stuck on one of the intermediate chains so either reaches the end or it's reverted and back on the origin chain um you can do uh batch asset transfers together with General message passing so instead of first sending out your assets waiting for them to arrive then sending an additional message to do something with that all of that can be compressed into a sing one um so there's a lot of really cool applications I think that can open up on this the moment you no

longer need to use two different bridging providers you remove the dependency of basically needing to check every single time like where where the did my assets arrive from which I have wrote like a couple smart contracts doing as transfers across chains you do need to check the lot where the is this going wrong yeah yeah I I think and we could talk you know at length about this I think there's like a dilemma that's been put forth where it's a trade-off between scalability if you're choosing to launch an app chain or your own rollup Sovereign or not sovereign you can choose scalability but you you trade off composability with the rest of the the onchain world but it doesn't sound like with this technology you have to make that that decision it seems like with this technology you can choose

scalability in an app chain and then also stay composable with the rest of ethereum and and the rest of modular rollups yeah and that's the exact objective right like I want to see a defi summer of applications that don't live on one specific chain I want users to kind of stop thinking about I'm an avalanche user and I do Avalanche defi I just want them to like Trader Joe star Arena friend Tech uh Unis Swap and just have those be on their bookmarks and just be transferring in between them without really realizing what chains they are being backed by and that's what's going to be I think the next boo Market yeah that's it I mean that's the way that um you know like you think about web two apps like you don't think

about you know what you know what browser you're using or what what type of uh uh inform info or email server you're on or you know you just use it you just use the social media app you just use the uh the financial app the game or whatever it is so yeah I think that the shift between like the shift from like the like the fat protocol thesis basically is is uh still correct in terms of like the value AC cruel mechanism for like say ethereum due to all these apps and different chains and rollups and all these different things happening and all this just basically Social Capital however the the real the real zero to one for crypto adoption in my opinion is is what you say where this

like this this ux of these apps that people use and have really no no no no care where yeah at least for me like I don't even think it's uh social capital or first to Market Advantage I think it's just ux centage uh if it takes me 30 minutes to figure out how to go to a new rollup and do something with it then I kind of need like a 20% apy uh plus to actually uh be willing to do these operations and I think that's why like ethereum and some of the first markets have an advantage because you're just not going to take the effort to move to New ecosystem if I need to go through medium POS with 40 screenshots on how to connect my new wallets and do all these

steps I just can't be bothered and so with like this new tech techology like you said for new startups building their products you can now choose to truly create the experience that you want tailored for your end users instead of having to choose a inferior solution simply because you need to provide easier access yeah no doubt I think that's a that's a great spot to kind of uh wrap up and push forward with the idea of what's possible in the future um thank you so much Carol for coming on uh giving us an badass presentation about what you guys are are building um and yeah thanks for the time thank you very much guys thanks Carol this was fun

cheers