Hop Protocol: A Trustless Protocol to Quickly Transfer Tokens From One Rollup / Sidechain to Another의 전체 녹취록

user. 00:05:03.199 --> 00:05:09.040 And at one point it would cost you know over$250 just to deploy to deploy this contract-based account. 00:05:09.199 --> 00:05:12.560 Uh, I think it would cost even more than that um some days today. 00:05:12.720 --> 00:05:20.560 So uh, you know, we we really saw layer two as kind of the only future for Authereum and for casual users in general. 00:05:20.720 --> 00:05:23.759 Like Ethereum itself was just too expensive. 00:05:24.079 --> 00:05:27.439 The cost to deploy an Autherium account was roughly two Uniswap swaps. 00:05:27.519 --> 00:05:35.360 So even if you could get the account deployed, there wasn't much you could do unless you were dealing with large amounts of money and you could kind of justify that that cost. 00:05:35.600 --> 00:05:47.680 Um, so we you know, we kind of had our backs against the wall and we're looking for ways that we could uh you know allow users to move directly from one layer two to the next so that they didn't have to kind of come back to layer one. 00:05:47.839 --> 00:06:03.199 So, you know, with with Aetherium, you know, we we started integrating with layer two solutions, um, you know, such as like Diversify and Loop Ring, and we saw that users would kind of uh bridge over to the solution, uh, they make a few transactions and then they bridge back. 00:06:03.279 --> 00:06:14.319 Uh, but the cost just to kind of get onto and off of layer uh layer two was more than they were saving if they just used the layer one um applications, you know, directly. 00:06:14.399 --> 00:06:22.399 And and so we knew that users kind of had to be layer two native and that they had to be able to, you know, get onto layer two and and then stay on layer two. 00:06:22.560 --> 00:06:37.040 And and you know, so we we came up with hop protocol, we put out um a paper about it um earlier this year, and uh just just to get some feedback and and uh along with a demo for for how it could work. 00:06:37.199 --> 00:06:40.000 And and the response was really overwhelmingly positive. 00:06:40.160 --> 00:06:52.639 So we we decided to kind of uh focus on this completely and realized that you know this could be you know true Ethereum core infrastructure and and could be uh you know a bigger opportunity than we what we were looking at with Aetherum. 00:06:52.720 --> 00:06:58.079 So that's kind of how we we got uh started on hop and and um to where we are today. 00:06:58.480 --> 00:07:01.040 Yeah, I appreciate that information. 00:07:01.839 --> 00:07:08.639 So the the future of Ethereum is as stated by Vitalik is a roll-up-centric one. 00:07:08.800 --> 00:07:19.759 I mean, he he laid out this vision uh years back, and only now we're we're seeing a glimpse of it uh with the start of uh launch of Optimism, uh, Arbitrum. 00:07:20.160 --> 00:07:24.480 There are also ZK rollups uh like Starkware and ZK Sync. 00:07:24.879 --> 00:07:32.000 So but I noticed that many people are still not very familiar with how rollups work in general. 00:07:32.240 --> 00:07:42.319 And uh given that you're you're really accustomed to them, could you could you maybe um explain how would uh a roll up, how is a rollup working in general sense? 00:07:42.560 --> 00:07:45.680 And uh what is it that makes them so special? 00:07:46.079 --> 00:07:46.399 Sure. 00:07:46.560 --> 00:07:52.800 So yeah, you know, with Ethereum scaling, we've always heard that scaling is right around the corner for for like years and years and years now. 00:07:52.879 --> 00:08:04.160 And it feels like roll-ups are kind of the first one that that really addresses everything that we've dreamed of with layer two, where you know, it it feels like layer one, we can deploy applications, we can deploy smart contracts. 00:08:04.399 --> 00:08:08.160 And so a roll-up is kind of this partial scaling solution. 00:08:08.240 --> 00:08:18.560 And so what I mean is that it scales in terms of execution, uh, but it still uses, you know, a scaling solution has um execution and then uh data availability. 00:08:18.639 --> 00:08:25.439 And so those are the two pieces that kind of uh are the two main costs of using Ethereum. 00:08:25.519 --> 00:08:37.759 And so any scaling solution uh needs to scale, you know, both of those, or you know, in the case of a roll-up, uh it's a partial scaling solution because it just scales execution and and not uh data availability. 00:08:37.919 --> 00:08:48.559 Uh but this trade-off allows us to basically use layer one Ethereum to, you know, as this data availability layer uh and and allows us to kind of order all of our transactions. 00:08:48.799 --> 00:09:00.320 So what I mean by that is is each rollup has what's known as a state route, and Ethereum itself has a state route, and this basically represents all of the state on uh on the solution or on Ethereum. 00:09:00.559 --> 00:09:07.840 And and so a rollup state route is is rooted into a uh smart contract on Ethereum. 00:09:08.320 --> 00:09:35.120 And when uh as kind of the rollup progresses, uh we basically say, you know, here are all the transactions, these are kind of updates to state, and we'll get from the current state route to some new state route, and then have um some uh validation around whether or not these these updates or these transactions that went from uh you know state route A to state route B are kind of uh you know is a valid transition. 00:09:35.279 --> 00:09:46.159 And so that's where you know the way that that those updates are validated, that that's kind of where the difference between an optimistic rollup and a ZK rollup um you know start to diverge. 00:09:46.399 --> 00:09:56.000 And so, you know, when when users are making um transactions, they they basically submit them to the rollup, and then those will actually get posted on chain. 00:09:56.080 --> 00:10:03.440 So all of the transactions that you're making on, say optimism or arbitram, they're actually going and being posted on layer one Ethereum. 00:10:03.519 --> 00:10:15.039

And then that's why you'll see that that rollups have this kind of non-negligible cost uh like you might see with with the these non-rollup uh scaling solutions like like uh Polygon and XDive. 00:10:15.519 --> 00:10:20.720 Um and so what once these transactions get posted onto Ethereum, they're they're not executed. 00:10:20.960 --> 00:10:26.159 You know, it's just posted for data availability, and but it does kind of lock in the order. 00:10:26.240 --> 00:10:38.000 So if anyone's kind of looking at these transactions, they can say, like, okay, here's here's the last update that we have on Ethereum, and then here is the the data of all these transactions. 00:10:38.080 --> 00:10:42.399 Um, but you know, no one's actually run the execution of these transactions on chain. 00:10:42.480 --> 00:10:55.279 But if I'm an off-chain participant, I can look at the ordering of these transactions and I can look at the state route that we had last, and I can actually um figure out the current state of the chain by just executing um them myself off-chain. 00:10:55.360 --> 00:11:01.759 And that's kind of where you get the scalability, uh, where you know the execution has been pushed off-chain for the most part. 00:11:01.919 --> 00:11:06.960 And so then, you know, the the uh kind of harder part is getting to that next update. 00:11:07.120 --> 00:11:10.720 And so with an optimistic roll-up, someone will just post the update. 00:11:10.799 --> 00:11:14.799 And then there's it's actually a week uh before that's uh finalized. 00:11:14.879 --> 00:11:29.840 And that week long um period, it basically gives enough uh people enough time to challenge the the, you know, that this these transactions that were posted between this state route and this state route actually led, you know, we're we're all valid state transitions. 00:11:29.919 --> 00:11:34.799 And and it, you know, if there's a challenge, the challenge can play out, and then the state can be updated within that week. 00:11:34.960 --> 00:11:48.799 And then a ZK rollup uses some some really cool, you know, uh cryptography to basically prove that that all of these transactions that were posted led from state from the you know state route A to state route B. 00:11:48.879 --> 00:11:55.840 And then it could just be proved on the spot, it's final on the spot, and there's no challenge game, there's no uh you know, week-long wait period. 00:11:55.919 --> 00:12:01.840 And that's why you'll see the exit times on ZK rollups are way faster than than they are on optimistic rollups. 00:12:02.960 --> 00:12:05.039 Uh yeah, thank you for that. 00:12:05.360 --> 00:12:08.000 Really good, um, really good intro. 00:12:08.240 --> 00:12:31.200 Um so with that, actually, uh you you touched on the point between the the ZK and optimistic rollups, and um especially with regards to the optimistic uh optimistic rollups, I also find that uh a lot of people misconfuse the uh seven-day challenge period, uh seven-day withdrawal period, actually. 00:12:31.440 --> 00:13:04.480 So just want to clarify that when uh when optimism writes the uh posts, uh optimism is called the sequencer, there's an entity that that that posts um transactions to layer one, but when they when they post that in in order, actually, and uh a full verifier node would actually be able to, as soon as it's minted on on layer one, uh a full verifier AL2 node would execute them and he would know 100% uh the state of the uh uh the state of the optimistic roll-up. 00:13:04.639 --> 00:13:07.919 So there would be no risk uh uh for for them. 00:13:08.080 --> 00:13:15.679 So the the seven-day withdrawal period is for users who not necessarily have the resources to compute these uh themselves. 00:13:15.919 --> 00:13:20.080 So I think that's uh the fundamental piece that that most people miss. 00:13:20.240 --> 00:13:24.320 And it's also a crucial part of how Hub Protocol functions, right? 00:13:24.559 --> 00:13:25.919 Yeah, that's exactly right. 00:13:26.000 --> 00:13:29.840 And we think of it as kind of on-chain finality and off-chain finality. 00:13:30.000 --> 00:13:43.360 If you're an off-chain participant, you can pretty easily compute you know all this, this, these state uh updates and and you know, get to finality, you know, pretty much after uh that that batch has been submitted or your transaction has been submitted. 00:13:43.519 --> 00:13:48.720 And then if you're on-chain, you know, the execution can't play out on-chain, otherwise we wouldn't be scaling. 00:13:48.799 --> 00:13:53.759 And and therefore you have to kind of wait for this uh week-long uh challenge period. 00:13:54.639 --> 00:13:55.440 Got it. 00:13:55.679 --> 00:14:03.360 So with that, um let's uh let's walk through how how hub protocol uh comes into play here. 00:14:03.600 --> 00:14:13.440 So I I'm on I'm a user on rollup A, and I want to transfer my tokens to uh roll up B, let's say up from Optimism to Arbitrum. 00:14:13.840 --> 00:14:16.799 So what is it that Hub Protocol helps me to do? 00:14:16.879 --> 00:14:19.840 And uh what what guarantees do I get as a as a user? 00:14:19.919 --> 00:14:21.519 What security guarantees I have? 00:14:21.600 --> 00:14:22.559 Uh sure. 00:14:22.879 --> 00:14:30.159 Yeah, so so hop basically allows you to um transfer your tokens directly from from one roll up to the next or one scaling solution to the next. 00:14:30.320 --> 00:14:32.240 And this happens almost immediately. 00:14:32.399 --> 00:14:37.919 We we basically wait for that, you know, the source chain to to reach off-chain finality. 00:14:38.080 --> 00:14:44.799 So so that takes about five, uh roughly five minutes for the most part, and then um then your transfer is completed. 00:14:44.960 --> 00:14:48.480 And hop doesn't introduce any new uh trust assumptions. 00:14:48.559 --> 00:15:09.600 You know, that there's obviously um smart contract risk with any kind of uh DeFi application that you're using, um, but it doesn't introduce like a new validator set, it

doesn't introduce a new consensus algorithm, it's uh actually just using um and leveraging the scaling solutions themselves, uh the message bridges between the scaling solutions and Ethereum. 00:15:09.919 --> 00:15:14.879 Um, and it you know does the rest completely trustlessly. 00:15:15.120 --> 00:15:26.399 And so, you know, to kind of uh get an idea of how hop works, it you know, I think it's important to understand how the the kind of native bridges for uh rollups themselves work. 00:15:26.639 --> 00:15:31.200 And so um each rollup will have a uh cross-domain messenger. 00:15:31.279 --> 00:15:41.600 And so that this basically allows um you know uh contracts on the rollup to talk to uh contracts on layer one Ethereum and then layer one Ethereum to talk to uh contracts on the rollup. 00:15:41.759 --> 00:15:47.360 And so the the communication from Ethereum to the rollup uh that happens almost immediately. 00:15:47.519 --> 00:15:53.679 Uh you know, uh it happens in the time it takes for layer one to reach finality, so also you know, five to ten minutes. 00:15:53.840 --> 00:16:01.039 And then communication from uh layer two to layer one, that that is uh only as fast as the exit time of the rollup. 00:16:01.120 --> 00:16:10.559 So if we're talking about an optimistic roll-up, then messages from the the roll-up to layer one Ethereum are are gonna take that full week before they can be executed. 00:16:10.799 --> 00:16:17.519 And so, you know, the reason that all uh rollups have this messaging bridge is because it's needed for the native bridge. 00:16:17.600 --> 00:16:25.360 And and so, you know, the idea um with roll-ups is you don't want to just have this siloed environment where you have like, you know, tokens on that rollup. 00:16:25.440 --> 00:16:28.639 You want to actually use the tokens that are on Ethereum on that rollup. 00:16:28.799 --> 00:16:43.519 And so, in order to make uh this this um kind of native token bridge for the rollup, um, the rollups will have this kind of lockbox on layer one Ethereum, users deposit tokens into it, and then they're minted a representation of that token on layer two. 00:16:43.759 --> 00:16:50.799 And and that native token bridge is all built around their cross-domain messenger, uh, which allows the messages to be shared. 00:16:50.879 --> 00:17:02.799 And and so that's why that's you know, why the exit time is also weak, uh, because you know the the user actually will um decide to exit, they'll burn their token on layer two. 00:17:03.039 --> 00:17:12.319 Uh, that will trigger a message from layer two to Ethereum, and it won't be able to be executed, you know, the exit won't be able to be executed for a full week. 00:17:12.480 --> 00:17:18.400 So, you know, that's kind of the the um native cross-domain messenger and the native bridge for each rollup. 00:17:18.559 --> 00:17:24.799 And so what hoc uh essentially is at the core is is this cross-rollup messaging protocol. 00:17:24.960 --> 00:17:32.799 And and so the

the core of the problem is is actually the messaging itself, not you know, and then on top of that, we we've built um token transfers. 00:17:32.960 --> 00:17:48.240 And so you could imagine kind of a naive way to, you know, if we're trying to talk um, say from Arbitrum to optimism, uh the naive way to send a message would be to you know propagate your message down to layer one Ethereum and then back up to uh the destination. 00:17:48.400 --> 00:17:56.240 Um and so that's not very scalable because for each uh individual message, we're gonna need a transaction on layer one Ethereum. 00:17:56.319 --> 00:18:04.480 And then we're you know, kind of have this big bottleneck because you know we we can't kind of scalably send messages uh between um optimism and arbitrum. 00:18:04.960 --> 00:18:11.440 And and so uh what we came up with hop is is we actually aggregate many messages at the source. 00:18:11.599 --> 00:18:19.039 Uh so what we won't actually trigger them to be sent, what we'll just kind of like store them in state um on the rollout itself. 00:18:19.200 --> 00:18:25.759 And then at some point, we will um move the whole batch of aggregated messages from the source to the destination. 00:18:25.920 --> 00:18:31.759 So so we kind of compress this this uh whole batch of transactions into what's known as a Merkle route. 00:18:31.839 --> 00:18:52.079 Um and then so we just have this single hash, and then we can propagate this single hash that could represent um thousands of messages uh down to layer one Ethereum to the destination, and then at the destination, it can be unpacked, and that kind of alleviates this layer one um bottleneck uh for kind of cross-cross-roll-up communication. 00:18:52.240 --> 00:18:59.680 And so just like uh the roll-ups on top of their cross-domain messengers, the first thing they built is is their native bridge. 00:18:59.759 --> 00:19:11.119 Um, on top of our kind of uh cross uh scaling solution uh messaging protocol, the first thing that we built on top of that is uh cross-scaling solution um token transfers. 00:19:11.279 --> 00:19:17.599 And so the way that the token transfers work is we introduce our own um you know asset. 00:19:17.680 --> 00:19:20.400 Uh and so this asset we call an H token. 00:19:20.480 --> 00:19:28.000 And so just like with the native bridge, you deposit into a lockbox and you get some representation of that token on layer two. 00:19:28.079 --> 00:19:30.720 Uh for the native bridge, we call it the canonical token. 00:19:30.799 --> 00:19:36.160 Those are the ones that users actually want, uh, like you know, USDC, ETH, uh, et cetera. 00:19:36.319 --> 00:19:42.720 And then for hop, you deposit and then you get H token, like HUSDC, HE, um, et cetera. 00:19:42.960 --> 00:19:43.200 Right. 00:19:43.440 --> 00:19:51.039 So so just to um uh expand on that point, the you you mentioned about the uh message uh message contracts. 00:19:51.200 --> 00:20:02.720 Um so correct me if I'm wrong, but uh any application, I

mean, once it's fully deployed on an open uh mainnet, these these roll-ups are are not whitelisted, et cetera. 00:20:03.200 --> 00:20:12.160 Any application can actually interact with that messenger and then represent uh and then create a representation of L1 token inside the rollup. 00:20:12.240 --> 00:20:16.000 So you would, for instance, see a bunch of dies there, right? 00:20:16.079 --> 00:20:17.920 Uh the different versions of die. 00:20:18.400 --> 00:20:27.759 But eventually there is a native rollup bridge uh uh and um and that's the one that you're referring to as canonical uh token. 00:20:28.240 --> 00:20:37.039 So there will be, for instance, in the case of let's say arbitrum, there we can call it maybe a die, uh, an arbitrum die, and that would be the canonical one. 00:20:37.119 --> 00:20:40.319 But but the but the hop bridge would be a different token, right? 00:20:40.640 --> 00:20:42.079 It would be like H die. 00:20:42.480 --> 00:20:48.480 So and you mentioned that eventually users want to get um uh arbitrum die. 00:20:48.799 --> 00:20:51.759 So how does this uh this work after that point? 00:20:51.920 --> 00:20:55.839 So we have an yeah, hopeful version of a token. 00:20:55.920 --> 00:20:56.319 Yeah. 00:20:56.640 --> 00:20:58.000 Yeah, that's exactly right. 00:20:58.079 --> 00:21:03.119 And and so you know, users ultimately want this A die or or you know canonical die. 00:21:03.759 --> 00:21:12.240 And uh we introduce this HDI because we need to kind of program in this special function, this special bridging functionality directly into the asset. 00:21:12.400 --> 00:21:24.000 Um so what when a user kind of transfers an H token from one role to the next, uh, the H token is burned at the source, and then um you know we have this liquidity provider role that mints it at the destination. 00:21:24.160 --> 00:21:30.720 Um but ultimately users don't want HDI, they don't really care about HDI, they they want real dye, the A dye. 00:21:31.119 --> 00:21:39.839 Um so we have uh stable swap AMMs uh between the H tokens and their their uh you know true or canonical assets. 00:21:39.920 --> 00:21:42.880 Um so that would be you know, say H DI to A DI. 00:21:43.279 --> 00:21:59.759 And so that way when when um the liquidity provider, we call this role the bonder, um uh mints um HDI for for the user because they they've made a transfer, then it immediately gets swapped uh through the AMM into uh the canonical. 00:22:00.640 --> 00:22:05.599 And then that's the one that the user can go on and you know deposit into Ave using Uniswap. 00:22:05.839 --> 00:22:10.319 That's the one that's going to be kind of widely adopted in that roll-up ecosystem. 00:22:10.799 --> 00:22:11.519 Right, right. 00:22:11.759 --> 00:22:28.960 And and also just to make sure this point doesn't get missed, um, we you also touched on the point that in a roll-up, a lot of transactions you you batch them together into a compact size, and then this get gets propagated uh through uh layer one to another rollup. 00:22:29.119 --> 00:22:39.039 But the um so here actually um the the question then becomes like why why there's any uh need for an intermediate token. 00:22:39.119 --> 00:22:43.039 And then uh you're also talking about the the bonders minting tokens. 00:22:43.200 --> 00:22:52.480 So uh what is the motivation be behind this uh to to have a hop representation of tokens uh to to cross access, actually? 00:22:52.559 --> 00:22:54.079 Uh can we expand on that? 00:22:54.720 --> 00:23:06.400 Yeah, so so you know for hop to function as it is functioning, we we we need to be able to basically burn this token at the um at the source and and then uh mint it at the destination. 00:23:06.559 --> 00:23:20.720 And so with kind of the canonical tokens or the you know, basically the tokens that that are the representations produced by the the roll-ups native bridge, um, we aren't able to to kind of program that that functionality into them directly. 00:23:20.880 --> 00:23:27.200 Um and so uh what sorry, what what do you mean when you say like we cannot program the the functionality? 00:23:27.440 --> 00:23:28.640 Um yeah. 00:23:28.960 --> 00:23:57.039 So so um so when with the H tokens, um they they basically will uh send a a very uh or when an H token is burned, that's when it kind of um adds a message to uh the list of of kind of you know pending transfers uh that will kind of eventually get aggregated into um the the batch that gets transported from the source to the destination. 00:23:57.200 --> 00:24:10.640 And so it we we aren't able to kind of uh you know with with the uh native bridge tokens, when they're burned, you basically just get to claim it on layer one, and we want to actually claim it at the the destination. 00:24:10.720 --> 00:24:19.759 So so we we kind of need this different um model that that we can't uh and we don't have that level of control with the the native assets. 00:24:20.160 --> 00:24:21.119 Understood, understood. 00:24:21.279 --> 00:24:24.799 And then uh let's let's continue from that point on. 00:24:24.960 --> 00:24:28.079 A user burns the uh the uh age token. 00:24:28.240 --> 00:24:34.400 Let's say he he wants to, yeah, and then uh what's the following chain of events uh from there on? 00:24:34.799 --> 00:24:48.799 So so the user burns the H token, and then uh the this uh role called the bonder, one of the bonders will kind of see this this um uh transfer has been initiated, and then they will come in and um complete the transfer. 00:24:48.880 --> 00:25:05.599 And you know, they basically have uh collateral locked up, and that allows them to um mint H token you know per you know the same amount that the user transferred minus a small fee at the destination, and then that immediately gets swapped into the canonical token. 00:25:05.680 --> 00:25:12.559 So from the user's perspective, they're just going from you know die on optimism to uh die on arbitrum. 00:25:12.880 --> 00:25:17.119 They don't really have

to think about this intermediary H token um at all. 00:25:17.440 --> 00:25:22.240 It's completely abstracted away from them, um, but then they get tokens at the destination. 00:25:22.720 --> 00:25:23.359 Got it. 00:25:23.599 --> 00:25:29.200 So so user has uh uh again the canonical die on optimism. 00:25:29.440 --> 00:26:05.200 He um he he basically wants to transfer it to to Arbitrum, he um he uh creates a hop transaction, and the hop transaction is um uh uh is is first converting that to uh H version, the the hop version of DAI uh on the original roll-up, and then uh this this one gets burned, and then in Arbitrum, again hop version of die gets minted, and then it gets converted to the the the canonical uh die on Arbitrum. 00:26:05.359 --> 00:26:05.839 Is that correct? 00:26:06.559 --> 00:26:09.440 Yeah, that's exactly correct. 00:26:10.400 --> 00:26:15.440 So um the the bonders here are actually playing a crucial role, right? 00:26:15.599 --> 00:26:21.920 Because um what once they see the intention of user, uh they the front liquidity. 00:26:22.079 --> 00:26:33.119 And in order to do that, they're uh putting up a collateral um during the time it takes for the transaction to settle out on layer one. 00:26:33.599 --> 00:26:41.279 So uh in terms of um capital efficiency, how uh how how do you see uh HOP protocol? 00:26:41.519 --> 00:26:41.920 Yeah. 00:26:42.160 --> 00:26:50.000 Yeah, so in terms of capital efficiency, um, we so to take a step back, uh Hop basically has two types of liquidity. 00:26:50.160 --> 00:26:55.519 We we kind of have this passive liquidity, and these are people that are providing liquidity to the AMMs. 00:26:55.680 --> 00:27:01.519 Um and then we have this what we call active liquidity because the bonder needs to kind of run this off-chain process. 00:27:01.680 --> 00:27:09.119 They're the ones that are kind of fully verifying the source chain, making sure that they're not being um defrauded or something like that. 00:27:09.440 --> 00:27:19.599 And you know, so so it's kind of this active role uh where their liquidity is is um, you know, they're consistently making transactions with their liquidity. 00:27:19.839 --> 00:27:40.160 And so the you know, ultimately with bridging, there needs to be some reserve of the canonical token that can be accessed by um folks that are are bridging because they they there needs to be um you know basically some pool that they can kind of tap into and pull tokens from uh when they they arrive at the destination. 00:27:40.240 --> 00:27:43.039 And so that's how we kind of think of the AMM liquidity. 00:27:43.279 --> 00:27:45.759 And so that I think is is optimal. 00:27:46.160 --> 00:27:55.519 Like there's no there's no way to kind of uh I don't think there's a way to kind of better use that liquidity because there ultimately has to be some reserve pool. 00:27:55.680 --> 00:28:03.519 And then the the kind of collateral that the the bonder locks up, uh this is where we see an inefficiency in the

current implementation of Hop. 00:28:03.839 --> 00:28:11.759 And so the bonder uses this collateral to uh you know to to kind of front liquidity or or you know, mint these H tokens. 00:28:11.839 --> 00:28:15.839 Um and right now they're using it, they're using the same asset that they they're bridging. 00:28:15.920 --> 00:28:18.640 So if it's die that they're bridging, they're locking up DIE. 00:28:18.799 --> 00:28:21.519 Uh, you know, if it's ETH that they're bridging, they're locking up ETH. 00:28:21.920 --> 00:28:30.400 Um in the future, uh, we're going to kind of decouple the the uh bonders uh collateral um from the asset they're bridging. 00:28:30.480 --> 00:28:34.559 And so you know this is gonna allow the bonder to hold you know productive assets. 00:28:34.799 --> 00:28:39.440 You know, this could be urine positions, it could be, you know, uh tokens. 00:28:40.000 --> 00:28:48.160 They could uh have a basket of assets in Ave and only borrow as they need to collateral, uh collateralize these transfers. 00:28:48.319 --> 00:28:55.200 And this is ultimately gonna remove all capital inefficiencies around um uh around you know the bonder role. 00:28:55.279 --> 00:29:07.440 That you they'll basically be able to hold the same basket of assets that they would otherwise and just earn a you know uh you know some extra yield um by performing this active service um with their their basket of collateral. 00:29:07.519 --> 00:29:13.200 Um so that's kind of how we think of uh capital efficiency with hop today and and hop in the future. 00:29:13.759 --> 00:29:14.319 Right. 00:29:14.559 --> 00:29:28.720 Um yeah, uh it's it's important to separate these liquidity providers because the the AMM liquidity providers, which we're accustomed to as as users, um, it's just that you're providing uh liquidity. 00:29:28.799 --> 00:29:43.759 And in the in the case of hop, that would be uh one side would be the canonical uh token, and the the other side would be the the hop version of the of the token so that it can be swapped one another at destination or or the origin. 00:29:44.720 --> 00:29:56.720 So uh the um so from here actually I I want to dig into like uh we we mentioned that bonders they they lock up collateral. 00:29:57.039 --> 00:30:01.359 And um so what is the let's let's play the worst case here. 00:30:01.440 --> 00:30:10.480 So a bonder he just mints a bunch of uh H tokens uh and sends it sends them to himself uh fraudulently. 00:30:10.559 --> 00:30:13.279 Uh such a transaction doesn't exist. 00:30:13.519 --> 00:30:16.160 And uh how do we protect it from this? 00:30:16.799 --> 00:30:30.880 Yeah, so so when when the bonder um mints a bunch of age tokens in the current model, since we haven't decoupled the like the collateral from the asset that's being bridged, they'll actually have uh an equal amount of uh that H token. 00:30:31.119 --> 00:30:45.680 So say it's dye, uh so they mint a bunch of H dye, they'll have an equal amount of H dye uh that was uh that is

locked up and collateralizing um that uh that mint or you know the completion of that transfer. 00:30:45.920 --> 00:30:58.160 And so if that was actually a fraudulent transfer, um when it's not a fraudulent transfer, their collateral is basically unlocked until they can prove that that H dye was burned at at the source chain. 00:30:58.319 --> 00:31:06.640 And so you know that that uh proof will that's what's actually gets uh propagated through layer one as part of uh of the batch. 00:31:06.799 --> 00:31:30.480 And so if they kind of bond something fraudulently and there never will be proof that that does reach the destination, um then their their HDI collateral will be um permanently locked up, and the bonder just ends up in a complete wash because they basically you know locked up HDI, they've minted an equal amount of H dye, and now that uh locked up HDI is is permanently locked. 00:31:30.559 --> 00:31:35.039 So they they ended up exactly where they would be in the system stays fully collateralized. 00:31:36.079 --> 00:31:40.160 And um yeah, that's that's that's great to know actually. 00:31:40.319 --> 00:31:49.039 So in terms of like trust assumptions, this is pretty much as close as you can get to uh Ethereum layer one trust assumptions, right? 00:31:49.200 --> 00:31:50.319 Um exactly. 00:31:50.880 --> 00:31:51.039 Okay. 00:31:51.599 --> 00:31:58.400 Um so when Hub Protocol, it um integrates with with many rollups. 00:31:58.799 --> 00:32:08.480 Um and each roll-up roll-ups don't necessarily like based on the implementation of the specific rollup, it can differ in terms of security, right? 00:32:08.640 --> 00:32:13.599 And also there is there's side chains that that uh hub protocol uh also supports. 00:32:13.839 --> 00:32:24.640 So in terms of the the risk here, uh am I as a user, am I exposed to uh to the weakest link here of the of the scaling solutions? 00:32:25.440 --> 00:32:26.480 That's a really good question. 00:32:26.720 --> 00:32:30.079 And so uh the answer is no uh from a user perspective. 00:32:30.240 --> 00:32:37.440 Um the the the bonders um are tend to be more at risk just because they touch more of the networks. 00:32:37.519 --> 00:32:43.359 But as a user, you're only exposed to the risk of um the networks that you're using and Ethereum. 00:32:43.680 --> 00:33:01.279 And so um what that means is you know, say you're on XDI uh and you're uh bridging to Polygon, um, then then you know you're you're subject to the risk of XDI, um, you're subject to the risk of Polygon and Ethereum, but not the risk of Optimism or Arbitrum. 00:33:01.680 --> 00:33:17.519 Um and so the the way that we do this is uh we we kind of track the um the H tokens that that you know so so user deposits say die into the layer one uh hop contract and then they're minted H tokens on um the layer two. 00:33:17.839 --> 00:33:30.160 And so we we track how many um H tokens are are minted uh for each layer two and and make sure that the H tokens that are kind of exiting that layer two can't exceed the amount that went in. 00:33:30.319 --> 00:33:38.400 And so that kind of uh silos or limits the liability any um single scaling solution uh presents to the rest of the system. 00:33:38.480 --> 00:33:59.039 Because, say, if the scaling solution were to go rogue and say um you know try to exit way more uh liquidity than actually existed on that scaling solution, um, then then uh this kind of mechanism would would just kind of stop it uh you know at the point where they they can only kind of compromise the H tokens that are on that scaling solution. 00:33:59.279 --> 00:34:08.079 Um and then the bonder role, uh, you know, they they are kind of uh facilitating transfers across um these different scaling solutions. 00:34:08.159 --> 00:34:15.599 Um bonders can choose to only um support uh just a subset of scaling solutions and they can limit their liability that way. 00:34:15.840 --> 00:34:21.280 Um but uh ultimately you know that they're gonna be touching more scaling solutions. 00:34:21.440 --> 00:34:34.320 And if they bond a transfer from a scaling solution that's gone road, uh there's a chance that that scaling solution doesn't propagate the proof uh over to the destination and they don't get to kind of unlock their collateral. 00:34:34.400 --> 00:34:42.000 So so that's how you can kind of think about the um the liability that that you'll face um when using hop. 00:34:42.079 --> 00:34:50.159 And so another point important note is that users don't end up with this, you know, wrapped hop token. 00:34:50.320 --> 00:34:52.719 Um they end up with the canonical token. 00:34:52.960 --> 00:35:01.599 So what you know you'll see with something like, you know, or what we saw with like, for example, poly network is is uh users were bridging assets to another chain. 00:35:01.679 --> 00:35:02.960 I forget what the chain was. 00:35:03.119 --> 00:35:06.800 Um but but the these were kind of wrapped tokens. 00:35:07.039 --> 00:35:07.760 What was it? 00:35:08.079 --> 00:35:09.360 I said no one knows. 00:35:10.079 --> 00:35:11.119 Yeah, yeah. 00:35:11.599 --> 00:35:17.519 Um and so users had this wrap token that was um produced by poly network. 00:35:17.679 --> 00:35:27.280 And and uh this is dangerous because users were kind of using this these wrap tokens on that network and not realizing they still had exposure, you know, risk exposure to the bridge. 00:35:27.440 --> 00:35:33.760 Um and ultimately a lot of those users lost their funds without ever kind of uh when they didn't realize that. 00:35:33.920 --> 00:35:48.079 With hop, uh you're going from one canonical asset to the next, you're only very briefly exposed to this um intermediary asset, which means that you only have risk exposure when you're making the transfer from point A to point B. 00:35:48.159 --> 00:35:51.599 And then the second you have funds on point B, you no longer have risk exposure. 00:35:51.760 --> 00:36:01.840 So uh if you're a user, the chances of of you

know using losing funds through hop are very, very low because you only have like a very, very short window of risk exposure. 00:36:02.159 --> 00:36:10.480 Yeah, this is this is like a great property to have for a cross-chain, cross-domain, any cross-domain messaging protocol. 00:36:10.960 --> 00:36:25.679 Um so just to break down here and sum up, users only get to have exposure during the time of swap, and bonders only get exposure uh in the uh in the scaling solution for which they provide liquidity. 00:36:25.840 --> 00:36:29.519 So um, yeah, that's uh that's that's great actually. 00:36:29.760 --> 00:36:43.519 So moving on from here, um I want to also have your maybe drifting a bit from Hop protocol, but talking about rollups specifically, I wonder your take about the uh the rollups. 00:36:43.760 --> 00:36:46.639 How how do you see the space to evolve? 00:36:46.800 --> 00:37:03.599 Like uh many giga brains are obviously working uh to onboard people into uh scaling uh scaling solutions, rollups, but um do you see uh any any potential resistance from users to to onboard to those scaling solutions? 00:37:03.840 --> 00:37:08.800 If any, what could be a what could be a concern concern there? 00:37:09.119 --> 00:37:11.679 Um yeah, that that's a good question. 00:37:11.840 --> 00:37:15.119 So I I'm you know very excited about optimistic rollups. 00:37:15.280 --> 00:37:25.119 I I think that's kind of the uh you know one of the better trade-offs in terms of um security and um and costs that we have right now. 00:37:25.280 --> 00:37:29.519 But the you know ultimately the the cost of optimistic rollups is still pretty high. 00:37:29.599 --> 00:37:39.679 You know, we we see kind of like uh it's like roughly 10% of what we see on uh you know mainnet Ethereum, and even 10% of what we see on mainnet Ethereum can still be pretty ridiculous. 00:37:39.920 --> 00:37:58.000 So I you know, I'm still still you know bullish on on chains like uh Polygon and and XDI where they don't necessarily uh you know share the same security level of Ethereum, but they do kind of allow these kind of use cases that even optimistic rollups today are are are pricing out. 00:37:58.079 --> 00:38:03.119 And and so these could be like you know, uh very small time users or traders. 00:38:03.199 --> 00:38:16.400 Uh this could be uh people that are playing games, um, where just like if they're they're playing with$10 of value, it doesn't make sense for them to be paying uh one or two dollars uh per transaction, which is kind of what optimistic roll-ups look like. 00:38:16.480 --> 00:38:37.920 Um that being said, if if a user is using DeFi, they have you know a large part of their you know net worth or even you know a portion of their net worth on um a scaling solution, it probably makes sense for those, you know, for that to be you know optimism or arbitrum where where we know that the security is is kind of matched by uh at the same level of Ethereum. 00:38:38.079 --> 00:38:42.639 And so

um, yeah, so I I think that there's gonna be room for both. 00:38:42.800 --> 00:38:46.320 There's gonna be use cases that that kind of um shake out for both. 00:38:46.480 --> 00:38:51.599 Um and then in the long term, I think uh ZK rollups are are uh really, really interesting. 00:38:51.679 --> 00:39:00.159 Um we we've kind of seen, you know, I I think like looking back in kind of the history of uh scaling solutions, we've seen how important it is to be EVM compatible. 00:39:00.239 --> 00:39:06.559 So like we saw like uh plasma, people trying to build application, you know, application-specific plasma implementations. 00:39:06.719 --> 00:39:11.920 We saw um state channels and generalized state channels and like games to start playing out there. 00:39:12.079 --> 00:39:24.960 Uh, but but you know, the second we kind of saw EVM compatible uh scaling solutions where we could just use the same tools, the same development tools, that you know, uh we could just point block explorers at them and they just work. 00:39:25.039 --> 00:39:33.920 Uh, that's where we've kind of really seen this explosion of activity on on scaling solutions, you know, as well as kind of non-ethereum uh EVM chains. 00:39:34.159 --> 00:39:39.519 And and so like I really think that that's where ZK rollups need to ultimately get. 00:39:39.599 --> 00:39:42.559 Um, but it's a really, really difficult challenge. 00:39:42.800 --> 00:39:47.760 Um, you know, that there's a people that much much smarter than I am that are working on this challenge. 00:39:47.840 --> 00:40:11.920 So, you know, excited to kind of see where those kind of develop because I think ultimately that that is kind of the holy grail, is the EDM compatible uh ZK rollup where where the exits are instant, uh the level of scalability is higher than what we can achieve with optimistic rollups, and and yeah, that that's kind of um the ultimate uh scaling solution, I think. 00:40:12.320 --> 00:40:14.559 Yeah, thank you for sharing your thoughts. 00:40:14.639 --> 00:40:27.599 And in that world where uh in that imaginary world where ZK proofs are so efficient and then we checkpoint every like uh frequently, uh then would hop evolve into something different? 00:40:27.760 --> 00:40:36.960 Um because because now like uh providing like fast, let's say uh fast exits is kind of uh loses its benefit, right? 00:40:37.280 --> 00:40:38.079 Yeah, that's right. 00:40:38.159 --> 00:40:58.079 And and I actually I don't think hop would would kind of evolve into something different because we so we see fast exit as like our big market today, um, but ultimately we see the real value of hop uh is kind of enabling these layer two native users where where they can just move directly from one layer two to the next and they don't have to kind of touch uh layer one at all. 00:40:58.320 --> 00:41:10.880 And so um while while yes, hop does kind of solve this fast exit problem, and and that's very, very needed today, that that is kind of like the the um

one of the main benefits of hop today. 00:41:10.960 --> 00:41:25.920 Um even in a world where where there is no long exit times and you can exit a ZK rollup immediately, um, exiting a ZK rollup to move to the next rollup is still gonna cost$100 today or hundreds of dollars today, could cost thousands of dollars in the future. 00:41:26.079 --> 00:41:33.760 And so we still uh you know see huge benefit for users to be able to move directly from one ZK rollup to the next uh using something like that. 00:41:34.880 --> 00:41:35.840 I see, I see. 00:41:35.920 --> 00:41:42.320 And also there is the uh there's there's the area of like uh just cross-chain messaging, right? 00:41:42.400 --> 00:41:48.719 It's not it's not only a value transfer, ultimately, they have to talk to each other ideally. 00:41:49.199 --> 00:41:51.760 But I I also wonder your take take there. 00:41:51.920 --> 00:42:08.000 So when when one rollups communicates to another, if if there is no bonder to to to front liquidity immediately, uh as it is right now, then the communication would would still be delayed with the with the L1 uh finality, right? 00:42:08.079 --> 00:42:16.320 So in Ethereum you need to wait so many blocks, uh depending on the the the amount uh let's say involved. 00:42:16.480 --> 00:42:25.519 But uh so it's it's not like we're we have this full composability that uh Ethereum L1 has today. 00:42:25.599 --> 00:42:29.360 Do you do you think that could be a um potential problem? 00:42:29.519 --> 00:42:31.679 How could that be mitigated? 00:42:31.840 --> 00:42:33.679 Um yeah, wonder your toss. 00:42:34.000 --> 00:42:36.559 Yeah, yeah, it will definitely be a challenge. 00:42:36.719 --> 00:42:51.280 So so kind of in in terms of um you know cross-chain messaging and and composability, uh, we we kind of see this move from you know a synchronous paradigm where where uh you know each contract can just kind of talk to other contracts. 00:42:51.360 --> 00:43:01.599 Uh each each transaction is uh completely atomic, where if if you know the transaction reverts anywhere along the way, uh the entire thing um is unwound. 00:43:01.679 --> 00:43:33.840 Um and then we're moving towards uh this like asynchronous paradigm where where you know now we have uh kind of you know the transaction starts and then and then uh there's like different um times where we wait, uh and then you know uh the transaction is completed at a later time, and you also lose that atomicity of the transaction where you know, say the the transaction reverts at you know during the second part, uh you can't necessarily unwind the first part because they they're kind of happening at um different times. 00:43:34.079 --> 00:43:38.559 And and so this, you know, this kind of presents a challenge. 00:43:38.639 --> 00:43:51.119 I I wouldn't say that it's necessarily a very bad thing, uh, but but uh you know, you have to kind of deal with the problems that come with this uh asynchronous communication. 00:43:51.280 --> 00:43:59.199 And and so the way we kind of think about uh the trust model on layer one Ethereum today is is you know, you you have this um this. 00:44:00.400 --> 00:44:03.119 From one contract to the next, it happens immediately. 00:44:03.360 --> 00:44:14.639 And then it's also like an owned um, it's like an owned message where you can actually see who sent it and uh verify that um in absolute terms. 00:44:14.800 --> 00:44:21.039 And and so with uh cross-chain communication, uh it kind of breaks up into two kind of two trust models. 00:44:21.119 --> 00:44:31.199 And and so one of them is where you can um communicate from one uh contract on one roll-up to the next roll-up um immediately, but that's not like an own message. 00:44:31.440 --> 00:44:33.199 You can't actually verify who sent it. 00:44:33.440 --> 00:44:37.519 It's more or less just you know triggering a meta transaction at the destination. 00:44:37.679 --> 00:44:42.960 Um, but this can still be very useful, especially if you can attach uh tokens to that message. 00:44:43.199 --> 00:44:58.639 So um, for example, someone could you know send USDC through hop uh to the destination and trigger um some functionality that that deposits it into um you know a vault contract uh with you know a specific owner address. 00:44:59.039 --> 00:45:04.480 And you know, that we don't need to verify who sent the funds, we just need to verify that funds showed up. 00:45:04.559 --> 00:45:10.239 And and so you know, we don't that you know that type of communication is fine, it can happen pretty much immediately. 00:45:10.320 --> 00:45:14.960 Um and then there's this kind of second type of communication where we actually need to verify the sender. 00:45:15.280 --> 00:45:21.599 So to clarify, that is the case where the transaction uh involves some token transfers, right? 00:45:21.679 --> 00:45:25.679 It has the token, so you don't bother with any further information. 00:45:26.400 --> 00:45:27.599 Is that why so? 00:45:28.320 --> 00:45:29.199 Yeah, exactly. 00:45:29.360 --> 00:45:52.960 Yeah, and and um yeah, and and for for most use cases for this type of communication, there there would need to be some token attached, um, unless you just want to kind of you know uh kick off some process or something, you know, it there's easier ways to do that than uh cross-chain um, you know, cross-chain call, uh you know, unless there's tokens attached. 00:45:53.519 --> 00:45:58.480 Um and so this other type of communication is that that's where things are really delayed. 00:45:58.559 --> 00:46:08.159 And so so this is where uh we actually need to verify who sent the um transaction at the um you know at the source. 00:46:08.320 --> 00:46:16.559 Uh and so for that to kind of fully verify uh who sent it, we actually need to wait for the exit time of the source uh roll-up. 00:46:16.800 --> 00:46:36.320 Um and then that will, you know, and then once it reaches the destination, then we can know in absolute terms that you know it

was sent from you know this address with uh on you know this roll-up, and then you know, that could be used for something like withdrawing from a vault that that is owned by a cross-chain owner or you know, on a different scale solution. 00:46:36.480 --> 00:46:40.719 Um so yeah, that's kind of how we think about the two two different models. 00:46:40.960 --> 00:47:15.840 Um and so I and so Vitalik actually released a really interesting paper on on doing um cross-chain NFTs that that um and it and he he has a very interesting twist on the second model where um, and it, you know, it's it's you know, Hopp has kind of a similar twist for for uh ERC20 transfers, where basically you complete it immediately, it can be verified off-chain, uh, and then it isn't until it can be verified on-chain uh that that um you can like you know completely uh release the collateral. 00:47:16.159 --> 00:47:16.719 Like settled. 00:47:17.039 --> 00:47:18.320 Yeah, exactly. 00:47:18.559 --> 00:47:37.039 Um so with with with the his proposal, you basically um can can transfer an NFT from one source chain, um, mint a kind of claim to that NFT at the destination, everyone can verify that off-chain, and then it's not until it's verified on-chain that it's kind of like uh completely settled up. 00:47:37.199 --> 00:47:50.159 So um it kind of shows how you can get around the constraints of this uh this asynchronous communication and and these uh long exit times without significantly damaging the the user experience. 00:47:50.639 --> 00:48:02.800 Okay, that that's very, very interesting because like almost all in almost all cases, NFTs cannot be ported over bridges uh due to due to their unique uniqueness. 00:48:03.280 --> 00:48:09.360 I mean the this uh yeah, this talk was like super insightful uh in my in my opinion. 00:48:09.440 --> 00:48:22.559 And uh when you think about it, like if a bunch of roll-ups exist, eventually there will be a cross uh roll-up uh communication, a cross-side chain as well, communication in the Ethereum world. 00:48:22.719 --> 00:48:29.440 But moving on from uh Ethereum world, do you what's your take on uh L1 versus L2s? 00:48:29.679 --> 00:48:39.519 Uh there we see a bunch of uh L1 uh uh projects also uh running EVM chains like Avalanche, for instance, and and and others uh as well. 00:48:39.679 --> 00:48:42.880 I mean, uh Solana is is doing great stuff as well. 00:48:43.119 --> 00:48:46.960 So so yeah, how do you see this competition to to to move on? 00:48:47.039 --> 00:48:50.800 And can Hop eventually support other chains as well? 00:48:51.440 --> 00:48:52.880 Yeah, that's a great question. 00:48:52.960 --> 00:48:57.760 And so yeah, I think it's undeniable that we're headed to this multi-chain world. 00:48:57.920 --> 00:49:06.960 You know, like like we're both seeing Ethereum kind of scale on its own layer two, and and then we're also seeing, you know, like competing layer ones popped up, like like you mentioned. 00:49:07.119 --> 00:49:26.480 And those kind of also provide uh, or they also are like cheaper environments because they they either you know make different trade-offs or or you know, they're also just you know less congested than what Ethereum is today, and and that kind of you know unlocks use cases that just aren't possible on Ethereum today or allows you know smaller users to interact. 00:49:26.639 --> 00:49:30.960 And so, yeah, I I think it's undeniable that that's that's where things are headed. 00:49:31.039 --> 00:49:34.639 We're we're seeing you know chains like Solana get get serious traction. 00:49:34.800 --> 00:49:46.239 And so, you know, we we definitely want to support bridging um across uh you know not just Ethereum's uh scaling ecosystem, but but also to these disjointed layer ones eventually. 00:49:46.559 --> 00:49:49.039 And there's a few ways we can do it. 00:49:49.119 --> 00:49:59.599 So so uh you know, like we talked about, uh, you know, hop very much relies on the cross-domain messaging uh between Ethereum and whatever scaling solution we're we're supporting. 00:49:59.760 --> 00:50:11.519 Um of these, and it and so when we think about risk of a user on a scaling solution, um that they uh they they're subject to the risk of that um scaling solution, and then also its bridge. 00:50:11.599 --> 00:50:14.480 And and so with with roll-ups, those are one and the same. 00:50:14.639 --> 00:50:22.320 Uh and and and then also with uh you know chains like Polygon, they're they're you know pretty much one and the same as well. 00:50:22.480 --> 00:50:35.920 Um but some of these uh kind of more disjointed layer ones um have introduced uh messaging bridges with Ethereum and those might have different um trust models uh that they introduce. 00:50:36.000 --> 00:50:53.280 And so we we could tech, you know, we could support these disjointed layer ones, and uh they would basically be subject to whatever uh the trust model of the messaging bridge is, um, as well as you know, the the uh security of of that chain itself. 00:50:53.599 --> 00:50:58.960 Um so this is one option that we see, and uh that that option is really available in the near term. 00:50:59.119 --> 00:51:34.880 Um and then another option uh that that's available or or that we we um will likely head towards um in the future is you know, for chains that don't even have a messaging bridge with Ethereum um today, uh, we could actually create one and and you know uh possibly um you know create our own uh messaging bridge and and our own you know this would likely involve introducing a new validator set that that um approves these messages and and um that would you know kind of allow us to bridge to completely disjointed uh layer ones. 00:51:35.440 --> 00:51:36.400 Yeah, got it. 00:51:36.559 --> 00:51:45.679 Yeah, I just yeah, the the the bridges is is quite complex and so it's a very uh open open design space. 00:51:45.840 --> 00:51:52.079 And uh um we're it seems like we're uh using them more and more more now.

00:51:52.239 --> 00:51:54.559 Uh and it's it's gonna keep increasing. 00:51:54.639 --> 00:51:55.679 So yeah. 00:51:56.239 --> 00:52:11.519 So uh it's um so I I think this this was a great conversation, and uh we we've covered uh I think almost all important properties of protocol, and I'm super, super excited uh about Hop. 00:52:12.000 --> 00:52:17.039 Before we uh close out, uh I have to ask this question, and it'll be the short one. 00:52:17.280 --> 00:52:18.320 When token. 00:52:20.719 --> 00:52:32.159 Yeah, I I can't uh say much, but um you know we we would like to kind of further decentralize the protocol and and and so we are kind of exploring ways that that um we can do that. 00:52:32.719 --> 00:52:41.119 Okay, so the details around the token is is I assume are not um uh let's say publicly disclosed at this at this point. 00:52:41.440 --> 00:52:42.320 Is that correct? 00:52:42.639 --> 00:52:46.320 Yeah, we we we're still kind of uh figuring out which which direction we'll take. 00:52:46.480 --> 00:52:47.199 Um yeah. 00:52:47.599 --> 00:52:48.800 Got it, got it, got it. 00:52:48.960 --> 00:52:51.519 Okay, Chris, thank you very much for joining. 00:52:51.679 --> 00:52:53.119 It was it was a great pleasure. 00:52:53.440 --> 00:52:54.480 Thanks for having me on, Karen. 00:52:54.719 --> 00:52:57.440 It was a great conversation and yeah, I really appreciate it. 00:53:04.079 --> 00:53:08.000 Before we go, we'd like to thank our sponsors for making this episode possible. 00:53:08.320 --> 00:53:16.480 With a proven track record of delivering products safely, the Kava platform is DeFi's most trusted, scalable, and secure institutional grade cross-chain engine. 00:53:16.639 --> 00:53:31.679 In addition to the protocols Kava and Hard, the Kava platform is launching Swap Protocol, a cross-chain AMM liquidity hub bridging DeFi, blockchains, and financial services to swap the world's largest assets and maximize yields across your entire portfolio. 00:53:31.920 --> 00:53:35.199 Try for yourself or learn more today by visiting kava.io. 00:53:35.760 --> 00:53:43.199 Cello is an open platform for mobile first DeFi with the vision of bringing decentralized financial tools and services to anyone with a mobile phone. 00:53:43.440 --> 00:53:57.280 Eco-friendly, Ethereum compatible, and governed by Cello holders, Cello's proof-of-stake consensus mechanism and automatic daily carbon offsets make Cello the world's first carbon-negative blockchain offsetting over 2200 tons of carbon to date. 00:53:57.519 --> 00:54:04.079 To learn more about how to lend, earn, and stake with Cello's growing family of platform-native stable coins, visit Cello.org today. 00:54:04.400 --> 00:54:06.719 Hey everyone, thanks for listening to the podcast. 00:54:06.880 --> 00:54:13.679 If you enjoyed it, please support the show by hitting subscribe on iTunes, writing a review, or sharing this episode on Twitter and LinkedIn. 00:54:13.920 --> 00:54:16.559 Stay tuned for our next episode out soon.