[trustless://interop.landscape] Panel - Interop protocols: who do you have to trust?

Transcript

Thank you so much for being here a day two of trustless conf. We have talked a lot about trust. Does it creep in into Ethereum? Does it align with its values? Is it something that is good or is it hurting us? Our next panel is fully fully packed with builders who will take on these questions and more. I'll introduce them one by one. Please welcome to the stage Frederick Yav Weiss Hart Lumber [music] Bartek and Peter Watts. Everyone down? Good. Okay. Yeah. Hey

everyone. Uh so in this panel we're going to be examining what trustlesses actually means in crosschain systems. Basically specifically when a user bridge or transact across chains what entities do they have to trust beyond Ethereum itself. We will compare various optimistic relay based and proofbased approaches and evaluate whether intermediary free execution is uh achievable in practice. But first, I would like uh everyone to give a very brief introduction about who you are and uh what you do.

>> Um so I'm [clears throat] I'm Bartk. I'm founder of L2 beat. Uh we're kind of like a community uh watchdog. Uh right now mostly for L2s. Uh however uh and we are policing these L2s to uh first of all um uh be honest with the community about the trust assumptions uh and uh second of all um progress towards what we believe should be a northstar for everybody which is a trustless uh setup. uh our goal uh and the reason why I'm on this panel is because we want to do the same for the interop.

>> Hi, um is this on? Uh hey, Peter from Relay. We do instant crosschain swaps uh with a big focus on UX and being extremely fast, extremely cheap on as many chains as possible. Uh yeah. Hi uh Yavai is from the Ethereum Foundation. Uh so I've been working on security research account obstruction and uh lately I've been building EIL the Ethereum interop layer which is also an inter interop solution focusing on uh focusing on making things trustless while offering a great UX and low latency.

And hey guys, I'm Hart Lamber from Across, co-founder of Across. And um we uh we build a intentbased crosschain bridge that also like Peter tries to have fast and cheap uh uh actions between blockchains um with the goal of kind of unifying Ethereum, making it feel like one chain again. >> Cool. Yeah, I'm uh I'm Frederick. I uh am part of the protocol security team at the Ethereum Foundation. I also do a bit of the trillion dollar security initiative and uh am a huge fan of trustlessness. So to level set I would want each of you to kind of give your definition of what trustnesses is can do in a sentence or two basically not have

to be super but uh yeah Peter would do you want to start like when is a crosschain transaction considered trustless basically. Yeah, I think there's kind of there's many angles to it. So, you know, even just holding a um you know, there's there's the level of trust around when you hold a token on an L2 um or if you're holding a stable coin, the kind of who has the ability to mint and burn that is some level of trust that you are kind of continuously uh under. And then when you have kind of intent protocols like the the kind of three of us are building uh or like effectively

cross-chain swaps, there are the the actors kind of involved in making that swap happen. But even there's kind of interesting things to consider of are you do you need to trust someone to not steal your money? But then there are like other factors of do you need to trust this uh intermediary to not kind of grief you and just uh kind of not do what they were going to say and and maybe even like levels in between of maybe you have a minimum output of what you want and and like a concept of slippage and do you need to trust them to give you the the full amount that was possible based on the market rate versus the minimum out. So yeah, I think the thing I would add to the conversation is it's it's it's kind of not a binary.

there are these different um kind of factors on which you care about it kind of not needing to trust someone and you know I think we we can all agree not needing to trust someone to not steal your money is is pretty important but then there are these kind of other things which I think uh the EIL kind of really you know is like a great solution on not needing to trust anyone for anything and I think that's kind of part of the conversation of like is a is a little bit of trust okay in you know for example uh kind of will someone do it or will I just have to you know you know will they grieve me or not and and the kind of odds of that happening. So yeah that's my take.

>> So >> well actually I think yo I'm going to give your definition from I think the panel yesterday. Um I think you said I don't know I think this was you. It's like u if you can hurt somebody here. I like this definition. Um you know trust trust something is trustless if you can't hurt the person. Um I and I think um breaking it down in our space is like can the user get hurt? Can they have their funds stolen, taken away? Um and then in some of our designs, there's another aspect of like maybe a more professionalized actor like a solver.

Can they get hurt or reorked or not repaid? Um but I don't know if I stole your your answer. Yeah, I can elaborate a bit, but yeah, this is exactly what I said. That is uh that when you're trusting someone means that basically they can screw you over in some way. So um so so then being trustless is not putting yourself in a position where someone can do this to you and uh it's um and this means both the user so like uh does the user need to trust anyone which I trust anyone other than the existing trust assumptions because we already have some I mean you trust you trust the underlying networks if like if if the underlying network is going to

rug you the inter protocol cannot help you but being trustless means not adding new trust assumptions beyond the absolute necessary which is the underlying chains or in the case of Ethereum you can trust L1 as well as the L2s because that's where they settle. So to me that's uh to me that's trustlessness. So maybe I'll take um maybe more uh technical angle here because uh otherwise I will repeat everything. So back in the days uh and I've been in this space for like nine years. We were obsessed uh in building trustless and permissionless systems. Uh and for me trustless was all always uh about removing intermediaries right you know

we were talking about this intermediation and we thought that you know everything can be done by uh smart contracts. So I trust code but I don't trust people right that run that code. uh turns out that you know sometimes I do need certain intermediaries like relayers like offchain actors in which case I need the system to be set up so it's permissionless right so that anyone can actually play that role and then I have trustless and permissionless and in such a setup um no one can hurt me essentially right that's the idea uh so that's like one side of a spectrum uh the opposite side of a spectrum is that you know I need to trust an unknown

entity. Uh which in traditional world we would all think that this is a crazy idea. No one would give $100 to a stranger uh and let that stranger walk away with this money promising us that you know they would come back with some goods no matter what it is. Like we don't do that you know like it's a common sense and yet on blockchain we seem to be doing it all the time you know. So for me like there's trustless and permissionless which is what we should all build eventually then uh you trust unknown entity and maybe somewhere in the middle you have to trust like maybe some I don't know security council of a known entities and whatn not and we

go into this complex discussion of uh reputational based trust right uh where you do have to trust someone however you know they have reputation to lose and you know what they are and maybe you can sue them and it's like you know it's kind of in between. >> Okay. Yeah. So um I think the intermediary part is a very good and interesting question here like uh if you think of it from uh across and relay um what kind of intermediators do you see like what what intermediators do you have and what can they basically do?

>> Yeah I think there's effectively two layers. you have solvers or relayers um however you want to kind of define them that are responsible for filling the crosschain order and then you have uh an oracle uh that is verifying what that happened and there's there's kind of various different forms of this um and I think an older version of of uh kind of relay worked a little bit differently but the the kind of version that we're working towards is actually kind of very similar to other intent protocols where the the kind of user is locking their money in the origin. A filler, a solver, a relayer is filling and then the oracle is kind of verifying that the fill

happened correctly. Um, and so they're kind of the two main actors and uh yeah, you you want to get to a place where you don't need to trust that uh kind of filler to uh fill your money, but there is some level of trust in that oracle and the robustness of that uh oracle. Um and yeah, so that they're kind of like the two two main ones. >> Uh can you just ask a quick follow-up question like what is the difference here between V1 and W2 uh with regards to relay? Yeah. So for relay we we kind of came out with this design um where in order to really minimize gas uh so like this idea that the kind of classic crosschain intents is you you lock money

in escrow and so the solver doesn't get paid until they prove that they've delivered uh on the destination and then they can go get their money. Um, and so the the kind of v1 early version of relay was you could instead have relayers be kind of staked and subject to some sort of slashing. Um, and and therefore you could send directly to the relayer. Um, and that would save on gas because you're not having to go through this process of saving it in a contract and then uh unlocking it. Uh, kind of pretty early. We there's a ton of issues with this original design and we did not even kind of build out some of the slashing pieces and we migrated to uh kind of more of a traditional lock in

escrow. But you know even within that there's like different ways that you can do that and and we're always trying to push uh kind of how you can minimize the onchain footprint and be as kind of low cost and fast as possible. But yeah, that's the primary difference. And so now now we look a lot more like kind of all the other protocols although there is different ways of doing it kind of like the the EIL um that maybe doesn't need an oracle at all except for uh like yeah more of a slashing model. >> Okay. Um I I've known Peter a while. I like Peter. I'll just caveat this. I think Peter is a trustworthy guy. He deserves trust. Okay. Um but I just because there's kind of this elephant in the room. Peter, we'll just like get

this all on the table. Like Relay is a centralized and trusted system today. Um the original version of relay uh sends funds directly to the relay solver EOA. So you're sending funds to an EOA and you're hoping they come out on the other side. And I think that is as trusted as it can get in my opinion. Right. in the version you have right now, which I think is a it's it's you're sending funds to a contract that is controlled by relay with an oracle that's controlled by relay. So, I don't think yet anything has changed. Just so we're being like super clear and transparent and I think that's okay, but we should just be like clear about it.

>> Yes. Yes. These things are work in progress. >> Okay. >> Yeah. So, that is a decision that you guys made. I think it's strategic and I actually to relay's credit um I do think on their doc site they they say this and you guys actually reference us too and like I I feel like there's a degree of there's can always be more transparency right but I feel like uh I don't feel like you are purposefully trying to like pull the wool pull the wool over something here I appreciate that um I also appreciate what you guys say about us and it's like all kind of nice so that's all cool but I think relay is a trusted design today so Frederick to answer your questions in across we did develop this over many years now.

Um and um we for better or for worse we actually really do try to make this thing be permissionless and trustless and have done from day one. Um which was really hard to do three years ago in particular. Um, our idea here is actually not just that like trustless is nice to have, but we actually do think it can make a better product because I think solver competition um is actually ultimately going to give the users better fills and a better experience here. So, a little bit goes to Bartk's point here. We talked about intermediaries where our view is you want to define the rules of the game on the blockchain and those are like enforced and unbreakable and then you

have open competition amongst these uh permissionless intermediaries to fill users. Um, so our system is permissionless today. Always has been from day one. Anyone can spin up a relayer. Occasionally we get attacked on Twitter for saying it's like all our relayer and that's just not true. I actually looked at the stats today. Our relayer does 14% of the transactions uh uh over the last 30 days. So we're not the biggest. There are others that are far bigger. Um, we do do some of the higher volume transactions, but even then there's good distribution. So it's permissionless relay. Um and we take a lot of effort to have a settlement system uh that anyone so the settlement users don't uh have this trustless

settlement system and any solver anyone on the network in particular can disagree with our settlement logic in this optimistic itself. Um yeah so I don't know if Craderick that answers your question but those are the kind of intermediators in our structure. >> Yeah. So in a cross you have these fillers. um that from my understanding are there to basically front capital. Do you see them as intermediaries or basically UX? >> Yeah. Um I mean I think we filler we should just semantics filler relayer solver. Um I'm going to use them all interchangeably. I don't know Peter.

Okay. So yes. Yeah. >> XLP. >> Yeah. Yeah. There's there's maybe a little difference there but I will go there but >> yeah the XLP never transacts on your behalf so it doesn't uh so it doesn't act as a solver relayer it only turns out to the source chain only to give a voucher but um what I I wanted to uh I wanted to ask so since uh I at least in the past when I read when I read the code and document it seemed that there were there were additional actors so it's a slightly more complicated protocol and like solvers/relayers fers like they are uh they are not the only entity if I call correctly or so what other entities are there like which ones

of them are permissioned or I mean or are all of them permissionless now >> so in terms of billing the user so just to answer the question then Frederick we'll go back to your your answer uh in terms of filling the user it's just the solver filler fills the user uh in terms of running our settlement process there is an offchain process to uh batch all the settlement instructions and propose that optimistically. Um, we call that a proposer function. Um, and then the any there's a disputer function where if you disagree with that proposal, anyone can dispute it. So those are functions that are in the settlement of repaying solvers and fillers. Does that answer your question?

>> Um, yeah. So, so these are so these are all the entities in the system if I understand correctly like the I mean all the actors and uh they are all and they're all permissionless, right? Right. So like you could replace uh any of them. >> The so the proposer function was permissionless. We've locked it down for our own um peace of mind uh a little bit. Um but it's something that is uh updatable by governance uh permissionlessly updatable by governance. >> It's a little bit of an in between thing just to be totally clear and it's something that um you know we wanted to make sure that this aspect of our system for safety reasons was safe. But the dispute function has always and will forever be permissionless. So there's um

no ability to push through of that answer. How do you how do you prove in the in the dispute mechanism uh since it's a permissionless how do I uh so like how do I prove something like if uh if the execution if my intent was not fulfilled as expected and I want to dispute it uh what is the process like and who gets to are there any permission any uh any trusted actors there or is there a way to prove it uh trustlessly? >> So this uses this is goes back to our design from three odd years ago. It uses the Yuma protocol, the same thing Poly Market uses to prove uh who won an election. Um it uses that same design principles which is all

based off of Metallic's 2014 blog post Shellingcoin too. So it's getting in the weeds. Um I will say that uh and part can maybe talk about this too. In the most recent version of across we are using succinct ck proofs in a part of that system and there's actually a path where we can do that entire proof function um with this CK proof which would be really cool um just more work to do on that. >> Cool. So so you are in the path of like a like if you want to remove Uma from this protocol and only use a sync would that uh so would that work?

It requires a little bit more engineering work, but yeah, >> it's something that um you know that wasn't possible just from ZK proving costs like maybe even six months ago. Um or we're pretty close with the sync team. I think it's pretty cool. Um and some of the things that we can talk about with the EF is like I do think like a ZK messaging layer embedded into uh Ethereum is super valuable. But yeah, Peter sorry. Yeah, I was going to ask like to dispute one transaction, do you have to dispute the whole batch and verify every transaction on every chain and across?

>> Correct. >> Yeah. >> And uh can you mention a bit more about the UMA protocol like how how that works and um are there any risks around from my understanding there's a token that's being used to kind of vote? Uh are there any large whales that could like change that decision in a way that maybe it shouldn't be etc. >> Yeah, we're doing a real technical deep dive on uh but uh if we want to go to the game theory the human protocol it is my favorite thing to talk about Frederick I'll keep it concise for a second. uh shelling point design the way you think about it is it's at core there's two layers and optimistic oracle is what we call it y of it's not dissimilar from actually the design in

your um in the eil where there's a challenge response game um so somebody proposes something is true there's a challenge period it gets accepted as true if nobody disputes it there's economic consensus around that um if a dispute happens it gets escalated to this uh shelling shelling point voting system where token holders with stake tokens uh vote on what they think is the true outcome here. Um token holders that vote with the majority get rewarded. Those that don't get slashed. Um uh and the game theory behind this, which I could go super deep on, is that the token holders are incentivized to vote their their their version of the true outcome. Um and that's partially because if the system breaks, their token value

is worthless here, too. Um, the UMA token distribution is actually shockingly distributed because it's been around for six plus years. Um, although on Twitter we occasionally do get FUD that say that there's like big whales that control the outcome, but I don't actually think there's evidence of that. So yeah. >> Cool. Thanks. Um, going back to Bartekch, I wanted to ask about the, uh, L2 beat, how you kind of measure this and, um, the topics that we've been discussing now. >> Um, yeah. So, so actually um I want to kind of address the elephant in the room here because you know the way we would see let's say like from the external observer uh like L2 beat um I would say

that the current version of relay is like I have to trust Peter right um with y um eil uh it's fully trustless even though it's not yet in production so you know there's hope I guess and across is somewhere in between with this complicated um and what not you know but this is pretty cool um but let's uh have a look at um not just uh what are the intermediaries but uh which system is actually being used right now by the users and like we've looked at the chain and relay is like amazingly successful protocol um is integrated everywhere

ware and a lot of integrators uh while giving a choice to the users, hey, you can choose the cheapest and the fastest, it would always go for relay because it's like super simple. So, it seems like either you're trustless, slow, and expensive or you're like super cheap, fast, and trusted. And end users would almost always go for the latter. um as witnessed by the amazing success of a really protocol. So my question now is if we all want to go trustless as you have guys declared how do you remove yourself from the market you know that's my question how do you how do you what

do you say to LiFi for example to remove uh this functionality they they're not using your smart contracts they are sending money straight to your way right and they should because you know there's not even an event for us to analyze that and I'm shocked that you know that's what they do but I fear that they do it because it's cheaper and it works, right? How do you remove yourself from the market since you're so successful, Peter? >> Yeah, I think it's actually not true that you have to choose. And I I think that it's more of like a a timing and what we prioritized first and in terms of prioritized building a product and understanding what people wanted and

what were the things that were important such as the ability to quickly expand to chains and like sensitivity to price and and kind of latency and even what are the biggest pain points for a solver around capital efficiency and rebalancing and all of these things. And so, you know, I think it's it's definitely correct to put the the kind of pressure on us and we kind of are on this path and I actually think you can make it trustless uh without, you know, a dramatic change in the cost and that's that's the path that we're on. I think we're not going as far as as the EIL in terms of trustlessness, for example, not having to trust that, you know, the relayer you're using. uh they could just you know so our design for example and

this is like a good point you have you choose a specific relayer and you have a a relationship with them versus this kind of competition uh of relayers where anyone could do it and one of the reasons we do that is it provides a much better experience to kind of have someone who's going to do something for you so that if they don't do it well well one example is sometimes things are unfillable and when they're unfillable. If you have an exclusive relayer that you are working with, they can refund and kind of like undo it extremely quickly versus needing to wait maybe an hour to kind of like for the thing to expire and then you can go get your money back. And so that is a choice we've made that can really improve the

UX in the happy case, uh, you know, which is 99.99% of the time. And then there's the unhappy case where maybe that is worse off because we didn't have an open competition for that order. Someone else can't step step in and fill it. But actually, you know, yeah, which which do you optimize for, the happy or the unhappy? And if you're building a modern kind of consumer product, you kind of have to uh optimize for the happy case. And uh and so our model is more of a similar to RPC, which I know some people don't like either, that you know, you're using QuickNote or Alchemy, but the thing is that if if you're unhappy with one of them, you can go to another one.

And that's our goal to build out kind of a market that you can choose from, but you are actually choosing. And and so then you can also have other levels of trust that I think are okay for example around slippage and so like I think we all agree that like the ability for a solver relayer to steal your money you know we don't want that uh but if there's some like range of outcomes because you are they are maybe executing on a dex for you and there needs to be some level of trust around whether the solver will give you know your minimum output or kind of like the market rate. these are kind of tolerable uh trust to have in the system where the the cost to the relayer if they abuse that is kind of loss of future order

flow and and so yeah I think that's how we think about it which is we are reacting to products that are in the market that are trying to grow that are trying to build delightful user experiences uh and like definitely kind of I think uh you know got ahead of our skis in in a in a few ways of some of the pieces we wanted to build that aren't fully built yet. But at the same time, yeah, you know, we've just kind of come from that angle and and yeah, I think to to close it, we can actually, you know, again going back to what I said at the beginning because it's a swap, I think, you know, and versus like the, you know, and as soon as that swap is complete, the kind of trust assumptions stop. I think it is actually possible to do it in a very

costefficient way and have enough trustlessness in the same way like when you get in a plane, you know, the the safety is less than in your home, you know, but you know, you're in that plane for a short amount of time and it's a worthwhile trade-off for the utility of going from A to B. And I think that's how we think about it, which is we want, you know, the the right amount of security and trust uh in order to deliver really good UX because that's kind of what needed. And then yeah, I think the last thing is allowing the the kind of core layer around how tokens are bridges. So whether that's the L2 native bridges or third party bridges for that to be as secure as possible and then allow people to opt into this fast

interrupt layer on top. Can I like respond to that uh and have a question for heart as well because you know I want to share my uh personal experience which might actually not be that different from others people experience. So we uh had a need to move uh some of our treasuries funds from one chain to to another and we decided to to use a cross actually. Um so we tried with a small amount it was like super fast, super quick, super efficient and then we moved uh significant amount right uh and by significant I'm talking I don't know like one month of salary of you know the whole company or something you know like for us very significant and nothing happened. So we were waiting and waiting

and waiting and maybe after half an hour I thought like hey I need to review the L2B rating and I need to find out you know if actually if they don't you know like fill our order I can walk away right uh so I went back to our own assessment um and then I figured you know if I'm going to wait for another hour I literally thought about DMing you hard about that because I did not know you know and and I'm professional right you know and I can DM you as opposed to like people, you know, from the other side of the world. Um, so, so I wish, you know, at least I should be able to walk away if my order wasn't filled without actually having to

DM every or heart or anyone really, right? You know, that's like the bare minimum for me. And maybe I should have known better because the amount was significant. It's just that, you know, this is what happened literally to us. And I can only say that the the the the dread the the pressure is mounting with time you know when you don't when you're not on the other side you're like hanging somewhere in the middle and and and yeah and this is not very comfortable experience right u so uh so I hope that you know you guys will work towards you know systems where if my order doesn't get filled because like let's say it's too big and um you know I should be able to permissionlessly walk away right

>> agreed Yeah. And you can, right? But uh yeah, I'm sorry you had a bad experience, right? >> No, no, no. It's it's I think it's actually quite normal, right? >> Well, it's pretty rare, right? It's it's it's a a function of the size here too. And this is again going back where because we have permissionless relayers, we have to guess at the capacity of our network at times. Um and there's times where we get it a little bit wrong and we uh that's that's something we have to be it's hard to do. It's actually a bit easier if we were the only solver, we would know exactly what's fillable at any given time. Um, but the thing I wanted to ask Peter, it's like like that it's sort of actually the thing similar to point BK like you know I I can DM you

in Slack and be like hey Peter I didn't get my funds and like that's all cool and I do think you're trustworthy and all that kind of stuff too but from Ethereum's perspective like you know if some other guy Joe starts a protocol that's just got you sending money to his EOA I think you'd be like yo guys you shouldn't use that protocol like don't send money to Joe's EOA or I'm curious to get your thoughts. It's just almost like setting a bad precedent that it's okay to start your business with a complete trust relationship like what do you think about that from?

Yeah, I mean in some ways the the parallel is equivalent to L2s and what was okay, you know, in certain times like well I would say maybe two things. one is that I'm I'm not worried about it and like like I was saying I think we can actually achieve a good level of trust uh and be competitive with that and and that's actually kind of one of our goals is to work with some of the other products in the market that are doing this kind of more trusted setup and and have a solution for them that's like here is something that allows you to have the same level of cost and speed and all the things that you're comfortable with but you can actually uh move to a more trusted cuz that's the problem is that if the if the

alternative costs 10 times as much and it's slower uh people will fall back to the kind of trusted models and so yeah I think you can criticize like the path we took and you know it was a very different time two years ago this is kind of like very early in the kind of rollup road map and also a lot of 7D bridges and you know yeah very very different times and like I agree with you and so yeah the question is like is you know definitely the responsibility is on us kind of where we're at now to kind of like raise the bar. You know, what others should do is kind of to them. But, you know, I think we're at a point now where we've figured out how to do it very efficiently and there are kind of nice new designs coming along as

well where that's just kind of less necessary. I'm curious to know about if you think that the users are aware of the risks today with using the different types of systems. Uh I guess I can ask it to you. Um if this is something that you feel is clear enough as of today with regards to like like was mentioned that you have higher cost when it comes to uh using these fully trusted systems versus using something that's just sending from an eway to another basically.

Obviously there's a cost difference there and people may choose the cheapest one because they don't want to pay so much. Um, but I'm curious to understand if if you I guess it's for all you guys, but if they if you believe that they can understand the potential implications by using a specific uh service. >> Yeah. So I think currently it's not communicated like when I use an aggregator or I use uh some web app that helps me send funds across chains or wallets that integrate these capabilities. I don't feel like they reflect the true risk and in some cases like if I want to send the $10 then I

would go for the fastest and cheapest uh solution because I mean why not I mean especially if I don't want to execute a call which is the focusing but actually just want to send $10 to someone then maybe I'm fine if I want to send $100,000 or a million dollars my considerations are different and currently I don't feel like this is reflected so this is something that They hope L2 bit will change but then it's uh so L2 bit can can give us this information but then we need aggregators and wallets to actually uh to actually deliver this information to the user and um and actually so and if I need to be like if I need something for a very large amount I would want something

completely trustless. So going back to uh the situation that B described um so in EIL in EIL for example once it's uh once it actually reaches mainet which is not yet but uh once it's on mainet when you request the voucher you set the expiration time for the request and you set the fee that and the fee gets increased over time to incentivize someone to give it to you. So, it's like a basically a reverse Dutch auction, but at the end of this auction, at the time that you set your funds, you can reclaim your funds and uh so you know exactly when you're going to get them. Now given that uh you want to do something today and EIL is not available today my

personal choice for a very large amount would be a protocol that is not represented here but is uh so there's the train protocol which is um so uh train is a they basically they basically match you with someone to perform HTLC to an atomic swap and I would be comfortable doing that with a large amount because it is an atomic swap and there is time logs So it's uh so for for a particularly large amounts I would go trustless and it is possible today at least for a not for execution but at least for transfers.

I would respond to your question uh Frederick that uh people have no idea at the moment and uh it's even worse than that most of them don't care at all and uh we've been working uh SL2B with two of the major aggregators being socket and Wi-Fi and socket uh told us that uh they did display you know risks uh but that did not change the users's behavior at all. LiFi told us that it's pointless and they are not even going to do that because no one cares. Uh so the question is like we're stubborn right we will expose these risks. Uh the question is like will people care and maybe right now my hope

is that maybe uh institutions will care because they actually manage other people's funds and if something goes really wrong and they knew about the risks uh they could be sued for gross negligence or something. So maybe this is our hope but you know I don't think the um the individual users will ever care or understand what's going on here right they will literally try to do the swap and hope for the best and in most cases it works and if it doesn't then well tough luck >> in many ways would you agree like every DAP that you use there's like an implicit trust with that DAP and who's running it that you know their DNS is secure that the call data they're giving

you >> yeah most most but uh again I would say that you know there's a difference in trusting the unis swap code or some other version which is like completely permissioned where you know eway can upgrade and we did have uh cases where uh there was a governance attack and through the upgrade you know the money was stolen through the protocols so that these are the risks that we're exposing right you know we don't want the OAS to be able to upgrade your contracts and we first and foremost we want these risks to be uh um properly disclosed because like half of the protocols will put on their websites that they're trustless and self custodial in most cases this is just not true uh when we read the code

uh but this is how you market your protocols right so so I think that has to change like we have to be like honest um as an industry and and frankly I don't have like personal issues with protocols like relay if they say like you have to trust us and you know we have reputation to lose if we like screw it. I do have a problem when you know a protocol says that very self-custodial and trustless we check and verify and there's a new way that can upgrade with no notice. So like what are we talking about right? uh so that's that's an issue right you know we need to I think uh be more honest when we communicate these uh risks u to the users and maybe for like retail users that doesn't

matter but maybe for institutional users that that's actually like crucial yeah look the only thing I want to add and I don't want to be this beat up Peter but at all um I do think our industry is supposed to say like being custodial is not cool like that I do think that is part of what we are supposed to push and Peter like one of the things that I'm genuinely like been surprised by is like you know you you were the maximal version of send money to my EOA and it people did it right and institutions adopted it too and I do it's like I I I I actually do believe your road map I trust you like I think you guys are like quality business I really do but it's like such a bad

precedent you Yeah, I mean uh what is custodial and like you it's like similar with you know again going back to kind of risk tradeoffs and you know protocols that have approvals that people have given kind of millions of dollars in approvals to and uh that protocol can kind of upgrade you know like a couple of aggregators got hacked and kind of like approvals drained because they were able to kind of deploy new integrations freely. In my mind, that's a lot more custodial and and kind of like this resting risk versus

traveling risk. So, yeah, like not I'm not trying to pass blame. Uh but it's just like more like put in context of like yeah, there there's kind of trade-offs and and like the path u but uh it's yeah, absolutely. you know, and we've also kind of learned along the way what is the optimal way to kind of have the same level of UX that we want uh and make it trustless. And so, yeah, it's it's it's been an evolution. And, uh, you know, I think it is actually kind of possible to to kind of reel things back in the same way that Ethereum has no privacy today, but now that we're ready for it, I think I don't think it's lost.

I think, you know, we can reel it back. And similar for L2s given a you know a pass for a long time I think these standards can change you know especially as zero knowledge costs go down we can demand higher standards and so that's my take of like you know there was demand for uh this product a lot of kind of pain a lot of people blocked you know we focused on solving that and you know people should absolutely put pressure on us to do better and they're absolutely doing that and you know I think it's good and and we will get to a a much better place.

>> Yeah. Uh final question here. Um what is the end what does the endgame look like to each of you? Uh basically so you mentioned that you're trying to do better etc. Um what what is the endgame in in your view on this topic? >> Yeah. So for us the endgame is is yeah you you absolutely do not need to trust around whether you're you know money is going to be stolen and you can just come and uh you know personally take the funds and and uh if something goes wrong and even beyond that I think even the model of solvers um where they have their own capital and you rely on them

to fill is something that we're very interested in how we can solve that because it's actually quite difficult to run a solver and I don't think there will ever be that many uh really high quality solvers with a lot of capital that are also really good at execution. So a big thing we're focused on is how can you unbundle what a solver is and have liquidity that is maybe in pools and that reduces solving down to just executing transactions across chain maybe even to the point where you can self execute on the destination like you can do in uh in the Ethereum interop layer but I guess the last thing is like it's not the endgame for us to have it so trustless that you know you know you know really optimizing for this relayer

can't grief you, for example. Like we in some ways we think that's a worthwhile trade-off in order to have uh the happy case work extremely well where the unhappy case might be like a little bit more inconvenient. And so that's kind of our endgame is I think there should be a spectrum of solutions. I think Ethereum should absolutely have a you know really strong solution uh kind of similar to forced inclusion around those cases. And then for us it's to kind of like meet the necessary bar um and maybe that security scales with the amount um but also just have something that that works uh like continues to work and uh and yeah I I think also we want to design

something that can compete with a fully trusted solution so that that is a viable you know you can kind of beat us without kind of having that temptation. I mean for what it's worth Peter I mean we assign the highest rating of L2 tools that uh in happy case with centralized sequencer you know they give you the excellent execution and UI and unhappy case you go through the pain of force including transactions via L1 we still give you the highest rating so if you can provide that you know I'll be like promoting your protocol left and right >> what about across >> yeah Frederick I think I want to add is um trustlessness I want trustlessness to actually be um

like I I want to do things that the trustlessness makes this protocol better for the users. Like it's not just a nice to have. It actually makes the protocol function better. Um and to me I think the endgame here is we are going to have many chains and many tokens and many stable coins and there's just there's going to be this ridiculous amount of fragmentation. Um, and even though I would like everything to be an L2 with like uh seamless canonical bridge on how to get to it, I don't think that's going to happen. There's gonna be other chain.

It's just going to be a mess. And I think the intentbased solver network is a beautiful way to create a translation layer uh between all these chains and all these tokens. I think Peter and I are kind of aligned on that vision. Um, and to me the endgame here is you have a hyperco competitive missionless network of solvers that are competing to translate between all those chains and all those tokens. And um, I actually think that's the most exciting part of where the trustless comes from is how you can have like a 14-year-old kid in their basement uh, be able to do this, including maybe being able to get the capital like Peter said to be able to do interesting execution between this. Will it be a 14-y old kid in the basement

doing it at scale? Maybe not. But I do think that if you have that option, there's going to be a lower barrier to entry for more and more innovation um in that space. And that's pretty [snorts] cool. >> Yeah, we're out of time, but do you want to say uh something quick regarding this? >> Yeah, my so uh I want my my end game is that users don't need to use intermediaries. So self-execution I think is key and that the trust assumptions at least inside the Ethereum ecosystem where we have a shared source of truth is only is only on that and I should mention since we're talking about the dispute mechanism that disputes are that actually the the correct term for it would be fault proof just like with

with rollups because there is a there is no dependency there should not be any dependency on any humans in the process it's actually it only trusts the canonical bridge. So my take is that uh trust should only be on Ethereum and the underlying networks the underlying groups you're using and it should be uh self-custodial and self uh self-executing not trusting intermediary for anything. >> Perfect. Thank you very much and um yeah give a big round of applause to to Peter Hart Yav and Bartek.

Thank you. >> Thank you once again to our panelists. Please big a round of applause when they leave the stage. Oh, that was big round of applause. Thank you so much.