Monad: The Parallelized and Supercharged L1 EVM | Keone Hon & Jon Charbonneau

Transcript

Hey everyone, if you have been listening to Empire, you know that Santi and I are fed up with unaffordable fees and frustrating transaction speeds that make the on-chain experience basically unusable. So, the Arbitrum team reached out and they showed us the platform. They showed us what you can do on Arbitrum. Whatever you're doing, you can experience frictionless transactions at lightning speed on Arbitrum. So, head over to portal.arbitrum.io and check it out. What's up, everyone? Before we jump into today's episode, I'm excited to share Empire's first-ever security partner. Harpie is the best tool to prevent your wallet from theft in real time. Harpie is not just a security solution, they are a piece of mind solution. But, don't just take our

word for it. Harpie is the only wallet security solution that protected 100% of its users from attacks like the Ledger one in Q4, which was an off-chain signature attack. To learn more about Harpie, click the link in the show notes or visit harpie.io empire. What's up, everyone? Before we jump into the episode, little plug for Digital Asset Summit coming up in London, March 18th to 20th. Tickets are pacing so far ahead of schedule that we had to decrease the discount code. So, instead of Empire 20, it is now Empire 10. Head over to the website, Digital Asset Summit, DAS London, March 18th to 20th.

Use code Empire 10 and get 10% off your ticket. See you in London. All right, everyone. Excited for this ep. Uh today is taught we're talking Monad. Uh we have Keone who's the one of the co-founders of Monad. We got Santi. Of course, we got John Charp, uh co-founder of DBA. So, John, Keone, welcome to the show, guys. Thanks so much for having me. Yeah. Yeah, pumped to have you here. So, I think the best place to start, there's a uh big conversation to be had about kind of integrated versus modular, I guess you could call it monolithic versus modular. Bunch of conversations that you can have about like the kind of technical optimizations you guys have made at Monad. There's a wide-ranging conversation we can have here. Keone, I think the best place to start would be to pick on you because you spent a lot

of time actually working on Solana when you were at Jump. And I'd love to hear kind of like the thought process behind like what happened in your head when you said, "Okay, we need to go build this. We have a conver- There's a decision that you can make. We could either go build something on the SVM, we could go build something on the EVM, we could do a roll-up on the EVM." Like, how did you settle on building what you guys built with Monad? Sure thing. Just to give a bit of background, um so I've been working for I guess 13 years now um about 10 years in the high-frequency trading space, and then started Monad about 2 years ago along with two other co-founders. So, right at the start of 2022.

But, before that, or immediately before that, I was part of the crypto team at Jump. Um and Jump is a um big supporter of Solana. Really, Jump was really excited about um what Solana had done in terms of building a really performant integrated blockchain um with high performance and low fees. And as a member of the team there, um we just spent a lot of time seeing applications that were getting built that couldn't be built in other environments where the low fees were an enabler and ultimately could allow developers to build applications that can cross the chasm um from Web3 into Web2 and and um have the potential for

mainstream adoption. I think that you know, normal people hate paying $3 ATM fees. So, why would they be okay with paying $10 Uniswap transaction fees, not to mention the slippage that they're going to experience um interacting with liquidity that's mostly not near top of book. Um and the space of solutions is still um pretty nascent overall, and there's a need for much more performant EVM. Um EVM is the dominant standard for smart contract development. It's like the JavaScript of of Web3. And there's just a need for much more performant EVM. So, while I was part of the crypto team at

Jump, um supporting builders who were building in the Solana space among others, um I just along with uh my co-founder James, who been working with since 2014, mostly as a high-frequency trader together, we just realized that there is this need for more performant execution and um no one is building it. So, ended up leaving Jump and um decided to start Monad with this vision. Nice. Why did you guys Okay, so once you Sounds like the first decision there is like, we need to go build something better. Second decision is, let's go do it on the EVM. Then there's another decision that you can make, which is, do we go build a roll-up or not essentially? Or do we go build like an L2 or do you do what Monad did, which is Monad is a EVM-compatible L1, right? Um

how would walk me through that decision? Yeah, I think that with any startup, the decision-making about what to focus on should be driven by doing something that is unique in the space. Um so, whenever there is an just like a like a glaring need, um and it seems like no one's building that, that's automatically something that's going to be more helpful to the space overall. Um so, that was one thing was that we could just see that no one is really working on um performant parallel execution.

Um but, I guess beyond that, yeah, I would just say that EVM is the dominant standard. Um EVM is um you know, most developers are building in Solidity or in some cases in Viper or other languages which compile down to EVM. Um 97% of all capital on chain, all TVL, is in EVM apps. Um so, there's a huge network effect. Um also on the research side, almost all the applied cryptography research is being done in the context of EVM. Like, people don't think about the research part as much, but um there's a huge network effect there as well. So, there's a huge need.

Um but, the yeah, there there's like not as much focus on the execution side. Um to come back to your original question about roll-ups, like, why not build as a roll-up? Um I think it's it's about going in an orthogonal direction that we thought made sense. Um we felt that the throughput of Ethereum at roughly 10 transactions per second, um or the throughput of roll-ups at about 100 transactions per second, um that there was still a huge gap between that and what we felt should be possible given what we know about computers. So, it was a very worthwhile effort to go down the path of making execution a lot more performant. Um and that improvement

is actually orthogonal to the question of of building out um a roll-up mechanism and doing this fractal scaling thing. So, it's just doing something orthogonal. Yeah, how much on the Just coming back to the EVM conversation, now I have another question about the roll-up. How much of the network effects are related to developer network effects versus user metric of versus user network effects? I would say it's 50/50. I think that the there is a lot of tooling that is kind of ingrained that users are familiar with. Um MetaMask, Etherscan, The Graph. Um you know, like these kinds of things that

are common tools. I think that for developers, it is much more appealing to build for the common standard because then there's no vendor lock-in effect. Um developers who are building And maybe I should actually take a step back for a second and just kind of say outright, so Monad is a new EVM layer one um that's offering full byte code EVM compatibility um with really high throughput. So, over 10,000 transactions per second of throughput, 1-second block times, and single-slot finality. So, Monad is basically giving users and developers the best of both worlds between performance and

portability. Um because right now, if you're a developer and you're building application, you're kind of having to choose between um building in the portable way, which is building for the EVM, but then um you know, the environment that the application is deployed in has limited throughput and high transaction fees, like 10 cents to a dollar at least. Uh on Ethereum mainnet, it's more like $5 to $50 even for a simple transaction. So, you can go that route and go portable, but then things are expensive.

Or you can go the other route of like performant, and then transactions are cheap, transactions are plentiful, but now you've built for like one very specific ecosystem, like Solana or Aptos or Sui, um where it's really hard to move out of that ecosystem. So, Monad is really giving developers the best of both worlds between those trade-offs. How much uh is the portability issue like going to be an issue over the next, I don't know, 3 to 5 years? Like, I appreciate like from from your standpoint, you could have maybe done SVM or something.

Um like, is portability an issue that we're talking about today, really focused, but it will be kind of largely irrelevant down the road? I think from from what we've seen in the past with technology, there is basically a common standard that develops, and then it's it's very very hard to change it. Um there may be subtle tweaks, like, you know, like think of HTML. There's like, you know, the different tags, like H1 or div or um BR or what have you.

There's like subtle tweaks to it, but the core is still the same, and it'd be very hard to like come up with a new standard for like websites cuz there's so many websites that are built already, and the browsers are already built to support that. Um So, yes, I think that the the network effect is is massive, um and it would just change what ultimately happened just through like incremental improvements like EIPs that introduce new opcodes and new precompiles. John, what do you think about this um I know you guys are big investor in uh Eclipse, um which is kind of like yeah, is focused on the SVM, and I mean, you can explain it if you want to, but um what do you think about this idea of like compatibility

um and just like kind of Monad's decisions here? Yeah, I I think the two of them actually like highlight really well the differences of like for the reasons of like why should Monad be an L1 or an L2 or whatever. Um I mean, one is just like do what you're really good at, and like Monad team like this is their background. They're really good at optimizing this level of the stack. Like that's what they understand really well. Um the other part is that I think a lot of people still to some extent just underappreciate like how much complexity and how much there is to deal with when you're thinking about building a new L2, and like someone like Eclipse they're thinking about like, okay, this is the VM we're using, and we need to think about like, okay, like which DA layer are we going to use, and like how do we

plug into that, and like how do we settle to Ethereum, and like do the proofing for all of this? Like that on its own requires a gigantic team, and then like everything that Monad is doing requires a gigantic team, which is an orthogonal problem to everything that Eclipse is solving. Um and so, that's why you saw someone like them who okay, you know, we want a super performant L2. What's the way that you do that in practice today is like you just go take the SVM already. Like, hey, this is the one that like the current implementation of it is really good. Like we can ship this thing today, and like it works. It's really good. Um the EVM is not your there yet. Like that's going to be like multi-year work of like the type of stuff that Monad is doing. Um so, it's definitely like a

rational decision to do that. Um part of it is also I would say the timing of it of particularly just like when Monad was started is like I don't think there was like any viable DA solution for them to have like looked at at that time of like Celestia and like EigenDA, and these things were like so far off. Now, if you're building in a super optimized EVM today, like now it could be a consideration of like, okay, do we think about from the start, do we make this thing an L2 using an alt DA? Um and that's what it seems like MegaETH I to my knowledge like that's what they were thinking of doing is like, hey, we have super optimized EVM, and we'll put it on like EigenDA. Um but like when you're building with the constraint of particularly like Ethereum DA, like that

obviously just doesn't make sense in the first place. Um as far as the portability across ecosystems, I I definitely think the trend over time is going to be reducing those barriers at like all levels. Um the question is, I guess, like how much does that reduce at the end of the day? Um because like in theory at the limit, yeah, you would hope that, you know, I just deploy an application, and whether I put it, you know, on an EVM chain, or I use like Neon on the SVM, and like that just works perfectly well, or I'm like using Stylus in Arbitrum, that like everything should hopefully work across all of these ecosystems super well. Um in practice, we still did like quite a meaningful amount of work before that's like actually a seamless experience walking across like working across these ecosystems, and like there's a lot of

work in between there. Um and the like it's just an implementation detail like we can fix this with the engineering is like quite a ways off. Um so, I definitely think the trend is to reduce those barriers over time, but in practice today like there's obviously like very clear barriers still for developers to be working across different ecosystems and same to you. Yeah, I was actually I was thinking about that in light of the part about DA like I was thinking about Antonio and dYdX, and would they have actually gone out and built their own chain if the rollup the rollup stack has gotten so much better in the last 18 months? Like would they have made that decision if uh they were making that decision if they were making that decision today, would they have done that, or would they have just like leveraged all the great

piece of technology? And I guess Keone to like throw John's point over to you as a question like now we have EigenDA and Celestia. Like would you go through this like hard battle of like creating the entire stack yourself if you were launching Monad today? I think that rollups are kind of the new app chains. So, you know, if the pitch to developers in the past was um you know, you can build a new chain that where you have control over um the VM and can make modifications to how the VM works, or run a specific program in the case of dYdX the order book um

internal to the client code, and maybe make it more performant that way. That was always the pitch, and so, the rollups are kind of like the more modern version of that, um but with definitely some differences like from the current, you know, deployments that we've seen so far, the the rollup sequencer is centralized. Um so, that's a huge consideration. Like for dYdX, I think from what I understand, I don't want to really speak for them, but I think the decentralization aspect is important. Um it's not okay to just have one sequencer that's like deciding all of the matching. Um

for various reasons. So, I think that that would be the, you know, probably the reason why they would continue to use the app chain approach. With Monad, uh sorry, go ahead. Yeah. Oh, I was just going to say like for Monad, I think we would still do exactly the our team would still do exactly the same thing that that we've done because I still don't feel that the solutions are all mature. Um and I think there opportunities at all levels of the stack, whether it's execution or consensus, or even the like the piece that integrates those two together.

Um I think there's still need for like very performant implementations at all levels of that stack, and um for us like we wouldn't necessarily be willing to like delegate that optimization to another piece. Um at least not in this current day and age. Like there's still a huge amount of low-hanging fruit from an optimization perspective, and it's really important for ultimately the end users of Monad, the users and the developers to have the most performant system so that um we can get as much performance out of commodity hardware as possible, and deliver really high performance decentralized network.

I want to maybe um you know, take a step back here, and for people that may be pretty uninitiated, like can you talk about like this idea of parallelization? It's it's something that is is a buzzword out there, but I think it's important to just lay the context of what has been when we think about scalability like, you know, single-threaded versus parallelized systems like and the choice that you guys made. I mean, I think it'd be useful to just lay the foundation and then for the subsequent discussion. Sure thing. So, I guess I want to mention two major um points here. The first one is talking about how optimistic parallel execution works, and how that contrasts to other approaches.

And then the second thing I want to mention is the fact that the biggest bottleneck for execution is not the CPU cycles. Like it's not the computation being done. It's actually the state access. So, the actual bottleneck for execution is making it possible to access a lot of state for a lot of transactions in a very performant way. Um cuz I think that's really key to the actual performant parallel execution that's in Monad. Um but sort of like rewinding back to that first point, um so, Monad does optimistic parallel execution. What that means is that the transactions in a block are linearly ordered the exact same way

that they are in Ethereum, and the result of running that linear order is always has to be just, you know, the result from running those transactions one by one in the most naive single-threaded way possible. Um with Monad, the optimistic parallel execution is basically a black box that strategically runs transactions in parallel while always producing the same end result as if those transactions had been run one after the other. And I think that's the first important point to emphasize because sometimes when people hear parallel execution, they're worried that it means that, you know, now a smart contract developer

who's, you know, when their contract is running, like a function is being called by some user, that that function call might be affected by, you know, some other um smart contract that's running in parallel, and that's just not the case. Like the end result is always as if those transactions were run independently one after another. So, that's the first thing I want to mention. Now, how do we do that? Um so, the algorithm is actually a very simple and intuitive one, and I'll try to describe it verbally, um and and see if it sticks. So, um roughly speaking, optimistic parallel execution means running a bunch of transactions in parallel, um as if they're starting from the same starting

point from a state perspective, and then generating a bunch of pending results, where each pending result records the inputs and outputs for that transaction, and then committing those pending results in the original order of the that the transactions were originally defined. Um and as we're going through the process of stepping through those pending results one by one, um inspecting the inputs for that pending result and making sure that those inputs have not since mutated. And if they have, then we reschedule the work, and immediately go re-execute. So, um as you could see from this algorithm, a couple of things jump out. One is that every transaction is executed up to two times. The first time in parallel and

then the second time possibly when it's being run through again serially. Um but hopefully most of the transactions don't have to be re-executed because the inputs have not changed. Um the only reason the inputs would have changed is because one of the other transactions that was being run in parallel um mutated one of the inputs as one of its outputs, right? Um but then the other thing to mention is that even in the event where there is re-execution, that re-execution is quite cheap because the dependencies like the inputs for that transaction are already in cache because they've already been um pulled into cache from the first execution which was running a bunch of uh transactions in parallel.

Yep. That makes a lot of In terms of like give people an idea of how big of an improvement this is, how much of the transactions currently in Ethereum or other networks like that are not running parallel execution like would have this like um conflicting state that you'd have to reor- like rerun it um sequentially? Because like when you think about like you have these hotspots, right? You might have an NFT mint going on and concurrently there's like a you know, people trying to do DeFi on an ongoing basis and there might be a game that's running as well. But you know, for the most part they're all kind of independent. They're not like conflict sharing state if you will. Uh uh but I'm curious if you

if you've done some quantification around how big of an improvement it is um relative to what we have currently. Right. So I understand where your question is coming from. Um and I guess the first thing I want to point out is that um even in the event where there are many transactions that are um conflicting, the parallel execution, this two-phase process, is still a significant improvement. Um and the reason for that is because state access is the biggest bottleneck. So this might be a good segue to talk about the second thing that I was alluding to and then I'll come back to your question. Um but the point that I want to make is that

you know, with these transactions, they're actually pretty simple from a computational perspective. Like if you look at Uniswap V2 swap uh function, it's like doing a little bit of math. There's some arithmetic, uh some addition and division, updating some balances. The compute is actually very, very simple. The thing that's expensive about executing that transaction is that it has state dependencies. Like you have to go look up the balances of uh you know, both of the balances of the two tokens for that Ethereum, state is stored um ultimately inside of a database called LevelDB or they're migrating out another one called PebbleDB, but it's a

commodity database. Um so it's like a high-level database used in many other applications other than blockchain. Um it has a tree structure underneath that is how it the data is actually stored on disk, but it's like a very high-level database for storing data and um the process of reading a value from state um like reading an account slot tuple from state is quite expensive. And the reason that it's expensive is a couple things. One is that the Ethereum Merkle tree data structure, which is how all state is stored, is being embedded inside of another tree structure. So there's almost like quadratic amounts of lookups needed in order to navigate all the way

down to the to one of the leaves in this Merkle tree to like go look up some value. That's one thing, but then the other thing is that um these databases don't support asynchronous IO. So what that means is that when we have many threads that are running in parallel, um running many of these transactions in parallel and they're all trying to go read something some piece of state, they block each other. Um and so effectively the the latency of looking up some value from state um is basically sequential access um doing a call that costs 40 to 100 microseconds or more if there's in the case of this um quadratic uh lookup because of the other

underlying uh data structure. So it's just super expensive to go do a single lookup and all these lookups are kind of blocking each other, so they're all um you know, cascading out the total amount of time to go look up something. So when you implement parallel execution, the bottleneck ends up being that state access. So with you know, just to bring it all back, with Monad, um one of the probably the thing that we've our team has spent the most time on actually is building a custom state database called MonadDB, um which natively stores Ethereum Merkle tree data on an SSD and basically unlocks the power of the SSD um cuz SSDs are actually very high bandwidth. Um they're slower than like storing something in memory, but they

actually you could think of it as a bottle with a big bottleneck. Actually, you can get a lot of data out of SSD um as long as um you have software that can appropriately make all those lookups in parallel. So with MonadDB, there's full control over how the state is being stored on SSD and then that ultimately allows these lookups which are being done in parallel because there's a whole bunch of threads running in parallel, that can proceed much faster. So then this overall process of parallel execution can be much more performant. Um sticking with parallelization, John, there was this tweet um by R89 Capital said uh it's hilarious to me that some .eths haven't figured out that new L1s that parallelize the EVM are long-term

vampire attack on on Ethereum. And you responded, you said, "Look, I generally agree if the EVM alt L1 isn't doing stuff to meaningfully improve the tech and upstream improvements, but there are a couple folks like if you are actually doing X, Y, and Z, then it is basically a meaningful ex- uh it is a meaningful improvement, I think you said." Something like that. And you said, "For what it's worth, from personal experience, Monad is the only L1 that we've seen do all three." Um and I'd love to hear you maybe like expound on that half-baked quote that I just shared.

Yeah, sure. Um yeah, like I th- there's always this debate of like what's cannibalistic to what and like what's competitive with what in crypto. Um and at the end of the day, I mean like got like a million chains. Like ever- everything is competitive and like nothing is competitive to some extent. Um like yeah, if you if you're of the view that like everything's going to sit on one chain at the end of the day, then yeah, then technically everything is cannibalistic to your chain. Um I I don't think almost anyone thinks that and certainly that's not the Ethereum view of the world. So in the Ethereum view of the world, it's like, "Okay, we're going to have a ton of chains." And so like what are the chains out there that like add some level of value back to Ethereum? Um I'd say there's

generally like three kind of different things that I see as like one is like you just directly pay fees back to the chain in some way. So that's what like most ETH rollups that like use Ethereum DA do today is like they are literally just like paying ETH down to the base layer because like they are using the computational resources today in the form of call data if in the future in blocks. Like they're literally just paying money to use the chain. It's pretty direct like you add value back there. Um the second thing I would say is that you are uh in some form um like indirectly I would say more so adding value back in the form of like um kind of expanding the usage of ETH and the ecosystem itself. Um so that would be something more like Eclipse is a perfect example

of that of like they're going to pay almost nothing in direct revenue back to the chain because like settlement costs are like they're super cheap. Like they're going to pay DA costs to Celestia cuz like it's cheaper, but it expands the network effects of like, "Hey, everything's going to be ETH based. Like ETH is gas, etc. Like ETH is money." All of that. Um so like that very indirectly, but like adds like a very meaningful amount of value particularly in the view of the world where like the value of Ethereum isn't like a DCF. It's like ETH being used in the network effects around the ecosystem that makes sense. Um so uh Monad would not have either of those two um as it's like it's a kind of own L1 um and that like is presumably not using ETH directly in any form of like gas or

anything like that. Um so then the last thing is like, "Okay, are you uh in some like software adding to like the network effects in the development around the ecosystem?" Um and so a lot of the work that Monad is doing is like fundamentally work that like anyone else who's building an EVM chain can at some point like learn from and use in the future of like a lot of the stuff that Monad is doing is applicable to Ethereum and other EVM chains like client optimizations that these other teams can make. Um and so that comes down to at the end of the day like I like it's kind of more difficult to measure this of like how involved are you with these different communities and like kind of adding value back? Like what's the licensing all of this stuff that like other people can go use what you're

doing? Um and from personal experience, I I mean like th- like there's a number of teams who are also working around like some similar areas now. Um like um like Avalanche is doing work around like Firewood, their da- databases like similar um other forms of pipelining. I mean like Sei is doing parallel EVM stuff, Polygon. Like there's a ton of people who are doing this stuff. Um so it's kind of just like a subjective measure of like is the team like adding value back and like kind of uh valuable to the ecosystem because at the end of the day like anyone that's working on EVM, if you're doing it in a good faith manner that's like open source work, well then like other EVM chains are eventually going to use this stuff at the end of the day. Like open source software is like never going to be your

moat eventually um cuz everyone else is going to be able to eventually use it. Yeah. Keone, what do you what are your thoughts on just like uh does Monad compete against Ethereum or not? I think I could probably make the argument both ways here and I'd love to get your take. Yeah, Monad is definitely not competing with Ethereum. I think that Ethereum one, from a pure execution perspective, is focused on really high value, low frequency transactions. Um but we think that there's another mode that is really important as well, which is um, individually low value, um, but high uh, frequency or high count transactions. I think that you know, so for example with Ethereum,

Ethereum is uh, delivering about a million transactions per day of throughput. So, that's really not enough to support any single application that um, is able to cross the chasm to mainstream adoption and has hundreds of thousands or or, you know, even millions of daily active users. Uh, whereas Monad with several different improvements that the Monad team has made including parallel execution, custom state database, asynchronous execution, and high-performance consensus, all these things put together, um, is delivering a billion transactions per day, which then is much closer to being able to support a single application that

um, that has a lot of users or that has high interactivity. Hm. How do you think about um, Kiani, so so Monad increases execution. I think most people think about that in terms of increasing the number of transactions. Like that's the first place you went. ETH does a million, Monad could do a billion. How do you think about this in terms of uh, increasing the complexity of the transactions instead of just increasing the number of transactions? Yeah, for sure. So, the the transactions per second is like very much uh, like a simplification. So, Nice meme. Yeah, I think at the end of the day what is important is um, well actually the the real measure is basically gas per second. So, Ethereum supports about 1.25 million gas

per second. Gas is just a unit of uh, work. Unit of complexity. And so, Monad is supporting a billion gas per second, which is about a thousand X. So, you could have transactions that are way way way more complex um, from a gas perspective. You could just have, you know, many both more complex transactions and many more of them on Monad than on Ethereum. Um, but at the end of the day like the capacity is is basically a billion gas per second. Hm. Um, Kiani, do you want to get into there's kind of like when I think of Monad there's like four big breakthroughs. We covered parallelization, Monad DB. Is there anything else you want to cover whether it's like BFT or deferred execution or any of that kind of stuff

that we might have missed? Yeah, well actually one thing I wanted to um, get back to was Santi asked about the, you know, collisions of transactions and what happens if you have people always and it's a good question. Like what happens if someone just submits a whole bunch of transactions that are all tied to each other and you can't Is it Just to make sure I understand Santi's question. Is this about like dependencies between transactions? Is that the Is that the same thing as collisions? Yeah, I think that's his question. Okay. Yeah. Um, so I think maybe to first it would be helpful to just give an example of um, what a collision looks like.

Um, and then I'll also then try to explain why um, the combination parallel execution and Monad DB is ultimately able to make the problem of any collision much less severe than you might otherwise think. So, maybe first of all like imagine that there's three transactions. Um, my USDC account has a hundred USDC in it. And there's three transactions. In the first transaction I send 10 USDC to John. In the second transaction like someone mints an NFT totally unrelated. And then in the third transaction I send five USDC to Santi. So, obviously at the end of these three I should have 85 USDC in my account. Um, so when parallel execution runs, the first transaction

generates a pending result which has an input for that, you know, that slot of a hundred and an output of 90 cuz like my USDC went from a hundred at became 90. The second transaction, let's not worry about that. The third transaction has an input of a hundred and an output of 95. Because these three transactions were run in parallel, so they didn't really know about each other. Does that make sense? Yep. Cool. Okay, so then we go and try to commit these three pending results. We just step through them one by one. So, first we see the first result, which again has an input of a hundred and an output of 90. We commit that one. That's fine. Then we get to the second one.

That one is fine. We commit that. Then we get to the third one and we inspect the inputs and we check to make sure that they're valid. So, we see the input on this third pending result is a hundred. But now that slot has become 90. So, that that pending result is now invalidated and we're going to need to go re-execute it. So, when we go re-execute it, it's re-executed with an input of 90 and then the output becomes 85. Um, and so I said before that the re-execution is not a big deal because that slot is already in cash. Um, the reason why that's important is because reading that slot from SSD is going to be the cost of an SSD lookup, which is 40 to 100 microseconds. Might not seem like a lot, but you know, when you're

operating at that scale that actually does matter. Versus if you that data is in cash, it's less than a microsecond, like a hundred nanoseconds or so. So, basically that re-execution is really fast. And I guess um, the other thing I would say is that there's actually another way of thinking about parallel execution that I think gives a good mental model for what's happening. And that is that the first stage of parallel execution, which is running all these transactions in parallel, is basically surfacing dependencies for all the transactions and pulling them off of SSD into cash. Cash. Right? Um, and because of Monad DB those all those dependencies can be surfaced and read from SSD very

efficiently in parallel. So, that first step is doing this like 40 to 100 microsecond, you know, per um, that that kind of cost really fast pulling all that into cash. And then it is generating pending results, which are like, you know, this is what happened when we ran that execution. But it's almost like the pending results don't even matter that much cuz then when we step through those transactions again, you know, if the pending result didn't the inputs didn't change, we can immediately commit. But even if we need to re-execute, that re-execution is much much much more uh, much cheaper because the inputs are in cash.

Yeah. Is there a capacity constraint to how much you can cash? Um, There not in practice because um, with with Monad the uh, hardware requirement is 32 gigs of RAM, um, which is still a huge amount of memory. So, there's not uh, in practice like that's not really a constraint. Got it. Um, and in terms of um, I'd like to maybe transition a bit into the the actual cost for these transactions. Um, and comparing it to other particularly Solana, right? Which is, you know, really optimizing for highest throughput and, you know, currently really low transaction fees.

Right. Um, yeah, I think that you could think of Monad as like similar to Solana in terms of overall transaction costs. So, fractions of a cent per transaction. Of course, the cost depends on the complexity of the transaction. But for like a, you know, a reasonable like uh, depositing in Aave or swapping on Uniswap, those are really simple transactions. We expect those to cost a tenth of a cent on Monad. Um, and I would actually add that the actual cost is probably just driven by almost an arbitrary parameter in the code base.

Um, like in uh, Ethereum there's basically uh, Let's see how to say this. So, like in Ethereum the cost is actually driven by supply demand and because there's more demand for block space than there is supply. So, there's an auction and the auction clears at whatever, you know, causes those two things to equilibrate, which is a very high number. Um, and that's how you get Uniswap swaps that cost five to fifty dollars depending on the activity level on the chain. Um, so in Monad my guess is that on day one there's going to be way more supply of block space than there is demand. So, the clearing price on that auction should actually be zero.

Um, but of course it won't actually be zero because um, then that would allow anyone to spam for no cost. So, it's really just kind of a de minimis cost um, to prevent spam and still enable any kinds of applications to to thrive without cost being a consideration. Yeah. Quick follow-up question on me and this I'm curious. Um, do you do you guys have anything kind of decided yet on what the fee market from there will look like? Um, because like for for context for the listener, I mean like this is basically where like Solana started as well of like pre because they have so much throughput like, all right, we'll just set like a low fixed number and as long as supply is over demand like they didn't have a problem and just like it's fine. Um, and

now as there's like a ton of TPS, now Solana has started to think about like, okay, like sometimes you do get really really hot spots and so like we do need a fee mechanism to move. Um, so just curious how you like you're thinking about that over time if like a fee mechanism is set to change the price and what that looks like. Yeah, I think it's still a pretty early pretty early ideation on our team's side. Um, but you know, we're happy to sort of follow the research space and and just learn from others. I think that one point I want to make about this sort of like congestion based pricing is that it's not always obvious that uh, an account like a slot that a piece of state that's in high demand should actually be more expensive. It

might actually be that it should be cheaper because if it's cheaper or if it's in high demand, that means it's definitely in cash already. So, I think, you know, the fee design system should ultimately reflect whatever the real cost is, but the real cost might be higher for something that's in demand because it causes more rescheduling, but also might actually be better. And I think we just have to go based on whatever the measurements are. Can you expand on that? I just want to make sure I understand it. If there's a particular thing that's really in demand, and you said it's in cash, are you clearing the cash after every block, or are you preserving that?

I mean, I assume like there's finality, right? And like at what point do you clear the cash, or do you not like I don't know if the question makes sense. Yeah, I mean, the the cash is really uh more of a you know, it would it would vary from node to node on how frequently it gets overwritten um depending on the exact amount of memory that's available. But um but yeah, no, we there's not clearing of the way the caches usually work is like you know, something gets pulled into cash, and then it's like uh uh least recently used cash. So, eventually it'll fall out of cash if it's not been used for a very long time.

Um but yeah, it's not cleared at the end of every block or anything like that. All right, I mentioned them in the pre-roll. Now, I'm going to bring them up again. It's Arbitrum. Santi and I are really fed up with these high fees, and we're really excited to have teamed up with Arbitrum for the next couple of months on Empire. As the leading Ethereum scaling solution, Arbitrum now powers hundreds of decentralized apps across DeFi, perps, NFTs, gaming, and a whole lot more. The team has showed us everything in the ecosystem both now and what's to come, and we're really, really excited about it. Arbitrum allows both daily users and developers to interact with Ethereum at scale with low fees and faster transactions. The way the team got me excited was through

portal.arbitrum.io. So, my call to action to you is to get started by visiting portal.arbitrum.io. Go experience on chain like it was meant to be. For a lot of Empire listeners, your crypto is not just another number on a screen. It's part of your future. I know Santi and myself feel that way. Our security sponsor of this episode, Harpie, takes this responsibility seriously, and is the only wallet security tool that shields users from both on-chain threats and sneaky off-chain signature attacks. If you've ever been in that situation where you're moving quickly, you approve something on chain, and you realize that the address might be a dubious address, or you're really hoping that you could take that back, Harpie has you covered. Harpie can

redirect your assets to your self-custodied vault, ensuring they remain completely under your control, safe and sound. With Harpie's always-on monitoring, you're not just detecting threats, you're actively blocking and recovering compromised assets from malicious transactions before they can even confirm on chain. Harpie is the only wallet security solution that protected 100% of its users from attacks like the Ledger one in Q4, which was an off-chain signature attack. So, if you're serious about protecting your crypto investments, it's time to make the switch. Secure your wallet for free at harpie.io/empire.

That's harpie, h a r p i e.io/empire. You want it to be even easier? Just click the link in the show notes. One of the things that people are really critical of a system like Solana is a higher hardware requirements. Um what are those for Monad on a relative basis? Like if you think about Ethereum being like Raspberry Pi, Solana being on the other end of the spectrum, where does kind of Monad lie? Mhm. Um Monad is much closer to Ethereum. I think the most notable difference is that the Ethereum um RAM requirement is 16 gigs of RAM, whereas for Monad, it's it's 32. Um but that's still much, much less than Solana, which I think is 256 gigs right now. Um RAM is really

expensive. RAM is 100x more expensive than SSD. Like for example, you can get a high-quality 2 TB SSD for about $200, whereas 2 TB of RAM is like $20,000 or more. Um so, with Monad, the reason why the hardware requirements are low is because of MonadDB, basically making the SSD much more usable, much more um able to serve a very performant workload. So, it's because of MonadDB that this memory is actually so low. Yeah. Correct. Yeah, because with with uh yeah, yeah, because the um when you're trying to have very performant execution, you run into the bottleneck of state access. And so, the

two kind of paths to alleviate that, one would be to jack up the RAM requirements so that more state is in cash, and then the other way is by doing all the work to build MonadDB to like make that SSD um like the data that's living on SSD much more um accessible. And and are you going to do what um what Solana did and make it so that validators don't have to know the full state so that new validators like don't have to replay and catch up, basically. I think that's my understanding of how it how it works, I think.

Um yeah, you're talking about state sync. Um that's correct. Okay. I have I have a follow-up uh question on this. I'm curious actually, too. Um and it it's another one of like the major differences kind of between the Solana implementation and the Monad implementation. I'm curious to get your take on. Um so, it it was something that you were touching on before of like the most of the bottlenecks kind of fundamentally here stem from the fact of Ethereum, like the way that we store the state, is like you have it in a Merkle tree, and you stick it in this database. And today, in practice, like most of those databases like are actually just like not built to be doing this like super efficiently of like looking up through the Merkle tree, changing it, etc. Um so, one solution to that is what Monad is doing. Um and what like I I

think some of the work on like Apple and Firewood is like similar to that as well of like, okay, let's just like optimize the database and make it for like looking up and changing this Merkle tree. Um another solution to that or approach to it is what Solana does, which is actually just completely different of kind of just saying like, all right, screw it. Like just like let's rip out the Merkle tree, and like we get rid of that. Um and we just don't get Merkleized in the state. Um and there are like some very different trade-offs of that of like it makes it more difficult for light clients and stuff like that. Um but it does also just kind of avoid a lot of these bottlenecks um around like working around the Merkle tree and like needing to build the database for it. Um I I'm

just curious like how you guys think about those trade-offs um compared to like what Monad is doing. And like do you like what what do you see as kind of the trade-offs in there? Like what do you think is the right or wrong approach? Or like when does it make sense? Um I'm a big fan of SSDs and a big fan of Merkle trees. So, I think that the Merkle tree is actually a very useful data structure for creating a commitment to all of the state um in a very abbreviated way, and that it enables a lot of other things like rollups where, you know, the rollup is posting the Merkle state Merkle root back to L1.

Um or bridges where the bridge is communicating a Merkle root from one side to uh the other side, and then that's a commitment to all of the state there. I think it's a really powerful construct. Um and I'm not really very eager to throw it away, especially given that um you know, we we have this solution that gives the best of both worlds in terms of um offering performant access and offering full Merkle tree support. Um but I could understand why like in the past, maybe it might have made sense to avoid this amount of work to build this database um to alleviate this bottleneck.

To me, it sounds like perhaps the biggest unlock here innovation is the MonadDB. Um do you see a world where other teams even at the Ethereum L1 like moves from Pebble, I think you mentioned, to MonadDB um and unlock like a big improvement? Yeah, I think it's possible. Um the the other thing that Ethereum definitely does want to move to, um and and this is kind of I would say like almost like the third approach instead of like optimize for the Merkle tree, uh get rid of the Merkle tree, um or just use a different type of state tree. Um and this is kind of I I haven't looked at closely, but I believe the approach that like MegaEth is going, um and also to some extent like what Ethereum kind of plans to do

in the future is just like uh to swap at some point from Merkle trees to Verkle trees as just a more efficient form of having the state um and unlock statelessness as well. Um I'm curious like how you kind of view that trade-off, and like what your plans might be for that over time, and particularly if Ethereum does decide to progress and go towards Verkle trees. Yeah, I think that uh Merkle trees are actually quite a nice data structure because um they allow they can actually be updated very efficiently if if done um with a good algorithm. You can update large parts of the Merkle tree in parallel.

Um I actually think that Verkle trees are um sort of going in the wrong direction from a performance perspective. Um so, if yeah, I think that I I understand the the goal, which is to sort of make it so that uh validators can be stateless so that um basically when nodes are validating the network in Ethereum, um they could vote without actually having access to all the state, and then they would just ask other nodes for Verkle proofs of um the balances of various staking accounts and so on so that they can have all the information that they need in

order to vote. Um to me that feels like um it's very much going in the direction of like being able to support like nodes that can validate without uh while having like very minimal requirements. So, it's kind of like going down the I I can understand the vision of like right now there's about 10,000 nodes um in Ethereum that are participating in consensus. And if you want to like go from 10,000 to like 100,000 or a million or something, then maybe it's the case that like node 200,000 to node a million are not going to be able to um like store all the state so that they could participate as a validator.

Um I think that it is still very much a it's like a huge change to like the operation of the node though just to support this like 200 200,000th validator um at a time when Ethereum is also talking about how there's like sort of two quote-unquote too many validators. Now, they're not saying there's too many nodes, they're saying there's too many validators. And there's like a lot of open discussions going on about um just like how the huge number of validators actually creates other overhead on the system. Like it means that the signature has become huge cuz there's a million signatures. Um uh and like things like that. So, I guess I'm not

sure that like it's or in the very least like it's branchy. There's basically a branch that's happening where one camp is saying like yeah, we want to be able to support the 200,000th validator who doesn't have to have all the state and we'll go through all this stuff to like introduce Merkel trees so that the witness size for like this these other nodes being able to request uh witnesses to attest to like these balances of these other validator accounts. It's like a whole lot of work to do that. And then the other camp which I would say the Monad team is much more in is like how do we make fundamentally like the execution of the internals of Ethereum much much much more efficient so that we can raise the throughput of the system and you know, still with like a very decentralized

node set and very reasonable hardware requirements so on get way more performance out of the system. But you know, inherently that does mean making decisions that that do prioritize performant execution. And I would say Merkel trees are much closer to be able to being able to support performant execution. So, therefore they're like pretty incompatible with uh the the idea of like the Merkel tree and that that direction. Timmy, what do you think of the recent uh idea to raise the gas limit on Ethereum? I think it was from a couple months ago.

But uh Vitalik commented on it as well. Yeah, I think it's a good idea. Um I think that it would alleviate to a certain extent some of the costs the extreme nature of some of the costs. Um and I think yeah, this is just a personal opinion, right? Like everyone literally every single person in the Ethereum community has different opinion about it. But um for me like it you know, right now it's kind of true that um like Ethereum block times are 12 seconds, but the execution budget is a gas limit which is chosen to correspond to like 100 milliseconds or so worth of execution time. Which is only 1% of the total block time. So, that's crazy because it means that there's this like

shrinking factor of 100x of execution throughput because of that like gas limit that's being imposed. Um and for a 12-second block time like you could definitely imagine that budget going from 100 milliseconds to 200 milliseconds without really like having a significant effect on the um on the overall like stability of the network. Yeah. I'm I'm going to pull us out of the weeds for a second here. Um there's this like a inherent friction in L1 in L1s and honestly outside of crypto in general just like in in protocols um which you which is that one day you start a protocol and you innovate on it and you do everything differently and you figure

out all these optimizations. And then if it gets big enough, eventually there's actually pressure there becomes pressure to not change things and to uh basically you need to ossify the system. And as that happens, you have to like slow down the rate of innovation. And I'd just be curious about like how you think about that as it relates to Monad, when that will happen, like what how do you Yeah, how do you think about that in general? Yeah, it's a good question. I mean, it's obviously a trade-off. Um Solana is a good example because I think they do ship improvements pretty frequently. Um but then that creates more risk of outages. And so like the recent outage that was like a month ago or so. Um you know, that was like a new feature

that got added and then um so so yeah, Solana is like very much on the extreme end of the spectrum of um trying to ship many features as fast as possible. Um and sometimes it leads to like liveness failures and that you know, contributes to um negative sentiment about the the blockchain and the its ability to um service financial rails for the rest of the world. So, I I mean, I would say it's like it's a trade-off, but obviously there's a way to do a lot of both. Um but that just comes from more effort like more rigorous testing, more um testnet environments that are running in parallel to mainnet that are complete

replica of how mainnet looks. Like I think on Solana mainnet, the real TPS is like you know, a thousand or so transactions per second, whereas the devnet is like 70 transactions of usage per second. So, there's still more that could be done to like make that dev environment more similar to the production environment. Um but it just requires work. It requires cycles, human cycles. Um and sometimes when you're trying to go really fast, you're devoting more um you know, more to speed like to the the engines at the back of the rocket ship versus the ones that are like steering it and keeping it safe. So, I I don't know. I mean, the only answer

is just to work harder and to but to be very rigorous and to have rigorous practices with respect to like rollouts and rollbacks. Um there are some I think some learnings there that are very concrete. Do you have a uh vision for the for the protocol? Like when when we we've had Anatoly on um and he clearly loves Linux, I would say. Um and like he kind of looks at uh Linux and like like Linus as like this kind of model for how to maintain it and how to be a founder in this open protocol. Like do you have that with Monad? You constantly hear him say you know, I want to bring Nasdaq on chain. Like you know, this idea of like single shared state really valuable.

Doesn't include perhaps all the use cases, but that's something that he's very focused on. As you think about like the mind share that you want to capture, the type of use case or builder application that is perhaps most well suited for Monad. Is there something in particular that like you would impress on the builder or the user that wants to come to Monad? I'm really focused on supporting um developers that aspire to build things that have mass user adoption. So, in my mind I always have this idea of like um people playing Runescape and you know, like acquiring items and leveling up their character and earning

achievements. And like for a blockchain to be able to support that level of complexity of application, let alone that level of number of users like literally millions of users um it's just going to require you know, a much faster car than um you know, the solutions that we have right now. So, I think that for any app to cross the chasm of adoption, probably for me the closest was Stepn. Um cuz like you know, a lot of people just understood the you know, the the premise. Like go for a run, you know, like record your steps, uh earn some achievements, like have something to show off your friends, earn some badges.

Strava on the blockchain. Like that's something that can appeal to a lot of people. But you're going to need a lot of performance in order to support that. John, where do you think Monad fits in in this landscape of like we have L2s, we have Solana, we have these DA folks, you know, with Celestia and um Eclipse now and we've got you know, EigenDA and all this kind of stuff. Like where does Monad fit in in like your mental model of the crypto landscape? The interesting part for me that I'm curious to see um is kind of like like what what ends up being the community and the kind of users of Monad. Um of in particular like how

much overlap kind of is there with the Ethereum community versus how different is it? Um like that is something that I mean, like Solana was on the far end of which seemed like a trade-off at first, but I think it ended up benefiting them clearly in hindsight is that you had a like completely separate and completely unique community of like these are just the people who go build Solana and the SVM. And like that's really difficult, but if you do make it through to the other side, like okay, you have like a unique community that like really sticks it through and like keeps building. Um Monad is in like somewhat of a middle ground of like there is a meaningful amount of clearly like kind of bootstrapping off of like using the EVM's network effects and everyone is building around that etc. Um while at

the same time doesn't fit as cleanly into the mental model and architecture of someone who's like entirely obviously relying on the Ethereum community of like you we're just a an Ethereum roll up that uses for DA, like, you know, we have ETH as gas, like Optimism, like that kind of thing of like we are very much like built on Ethereum and like 100% this is the community that we want to kind of like reuse and build on top of. Um Monad is in like a middle ground where like they clearly have done like a great job and this is probably the thing that I underestimated the most in the last year actually of like having a quite unique community um because my reaction candidly when I first heard of Monad like whatever it was like a year ago or something at this point was just like oh

like like it's another like all-in-one EVM, like aren't we like kind of past that? Like are people going to get interested in this thing? Um even if the team's great, the tech's great and all of that, like that sounds like really hard to like get people to care about that again. Um and was completely wrong about that. Like they've done an amazing job of that over the past year of like getting a community of people who like care about this thing. Um and I I think that that is going to be kind of their place if they're successful is that they are able to get like a genuinely unique community that like really cares about Monad and isn't just like hey, we are like recycling everyone that's in Ethereum and just like putting them on another chain that's like faster and cheaper and like kind of does the same thing. Um

it's going to be like do we actually just get people who aren't just like you know, obviously copying Uniswap and just like okay, we like go put it on Monad now it's like a little bit cheaper and the users move over. It's like no, we have teams that like go build on Monad from the start and are just like we build here, like this is our community and like get really into it. Um if Monad's going to be really successful like that like that's what they're going to have to do. Um and thus far, I mean like obviously still early days, testnet live, all of that, but like have done a great job of that um and that that's one of the things that I think Monad has understood like very well over the past year is like they need to do that for them to be

successful. I mean still like genuinely have like a unique community that like cares about and like builds there with Monad in mind. Keone, how much of um of uh building an L1 has been about community? And like I guess maybe differently phrased like how much of an L1 do you think is about the tech stack versus just the social layer? I think it's um I think the tech stack can enable usages that maybe are unique and that the tech stack is kind of the the backbone um upon which you know, the backbone of the the beast so to speak.

But the social layer is like the biggest part probably 80% um I made that number up. That's obviously like uh you know, how would you measure that even? But I think it's just Measure it by the number of people uh fighting to get into the Monad uh Monad private private Telegram chat. Right. Yeah, yeah. Yeah, there's certain KPIs. I mean, I think that for crypto overall, the thing that that crypto has as a superpower it really is community cuz like with any like traditional tech startup, their Twitter will have like you know, 100 followers and they'll put out a tweet and like two people will like it.

And it's the you know, it's like someone on the team and then their their mom who liked the tweet. So I think there is actually like this incredible superpower from having all these people that care about the product and are eager to try it and eager to give feedback and eager to get involved. Um and there's a financial aspect for sure, but it also goes beyond that because people literally like make really good friends with other people on the internet just through their participation in the in community. Um and then the community is all built around a mission. I think that you know, like in this day and age like it's hard to meet new friends um and it's hard to like find things that you really like believe in that are

your mission and that's something that the crypto community overall has is like decentralization's really important mission, self-sovereignty really important mission, owning your own data, owning your own assets um and composability, like the idea of having open APIs where people can build an application and then someone else can just build another application that atomically like utilizes that other app as a subcomponent, can build more powerful things um by leveraging this composability aspect. Like these are all fundamental aspects of the technology that um you know, go beyond the pure tech and also are about philosophy and like things that we value, things we believe in. So I think that that's the thing that makes

me the most bullish about the space overall is that you know, like we have the ability to change the world and then individual people are just passionate. You know, like if you're it's similar to being like an Apple super fan. Um but in crypto like you can actually change the outcome as an individual user. So I think that that's that's incredibly powerful and that ultimately uh for crypto to succeed, we have to really embrace that community aspect and use that as our superpower. I I'd say like uh not that my opinion matters much, but in a world where like people have some fatigue of like the incremental cost or to attract people is I think getting higher and higher as we have more L2s,

as you have the Aptos Sueys. And so there are people that are saying like do we need another L1? And I I think we should always continue to explore the design space because we're nowhere near I think reaching a state where we can see billions and billions of users. But I think something that you said which I definitely agree with, I think it does start with a really good tech at this point. Like it I would be hard-pressed to think of a project that like doesn't have much tech um and has can attract community early on, like if there's speculators for the airdrop, whatever, but sustain that community over time and attract a really good ecosystem of builders.

I think that most most teams, a lot of them will probably fall short of the expectation. But if you have really good tech, I think medium to long-term you thrive and you win meaningful mind share. But that's probably going to take five year, you know, another cycle or two to really play out. Cuz you're you're seeing right now projects that you know, the airdrop craziness and you know, is that community? No. Not really. Right. Right. Yeah, I think that um you know, the thing that our team has done really well in terms of cultivating community and it's really not my doing.

It's it's literally just all members of of our team who have really stepped up and then individual community members who have really stepped up. It's like kind of going against the grain in terms of not giving in to like whatever the easy KPI win is. So like I see a lot of people making the mistake, projects making the mistake of like oh great, like I have this many people in my Discord, that's awesome. Oh, there's more people joining, like even more awesome. Like even more people chatting, volume of messages sent, like this is good. That's actually bad because it actually kills community because if you have a bunch of bots that are just chatting um then the people who actually know each other are trying to hang out, you know, the bots totally like kill the vibe. Um and it's like almost anyway,

that's the thing that's really unique about the Monad community is that um like if if our team did any steering, I would say it was just to like be anti-bot and anti low-quality like contribution and just you know, like make it a place that's actually enjoyable to hang out in and enjoyable to hang out with your friends in. John, what is your um working model of I I want to ask you guys both this question. Um of basically what happens how how much of the world moves on chain? Cuz I I guess I'd say like okay, there's Poloniex if you guys have like read Poloniex's blog and that's basically like it's only going to be money and identity. And then there's the other end of the spectrum which is like the crypto will eat the entire world, everything will every single thing and

application will eventually move on chain. And you're seeing this like interesting thing play out with Farcaster right now where like some stuff is on chain, some stuff is off chain. I think it's making people maybe rethink what does go on chain, what doesn't. So I'd love to I'll ask the same question to both you guys, but like what's your working model of this? And John, I'll throw it to you first. I have almost no idea and I think pretty much everyone has almost no idea. That makes two of us, my friend. Yeah, I like I I think and this is part of the thing that like also makes like the you know, everyone arguing over these architectures like fun is because I think you can make like a very coherent argument that like 99.9% of the important things in crypto will happen within like 100,000 TPS and I think you

can make an equally compelling argument that it will take like 100 billion TPS to get like 99.9% of value. And those two are just like radically different outcomes of like what like what is the type of stuff that you think we need to put on chain and like what is the order of magnitude of like actual transaction count for that? Um I I genuinely don't think that there's like any way you can reasonably come up with the correct answer within like orders of magnitude. Um particularly because I mean like the the like limited view is like okay, only the things that touch money is the like small view of crypto. Like like only things that touch financial applications in some form is like a incredible amount of things that we probably don't even like think about on a daily basis. Um things that like touch to even to like a

minimal minimal degree and like anything that like touches identity and all these different things. Um so I my general view is that like we need to kind of build for and the likely outcome is that it is just like a like a an amount of compute and transactions that we like can't like honestly kind of reasonably intuit about as a person of like oh, we need to build for like a million TPS. I think you just need to build for like effectively infinity. Like at a certain point is like what you need to start thinking of like the whole system as. Um and like that is the direction we'll move to over time and it will just be much more background of like you're just not aware for so many of these things that like everything is on chain. And the way that like for far

far for something like farcaster of it's not like every single button that you click is an on-chain transaction, but there's like a minimal amount of infrastructure that is like makes sense to have for these things on chain in the background. And I think more of those things will start to make sense over time. And once it starts to be okay, there's just like this background infrastructure for so many different use cases. I mean this is like like an amount of transactions can be that it's like you kind of like can't reason about it's like it's it's a lot of transactions. They're going to be a ton. I think the question is like almost somewhat of like how like how present to the user is that going to be? And I think a lot of it will probably be abstracted away for like stuff like farcaster. Like you don't need to know

that stuff is on chain when you use farcaster for the most part. It's just like it's just a social app. And I think more stuff probably moves in that direction and same with financial applications. Today it's clearly very present, but I do think that we move in that direction of over time of like it's an obscene amount of transactions that we like can't really reason about. That means you're going to need a lot of chains and like a lot of it will be kind of more background stuff. Yeah. overcome. Keone, what do you think? I think that it's kind of like how a mall-esque just grows into whatever the size shell that it has.

So, you know, if we have an environment where we have capacity for several billion transactions per day, then we can actually enable apps that that got to using you know, tens of millions of transactions. And it's not a design consideration, but up to now a lot of the design is really predicated on the assumption that transactions are very very expensive. Storage is very very expensive. Like, you know, committing anything to this like shared global database thing it's really expensive. And so that we have to be very very stingy about what we commit.

And then, you know, things will just evolve to to take advantage of the space. But of course the first thing like John said is just to to lay the foundation to like make it really cheap, make transactions really plentiful, and then and then see what can what can come from that. Nice. I have a maybe one or two like business model questions actually and then we can start to think about wrapping it up unless Santi and John have anything else they want to talk about or ask you Keone, but I guess my first one's like blockchains are this weird blend of like where you have a weird blend of two customers, Keone. You have like the user as your customer in a sense and then the

developer is your customer. Who like when you close your eyes and think about the your customer of Monad, who is your customer? So the ultimate customer is really the users because the users are um you know, willing to like pay some value for services. Um they're paying perhaps the money in the form of transaction fees or um application specific fees or slippage or what have you if they're trading slippage. Um but ultimately that's that's the ultimate end customer. Um but of course as a platform like our you know, our job is to support

developers who are then going and providing valuable services to those users. Um So I guess, you know, in my head I have this idea of like, you know, you're building a mall and you want to um yeah, like the revenue of the mall or like the yeah, the basically the revenue of the mall is predicated on the revenue of the individual stores inside of it, which is ultimately you know, driven by the value like the customer is the like how much the customers are willing to spend when they come into the stores.

But you could you know, make the mall much you can make it much easier to open a store in the mall or you could you know, make the roads going into the mall much better so that it's easier to like bring more inventory in or you could have buses that bring users in. So there's a lot of still things along the side that Yeah. that one can do to like help grow the businesses that are inside of the mall. I've never I've actually never thought about the the mall analogy. I've always thought about like almost cloud where like like AWS would say that the end user organization is their customer and then that cut that end that end customer, right, will like will pass will basically market to the users, but it's not AWS's role. Um yeah.

Yeah, I mean the other thing I want to mention is that in Ethereum um users like the end users end up paying about $3 billion per year in fees just to the Ethereum network. And then, you know, some of those fees get distributed to validators, some of them get uh burned so then contribute to deflation. But overall it's like a $3 billion a year business, which is massive. Um but it's, you know, supporting about 300 million transactions per year. So people are paying on average $10 per transaction. So it's very catered toward like you know, usages where one transaction is worth more than $10 to

that user so that they're willing to pay that $10 fee. So but you know, our thesis is that there's many more users who would be willing to pay some fee, but probably not $10. Maybe they'd be willing to pay like 1 cent cuz they're getting like 10 cents worth of utility to do this transaction. So they're willing to pay 1 cent. And so there's just like this whole larger space of users that are currently not able to use applications right now. And so you couldn't build a business that then caters to those users. Um would you agree that perhaps where we'll see the most amount of innovation and optimizations going forward are on dynamic pricing and fee markets?

Less so on hardware like you know, other optimizations? Um are you're saying like after after Monad or just Yeah, just after Monad like in general. Like it feels like one of the more unexplored or things that we're perhaps may not know today is because we don't have as many users and when we have more users and hotspots John, you made this great point. Solana's now figuring this out which is they need to make some modifications. But it's one of those things that you don't really know until you have 100,000 users, a million, a billion, 10 billion.

Like I feel like that's more of my point where we're going to have to probably reserve some pretty large wiggle room margin to make some changes on how fees are set. I see. Yeah, I think from from the Monad engineering team's perspective, we feel like even beyond the initial launch of Monad, there's still a lot of other improvements to be made that are in the realm of either performance optimizations or additional features like support for new pre-compiles or opcodes that allow developers to build more powerful applications. So it's not there's still like a whole like realm of engineering-y things that are not

necessarily fee-related. I think from the application perspective, I would expect to see applications that have like, you know, more novel mechanisms of capturing more value. Like the extreme example is Uniswap where you know, it just seems from the team's public comms that there's frustration about the fact that you know, there's a ton of users coming to Uniswap paying a lot in fees back to Ethereum directly, paying a lot of fees back to Ethereum indirectly in the form of MEV, like a lot of slippage with then which then creates an MEV opportunity where then the searcher then goes and takes, you know, captures the value but then pays it most of it back to Ethereum. So

there's like from the app developer like Uniswap's perspective they would want to be able to capture more of that value that's currently all flowing to validators or to the Ethereum network. Um but that's only possible if like the baseline fee is much much lower and the interaction can be much frequency of updates by market makers. So there's like a whole like technological improvement that needs to be made in order to enable a business model where then maybe Uniswap could capture more value either for their LPs or maybe for their token holders or maybe even for Uniswap Labs.

Like who knows? But right now some of which is so much is just being paid out baseline because of the way that the technology works. Yeah. Keone, is there one other ecosystem that you've like studied that you think whether it's like Sui or Aptos or Avalanche or Solana that you think is like done a phenomenal job? Or maybe I'd even push you one step for like if you weren't building on Monad, like is there one ecosystem that you would go build in?

Um probably Solana, honestly. I guess that maybe that's what you would have guessed, but just the you know, overall ecosystem's focus on performance I think aligns well with what um what I really value. I think there's still a lot of low-hanging fruit for optimization in the Solana space as well. So like that's how you end up with a project like Fire Dancer. Like nothing is nothing is is mature. Like there's still opportunities to add a lot of value in a lot of different places. Yeah. John, Keone, it's been great, guys.

Any any closing thoughts, final things that we missed that you feel like we should should should discuss or should we call it here? I think we hit most of it from my side. This was a ton of fun. Yeah, good here. Thanks so much. Cool. Thank you, guys. Keone, John, appreciate it. Santi, as always, be well, sir. Thanks everyone for listening. Really good discussion. Thank you. Everyone, Jason here. Thank you so much for watching today's episode. Wanted to take a quick second to thank today's title sponsor, Arbitrum. We know you are tired of on-chain experiences that have unaffordable fees and frustrating transaction speeds, and that's why we partnered with Arbitrum. You can experience frictionless trades, lightning speed, and lag-free transactions, all for pennies per transaction. Explore Arbitrum's

expanding ecosystem at portal.arbitrum.io. That's portal.arbitrum.io. See you for the next episode.