Ethereum’s Next Big Upgrade: Pectra, Fusaka & Beyond | Tim Beiko

We’re joined by Tim Beiko, Ethereum Foundation coordinator, to break down Ethereum’s next major upgrades and the future of scaling. We explore the upcoming Petra hard fork, which introduces validator consolidation, increased blob space for rollups, and EIP-7702 for improved account abstraction. Tim also shares insights on Fusaka and Glacier Dam, Ethereum’s roadmap for scaling, and how Ethereum’s upgrade process is becoming more efficient. ------ 📣SPOTIFY PREMIUM RSS FEED | USE CODE: SPOTIFY24 https://bankless.cc/spotify-premium ------ BANKLESS SPONSOR TOOLS: 🪙FRAX | SELF SUFFICIENT DeFi https://bankless.cc/Frax 🦄UNISWAP | SWAP ON UNICHAIN https://bankless.cc/unichain ⚖️ARBITRUM | SCALING ETHEREUM ⁠https://bankless.cc/Arbitrum 🛞MANTLE | MODULAR LAYER 2 NETWORK https://bankless.cc/Mantle 🌐CELO | BUILD TOGETHER AND PROSPER https://bankless.cc/Celo 🏦INFINEX | THE CRYPTO-EVERYTHING APP https://bankless.cc/Infinex ----- ✨ Mint the episode on Zora ✨ https://zora.co/coin/base:0x0d142a1a30adcbc06c3c2a537d2cd1a9b7901c35?referrer=0x077Fe9e96Aa9b20Bd36F1C6290f54F8717C5674E ------ TIMESTAMPS 0:00 Intro 5:43 Current State of EIPs & ETH Hard Forks 8:01 Why Security Is So Important 12:43 Naming Conventions of ETH Hard Forks 13:55 Pectra Upgrade & Its Effects 16:15 Maxeb Upgrade & Its Effects 24:29 Hard Forks, Bandwidth & Scaling 28:51 Other Updates Regarding Pectra 31:40 EOAs & Smart Contract Wallets 36:17 Smart Contract Wallets' Effect on Layer 2 43:15 Timeline of Fusaka & Glamsterdam 48:09 Vitalik's Tweet on Fusaka 51:15 Alcore Devs' Plans 54:25 What's EOF 59:18 Other Updates Regarding Fusaka 1:00:41 Uncertainty Regarding Glamsterdam 1:02:18 ETH's Slowness & Developers 1:05:19 Misconceptions Around ETH 1:07:32 Scaling the Layer 1 1:14:52 Summer of Protocols 1:18:13 Closing & Disclaimers ------ RESOURCES Tim Beiko https://x.com/TimBeiko Ethereum Roadmap & Hard Forks https://ethereum.org/en/roadmap/ EIP-7702 (Account Abstraction) https://eips.ethereum.org/EIPS/eip-7702 Ethereum Object Format (EOF) https://ethresear.ch/t/ethereum-object-format-eof/ ------ Not financial or tax advice. See our investment disclosures here: https://www.bankless.com/disclosures⁠

Speaker names marked ? are inferred from speaking time and the show’s known hosts — they are not voice-verified.

• 0:00David Hoffman?

  For 2025, we need Fusaka on the Layer 1 with pure DAS, ideally with 48 blob target. And then he falls up saying, let's aim to get a Fusaka testnet with these blob parameters running the day after Pectra goes live.

• 0:13Speaker 01

  There's all these proposals saying like, we should hard fork every six months or every quarter or whatever. This sounds good in theory, but imagine we're doing this, say, for the merge. And it's like, okay, we mixed the six months deadline. Do we just like ship a bunch of random, less useful stuff? Obviously, it's still the highest important priority to ship the merge. If it's going to take an extra six months because there's something fundamentally hard about the merge, we should still be willing to pay that cost.

• 0:42David Hoffman?

  Welcome to Bankless, where we explore the frontier of internet money and internet finance. And today, we're exploring the next steps in the Ethereum roadmap. Ethereum is alive. It is an organism that is constantly evolving and adapting through a slow iterative process of debate, deliberation, and rough consensus. And the coliseum for where this all goes down is the Ethereum All Core Devs calls. This is where priorities are hashed out and EIPs are either marked for inclusion or cut and left on the floor. With me today on Bankless is Tim Baker, who is a coordinator of these All Core Dev calls. He is right in the middle of everything, traffic controlling conversations and priorities from the various components that make up Ethereum, while also ensuring that things do keep on progressing. With the Pectra hard fork on the horizon, I thought it was time to get Tim on the show

• 1:27David Hoffman?

  to give the Bankless Nation an update as to what is included with Pectra, as well as what's coming over the horizon with the next Ethereum upgrades, Fusaka, and then eventually Glampsterdam. And if these names feel both odd and familiar to you, they are. And we'll explain how these names of Ethereum software upgrades come to be in the first place. In this episode with Tim, we talk about Ethereum's increasing aggressiveness with scaling and data availability, and why scaling the Ethereum Layer 1 is harder. How Ethereum's staking mechanics are getting an overhaul, and WTF is Ethereum object format, and what does it do for improving the developer experience on Ethereum? If you appreciate this podcast, please subscribe. If you already subscribe, perhaps also leave a rating or review. Those five star reviews do help us get to the top. The charts so we can help the world go bankless.

• 2:12David Hoffman?

  And if you are already a bankless citizen who is listening to this on your ad free premium RSS feed, make sure that you get the private RSS feed loaded up into your Spotify. The album artwork for every episode is just so incredibly pretty. Shout out to our designer as well as all the early podcast releases and perks that come with your premium feed. Let's go ahead and get right into this episode with Tim. But first, a message from some of these fantastic sponsors that make this show possible. You may have already heard about InfineX. InfineX has, in my opinion, the nicest cross-chain swap and bridge feature that you will find anywhere. It is called Swidge, Swap and Bridge, and we're going to show you what it looks like. First, we're going to log into my InfineX account with a pass key. Now, there's no seed phrases in InfineX. This is just a one-click setup with biometric pass keys. But in addition to that, my InfineX account is fully non-custodial.

• 2:57David Hoffman?

  So bam, I just logged in. It was two clicks and I'm already into my InfineX account. So let's go make a Swidge. I'm going to go Swidge my USDC that is on base and I'm going to buy Bara Chain, which is a completely different chain. So we're going to Swidge this. I'm going to press that button and then InfineX is going to execute this order, this cross-chain order for me. And now it is done. But actually, I'm not really feeling bearish anymore, so I'm going to go from Bara to Penguins. I'm going to buy Penguin on Solana, so I'm going from the Bara Chain to Solana. See, no transaction signing, no gas to worry about. You just Swidge across whatever chain that you want with InfineX. That was so easy. Go check out InfineX and try your first Swidge today. The Arbitrum Portal is your one-stop hub to entering the Ethereum ecosystem. With over 800 apps, Arbitrum offers something for everyone.

• 3:41David Hoffman?

  Dive into the epicenter of DeFi, where advanced trading, lending, and staking platforms are redefining how we interact with money. Explore Arbitrum's rapidly growing gaming hub. From immersed role-playing games, fast-paced fantasy MMOs, to casual luck battle mobile games. Move assets effortlessly between chains and access the ecosystem with ease via Arbitrum's expansive network of bridges and onramps. Step into Arbitrum's flourishing NFT and creator space, where artists, collectors, and social converge and support your favorite streamers all on-chain. Find new and trending apps and learn how to earn rewards across the Arbitrum ecosystem with limited-time campaigns from your favorite projects. Empower your future with Arbitrum. Visit portal.arbitrum.io to find out what's next on your web-free journey.

• 4:27David Hoffman?

  Imagine a world where your day-to-day banking runs on a blockchain. That's exactly what Mantle is building, powered by a $4 billion treasury and poised to become the largest sustainable on-chain financial hub. As part of their 2025 expansion, Mantle is introducing three new core innovation pillars that bridge traditional finance with decentralized technology. First is their enhanced index fund, aiming for $1 billion in AUM by Q1. It provides optimized exposure to Bitcoin, ETH, Solana, and USC, complete with built-in yield opportunities. Next, Mantle Banking promises to revolutionize global value transfer through seamless blockchain-powered banking services, bridging crypto into your daily life. Finally, Mantle X blends AI with DeFi to deliver an intelligent, user-friendly experience for everyone.

• 5:09David Hoffman?

  And the best part is that this is all in addition to their already-launched products like Mantle Network, ME, and FBTC. Ready to step into the future of finance? Follow Mantle on X at @mantleofficial and join the on-chain revolution today. Bankless Nation, very excited to introduce Tim Baker. He is a coordinator at the Ethereum Foundation. He's a central information hub for all the various components of the Ethereum protocol and helps kind of guide the hard fork upgrade process for Ethereum, as well as the All Core Devs Call. Tim, welcome to Bankless.

• 5:37Speaker 01

  Thanks for having me.

• 5:38David Hoffman?

  So I really want to kind of just get a download on the kind of the current state of thinking as it relates to EIPs that are going to make it into Ethereum. And of course, any informed listener would know that these go into Ethereum in chunks. We call these chunks "hard forks." The next hard fork that we are currently preparing for is called Pectra. But then there are other hard forks that happen after that as well, such as Fusaka and Glamsterdam. We'll actually talk about how these names come to be. But maybe, Tim, maybe you can kind of zoom out a little bit and kind of give us a lay of the land of what things seem to be being prioritized, generally speaking. So when we look into the updates that the All Core Dev meetings are discussing, what kinds of updates are rising to the surface? Like, what is the ACD calls of Ethereum, All Core Devs calls?

• 6:23David Hoffman?

  What are they prioritizing?

• 6:25Speaker 01

  Thanks. Yeah. I'd say the first thing, which is kind of obvious to some people, but probably doesn't get emphasized enough, is security. So first and foremost, the thing that kind of differentiates it Ethereum from other chains is just this like extremely robust approach to security. And in practice, this shows up as like the chain has never gone down. And there's an immense amount of work that goes into this. So if you're listening to like some random segment of an awkward dev's call, you're probably hearing people just like debate, is this thing safe? How is it going to break? And if it broke, why and how can we fix it? So while this isn't like a feature as much as some of the other stuff we'll talk about, it's worth being mindful of this because it is kind of the thing that then dictates all of the other priorities.

• 7:09Speaker 01

  Like, why can't we do this specific thing that seems obvious? The answer is usually because there's like some security property we're trying to work through to make sure that it's actually robust with the point on the theorem. But with that being said, I'd say like the most like prominent theme of the past year or so has been around scaling, both on the execution and consensus layer. So Pirdas is the main thing people are talking about now. But even before that, we've been working these past few months on the Pectra upgrade, which will also scale the consensus layer broad data. So we can get into any of those, but like high level themes, security. And then more recently, in the past year or so, scaling has been coming up more and more.

• 7:46David Hoffman?

  You know, I expected the answer, like if I had to guess, was going to be scaling. But I want to unpack that a little bit more. The idea that security is like this kind of common denominator for all future like properties of Ethereum. Like there are some properties that Ethereum does not have that we want it to have. And so we can like prioritize those. But I really like the illustration of like, well, yes, but first comes security. Color in that just a little bit more about like why security is so important when it comes to the all core dev's calls? And why everything, all updates to Ethereum have to pass through that security filter first?

• 8:18Speaker 01

  So sure, it's like, if you think Ethereum should be this robust, durable platform, which secures billions and potentially trillions of assets, you want this thing to be safe. And the way that say, you know, non crypto handles this is through centralized third parties, right? Like your bank has some security control, but if those fail. They'll send like a lawyer to fix it up, right? Then you often see these cases like some bank accidentally sends someone like a hundred million dollars and then they just revert the transaction. And so, you know, they obviously have placed checks in place to ensure that they're not sending you a hundred million dollars to random people all the time. But if and when it happens, there's like this legal system and other ways that they can kind of go off-chain to resolve this. On Ethereum, we kind of don't have this luxury, right?

• 9:02Speaker 01

  Like, we have the chain and when a smart contract is deployed on it, or when someone has some ETH on it, there is no other mechanism by which we could go and change sheets. And this has become more true over time, right? If you look in, you know, blockchain's early histories, you know, Bitcoin obviously had the inflation bug and they had the fork for this, Ethereum had the DAO. And I think what you learn through these experiences is these events are like extremely contentious for the community and the bar for them to happen just keeps getting higher and higher and higher. So we need things to be secure because we should assume that we're not going to be able to intervene. And I was looking up the DAO recently and people like to kind of talk about it and it's like this very intense part of Ethereum's history.

• 9:44Speaker 01

  And I think it's kind of less appreciated today, just how big of a deal it was. So to put it in perspective, when the DAO hack happened, the DAO had as much ETH as all of the L2s today and the wrapped ETH contract. And that's kind of the scale that it took, you know, to have some sort of social intervention on Ethereum. So if you told me, you know, tomorrow I wake up and like all of the L2s and the wrapped ETH contract are brick, they're like, yeah, potentially we would be considering, you know, some way to solve this. But for anything like below that threshold, we need Ethereum to actually just work. And that is why like it has to be secure. So if we didn't care at all about security, we could get scalability. And there's a lot of other chains who just fork Ethereum's code, you know, 10x the gas limit, lower the slot times.

• 10:27Speaker 01

  And those chains work, but you can't sync to them. You know, you have to have like manual operations where like, you know, people come in and they're like, you'd already restart the chain from time to time. So if you want to avoid all of this, then you need to find ways to scale, but not compromise kind of this ability of the network to keep going.

• 10:43David Hoffman?

  I think there's a large number of reasons as to like why Ethereum upgrades slowly. One is like caution for that security reason. One is like, well, it's a decentralized ecosystem. There's multiple clients. It's just harder to upgrade a multi-component system. But maybe one of the reasons why Ethereum tends to upgrade slowly is because, well, we hold security to the highest degree possible.

• 11:04Speaker 01

  Yeah, I think that's true. And I think that's not to say there's no like process improvements or things we couldn't do better. But I think in general, like over Ethereum's entire history, the reason why upgrades are, say, between, you know, six and 12 months rather than six and 12 weeks is because there is like a pretty thorough testing cycle. And I think the other thing is, if you look at all the stuff we did not do, right? Like, there's way more EIPs that have been proposed than the ones that have been actually deployed on-chain. The common denominator is usually there's something broken from a security perspective about them. And it can often take years to like iterate on a design to get to some version of this idea, this feature that we feel is actually going to be safe on mainnet. And in the current hard fork that's coming up, Pectra, there's this EIP 7702 that helps with account abstraction.

• 11:49Speaker 01

  This is like a great example where the first drafts of this EIP probably date from something like 2017, 2018. And it's like, over this process of many, many years and rounds of iterations, we've come up with some construction that we feel is safe and also kind of delivers the value of this feature.

• 12:05David Hoffman?

  Okay, so let's get into the near-term hard forks. But before we do that, let's be one more level meta about it, because I want to talk about the naming convention. I think we did this last time I had you on the show, but I think it's worth tracing over. The next hard fork that is incoming, that is Soon TM. Soon TM is Pectra, followed by Fusaka, followed by Glampsterdam. These are not real words. Can you talk about the naming convention for how Ethereum hard forks are named?

• 12:27Speaker 01

  Yeah, so after the merge, we now have two parts to Ethereum. There's the Beacon Chain, the execution layer. The Beacon Chain would use star names for their upgrades, and the execution layer uses DEFCON city names. So, you know, we still kind of refer to those component parts using that way. So the Pectra hard fork has like the Prague execution layer change and the Electra consensus layer changes. But for users and for the community, it's just like one hard fork. That happens at the same time. So we mash them together. So Pectra is just Prague and Electra. Fusaka is Furu and Osaka and Amsterdam is, I forget what the G star is, but then Amsterdam was the city for the first step. Correct. That's where these things come.

• 13:08David Hoffman?

  Right. So it's a portmanteau between a city on planet Earth and a star in the galaxy somewhere.

• 13:14Speaker 01

  Yeah, correct.

• 13:15David Hoffman?

  Yeah. Okay, cool. So Pectra is coming up next, and that is the near term hard fork. As a vibe, how would you characterize Pectra? Like, what are the things that Pectra is prioritizing? How is Ethereum going to be changed by Pectra?

• 13:26Speaker 01

  So on the consensus layer, the two biggest things are, one, the increase of validators maximum balance. This means that we can consolidate validators into a smaller number of them. So when we talk about scaling, a big bottleneck for scaling the consensus layer is how much bandwidth it uses. Ethereum has like a very big validator set. I believe we have over 1 million validators. Each of them need to like sign a bunch of messages and then send those messages to all the other validators, which is just like a lot of bandwidth usage. But in practice, you know, even though we have a bunch of 32 ETH denominated validators, many of these are run by the same entities, right? Like Lido, you know, has, say, I think 30, 40 different node operators. So like, one of those node operators obviously has way more than 32 ETH.

• 14:11Speaker 01

  So with the Pectra upgrade, they'll be able to combine this into chunks of up to 2048 ETH. And the value that you get from this is twofold. One, large operators can kind of generously combine their validators together to reduce the bandwidth that they use on the network. And this means more bandwidth for blobs and other kind of scaling stuff, which we'll talk about after. And then the other nice part is if you're a smaller validator, say you have only 32 ETH. Today, if you have, say, like 50 ETH, you would have to have like your 32 ETH, you can stake that, but you can't do anything with your other 18 ETH. So with this feature, you'll be able to set up a validator with an arbitrary amount of ETH between 32 and 2048. So for anyone who's like on like the more like solo stakeer side of the spectrum,

• 14:54Speaker 01

  it means they can compound the rewards effectively for like any amount up to 2000. And when you get to like 2000 ETH, you know, you could split that into 2000 ETH validator. So there's not really like a ceiling on compounding there. So this feature is really nice because it allows big validators to kind of reduce their bandwidth footprint on the network and then give small validators more compounding. So that's one of the big ones.

• 15:15David Hoffman?

  But before we move on, can we actually just hang out at Max EB? Because I think it's one of my favorite upgrades to Ethereum in a while. And so just to really trace over what you said, right now, before Pectra goes live and before Max EB is live, Ethereum validators are these discrete 32 ETH chunks. And you can only stake 32 ETH or you can't stake below that, you can't stake above that. And so if you have 320 ETH, you would need to spin up 10 validators and you could in theory do 10 validators on the same machine, on the same piece of hardware.

• 15:43Speaker 01

  Yes.

• 15:44David Hoffman?

  And then they would be spitting out 10 times as many messages in theory as they would really need to because it's, you know, 10 times as many messages going into other people's validators coming back into your machine. And so with Max EB, we're able to consolidate this like 320 ETH down into one validator that has like 10 times the weight.

• 16:03Speaker 01

  Correct.

• 16:03David Hoffman?

  But still just one machine. Can you just trace over, I kind of explained it a little bit, but just like how it reduces bandwidth? And then what that unlocks for Ethereum?

• 16:12Speaker 01

  Yeah. So the reason it reduces bandwidth is assuming the validator set stays the same, right? Like say we have a million validators today. If we know that like 30% of those are grouped in like much larger entities, take say Coinbase, for example. Coinbase right now, you know, I don't know what's their exact share of the stake, but say they had 20%. It means they have like 200,000 validators and they're constantly sending messages from like the same servers or, you know, like a small subset of servers from 200,000 entities. But then with this, they can effectively reduce that by not quite 100x, something like 80x to go from like, you know, 200,000 validators to like 200,000 divided by 2048, which would be maybe say 1,000?

• 16:55David Hoffman?

  It's a much lower number.

• 16:56Speaker 01

  Yeah, exactly. Like, yeah, about 80x this. And then because of this, it means every one of those like big validators now is only sending one message, but yes, their message has like a higher weight to it. So instead of getting like, you know, 10 pings from 10 different validators, you get one ping from one validator who's way In terms of attestations and whatnot, you just tax. And like maybe like a very like naive way to think about it is like every validator is currently sending like a message that says like one vote all the time. And then with Maxi B, you can have a same message, but you say 10 votes instead of one vote. And that means that over the internet, like as you're gossiping these messages through all of the peers, you can greatly reduce that number. And for people who maybe don't have an intuition here,

• 17:38Speaker 01

  it's not like you're sending this message just to one person either, because all of the validators send their messages to many different validators, right? So it's more like you're sending this message like 50 times over or something like that. And then you go from sending this message from every one of those people 50 times over to like still sending it 50 times over, but you're sending one message in each of those things. Does that make sense?

• 17:59David Hoffman?

  Yes, yeah, totally. Do we have any intuition or any guesses about the reduced bandwidth footprint that Ethereum will have on the internet post this update? Like, do we know how much reduced bandwidth Ethereum will consume as a result of this?

• 18:10Speaker 01

  We don't have those yet, in part because like it's hard to estimate. Like you could estimate like if everyone did it perfectly, what would be the max saved? So we'll have to wait and see a bit like, okay, you know, to what extent do Coinbase and, you know, under entities consolidate? There are some like moderate risks to consolidation, like you wouldn't want to consolidate everything on say like a single server, even if you have like, you know, more than 2048 ETH. So I think we're going to want to see like, okay, what's the people actually do? What sort of best practices emerge in terms of an institutional use case? But there's clearly some value in consolidation because today, you know, to say, again, take Coinbase as an example, say they have 200,000 validators, they're not running 200,000 independent servers, right? Like maybe they're running, you know, say Bulwark, say they were running like 100.

• 18:55Speaker 01

  Then you could imagine, okay, there's like some amount of risk that they're already taking where those 100 servers are kind of correlated. And so they can consolidate their validators without necessarily increasing that risk. So that's something we'll have to wait and see. And then the other part of Maxi B that is very good is the smaller stakers get compounding for free, right? Like they start to auto compound their stake. And so what this looks like is, you know, I had 32 ETH when I deposited and now I have say 34.5 ETH. My votes now counts for 34.5 ETH and when I'm earning rewards, I'm earning rewards on that 34.5 ETH. And that will see kind of instantaneously. So it's kind of nice that this feature works for like both ends of the barbell in a way.

• 19:37David Hoffman?

  And then I think the last part of this conversation is what this really unlocks for Ethereum with future upgrades. You identified bandwidth as a big bottleneck for Ethereum. It's not the only bottleneck, but it's a big one. Once there is reduced bandwidth consumption by the Ethereum protocol at large, what doors is that unlock for Ethereum in the future when it comes to scaling?

• 19:52Speaker 01

  Yeah, so the big reason we want to use bandwidth for in the medium term is to scale the amount of data we can get L2s to use, which we call blobs. So in the Pectra hard fork, we are also going to increase the number of blobs by 50%. So right now, every block can have three blobs in them on average and up to six in kind of the worst cases. In Pectra, it's going to be six on average and then up to nine in the worst cases. So anytime we can kind of shave off some bandwidth usage, it gives us more room in the protocol. If you assume that you're kind of keeping bandwidth requirements constant to like deliver more data to users of Ethereum. And there's another thing we're doing in Pectra as well to cut some bandwidth on the execution layer. But you can think of this as like all these kind of small gains that we can compound.

• 20:36Speaker 01

  We can then directly translate that into more scale for data, which is what ends up powering all the L2s on Ethereum.

• 20:42David Hoffman?

  Okay, so the bandwidth that we are saving due to Max EB in the same hard fork in Pectra, we are able to take that bandwidth savings and apply it to bandwidth spendings that we can spend on data availability. Is that correct?

• 20:54Speaker 01

  Yeah, yeah, basically. And it's a bit optimistic again, because we don't quite know how much bandwidth will save because we haven't seen consolidations. So there were some cases we were concerned about of like worst case scenarios. And to address those, we've made a change on the execution layer that caps the highest bandwidth block size on the execution layer. So we feel that because we have consolidations coming in and that we have kind of these mitigations for the worst cases on the execution layer, we're able to now increase the blobs security on Ethereum.

• 21:21David Hoffman?

  Right. And just so I make sure I know this. So when Pectra goes live and we go from three blobs a block to six blobs a block immediately, we're going to have a doubling in bandwidth just from blob space. But then the savings from Max EB is actually going to come over time. Because we will need validators to actually kind of update to this new form factor. And so we don't know how much bandwidth savings we're going to get, and it will take time. And then maybe by the next hard fork, we'll actually be able to say like, oh, we actually maybe even underestimated how much bandwidth savings we're going to get. And then we can add that slack to further blob space in the next hard fork, which is Fusaka. Is that right?

• 21:59Speaker 01

  Yeah, that's correct. And then I think. To add a bit more context is we knew we had a bit of wiggle room on the bandwidth side before coming into this fork, but again, we had some concerns about like some like worst case scenarios. So by having some wiggle room and patching these like worst case scenarios, it means we can comfortably increase the blob size now. And then yes, to whatever extent we have like more bandwidth in, you know, reserve by the next hard fork, we can still use that to scale Ethereum. But we also have other plans for how to scale Ethereum more efficiently for Fusaka, which we can talk about later.

• 22:30David Hoffman?

  Yeah. Okay. So we just hit two birds with one stone. We talked about the incoming blob space upgrade. We're getting a doubling in the average blob space going into Petra. And that's just kind of how it's going to be with all future hard forks is like, we're going to identify that we have some amount of bandwidth slack in the system. And then the number of blobs that we get per block is going to just increase according to what the all core devs feels like is safe. So right now we have three blobs per block with Petra, we're getting six. And then that's just kind of how it works. We're going to get a higher number next time. And it's going to be a downstream like kind of calculation of what we think is safe in terms of bandwidth consumption. Is that right?

• 23:05Speaker 01

  That's correct, but there's more we can do to go even beyond that. So one way to think about kind of Ethereum's data availability arc is before we had these blobs, all we had was call data on Ethereum. Call data is effectively data that you store on Ethereum forever. So it's quite expensive to use. And this is why we came up with these blobs. Blobs are data that is stored on Ethereum, but gets deleted after a couple of weeks. And because most L2s only need the data there for, you know, like their exit window and fraud proofs, they were kind of overpaying by storing their data on Ethereum forever when they actually only needed this data to be up for a few weeks. So this is how we got kind of the first 100x cost reduction in data for L2s, which is what we have today. And we can keep improving that amount of like ephemeral data, but in terms of just

• 23:49Speaker 01

  like a qualitative change, we went from data stored forever to data is only stored for a few weeks. The next step we'd like to take is today, even though this data is only stored for a few weeks, every single node on Ethereum stores it. What we'd like to do in the future is move to a world where every node only stores a subset of the data, but then pings other nodes on the network to check. With like high probabilistic guarantees that somebody else has the data. And so what we can say is like, you know, say we have a million validators. We can partition so that we have some fixed numbers of copy of that data. And that the validators are always checking like, okay. Is there someone who can prove that they have the data?

• 24:30Speaker 01

  And this is kind of another qualitative leap where we go from everyone has the data forever to everyone has the data for some amount of time. To everyone has a subset of the data for some amount of time and uses cryptography to check that other people have it. And this is the main thing we're working on for the Fusaka upgrade. It's called PeerDAS, but that's kind of the high level idea of going from not only do we have blobs that take up some amount of bandwidth, but if we're able to only download a subset of the blob data. We kind of go from, okay, every node needs all the blobs to every node needs, say, one tenth of the blobs data. And that gives us effectively 10x increase at the same amount of bandwidth.

• 25:07David Hoffman?

  So maybe just to make sure I understand that there's a kind of like two ways to grow blob space on Ethereum. One is just engineering, which is I think what we're doing with Max C B. We're just engineering more efficient systems out of Ethereum. And then there's like cryptographic step function changes, which is what you're saying with PeerDAS. In addition to that, where, you know, with engineering, we're going to get a doubling with Pectra. We're going to go from three to six. Great optimization was exactly what we want. But then with cryptography, we are going from like one to 10 or even something much higher than that. And both are happening in parallel.

• 25:38Speaker 01

  Correct. Yeah. And then, you know, so the plan, you can think of like before, before Pectra actually introduced the blobs, then Koo. So it's like, then Koon was kind of like research getting into production. And so we got this like step function change. And then in Pectra, we found like some optimizations and we can kind of improve things. And now we have this other kind of research to prod feature called PeerDAS going into Fusaka. And then even when PeerDAS ships, there'll obviously be a bunch of optimizations we can do to it. So we expect we'll ship PeerDAS with some initial amount of blobs that'll be much higher. Some numbers being discussed or something like going to 48 on average instead of six. To give you a feel for the order of magnitude or the order of difference. But then, once we have, say, 48 running on PeerDAS, there'll probably be a bunch of engineering.

• 26:21Speaker 01

  Optimizations we can then do to bring that to some like higher number. That's not like, you know, a five, 10x increase. So I think it's like a good mental model to think about it. Yeah.

• 26:29David Hoffman?

  Okay, beautiful. All right. I feel like we've actually covered a decent amount of Pectra so far and a little bit beyond. Is there going back to Pectra?

• 26:35Speaker 01

  Yeah.

• 26:35David Hoffman?

  Are there any other updates making it into Pectra that are worth highlighting? I know there's often just like a bunch of little things that maybe like are too in the weeds to talk about.

• 26:42Speaker 01

  Yeah.

• 26:42David Hoffman?

  But is there anything else, any other stones that we should unturn around Pectra?

• 26:45Speaker 01

  I guess one last big one is EIP 7702. So this effectively is the first in protocol version of account abstraction we'll have on Ethereum. And like I was saying earlier, it's something that's been in the works for a really long time. And the way EIP 7702 works is that you can use any account on Ethereum, so any regular EOA. But you can delegate to an account which adds smart contract functionality to it. So for example, you could have something like I have my EOA. And I want to delegate to something that gives me the equivalent to a safe. And this is kind of neat because it means you can use your existing account with all of your assets and everything there. And you can effectively choose like, oh, this is like the smart wallet I want to run under this account. And you can change this over time.

• 27:29Speaker 01

  So maybe I have like, you know, my EOA today, I want to delegate it to some sort of safe-esque wallet. So I can do that. But then maybe there's like some other feature that I want to use or like on another wallet, I want to use, say, auto approvals up to a thousand dollars. Right? Like I want to have some smart wallets that just gives me a better UX. I'm able to then use 7702 for on that separate wallet or to change a delegation on my previous wallet. Move to a different sort of smart account. So this is a very nice model because it kind of gives the users the flexibility to choose what they're delegating to. To revoke that delegation as well to say like, oh, you know, I don't like this thing anymore. I can go and move back to like not being delegated or delegated to some other feature. And it kind of gives the ecosystem the ability to keep innovating on this, right?

• 28:13Speaker 01

  Where maybe, you know, we expect there's not going to be like hundreds of these different smart wallets. But say there's like, you know, five or 10 that are developed up in the next year that are, you know, well audited, well tested and whatnot. And they're great. People use them. But perhaps two years from now, someone comes up with like a new idea or a new version, they can just go and, you know. Ask people to change your delegation to them. So it's still something that like kind of allows for innovation in the space and doesn't lock you in to say, oh, you delegated once, you know, you use the safe once and now you're kind of stuck with it. Which is how a lot of smart wallets work today because effectively, you know, if you have like a safe account deployed, that is like the smart contract, like the address is the safe. So 7702 is more like your EOA has a pointer to a specific type of smart account.

• 28:57Speaker 01

  And so this is the other thing that'll be going live in Pectra. That's kind of a huge deal.

• 29:00David Hoffman?

  Yeah, this is relatively new to me. So my understanding, correct me if I'm wrong, is that my EOA, which for listeners who don't know what an EOA is externally.

• 29:09Speaker 01

  Owned address.

• 29:09David Hoffman?

  Externally owned address. Wow. Yeah, it's been a while. Externally owned address. And that's just like if that's your MetaMask, that's your Ledger, that's your Rabbi wallet. It just means that it's an account that is owned by something external, as in your private keys is I think what is being referenced externally. And then in contrast to that is a smart contract wallet, which is the owner of a smart contract wallet is going to be an EOA, not itself. Okay, so with this, what you were describing, it kind of sounds like there's going to be some very useful addresses out there with these bundle of features that I'm going to be able to point my EOA to and basically have those features be like absorbed into my EOA or like for some reason I'm getting like

• 29:50Speaker 01

  Correct.

• 29:51David Hoffman?

  Having this mental model of.

• 29:52Speaker 01

  You could think of it as almost like a plugin for your EOA.

• 29:54David Hoffman?

  Plug in, plug in, that's what I needed. Yes. And so I just point my EOA at some smart wallet out there that has been deemed useful by the community and all of a sudden I have those features that correlate to my EOA. Is that right?

• 30:07Speaker 01

  Correct. And then you're also able to change that in the future, which is the other important part. Or because, you know, today you could just set up like a NoSafes and, you know, NoSafes are great, but you you can't change your NoSafes to like something else, right? It's fundamentally a NoSafes, whereas in this model, you're able to say my EOA has like plugin A and I don't like plugin A anymore. I want to go to plugin B. And you can do this and still keep the same address and still keep the same private key that secures the EOA.

• 30:32David Hoffman?

  So it sounds like just a hybrid benefit model of just like there are something properties about my. EOA that I like, but it doesn't have any smart contract features. And this kind of sounds like it's trying to thread the needle of being the best of both worlds.

• 30:44Speaker 01

  Yeah, correct. And this is kind of why it took so long to get to these types of solutions where it kind of blends a lot of what smart wallet developers want with kind of the practical realities of, okay, users have EOAs today. How do we minimize the migration costs? And also, how do we do this in a relatively safe way? And so one example on the safety side was, should we allow this? When you delegate to a plugin, should it happen just on Ethereum or across all of chains? And we felt like it should happen on Ethereum. And that if you're delegating to another chain, you should have to click the button twice. It's worse on a UX level in a way, but it also means that, say, you're using some random L2 and they have some sketchy delegation wallet and you happen to delegate to it. You don't get all your assets drained from every chain forever.

• 31:29Speaker 01

  Or imagine some other ecosystem copies Ethereum, which often happens. And they decide that some stuff is safe that the Ethereum community doesn't think is safe. If you're using your same address on say, chain A and chain B, delegating to something bad on chain B won't automatically mean you lose all your money on chain A. So this is kind of one of these examples where like, okay, thinking through the actual security implications was really important. And I think in this case, we've, yeah, landed on a really nice compromise between giving you a lot of value and functionality to users, while also making sure that there's some level of security in the system.

• 32:02David Hoffman?

  Is this update something like a foot in the door for future improvements on the Ethereum smart contract wallet landscape? Or do you think this is something closer to, and we are done here? Let's wrap a bow on this and call this good.

• 32:16Speaker 01

  I think we'll see more. I think there's a lot around account abstraction that's not part of this. At the very least, the entire arc around not having ETH to pay for gas and having your wallet that manages that is not part of this. Obviously, if you're using an EOA, it assumes there's ETH in the balance. The other part around account abstraction is, okay, what if you want to actually change your private key on an account? That also is completely out of scope from this. So I think 7702 effectively gives us a very practical feature to address most user use cases, which is like, I want to. Delegate to some smart account. I want to do auto approvals. I want to have like some social recovery. So you can address all of these. It doesn't solve everything. It's not like some silver bullet. But we felt it was better to ship something useful short term than to try and like come up with the perfect

• 33:01Speaker 01

  solution and wait for another five years, especially given that people have been wanting something like this for probably already five years.

• 33:07David Hoffman?

  Yeah, I think one of the parties of people that have wanted something like this the most are layer twos.

• 33:12Speaker 01

  Yeah.

• 33:13David Hoffman?

  Because layer twos have had to roll their own code when it comes to building smart contract wallets into their chains. Because we all understand that the smart contract wallets are very powerful, very beneficial. We're eventually all going to have them. Layer twos who have been faster to move than the Ethereum layer one have just beat Ethereum to the punch and just rolled their own code and built their own smart contract wallet straight into their chain. But as a result of that, just like the layer two fragmentation problem is that they have all built their own solution and now there's no standard. So now the Ethereum layer one has some semblance of some standard. How does this conversation carry into layer twos? How does this impact like layer two roadmaps when it comes to smart contract wallets?

• 33:47Speaker 01

  I think, yeah, it helps to say there's like a standard there if there's still a lot to unpack in terms of standardizing account abstraction on layer twos. I do think like, yeah, all these questions around, okay, gas payments or, you know, what is like the default flow you onboard people on or just interoperability across different L2s are things we will continue to spend time on. But yeah, I think for layer one broadly and then for layer twos as a default, seven seven zero two is like a really good practical step. But yes, you will keep hearing about account abstraction debates for the foreseeable future.

• 34:18David Hoffman?

  I haven't heard about smart account abstraction debates since I have been in Ethereum, since like 2017.

• 34:24Speaker 01

  Yeah, right. Yeah, yeah. People have worked on this for a very long time.

• 34:27David Hoffman?

  Okay, Tim, I think that wraps Pectra more or less. Again, there are many other EIPs that are getting into Ethereum in Pectra, but many of them are small. This is kind of how hard forks work. Are those all the big ones that are worth discussing?

• 34:38Speaker 01

  Yeah, I think, yeah, for all practical purposes, yes, there's about 10 EITs, I believe, in Pectra. So there's plenty more there. If you're a smart contract dev, there's things like the DLS precompile that are coming in. If you're a validator, there's also a bunch of other tweaks around the deposit queue and using execution layer with your credentials. So there's definitely more to explore. I wrote an article about it and there's, I believe, going to be a section on east.org about the upgrade as well. So yeah, if you want to go deep, there's a lot to go into, but at a high level, Maxi B, increasing the blobs and seven seven zero two are the biggest kind of new features coming in.

• 35:14David Hoffman?

  Let's talk about timeline because we are currently in the testnet phase of Petra. So some of Ethereum's testnets are being Petra-enabled. They're getting Pectred as we speak. Where are we in the timeline for Petra making its way all the way to Ethereum Layer 1? Like, how soon can we expect Petra?

• 35:28Speaker 01

  Yeah, so if you follow testnets, you'll notice that there have been a few issues.

• 35:33David Hoffman?

  Yeah, there's some drama.

• 35:34Speaker 01

  So we ran into issues on testnet, mostly due to different configurations between testnets and the Ethereum magnet. And the reason we have these is, in short, because there's no incentive and proof of stake to run a testnet. So we kind of have to come up with these ways like, okay, how are we going to test stuff if no one wants to run a node? So we have two testnets right now, Sepolia and Holeski. Sepolia has a whitelisted validator set. So because we want it to be stable, we said only like client teams, infra teams, and like, you know, whoever else is like a professional operator that wants to do this can run it. So to actually run a Sepolia validator, you need like a special ERC20 token, which means the deposit contract on Sepolia was different.

• 36:17Speaker 01

  And so we ran into some bug because of like how the deposit contract on Sepolia was structured relative to Maitland. Before that, though, we ran into another issue on Holeski where Holeski has an open validator set, but we wanted the ability to like mint some amount of ETH and kind of configure the network a different way. Because on Gordy, we ran into all these issues around like not enough testnet ETH going around. So we fixed all of this, but then when deploying the Holeski testnet, because of some changes, the deposit contract address was different. And we also ran into some bugs because some clients like effectively assumed that it was the same. And so because of this, like the testing process has been a bit like curveballed with like relatively minor configuration issues that ended up kind of delaying things.

• 37:02Speaker 01

  And then because the effective validator sets, especially on Holeski, they ended up kind of making it much harder for validators, especially staking pools and people with more complex setups, to test the entire lifecycle on the net. So to address this, we actually launched a new testnet today called Hoodie. So the idea is to have this new testnet from scratch, have it have an Open validator set that people can use. And this is kind of our last step towards testing Pectra before we go to mainnet. And the idea is that we not only want Cordevs to test Pectra, which we've been doing and can still do on Sepolian Haleski, but we want people like, say, Lido and Rocketpool to test this, especially because there's so many of these features like Max C B,

• 37:44Speaker 01

  but also some other features around how exits and withdrawals are processed, that it's really important for them to get right before this goes live on mainnet. So testnet launched today. The Pectra hard fork is happening on this testnet next Wednesday, which is March 26th. For people listening, after that, we expect it'll take a few weeks for, you know, staking pools and other people to just test their entire infrastructure on the network. You know, they have to go and redeploy everything and make sure that it all works. And for all of these staking pool projects, it's not just a set of smart contracts, right? Because they run all these validators, they have oracles. So it's a fairly complex setup. So that is kind of the last part of testing that we want is we want to make sure things work well for them before we move to mainnet.

• 38:26Speaker 01

  If we found something that, you know, broke, how staking pools manage exits or something like that, we'd obviously want to reconsider when we move to mainnet. So assuming all of this works smoothly, the earliest date we said we would fork mainnet was 30 days after Hoodie has this Pectra fork activated. So, you know, from March 26th, that would be late April. It's possible that we have a few weeks after that, that there's like some testing to be done. You know, we realized there's like some minor issue to fix. But I think we'd be looking, if things go relatively well, sometime around May for Pectra.

• 38:58David Hoffman?

  Okay, so May is the happy case for.

• 39:00Speaker 01

  I'd say it's like, yeah, the base case, like, you know, maybe we find some minor issues or stuff like that. But, you know, if we find some major issues, something completely wrong, it would go beyond that. I do think at this point, we've, Pectra's been tested quite thoroughly. I don't want to bet on this. Like, I feel like if I say, you know, we're all good, then we will find something else as soon as I drop up this call. But I think base case is like May is a reasonable timeline.

• 39:23David Hoffman?

  Okay, so May is the base case, and then after Pectra is Fusaka.

• 39:28Speaker 01

  Yep.

• 39:28David Hoffman?

  And then after that is Glampsterdam.

• 39:29Speaker 01

  Yep.

• 39:29David Hoffman?

  Just like, I know timelines, as soon as we get any further out, then one hard fork starts to become incredibly hazy.

• 39:36Speaker 01

  Yep.

• 39:36David Hoffman?

  And we don't really want to like, set any expectations. But understanding that, can we just like, draw a like, hazy cloud of timelines for Fusaka and Glampsterdam?

• 39:46Speaker 01

  So, for Fusaka, I think there's a couple of things that are really important. One is, we've been working on Fusaka for quite a long time now. So the two main features for Fusaka are Pirdas, which we talked about a bit earlier, then EOF, which is a big overhaul of the EDM. Both of those things, we've been working on in parallel to Pectra for like, over a year now. So we have devnets, you know, they're running, the specs aren't completely frozen, but you know, we have pretty stable specs that are being iterated on and kind of getting the finishing touches. Which is very good, because it means we're coming into this next hard fork and we have the bulk of the code for the hard fork after for Fusaka already written. I think there's a very strong desire across the entire community, both core devs and, you know, everyone else, to see a larger blob increase before the end of 2025.

• 40:31Speaker 01

  So that's been the rough target for Fusaka. So saying, you know, like, we want to ship Pirdas, we want it to happen this year. I think what this means is, if there's any other feature in this fork that say were to delay Pirdas, we would just remove it. So we'll probably keep the scope for Fusaka relatively small. We want to finalize the scope for Fusaka around April this month. So the hope is that, you know, when Pectra has gone live on mainnet, we already know everything that's included. And, you know, nothing else is being considered, but then even for those other things, if we find some weird issue or bug or delay, we would probably err towards removing them to make sure that Pirdas can ship in 2025. And then I think the risk there is, if there's something unexpected with Pirdas itself, obviously Pirdas is the most important thing to ship. We will do everything we can to ship it this year.

• 41:16Speaker 01

  But the reason the hard fork timing conversation is hard is because so many of these things have like, a heavy R and D component to them. So, you know, if there's like, an unknown unknown, it can be hard to predict like, oh, you know, we didn't know that this issue would show up because this thing did not exist three months ago. I think the fact that we've been working on it for over a year. Means there's a reduced chance of that. But yeah, you can't completely write off the chance of like, okay, you know, we move forward. PeerDust, we see that there is this thing to fix with it and like the quickest path to scaling Ethereum is still to fix this thing. So I'd say everyone is trying hard for 2025. It's unlikely to be anything else than PeerDust would be like the cause of a delay. But if something happened with PeerDust or some like big unexpected twist, obviously that can always delay things.

• 41:58David Hoffman?

  Cello is transitioning from a mobile-first, EVM-compatible Layer 1 blockchain to a high-performance Ethereum Layer 2, built on OP stack with EigenDA and one-block finality, all happening soon with a hard fork. With over 600 million total transactions, 12 million weekly transactions, and 750,000 daily active users, Cello's meteoric rise would place it among one of the top Layer 2s, built for the real world and optimized for fast, low-cost global payments. As the home of the stablecoins, Cello hosts 13 native stablecoins across seven different currencies, including native USDT on Opera MiniPay and with over 4 million users in Africa alone. In November, stablecoin volumes hit $6.8 billion, made for seamless on-chain FX trading. Plus, users can pay gas with ERC20 tokens like USDT and USDC and send crypto to phone numbers in seconds.

• 42:43David Hoffman?

  But why should you care about Cello's transition to a Layer 2? Layer 2s unify Ethereum, L1s fragmented. By becoming a Layer 2, Cello leads the way for other EVM-compatible Layer 1s to follow. Follow Cello on X and witness the great Cello happening, where Cello cuts its inflation in half as it enters its Layer 2 era and continuing its environmental leadership. In the wild west of DeFi, stability and innovation are everything, which is why you should check out Frax Finance, the protocol revolutionizing stablecoins, DeFi, and Rolex. The core of Frax Finance is Frax USD, which is backed by BlackRock's institutional Biddle fund. Frax designed Frax USD for best-in-class yields across DeFi, T-bills, and carry trade returns all in one. Just head to frax.com, then stake it to earn some of the best yields in DeFi. Want even more?

• 43:25David Hoffman?

  Bridge your Frax USD over to the FraxTal Layer 2 for the same yield plus FraxTal points and explore Fractals' diverse Layer 2 ecosystem with protocols like Curve, Convex, and more, all rewarding early adopters. Frax isn't just a protocol, it's a digital nation powered by the FXS token and governed by its global community. Acquire F X S through frax.com or your go to Dex stake it and help shape Frax Nation's future. Ready to join the forefront of DeFi? Visit frax.com now to start earning with Frax USD and staked Frax USD. And for bankless listeners, you can use frax.com/r/bankless when bridging to Fraxl for exclusive Fraxl perks and boosted rewards. Introducing UniChain. Built for DeFi, empowered by Uniswap, UniChain is the fast decentralized Layer 2,

• 44:08David Hoffman?

  designed to tackle blockchain speed and cost challenges. With this mainnet now live, you can enjoy transactions at up to 95% cheaper than the ETH Layer 1, all while benefiting from an impressive 1 second block time that will be getting even faster very soon. UniChain is the first Layer 2 to launch as a Stage 1 rollup on Day 1. That means it comes with a fully functional permissionless proof system from the start, increasing transparency and further decentralizing the chain. More than 80 apps are joining the UniChain community, including Coinbase, Circle, Lido, Morpho, and Uniswap. You'll be able to bridge, swap, borrow, lend, and launch new assets and more from Day 1. Built by Uniswap Labs, the team behind the protocol that's processed over 2.75 trillion in all-time volume with zero hacks, UniChain truly enhances DeFi experiences with faster, cheaper, and seamless

• 44:52David Hoffman?

  transactions even across chains. And soon, the UniChain Validation Network will allow anyone to run a node and earn by securing the network. Visit uniswap.org and swap on UniChain today. I want to read a tweet from Vitalik that I'll also share on screen here. He tweeted out, this is on March 1st, so about a little over 2 weeks ago. He says, "For 2025, we need Fusaka on the Layer 1 with pure DAS, ideally with 48 blob target, 48 blobs per block." And then he falls up saying, "Let's aim to get a Fusaka testnet with these blob parameters running the day after Pectra goes live." Now, I don't know, Tim, if there was any previously established expectation on blob count for Fusaka prior to this, but this was,

• 45:34David Hoffman?

  in my interpretation, something like a doubling 2.5x more aggressive blobs per block than I expected to have by the end of this year. Maybe you could check me on that. And then also just kind of like fill us in on what the reaction was around the all-core devs space around this tweet.

• 45:50Speaker 01

  Yeah, I think people broadly agree with this. Maybe some of the caveats are one, you know, whether the devnet goes live the day after Pectra goes live or not. Like, again, we already have a pure DAS devnet up, so we are, you know, getting close to this. And I think at a high level, the- The thing that's still somewhat undecided is, is the best way to test this to start with the highest possible blob count, say like 4872, and then kind of work backwards from there? Or should we try to like, run pure DAS with say, you know, the same number of blobs, make sure that works, and then ramp up, ramp up, and see what breaks? I see the value in both approaches, but we haven't quite made a call yet. So you could imagine something where we decide to test pure DAS with like, a lower number of blobs,

• 46:33Speaker 01

  and you know, we're like doing, I don't know, say 1836 or whatever, and that goes well, and then we try 2440, and then that breaks, and we feel pretty confident in 1836. It might be the better move to just ship this, and then in the fork after that, go from like 18 to 42, or whatever. So I wouldn't necessarily commit on a specific number. I think everyone agrees that we want to get there, but it's really hard to know, like, okay, is there some weird point where things break between what we have now and that number? And we should figure that out before we ship it. One other idea we've been considering is, maybe we should ship pure DAS, if we're like, pretty confident that, you know, we can reach this high number, but we still want to make sure, we could ship pure DAS with kind of like an escalator increasing

• 47:18Speaker 01

  blob count, where we say, okay, when the fork goes live, maybe there's like, actually not even a blob increase, but then two weeks after that, it goes, you know, from 6 to 8, and then two weeks after that, from 8 to 10, or something like that. And this could be kind of nice, because it would maybe let us make sure that at every step of the way, things are smooth, and then if there is like, some major issue at some point, you kind of have enough time to intervene. So the exact rollout to get to that number is still being discussed, but I think broadly, people agree we should have this in 2025, we should go for like, a fairly aggressive number, but we want to make sure that, you know, we don't just overshoot and then miss out on like, some, you know, 2, 3x improvement over the status quo, because we're trying to go for closer to 10x.

• 47:57David Hoffman?

  Understanding that the all-core devs community, group of people, are like cautious by default, I'm still getting a hint, some like rumblings, that there's just more appetite for aggressive numbers, my aggressive scaling numbers. Maybe you can kind of comment on that vibe, like loosely, like, what is the appetite for aggressive scaling numbers, or just like, more aggressive shipping around the all-core devs community?

• 48:19Speaker 01

  So I think, there's definitely like, a renewed, I don't know, interest, or say like, accelerating?

• 48:26Speaker 01

  That said, you know, the blobs have been live for like a year, right? Like a year ago, we shipped like this reduction for the call data to blobs. This year we'll ship hopefully Pirdas as well as kind of this increase with Fusaka. So I think it's true that it's always been kind of a priority to scale. Maybe the thing that's changed recently is realizing that this should be, if not only the only priority, but like part of a much smaller subset of priorities. I feel like the perception or the thing that kind of gets awkwardness is not just like, people don't care about scaling, but they care about scaling and 19 other things. And then being able to focus and saying like, okay, scaling is the only thing, or like one of the few things that actually matters in the short term and we should double down on that.

• 49:07Speaker 01

  I think that sort of like vibe shift has happened, definitely on the consensus layer. I think on the execution layer as well, there's been more thinking about like, what is the right role and what is the right thing to optimize for? So now that we have, you know, L2s in production, I think everything around the MEV space as well has kind of settled a bit, where for the past couple of years, it wasn't quite clear what, you know, proposal builder separation would look like, what would the bottleneck be? Now it at least feels like we have some good understanding of what is like the topology of the execution layer. And we can actually identify bottlenecks and be like, okay, you know, this is the thing that's preventing scale there and this is the thing that's preventing scale there. And start addressing those.

• 49:50Speaker 01

  I think historically, yeah, it's been hard to do this because there's many moving parts and the execution layer has less of a like clear lever or clear thing to tweak. You know, we have the gas limit, but the gas limit is kind of an aggregation of all these different things, right? Like all the op codes, all the state growth and all of that. And now I think we understand much better, like, okay, these are all the inputs that go into it. And these are the things that will break at these levels. And so we can kind of prioritize solving them. But yeah, renewed focus, I think would be the right way to frame it. And that said, you know, it's still like an open process, right? There's still people who disagree with this, there's still like different perspectives. I think this is something we want to be cautious of not losing where, you know, Ethereum is very valuable because of this like plurality of thoughts and of contributors.

• 50:35Speaker 01

  So while you want to like focus people, if you overdo that, then it's easy to just have everyone kind of feel excluded. And, you know, you end up being like a very small circle and everybody else is left.

• 50:46David Hoffman?

  Okay, so we've pinned down Pectra.

• 50:48Speaker 01

  Yeah.

• 50:48David Hoffman?

  We're in the process of pinning down Fusaka.

• 50:50Speaker 01

  Yeah.

• 50:50David Hoffman?

  Fusaka is mostly pure DAS and increased blob counts. But then also this thing called EOF.

• 50:56Speaker 01

  Yeah.

• 50:56David Hoffman?

  Which I have just learned as of this morning is called Ethereum object format.

• 51:00Speaker 01

  Yeah.

• 51:00David Hoffman?

  I don't know what that is. Maybe you could enlighten me. What is EOF? And why are people so excited about it? Because when I asked Twitter about like what I should ask you on this episode, Tim.

• 51:08Speaker 01

  Yeah.

• 51:08David Hoffman?

  EOF was a pretty common thing that was brought up by people. And I don't know what the hell it is. So please inform me.

• 51:13Speaker 01

  Yeah. All right. So the best like non-virtual machine expert analogy I've heard is Ethereum's virtual machine is kind of like a 1950s computer. And EOF makes it like a 1990s computer. So the EVM.

• 51:27David Hoffman?

  It's still on 2020s.

• 51:28Speaker 01

  No, no, we are, we are like, yeah, literal decades. And I think this is correct because, you know, computers are very hard or complex. And Ethereum needs to be super secure. So it's reasonable to say like, you want to have a limited feature set. Like, we don't want to do everything that modern computers do on the Ethereum virtual machine. Because we keep finding bugs in those. And there's a lot of debate around EOF. But I think like at a very high level, this is kind of the gist is, do you think like a 1950s style VM is sufficient? And like minimal enough and we can just build everything else on top? Or do you think we should actually take the time to improve it to go to something like the 1990s? Which is not to say we bring it to like the absolute cutting edge of computer science. But it's like, we add a bunch of things that are kind of pretty table stakes that the EVM lacks.

• 52:11Speaker 01

  And some like, you know, pretty high level parts of this is just like separating code and data in the EVM. So right now, when you have like a smart contract, the code and the data that's stored in that code can be kind of all mixed together. And for a bunch of toolings, it's much easier if you're able to say, okay, like this is the code. And this is the data that goes into the code. And, you know, current EVM contracts do not have things like that. There's a bunch of just like specific opcodes that, you know, we lack that make it, you know, just writing compilers and writing programming languages on top of the EVM easier. The other thing as well with EOF is there's a bunch of things that we would like to ban in the EVM for different reasons. That you sort of can't do on the main EVM because contracts use them. But now with EOF, it kind of get this like fresh start.

• 52:56Speaker 01

  Where we're able to say, okay, like now you can't do those things anymore and these types of contracts. And maybe to zoom out a little bit, like the way EOF works is it's effectively like a versioned type of the EVM. So you'd see like if a smart contract has an address that starts with these specific things, it's an EOF contract. And if not, then it's not one. And that's kind of the high level idea is just saying like, okay, for like these new types of contracts, which are upped in, we're not like forcing anybody or like deleting any old contracts. We just have like more functionality. We have like some better kind of data management of what's in the contracts. And we kind of remove some stuff that we feel is just like not super valuable and kind of problematic to a lot of the longer term Ethereum roadmap items.

• 53:40David Hoffman?

  So is this mainly an upgrade to just the developer experience for people who are writing solidity? Or like whose life is enhanced the most here?

• 53:47Speaker 01

  Yes, and it would be like one level underneath that almost. It's like an upgrade for solidity and other languages on top of it, right? Like you can think of the solidity is constrained by what the EVM itself can do. And so by improving what the EVM does or how it is like structuring the work that it does, then we can improve the experience of the people who write compilers and write programming languages. And then also, I think, again, back to security, anyone who's actually looking and trying to analyze what contracts actually do, and especially in edge cases like auditing and stuff like that, DOF also helps with some of this.

• 54:21David Hoffman?

  Okay, I'm finding it hard to analogize about this, but I think I get it. There's just like a very low level structure of how the EVM works. And we're just upgrading it. It's just getting better. It's going from a Toyota Camry to, which is something very dependable and very standard, but maybe kind of clunky, to something like a Volvo, which is also very dependable, but a little bit more polished.

• 54:40Speaker 01

  Yeah, yeah. And I do think the 1990s like example, I don't know if it's perfectly accurate. I'm not like a VM expert, but I think it gives a rough sense of. The level of like complexity as well. So a lot of the objections to EOF around complexity and whatnot. And while it is true, it's a big upgrade. It's also not saying like, okay, we are going to take like the absolute cutting edge, you know, of like how computers are built today. Like Saturn, what Apple, whatever they do in like their chips, but like, and then do that. Like we're still, you know, in relatively basic territory.

• 55:11David Hoffman?

  Okay, great. So that's Petra, that's Fusaka. Is there anything else left in Fusaka worth highlighting?

• 55:16Speaker 01

  Yeah. So we haven't finalized the scope for Fusaka, but I think like I was saying earlier, one thing that's clear to everyone is we want Pirdas to ship as soon as possible. So a few of the client teams have already signaled what they'd like to see in the fork. And generally the sentiment is that Pirdas and EOF should be the only two big things. We should maybe include like some select amount of small things, especially if they're like some security related or like, you know, very like easy low hanging fruits. But we should not try to do too much. And actually, Petra used to have Pirdas and EOF as part of the single fork. And last summer we realized that was way too much and we decided to cut it. So you can think of Fusaka as like the two big things, EOF and Pirdas, that were originally in Petra, but felt like they warranted their own fork.

• 56:02Speaker 01

  And approaching it with that mindset is probably the right approach. Saying like, okay, we already had way too much stuff. Now we like ship the first half, let's just ship the second half, maybe, you know, add a couple of small tweaks. But not try to like do the same mistake again where, you know, instead of having like EOF and Pirdas be the ones that are moved out. We add a bunch of stuff and realize six months later that it's too much. Those two are already pretty big changes. So we should like, yeah, stick close to that if we can.

• 56:28David Hoffman?

  And then after these two comes Glamsterdam.

• 56:30Speaker 01

  Yeah.

• 56:30David Hoffman?

  My intuition is that Glamsterdam, we know the name, but it's just so loose and nebulous about what's actually going to go in it. It doesn't really have an identity yet. It's just kind of this placeholder name that we know is coming, that we're going to deposit. Things that we want into it at a later date in time. Is that kind of the vibe?

• 56:45Speaker 01

  Yeah, that's correct. And one thing that we're thinking throughout the Alcor Devs level now is. We've gotten better at paralyzing, working on the forks over time. So like now, you know, what's coming in Fusaka, we've been working on for like the past year. One sort of experiment we'd like to move towards is, okay, if in the, say, in the next month or two, we have the scope for Fusaka completely finalized, can we already start planning to Amsterdam so that, you know, a few months after that, we know exactly what's in Amsterdam and teams can start working on it? And then, you know, we start looking at the next thing. And there's a limit on this because a lot of the times, like, you want the same people to look at it all, right? Like you can't, you can't completely replace people and just have, say, you know, like, Group A decide what's in the fork and Group B implement it because

• 57:30Speaker 01

  Group B will probably have like high context around what should go in and the risks there. But I think just getting better at paralyzing like the planning of the fork and the implementation so that as soon as we're done with one, you know, we have prototypes for the next one and we're kind of ready to make it the main thing. Hopefully we can do that so that, you know, Amsterdam is set up in the next few months in terms of scope and we're starting to talk about what's next while we start to prototype Amsterdam and ship Fusaka.

• 57:53David Hoffman?

  Okay, and this kind of just all goes back to a related conversation about just like Ethereum, all core devs being just more aggressive and ambitious about upgrades. Maybe not ambitious, but just learning to really make processes for all of these things and learning where can we take up slack in the development system? Because, you know, Ethereum's greatest strength is that it's decentralized, it's rough consensus, but that produces its like weak underbelly, which is, you know, it's low, it's low. And we have these like centralized, smaller competitors that are really taking advantage of this. And so like learning to have faster upgrade cadences, that energy is coming out of like this angst in the Ethereum community of like Ethereum just goes so slow. Why does it have to go so slow? And well, there's very good reasons why it has to go so slow, but it sounds like the all-core devs calls, they are finding some slack in the upgrade system that they are

• 58:38David Hoffman?

  taking out of just via operations and process. Is that right?

• 58:41Speaker 01

  Yeah, and I think you could think of two causes to slowness. One is like process and operations and we should obviously remove all of that slack if we can. And the other one is just due to like R and D being hard, right? Like, so again, to take PeerDust as an example, or even something that already happened, take like the merge. When we started working on the merge, like we knew this was the priority and we made it the priority number one. But as you work on it, you find new stuff, you find new issues. You should still keep working on the merge, right? It's still the most Important thing. So I think a lot of the time, like there's all these proposals saying like we should hard fork every six months or every quarter or whatever. This sounds good in theory, but imagine we were doing this, say for the merge. And it's like, okay, we mixed the six months deadline. Do we just like ship a bunch of random, less useful stuff?

• 59:24Speaker 01

  It's like, obviously we should not like, obviously it's still the highest important priority to ship the merge. And so, you know, if it's going to take an extra six months because there's something fundamentally hard about the merge. We should still be willing to pay that cost. And sometimes this can stop being true, like maybe. Like the merge was probably the most consequential upgrade, but you could imagine, you know, there's something else we work on that we think is the highest priority. And then we realize it could take an extra year. And the fact that it takes an extra year might mean it's no longer the first priority. But I think that's like a different type of solonist from saying like, okay, are we spending six months like waiting around to figure out what to do? And that latter type, we should obviously just, you know, get better at that. And I think we have over the past couple of years and a lot of it has happened fairly informally.

• 1:00:07Speaker 01

  So I think now we're at the spot where we can start to say like, okay, this is how the process actually should work. And we have all these components. We're like, yeah, we're already prototyping these hard forks, you know, one after the other. We already have like this news intuition that we should know what comes next. So let's just like make that a real commitment and say like, okay, by this date, we finalize the scope. By this date, we expect to start prototyping. And if there is like some hard R and D or engineering issue, like obviously we'll take the time it needs to fix it. But it's not like the process slowing down the engineering. And so I think like, yeah, we are trending towards that and hopefully we'll get that so in the next year.

• 1:00:40David Hoffman?

  So Tim, you probably have, out of anyone, the most context for how all core devs works and how the Ethereum upgrade process works, or just Ethereum broadly. What's the most frustrating FUD or misconception you would like to clear up? Since if you're the high context individual around your domain and then there's, you know, 10,000 low context individuals tweeting bullshit on Twitter. What's the most annoying thing that you hear that you would like to address?

• 1:01:06Speaker 01

  So I think. One thing that always is weird is when people talk about things being delayed before there's been like a date set to them. And this is kind of part of my like, you know, engineering unknowns process. And I've struggled to find the right way to deal with this because everyone wants like to know when the upgrade is gonna happen. You know, like I just said, Petra will happen sometime in May.

• 1:01:27David Hoffman?

  Probably.

• 1:01:27Speaker 01

  Yeah, this is like my current base case, based on like everything I've seen and I know, but like it's not scheduled for me, right? Like we don't have like a date that says like it's May 18th or it's May 7th or it's May 23rd, whatever. And so there is a point where like we do schedule that thing and say it's like a month out and then it is like actually a delay to say like, okay, it was scheduled for May 13th and we found a bug and it's now May 28th. But I think like, yeah, the hardest part is figuring out how do we talk about things when they're still in the uncertainty level while not falling either into like, we say like Fusaka is gonna ship, you know, on October 15th and then it doesn't. But then the alternative is saying like, okay, it'll ship when it's ready and it ships in 2027 and Ethereum's become irrelevant.

• 1:02:09Speaker 01

  So I think on both sides, I kind of feel this pressure of like, what is the right level of granularity to give to stuff based on the current level of uncertainty? And I don't think we found like the right way to communicate that, to say like, okay, this is like a six out of 10 certain for like this window because there's like these and these like unknown unknowns. If like I could somehow fix that, I think it would make a lot of the like perception issues much better.

• 1:02:34David Hoffman?

  One thing we haven't talked much going through some of these hard forks, Petra, Fusaka, Glancor Dym, is scaling the layer one.

• 1:02:40Speaker 01

  Yep.

• 1:02:40David Hoffman?

  So where does the conversation around scaling the layer one rank in priority? What does that conversation look like? How does that conversation fit into the future of Ethereum?

• 1:02:48Speaker 01

  So I guess by scaling the layer one, this means scaling the execution layer, right?

• 1:02:51David Hoffman?

  Yeah, scaling the execution layer between just gas throughput and/or decreases of block time.

• 1:02:56Speaker 01

  Yeah. So I think this is something that's been like getting more and more attention. Again, you know, there's like bad ways to do this and they have like security issues. But what I was saying earlier is now I think we understand a bit better what some of those bottlenecks are and what the ecosystem looks like. So there is a renewed interest in it and at least a better understanding of, okay, for example, You know, state growth was one of the things that over time like stopped us from scaling the layer one. But then paradigm did a bunch of research last year and realized like it's maybe not as much of an issue in the short term, up to some levels than we thought it would be. So like, understanding like, okay, actually, history growth is like a bigger bottleneck on node in the short term. State growth will become a bottleneck on nodes, you know, in the medium term. And then, you know, we have these other bottlenecks at different places.

• 1:03:41Speaker 01

  That feels like it's improved a lot in the next year and in the past year and will continue to do so. And this is kind of the fundamental challenge here is, you know, again, we have the gas limit, like we can say, we just increased the gas limit. And that is kind of our very like coarse lever, but it would be good to understand like, what is exactly the effect of doing that? For example, one other effort that's been happening recently is thinking about can we reprice opcodes in Ethereum? To make a bunch of stuff cheaper because it's currently overpriced so that, you know, we can keep the gas limit the same, but there's a bunch of stuff where we can increase the amount of those operations in a block, you know, for fixed size. So a way to frame it is on the consensus layer side, we have like a very clear North Star, just like, okay, how do we like scale the blobs?

• 1:04:26Speaker 01

  On the execution layer side, the North Star is clear, the gas limits, but the mechanisms are like the inputs to it are just like much more complex than on the consensus layer side because the consensus layer, you just have like some amount of data and you're trying to figure out how to send this, shard it, distribute it efficiently. So yes, I think it is like important to scale the L1 and people are working on it. But there's just a bit of a clear understanding of like, okay, this is the actual short term practical thing. We kind of have 10, you know, different things that people are working on and hopefully those kind of compound together. Yeah.

• 1:04:57David Hoffman?

  The conversation of scaling the layer one is just so multi variant and there's many different inputs and that makes it complex. And harder to like really optimize, whereas with scaling blob space is like pure desk and blob targets.

• 1:05:09Speaker 01

  And again, like it's not like an impossible thing on L1, but I think we're now in a better spot to like actually start to tune those knobs than we were a couple of years ago. And, you know, to give you an example, like just the idea of like, okay, where does the block get built, right? There's something that's changed a lot because now most blocks get built through like MEV and one of the things That's kind of a bottleneck on this is like, when should the block be verified? And the way that like block verification works, it's just like, you know, you kind of build this block, you verify it all within the current slot and then you're good. But now because of NEV, people want to wait until the last possible second to actually build a block. So we have kind of less time for verification, which is fine now, but if we scale the gas limit, it becomes a problem. So if we know that we have like high resource builders that can build these blocks very efficiently,

• 1:05:55Speaker 01

  should we just delay when we actually verify them and say, okay, you build a block for slot one, it gets verified in slot two. And that's probably a way that we can, you know, leverage the way the ecosystem has like been set up to scale the L1, but it's something that wasn't as obvious, say, two years ago. That's just like one random example, but it's all these types of things where, okay, now that we actually understand things better and the equilibria are a bit like better set, we can have better intuitions for this. And hopefully this means we will scale the L1 as well. I think there's a more applied research work to be done there.

• 1:06:27David Hoffman?

  One last conversation, Tim, before I let you go, just the conversation around interoperability and fragmentation of layer twos. Is any part of that conversation actually in scope for all core devs? And if so, what is in scope for the interop conversation for all core devs calls? Cause I think that's mostly in the ecosystem standards thing. So it's outside of all core devs calls, but to what point is that actually a conversation that is talked about in all core devs?

• 1:06:49Speaker 01

  So there are some cool protocol things we could do. The challenge is they are a lot of work and they make a lot of like complex assumptions. So they will take years to ship. So yes, like this is something we think about, but it's not gonna happen in like the next six months. So I think if you're looking in the short term, then going all out on like, what can you do at the application layer in terms of standards is the way to go. But longer term, like, yeah, Justin has this idea around, you know, native rollups, right? You can imagine this being a direction we go in where we say, okay, there's like a common pre-compile on Ethereum that rollups use and that because we know they're all using this, they can interoperate better and get kind of, you know, L1 guarantees around this. The challenge is this is like an extremely complex piece of code that, you know, is custom to every rollup now.

• 1:07:34Speaker 01

  So we need to figure out like, okay, what is the right abstraction to have? On L1, how do we test this? Rollups are very different like performance and security guarantees than L1. You know, they're kind of architected in like a different way. And so it is going to be years of work to figure out what is the right set of abstraction that kind of works for rollups works for L1. But yeah, I believe pretty strongly we should do this. Like, I think if you think Ethereum L1 is kind of like a utility provider for like rollups. Like, we need better plumbing and infrastructure and stuff there. And we should also be willing to say like, okay, after consulting with everything that existed, we think this is the right approach. And, you know, nudging existing rollups to migrate to that.

• 1:08:14Speaker 01

  Like, I'm pretty bearish on the idea of like Ethereum creating like an L1 and try and roll up or something like this to like go and compete with what exists. But it should be fine to say, hey, these are like some standards, say contracts on Ethereum or protocol features that give you interrupt features that give you security. But you're going to have to migrate to adopt them. And obviously, the migration should be possible for rollups. Like, it shouldn't be something that says like, oh, yeah, you have to completely abandon your project and start a new rollup. But yeah, that entire process of just designing the right thing, getting people to adopt it, but not, it's not going to happen within six months. So in the short term, I'm very bullish on just app level and wallet level standardization.

• 1:08:51David Hoffman?

  Tim, this has been super informative. I've learned quite a lot. So thank you for coming on and just helping me run through some of these things. Is there anything that I haven't asked, any like stone I haven't unturned about any of the near term hard forks in Ethereum or anything adjacent to that?

• 1:09:04Speaker 01

  No, I think we've covered a lot. Yeah, can't think of anything right now.

• 1:09:06David Hoffman?

  All right. Well, one last thing before I let you go is Summer of Protocols. This is something that we did on Bankless, actually, the first Summer of Protocols. If maybe listeners missed those episodes, maybe you can talk to them about what Summer of Protocols is because I'm reading your tweet here. Summer of Protocols is back for 2025. Just to give the listeners a little bit of context of what's going on here.

• 1:09:25Speaker 01

  Yeah. So the idea with Summer of Protocols is that when I was working on Ethereum a couple of years ago, I realized there's not a lot of analogues for this thing I work on, right? Like, if you're like a software engineer and you think about like writing good software, there's a lot of ways and like frameworks, whatnot, how do you write good software? If you're like starting a company, there's a lot of like frameworks for how do you run a startup? And there's not much out there in terms of how to work with protocols. And this comes up often when people talk about Ethereum, right? They say like, oh, Ethereum is like this tech platform or ETH is money or ETH is like a world computer. And so there's like all these different aspects that represent part of it, but are not kind of a full picture. So in 2023, when we launched this, we wanted to figure out, can we actually understand protocols better? And so we funded a bunch of researchers in many different domains to

• 1:10:10Speaker 01

  study protocols and try to see, okay, do they have some common like learnings? And it turns out that they did. Last year, we wanted to test, like, does this actually work in production? So we funded a bunch of people to like, improve protocols in different domains. We had some people working on like cryptography protocols, some people working on like wildfire management, some people working on plurality voting, and figure out like, okay, are there like more like applied things of how you do your work with protocols that we can generalize? And we also found there was a bunch of stuff. Now, in 2025, we feel like we have like all this knowledge, but it's very poorly organized, it's a bit chaotic. And so we want to try and make it understandable for the world. So what we're funding is a bunch of teachers and educators

• 1:10:52Speaker 01

  to try and take everything that exists and kind of condense it in different types of classes, online courses, books, and whatnot to like, have a sort of unified explanation of how all of this works together. So if you're interested in this, we have our kickoff this Friday, March 21st, but you can also go to summerprotocols.com and get all the info. And then all the research we've published over the past two years is just up there and free for people to read. But yeah, it has been really exciting to try and think through like, okay, how should we think about Ethereum better? And one unexpected side effect of the program is a lot of like really smart people who don't necessarily care about blockchain, or even like some of them just straight up don't like crypto, have been like really willing to engage with us. And I found like, talking about Ethereum problems through

• 1:11:37Speaker 01

  the lens of like, I have a protocol and it has these problems, has been really helpful to like, learn from them and exchange with them, rather than saying like, okay, this is like a crypto thing, or like a crypto economic problem that we're trying to solve. So yeah, that's the idea behind summer protocols. It's run by Venkatesh Rao and Timbershroff this year. So yeah, check it out.

• 1:11:55David Hoffman?

  Yeah, I'm listening to the episodes that we put out on Bakers about some of these researchers that went out and did their research about protocols, and then learning about kind of the connection points between seemingly very disparate ideas as it relates to protocols. And a protocol is already something so incredibly meta, like Ethereum isn't one thing, it's actually a collection of things. Things being held up by all these different client teams is something very meta. And then now we're talking about learning about protocols. So we're already getting even more meta than that. And so like, kind of learning from these perspectives of these researchers, protocol researchers. It felt like, kind of like touching the metal of the universe. It's like, something feels very close to like, the byte code of how this universe is working. And so I thought it was very, very interesting. I'd never got any sort of education about anything related to that anywhere else, other than some of the episodes that we did.

• 1:12:40Speaker 01

  Yeah, and maybe one last thing on that, like, Venkat framed it really well. It's like, if you think of the fields of economics, before we had this idea of supply and demand, people still bought and sold stuff to each other, right? So you could maybe walk around the world and be like, oh, this person's selling cows and this person is selling boats and whatnot. And like, you could build an intuitive sense of like, oh, more cows means like, the cow price is lower. But then, you know, you kind of have Adam Smith come in like, okay, like, we can formalize some of these concepts and say like, this is a way to think about these things that are already happening. This is, I think, like, the cleanest, most possible example. I don't know that we'll get something as concise for protocols. But that's a rough idea, saying like, you know, protocols exist, people obviously work on them, they improve. But they are kind of different to like, the way they're instantiated.

• 1:13:25Speaker 01

  Like, the best practices for software development don't all apply to Ethereum. And the best practices for like, how you are like, the legal practice, don't all apply to like, international relations and like, how you do like, you know, multinational protocols in terms of conflict. So I think trying to surface like, what is a better way to frame those things is the goal. And yeah, hopefully this cohort gets us a bit closer to that.

• 1:13:47David Hoffman?

  Tim, thank you for joining me on Bankless today.

• 1:13:48Speaker 01

  Yeah, thanks for having me.

• 1:13:50David Hoffman?

  Bankless Nation, you guys know the deal, crypto is risky, you can lose what you put in. But nonetheless, we are headed west. This is Frontier, it's not for everyone, but we are glad you are with us on the Bankless journey. Thanks a lot.