As a space, we face a big problem: how should we think about where assets live. Is Eth different from oEth or aEth. Does it matter where Circle prints your USDC? Should chains delegated to the kind of infra that Google Cloud or AWS is today? Clearly, the fragmentations of USDC/USDT/xDAI and then all the L2s creates horrible UX. However, the underlying assets are different things and the chains they live on have completely different security guarantees. Let's fix this!

Stage 4

Konrad Urban

Chain abstraction? But I want to know where my tokens are

 Hello. Hi. This is not going to be nice. I'm here to tell you that it will be your fault if things go wrong, and I will explain that in greater detail. I think it's such a nice segue to have Radina's talk earlier because exactly what I want to talk about is the responsibility you have when you abstract chains and when you curate the infrastructure that you have. So about me, I'm the peanut brain at Peanut Protocol and we've been doing chain abstraction when we still called it chain agnostic payments. So we do chain abstract payments. You can do a payment, let's say, in 10 USDT on Optimism, and someone can receive 10 USDT on Polygon. We don't use Intents. We don't use fancy solvers. We use simple bridges to make that happen. We've been around for a while now. So yeah, for generalized chain abstraction, I think it's important to ask, like, why should I even care where my tokens live? I think I personally care because the risks are very different to something like a traditional centralized financial institution. When you think about a bank, you have legal guarantees and you have bailouts that secure your funds and you don't need to worry about the exact capital, the underlying capital of the bank. You can be pretty sure that you are able to withdraw your funds in any mature economy. In crypto, well, we don't have legal documents to back us up. We have smart contracts. So I want to talk through two dilemmas. One is simple UX and very stripped-down UX and exposing all of the risks. So L2 beat, when bridge beat? I think it's, yeah, a slide that I stole from Radina that I briefly want to talk about. Look at all of the risks that are involved in such a simple thing as just having USDC on orderly. Well, getting USDC on orderly. You not only have all the circle risk, then you get like the mantle risk, get the canonical risk layer zero and so on. That's crazy. So let's make the pizza green. And let's talk through some ways we can communicate these risks to end users. So we have this first generation of chain-first UIs, which emphasize the chain, and then the assets. So that's like MetaMask, where you have to pick your chain, and then it only shows the assets on that specific chain. Then we have asset-first UIs. So Rabi, I think, is a really nice example, where it shows you the assets. It will even show you the network as separate entities, but it will show the asset first. It will show the network as a small thing in the back. Well, how should we do it as product people? What should a product person do? Should they just like slap thousands of warnings everywhere? Surely that's not a good way to onboard users. It gets even worse when we abstract everything and we just have like a final balance and we just assume that everything's going to route it everywhere, right? Yet we have to expose these things somehow, these things somehow, especially that with chain abstraction, essentially what happens, I would argue, is that the FAT protocol thesis kind of stops existing, and the middleware thesis plus the app thesis become much, much broader, which means that you are much, much more responsible for curating the infrastructure in the middle where you're using and what you're exposing to the end user. So there is this phenomenon, I think, that we'll see with mass onboarding and very simple apps where we'll have a race to the bottom in terms of not showing these risks, right? Like as a business, especially as a startup, I want to move fast and break things. And yeah, it is a disadvantage. It is objectively a business disadvantage to be like, warning, this thing is at risk. Warning, that thing is at risk. Which means that it's even more important to internally, as a product team, to vet the infrastructure that you're using and consult tools and people like L2Beat and maybe BridgeBeat in the future. One thing that I wanted to emphasize is that the market doesn't seem to price these risks strongly. Like one ETH on some random L2 is going to be exactly the same dollar value of ETH on mainnet. So it seems that the market just doesn't price these. Maybe because we haven't seen a catastrophic risk yet, a catastrophic failure yet. So yeah, if you ever want to chat about interoperability for payments, DM me, I will send you money. These are my details. Thank you, Conrad. And you can already talk to Conrad right now, if you ask a question. Incredible, right? You can ask your question by raising your hand and I'll get the box to you. Yes. Oh, that's far. Maybe it's easier if you do it from there. No, no, it's okay. You can stay. I like standing up anyway. So I understand about the counterparty risks of the bridge introducing different risks to the bridge asset. But in the far future, if we have soft smart contract security and all that, with like ZK or whatever people are using, do you foresee it being at risk parity across all the chain and therefore chain abstraction is viable? I think when we say chain abstraction, it's still some basket of chains that you as a product creator curate, right? So I think maybe there will be a world where all this tech will go down to zero. It's going to be very, very simple to have really, really, really good tech there where we don't need to do all these audits essentially. But yeah, it's up to you to curate. I think that's my main argument, yeah. All right, we have another question. But in the far future, yeah, sorry. For someone that's new into the space, me, here. For someone that's new into the space and building, doesn't have a plethora of knowledge of existing third-party risks that exist with bridges, how do you actually assess and price in that risk when building? Where's the best place to do that? Yeah, really, really good question. So EltaVita is a great place. I think my main message would be, again, it's you as the product owner or even like co-founders who have to make that decision about curation if you want to hide the risks. Like you're faced with this dilemma of like either you expose the risk and you are fair to the user and say, well, it's going to be your own fault. You're responsible, which creates worse UI. Or you curate it for them and then don't get surprised if people will spam your support email if they lose their funds and they will hunt you down. Cool. We have time for another question. Anyone wants to ask one? Maybe you do. Yes, you do. Fantastic. Get ready to catch and go. Good catch. Do you think this is going to create a barrier of entry for new L2s to enter because there's a risk in a new player? I think it's the opposite. So I think as with any research project, there's a first mover disadvantage because you're pouring in millions and millions into the biggest brains of the industry to design a new infrastructure and then anyone else can just fork that or build a very similar copy um yeah whilst inheriting all of the niceties of the first mover but you wouldn't apply for if they are using a new technology for example yeah sure if you're building something new then you need to convince everyone that it's good tech, and you need to really pitch yourself. I think that's also a message to all infra projects, like pitch to apps that you are the best option, the secure option for your users, because app developers have this responsibility towards their end users of curation.

https://streameth-develop.ams3.digitaloceanspaces.com/transcriptions/673576739dbb7a90e1ae4a04.vtt