 It's really exciting. I'm actually really happy that the last two people covered kind of cross-chain messaging and bridging and layer 2 stuff, because I'm going to talk a lot about that. But it's great to have context. So again, I'm Matt. Welcome to my TED Talk. So three things I'm going to try to cover here. There's a lot of stuff going on in layer 2. There's a lot of stuff going on in crypto. I'm going to try to focus on three things. Last one I know is broad. Talk about bridging. Talk about compatibility and interop. And I'm going to talk about some scalability issues that I think we're starting to coalesce around that we have been talking about for a while. So bridging. You've got to move funds from layer 1 to layer 2. At some point, this shouldn't be something you have to think about. So we want there to be zero degrees of separation between the layers at some point in the end game. You bridge right on to layer 2. So here's what we are today. It's state of bridging. It continues to be really challenging. It continues to be risky. We see hacks all the time. It's not great. But it's something that we have to deal with. UX for users is tricky or even impossible, depending on the asset. Not all tokens are used through 20s. Sometimes you can't bridge. Sometimes you have to bridge in a different way. So it becomes really challenging for someone trying to use any kind of crypto product in the beginning when you have to educate them on what bridging is. And what that means is for developers, not all token implementations are created equal. On Arbitrum, we have standard versus custom bridging. So when you're bridging an asset over for the first time, we can deploy that contract for you on layer 2 and it'll auto deploy. But if you have things like interest or other things that are maybe more custom for implementation, you have to work with us or you have to build your own custom solution. So it's pretty complicated. And I think we're not in a space where things are perfect, but we're making a lot of progress. And kind of at a higher level view, this is our bridge. Fantastic work from the team. But if you think about it, bridging is really designed for power users. So it's not something that in the long term we want to have be kind of like the canonical thing you have to do on the blockchain. So what's next? And again, this is a lightning talk. I'm trying to go as fast as I can. One thing that we're exploring is fast withdrawal confirmation. So on Arbitrum Nova we have a data availability committee. We can actually use that system to allow for withdrawals back to L1 to take less than a week, be almost instantaneous. It's not something that's live yet, but something we're thinking about. It'll make this a lot smoother. Let's see. Yeah, something that we'd like to see happen in the ecosystem is more wallet integration, deep wallet integration, I would say, with fast bridging. So when you're in a wallet, you have an asset, you can just use a fast bridge from within there. You don't have to go on the browser and actually sort through all these options to make trade-offs with your own independent research. You can actually have that be automated for you. Obviously, that's gonna require community discussion. This is just something that goes without saying. Something that we've done a lot of work on is within the bridge itself, increasing discoverability of fast bridges and making sure it's more performant. Not all bridges are created equal. There's lots of different options. And so doing what we can from an agnostic perspective to make sure that we provide the best UX is something that we try to do all the time. And something I'd like to see long term is bridge aggregation and standard functionality. There's lots of trade-offs you have to make to find the best performance, the best security between all the options that are out there. Having functionality built in, and I talked about this with Waltz before, as kind of a standard functionality where you're given a bunch of options. You can see the average cost and you can make a decision for yourself in the UI. That would be great. And making that standard across all options would be phenomenal. So, sorry, I'm going really fast. But the next thing I wanna talk about is kind of compatibility, right? So we're in a good state right now in Arbitrum on a lot of layer twos. Drop in compatibility is standard. So the good news is, you know, EVM programs work out of the box. It's something that you can rely on moving on to layer two as a developer is basically kind of like not a huge issue. And the other thing is Core Infra that you kind of come to know and love on Ethereum, on L1, on other blockchains, RPC providers, price oracles, graphs, monitoring analytics, it's all there. It's already ready for you on L2. So we've got a robust set of tooling and infrastructure if you wanna deploy. So we're in a pretty good state there. And you know, SDKs and frameworks, we have new things like Foundry coming up every day. They're beginning to multiply. You have lots of options. You have lots of things that you can, you know, potentially use to make your development experience easier. This is just a quick graphic with Nitro. We're running Geph at the core. So in terms of compatibility, we're, you know, reaching parity as much as we can. So what's next, right? You know, you can keep pushing the envelope here, but one thing that we wanna think about right now, contracts, solidity. As you think about rollups in the future, we wanna see broader language support for smart contract execution. So this is something that you can imagine having, you know, different options to write your contract code in and compile down to something that'll still work with the EVM. It's a really exciting time. Again, right now on Arbitrum, we have two-dimensional gas, we price L1 call data, posting costs, separately from L2 execution costs. This is something that, you know, if you're a developer, if you're a project, you're doing a lot of things, estimating it and getting accurate pricing for the gas as time goes on, especially with high volume, is really difficult. So making that better and working with wallets to have different standards with transaction types is something that we wanna push for. Again, I mentioned before, a lot of these SDKs popping up. I think as more developers, you know, come into the space, and this goes on to this next point, longer term, having better rails for Web2 developers to come into the space with canonical paths forward for any kind of applications and having community consensus around what the best tooling to use is, is something we need to all think about. It's hard to make those trade-offs. The last point I wanna make here is there's a huge perception issue in kind of like major tech. I came from that industry before working here. People are not super enthused about crypto development and we need to do something about that. I don't know exactly what that is, but it's something we all need to think about. So kind of a philosophical point there. I think this next point is kind of on performance, right? Like as much as we can increase throughput and bandwidth and execution speed on the chain, more people will use it, more developers will build. So the good news is, this is happening all the time. You know, we're doing this today. We're at a conference talking about how we can all work together to make this possible. So there's lots of stuff happening. We shipped Nitro a couple months ago. We seven extra capacity. We lowered speeds. Things are looking pretty good for rollups. And the one thing here to think about though is we focus on gas all the time. Remember, rollups and blockchains in general are not just about gas. You have to have security on the chain. So making performance for validators or for nodes that are serving as validators, making that more efficient, making that more accessible is something that's gonna continue to be more important as time goes on, especially with state growing and the way that it is. And this is just a quick reminder, speeds are low. They're not arbitrarily low. They're not tiny, but we're getting better. Things are kind of improving. And so I'm not sure how much time I have left. Yeah, so state bloat, it's a problem. We're gonna try to continually optimize for client performance. And there are a couple of things that we're experimenting with, the rentable storage. We've talked a lot about statelessness. There's still a lot of work to be done here. I think we have a lot of progress to be made. The one last point I wanna end with is at a high level, in order for state bloat to be a problem, we need to get people to actually use blockchains outside of the canonical use cases we're comfortable with today. I personally would like to see a lot more use cases come to market with lower barriers to entry. Right now, most games in crypto, in order to play, you gotta spend $500 on an asset. That's not something that most people can actually do, right? And you're gonna make a leverage long on some asset that you've never heard of. Most people, as they go into the world and wanna try to experiment with these things, you need to make sure it's easy for them to get involved with. We wanna make sure things like onboarding to DeFi, having account abstraction, being able to pay with different fees for your transactions, paying with different tokens for your transactions, something that we wanna see, something that we wanna encourage. And something I wanna talk about just as the kind of a last point is we have novel experimentation going on with insurance on chain. We see a lot of hacks, we see a lot of teams focusing on security, focusing on audits, focusing on having the best talent in-house to make sure that things are secure. That's not the only way to solve the problem. You can kind of think about hedging in a different way. So baking in insurance into the core flows for DeFi is something that I think there's a lot of potential and that we have lots more of experimentation to do with. So sorry for going really fast, but yeah, that's Arbitrum and that's us. Woo! Yeah. Thank you for the sprint.