Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Why Only 3 Builders Control All of Ethereum

Episode Date: May 1, 2026

In this episode, host Friederike Ernst is joined by Kubi Mensah, CEO and co-founder of Gattaca, the company behind Titan Builder. Kubi sheds light on the highly competitive and often opaque world of Ethereum block building, explaining how Gattaca evolved from a centralized exchange proprietary trading firm to one of the three dominant builders responsible for constructing the vast majority of Ethereum blocks today .  They dissect the true "journey of a transaction," revealing why over half of all Ethereum transaction value bypasses the public mempool in favor of private order flow auctions and MEV-protection services . Kubi explains the intricate mechanics of top-of-block bidding by high-frequency DeFi arbitrageurs, the necessity of extreme latency optimization, and the "flywheel effect" that makes block building a natural oligopoly . Finally, the discussion turns to the future of the Ethereum roadmap, unpacking how upcoming upgrades like ePBS (enshrined Proposer-Builder Separation) and FOCIL (Fork-Choice Enforced Inclusion Lists) aim to permanently alter the power dynamics between block builders, validators, and originators .  Topics04:15 Transitioning from TradFi Trading to Ethereum Block Building09:30 Redefining the Builder: Relays and Order Flow Auctions15:00 Unpacking the Mempool: Public vs. Private Transactions21:45 The Anatomy of a Block & "Top-of-Block" Arbitrage27:10 How Builders Pay Proposers to Win Auctions35:20 The Oligopoly: Why Only 3 Builders Dominate Ethereum42:15 Trust in the Dark Forest: Handling Searcher Bundles49:00 The Convergence of Builders and Solvers55:30 The Impact of ePBS, FOCIL, and Pre-confirmationsSponsors: Lido V3 introduces stVaults: a modular staking infrastructure that lets builders and institutions deploy custom staking vaults, while staying anchored to stETH as a shared liquidity layer.Get started building with Lido V3 today: https://lido.fi/stvaults?mtm_campaign=epicenterBlock Space Forum: https://blockspace.forum/

Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization in the blockchain revolution. I'm Frederica Anne. Today I'm speaking with Kubi Menza, who is the CEO and co-founder of Gataka. Gataka builds the Titan builder. A lot of the edge that you actually get as a trading firm comes from understanding how things work under the hood. So then we had to really go deep into the EVM, the P2P layer, how nodes work, how consensus work and all of that. that actually unleashed even more fascination around like, oh, this is actually how this all gets put together and how it all works. It took us a little bit of time to get full conviction in terms of the sustainability or the business durability of that venture. But once we did that,

we basically burned our boats. We stopped all training activities and we went full on into block building. Yeah, I guess the rest is really history. Thank you so much for coming on. Hey, good to be here. Cool. Maybe give us a little bit of backstory because kind of Gataka and Titan are very much projects that don't dominate

the discourse a lot. So kind of people who are deep in the stack they know who you are. But maybe talk about kind of how Gattaca got started and how Titan emerged and and so on. Yeah, sounds good. So Gattaca has been in the space

for a while and we have our origins in trading, actually. So we started off as a proprietary trading firm initially on centralized exchanges. So this was in the early days when it wasn't as competitive. And the professional traders from, you know, TratPai hasn't moved or hadn't at least moved in at scale yet. So they were there to some degree.

And then we moved some of our resources from proprietary trading on centralized exchanges, such as market making, just the standard stuff, arbitrage, liquidity provisioning, and move some of those resources on chain when we started seeing more activity on decentralized exchanges. And the thinking basically was, hey, you know, the market structure might be a little bit different in crypto and centralized exchanges, but it's still very close to the traditional system. So most people will probably just be able to move over their playbook and then just dominate.

And so probably not an ecosystem where we would have sustainable modes. But then when you look at decentralized exchanges, that was just like a new world that had never existed before. So there was both the sort of strategic reasoning of, okay, this is actually something new and novel that hasn't existed before. So being one of the early adopters or firms to move into the space can give you an edge, but also just a bit of a fascination around the technology and what was possible. And then over time, we basically shifted more and more resources fully on chain versus centralized exchange. changes and a lot of the edge that you actually get as a trading firm comes from understanding how things work under the hood. So then we had to really go deep into the EVM, like the P2P layer, how nodes work, how consensus work and all of that. That actually unleashed even more fascination around like, oh, this is actually how this all gets put together and how it all works.

There was almost a little bit of an element of formal, so to speak, that we were a participant. outside of like the cool stuff that is actually being built and almost this new industry. And we weren't actually part of that. We are just sort of on the sidelines sort of trading on their layer, but not actually being part of the layer itself. Then I remember a few months ahead of the merge and there was 22. And I think it was an MEV day or something. And PBS was discussed and the role of the block builder.

I think that was the first time where we were aware of, oh, there's a potential for this new infrastructure player that's actually going to be part of the underlying fabric of this ecosystem. But at the same time, also recognizing that a lot of the things that we are good at or the capabilities that we sort of build up in-house by becoming competitive traders were very much applicable to this problem set. But it's not just purely an optimization problem. There's also this service layer to it. And so I think that made it really, really interesting. And so when the merge happened, then obviously PBS and the block building market emerged from there, it took us a little bit of time to get full conviction in terms of the sustainability or the business durability of that venture. But once we did that, we basically burned our boats.

We stopped all trading activities. And we went full on into block building. And, yeah, I guess the rest is really history. block buildings changed a lot since you guys started so kind of it kind of it used to be a fairly niche thing and now it's extremely competitive and kind of it's just become professionalized maybe talk about kind of how I mean it's been what four years or something it's not been all that long so tell me about how block building has changed from your vantage point yes so I would say four years and Crypto is actually really long. So there's that. And I think as with any other markets, over time, you know, the market matures and the participants mature. I think not just block building itself, but just crypto as an industry has also matured a lot.

And so the sophistication of the professionalism of the entities that are in crypto, as we just actually discussed before getting on, is increasing. So I think that applies, I think, also to the broader industry. But then blockbuilding specifically is also very competitive in its nature. And so if you put those two things together, then you have this natural acceleration of like what is required to be the best at this game. And so I think what has changed is basically on one side, just from a pure technical perspective, the capabilities needed and the type of infrastructure, the performance, the latency, the uptimes, the consistency of processing transaction in different markets, scenarios, all of that the bar has just gotten a lot higher. And the expectations from, I'd say, block space consumers,

so anyone who actually censored transactions, transaction wants that to be executed in chain, the requirements depending on the use case have also gone up. And so I think that, put together has just increased the bar so much. And yeah, that's the state of the world. And happy to go into some more specifics, of course. This episode's brought to you by Lido. As Ethereum Staking continues to evolve, more teams building staking products

are running into a familiar challenge. On one hand, pooled liquid staking gives you liquidity and access to Defi, but can limit customization. And on the other, bespoke staking setups setups offer more control over things like pricing, performance, and operator selection, but they often come with added complexity and less flexibility.

LidoV3 is changing that with STVALs. SDVOLTS is modular staking infrastructure. It lets builders and institutions deploy custom staking vaults tailored to their specific needs. At the same time, they're staying connected to SDEth as a shared liquidity layer powering Ethereum's broader defy ecosystem. If you're just looking for a place to generate yield

on your idle assets, Lido Earn makes it super simple. It offers curated defy strategies built around STEth. You deposit once, you choose a vault, and manage everything from a single interface. To learn more and start building with SDValtz, go to lydo.5. slash SDValtz and get in touch with LiDor contributors today. Is Katika today just a block builder, or do you have other parts that kind of other projects that you're working on? Yeah, so it's a good question. So I think our mental model of how we think about block building has evolved a bit.

It used to be, hey, it's this pure function that you plug into an existing protocol. There's an existing market structure. It's permissionless. So, you know, anyone can come in. There's a set of transactions in the MIMPOL. If you build a better block with these transactions, then you win as a builder and you get a bit of a margin depending on what the delta between you and the second best builder is. The mental model of thinking about a block builder has changed quite a bit. And with that also the scope of what we do at Gattaca.

And so there's just a pure block building business, which from our perspective is just something like optimal allocation of block space, right? But we have also expanded a little bit further across the supply chain. So, for example, we operate MV Boost Relay, which is basically how validators connect to this out-of-protacle block construction market. The way to think about it is basically where price discovery for the wholesale block space happens. And then on the other side, we also have something that falls into the category of an OFA order or an order flow auction platform, which serves both as sort of privacy preserving endpoint to send transactions so you don't go to the public mempool, but also a service where if you leak any MEPV, the MEPV gets rebated back to the users or the originators. It's also now a venue where you optimize for how much gas you actually pay

because it's quite difficult to actually price how much your transactions are paying. So we've basically taken a more holistic approach where we see all of this together almost like as a bit of a platform where from one side of you have a, on one side you have the block space consumers and different categories of users that all have their use cases and they want to consume block space. And on the other side, you have the validators. sort of core protocol that basically produces raw block space, and we are building sort of their platform in between

to optimally allocate and sort of serve both sides to refine this raw commodity into some higher value good, and on the other side, basically, give the best services to the consumers. Yeah, that makes a lot of sense. So basically it's just kind of like block-billed adjacent services on either end that kind of you offer in addition. Maybe let's deep dive into block building, itself. So kind of I think a lot of people, even technical people in this space, have a very naive view

of kind of how blocks are actually built, right? Kind of like they think, kind of like you send a transaction to the mempool and then kind of the validator who is slot it is kind of picks it up and kind of sends builds the block, right? And in principle, kind of like blocks can be built like that. So kind of like it's not completely for us, but kind of like there's a lot of neon missing and kind of why the process of block building and proposing has kind of been divvied up between different parties. And then secondly, also kind of the role of the mempool and kind of how orders, transactions actually get to the block builder. Because last time I checked only about half of the transactions that later get included are actually go through the public mempool.

And everything else is public order flow. And that's by number. of transactions by kind of transaction value, it's more than half. So kind of they never actually see the light of the mempool because obviously kind of you make yourself extremely vulnerable to kind of leaking value there. Maybe give us your take of how block building actually works for someone, explain for someone who kind of who knows how Ethereum works, but who's never really thought about how the block building works kind of on a construction level. Yeah. So I guess the way to think about it is think about it like a journey of the transaction. So you know, you have the originator and then the intent is for that transaction to be actually included on chain right in the final block.

And then there's a lot of infrastructure and piping in between that in order to facilitate this. And as you said before, even if you think about the public mempool, there isn't really such a thing as, you know, one pool where everything is publicly, but you know, it's a, it's a network of nodes and each node has a local view of transactions that they are seeing and they are sharing that with each other, right? So even if you just, from a block builder's perspective, getting access to public mempool transactions is not just, hey, you know, I run one node locally and then I just subscribe to some web socket, but it's, it's operating multiple nodes are globally across the world, making sure that they appeared with the right peers in the network to make sure that connectivity is high, and then from each of those sort of funnel

transactions to local builder instances. So that's the connectivity to the public mempool. At the same time, there are also some third priority providers that have some optimizations and latency advantages rather than just running notes directly if you don't want to spend too much resources. So that's also out there, and it's also good to have that as a failover. So that's the public manpool side of things. And then there's this other less transparent, I guess, part of the ecosystem, which is a private manpool, a category of players that aggregate transactions privately. So you have RPC endpoints, for example, that are offered by certain RPC providers that connect directly to block builders and just fan them out. There are order flow auction platforms, like I mentioned previously,

and you have things like Mephblocker, for example, right, or Blink or FlashBots Protect and a bunch of other services, right? And similarly, we also have an order for auction platform. And basically, it's an end point where then you send your transaction to and it doesn't just forward it directly to builders so that your data doesn't get leaked. But it actually looks at what your transaction is doing. Let's say you are doing a swap.

And if that swap would cause an arbitrage opportunity, It will also auction that transaction off to traders to compete for the right to correct that arbitrage and then bid a lot of the value back to the originator who actually caused that transaction. There's also a gas optimization component because it's actually quite hard to price exactly how much priority fees you need to pay in order to be included in a block. And so these OFA, so speak, often have a view not just of what current gas prices. are but also a local view of what the demand for block space is. And so basically try to give more precise recommendations on how much fees you should be paying. So all of that sort of gets, you know, bundled together as one service. And then those transactions either individually or with some parameter around how much of the

priority fee that are being paid to the builder should actually be used to include the transaction and how much should be paid back to the user, for example. Or they might show up as bundles where the transaction plus the trade that then captures the arbitrage after it. Or some order flow action platforms actually combine multiple transactions into one bundle because then combined transaction pay more fees actually have an influence where these transactions will be placed in the block so they don't just send transactions individually. And so there are all these like techniques and optimizations that then completely gets. abstracted away from users but overall tend to give the user just better execution than if you

send to the public mempool or even just directly via a private mempool service all of this then ends up on the builder level often you have also very sophisticated other parties so these are the more large-scale consumers of block space and a big example would be the c-fi defy arbitrage traders right So they basically look at prices off-chain and then what's the local prices, let's say, within Ethereum are and whether there's a discrepancy, then they'll basically hit the order book on one side or the AMM on the other side. Trading firms generate quite a lot of transaction volume. And so they have very, very specific needs when it comes to the execution of those transactions. For example, they would try to minimize as much as possible around the time. when the transaction gets submitted to the builder closest to the end of the auction window.

And for example, on Ethereum, it's 12 seconds, right? Which is like a lot of time. But then they would want to wait ideally till the last nanosecond possible before submitting the transaction because that means they have the latest information from the outside world where information is continuous. Often these traders also touch their top of the market. the block, right? Which means that if you include one of their transaction, you still, you can't just add it to the end of the block and you're done with the block and send it off. You basically now have to construct the rest of the block based on that transaction that just tried to get in

the last like microsecond, right? Then you potentially have other sort of categories of players, like, for example, TelegramBots, that was like a big category of consumers of block space, at least last year, for example, where they have sometimes these buzzer. of hundreds of transactions, right, that target a specific pool. They have requirements around like how those transactions or that big bundle gets included and so on and so forth. Right. And so then it's basically the job of a block builder now to cater to all these different consumers of block space, all of their needs and execute optimally.

And the better you are in aggregate across all these different services, the better you are as a block builder and the higher value block security. build, which then in an end effect means there's more effective consumption of block space. You generate more rewards for the proposer, but also there's more on the table for the block builder to potentially also keep us revenue, because their revenue is dependent on basically the delta between what you build versus the second best builder. Okay. There was a lot to unpack there.

So kind of maybe let's go back to kind of the different kinds of transactions that you get. So kind of you get kind of the public transactions from the Mampur, then you get the private transactions from the private mempools and kind of the bundles. You also, I assume, get order flow from intent-based depths on top of that, right? So kind of that's probably also quite a chunk. Maybe we can talk about this after. But then kind of tell me about, so I understand why someone who does dex sex arbitrage, why they want to sit at the top of the block, because kind of they want to act on the state that they know is the current state, right? So kind of this is kind of, this is kind of they don't want their state messed up.

Their entire thing is kind of like they want to know the exact state they're acting upon. So how do they make it worth your while to kind of for them to become top of block? Because you said kind of like, okay, they kind of they will send it the last millisecond and then kind of like we need to reconstruct the block. You're not doing this out of the goodness of your heart because you feel for the arbitrageeure, right? How do the economics of that work? So the economics is a function.

basically of trying to collect as many fees as possible, express either directly as priority fees or direct builder payments. And builder payments are basically just transfers to the Coinbase, which is an EOA that is set for a specific block. And so the totality of priority fees plus Coinbase payments gives you the overall block reward. And that's the thing that ultimately determines whether, first of all, win the auction and also how much revenue make us a builder. and in a broader sense,

the way to think about it as well, what a builder is essentially facilitating, it's basically optimally auctioning off specific states, right? So now we talk about top of block, but potentially you could auction off that piece of states also later in the block if no one else gets to touch it, so it doesn't necessarily have to be the first transaction, right?

And so the incentive here is basically from the originator. if you want access to a specific piece of state, whoever pays the most gets access, right? So there's this latency component, and we are incentivized to invest into building this very latency-sensitive infrastructure because that allows the traders to basically bid more in terms of the overall block value,

which then unlocks more value overall and allows us to win the auction when it comes to the wholesale of block space. Okay, I understand. So basically the block kind of now has a price attached to it. But kind of the person who actually builds the block is the validator, right? So kind of that money goes to the validator and they pay you on the delta kind of between this next best bid or how does it work? Yeah.

Okay. That's a good question. So the mechanics actually work. So the validator no longer builds the block at all. The validator just proposed a block. So in PBS, propose a build. operation, the validator is basically just the proposer. So how it works is that the block builder sets the Coinbase address to a wallet

day control. Then they collect all the fees. And then once the block is constructed, they add a payment at the end of the block that basically transfers some value from the coin base to the proposes fee recipients. And this is basically what is classed as the bid. Right. So the proposals or the relays on behalf of the proposals will look at the blocks being submitted and we'll just check how much is the proposal being paid and then just pick the block which pays

the proposal the most. But naturally, the more you collect in fees and the better you sequence that leads to you being able to pay the proposal more. And then there's also a little bit of a game to try and understand how much do you need to pay the proposal to win the auction but still leave a bit of a bit of. a margin in order to make some revenue yourself. And so basically the full block is constructed by the builder. The builder decides how much to pay the proposer.

The relay selects the block that pays the proposal the most. And the proposer basically just signs off on that block the relay has picked for the proposal. And then the block gets propagated to the network. Is there any optionality on the side of the validator? So can I as a validator say, look, I really don't like this guy, Kubi. I just don't want any Titan-built blocks. So kind of give me whatever was next best.

So currently, most relays don't have any sort of filtering logic other than the OFAC SDN list. So some relays actually look at that list. And if there's a block that includes OVAC transactions, they don't serve it to specific proposals. And the proposers can basically specify that when they register with a relay that I only want to accept those kind of blocks. Now, in theory, you could try to, as a proposer, filter for, let's say, I only want, you know, quasar blocks,

or I only want Titan blocks or only want build on it. That's definitely possible, but in general, just not incentive compatible. There's a lot of builders around, but kind of not a lot of builders actually build the majority of blocks, right? So, if you look at the stats, kind of 90 plus percent of blocks are built by Titan plus Beaver plus flashboards, right? Those are currently the biggest three. why is there only the small handful of competitive builders? Yeah, so actually currently the

So we are the currently largest second largest build in it so by FlashBots and then the third is a builder called Quasar and so in Agri, I think they have like 15 to 20% and FlashBoss has like 20 to 30 and we have like something around 50 usually

the key reason is that there's a bit of a flywheel effects to block construction and also the incentives and I'll double-click on that. So let's start with incentives. And I'll give a simple example. So let's say, just to oversimplify things, there was a single transaction in the Mimpool for a given slots,

and that was the only transaction on Ethereum that is willing to pay to get included. And let's say that transaction pays one eth. If that transaction went to, let's say, two builders, now two builders will have exactly one eth of priority fees, and now they are competing in an auction to win. And so the outcome will probably be that 90 plus or 100% of that value would just be paid to the proposer. But from a originator's perspective or a block space consumer's perspective, you would want to pay as little as possible, right? Which is sort of this fundamental tension between like the producers of block space and the consumers that producers want to get as much as possible for their block space that they're selling and the consumers want to pay as little.

Because the consumers want to pay us little, it is in their incentives to not send transactions that pay a lot of priority fees to all the builders, right? Because if you send, let's say, to all the builders, then every world builder would have the exact same amount of priority fee and then 100% of it will be paid. But if you send that transaction to a single bill, then now the builder can sort of try to keep as much of that as possible and then refund a bunch of that back to the user. so that the effective price that the user's paying is actually lower than the initial sort of one-eath in that example. And so I think that is crux of it. And this realization was actually made by the old,

the first block builders. There were also sex-stex trading firms. So there was Beaver builds and there was R-Sync, which are both large trading firms. They were at a time the largest block builders and a lot of the edge came from the fact that they were creating all this in-house valuable order flow that was paying a lot of priority fees. But they realized if they send those transactions to everyone, then all those priority fees

would be bit away. And so if they just kept it to their own builder, they could optimize on those fees, right? And so that was sort of the starting point where different players in the industry realized that, okay, us included, obviously, especially because we didn't have any internal order flow. So we purely came in this from the perspective of being a service provider. So, okay, what service can we provide to other originators that don't have a block builder in itself? Can we do that on their behalf? And so that sort of created this game where like the better you are at block building

and targeting specific users for specific services, the more they will use your builder over someone else, which meant then that you have more priority fees, which then meant you can refund them more, but it also has this flywheel effect of basically, you know, competing lots and lots of builders out of the market. And this refund, is this something that is contractually kind of specified? Or is this kind of a handshake kind of agreement? Yeah, I mean, some of it is via just APIs and you can set sort of refund percentages and stuff like that. Some of it is also a bit bespoke where if you have like one or two players across like an category, it often doesn't make sense to like spend the resource to build like a fully fledged system that's then fully permissionless.

But yes. So it's basically a mix of those. Do you give traders access to your block before you post it? Because I would imagine that kind of like if I were a market maker, obviously I'm kind of being the maker is typically a lot more expensive than being the taker. So kind of you have to make sure your orders don't go stale. Basically, the prices don't move under you.

So kind of, if you give me your block and kind of that you've constructed and you tell me, okay, this is the block I've constructed? Is there anywhere you kind of want to insert an order here? It's possible that I might want to do that, right? So kind of, I mean, you do that yourself, I assume? But kind of do you also give that parties the same opportunity.

I mean, obviously not anyone, but kind of like you also accept bundles from other searchers, right? Despite the fact that you can also search yourself. That is actually something we feel very strong about. And till date, we have not given any external party access to private state. And that is just because of the guarantees we give to all of our originators. And it can just be that there might be some trading firm

that has some niche strategy, right? But then, you know, there's the more sophisticated traded firm, and now it looks into the block and sees what someone else is doing. And there's all this, like, conflict of interest and potential use cases that arrive that might be adversarial to the other side or more serving the customer base more holistically. So it's something we absolutely don't do. What we have done, we have done a little bit of an experiment with flashbots where we basically strained our state into a TE that was locked down. and the TE was configured such that the only data that was leaving the TE was a bundle that is sent back only to our endpoint. So that was like end-to-end under control. So under these conditions, we were comfortable sharing the data within this trust-e execution environment.

There was written like, you know, within a cloud and we knew no one else had access. And we knew the only data that was leaking out of this was a bundleer sent back to our builder. And then we also decide where to place this bundle so we can make sure that no one could actually create friends. front-running bundles and anything that might be again under cereal. But other than that, we don't give access to anyone else. And I guess the other clarification I should make as well, I often talk about market makers. And that's just because the competitive sex tax traders are all market makers as well.

Because in order to be competitive, you kind of have to have a really good global view of fair market prices, which means that it's not just, you know, looking at Binance mid, but maybe you have some OTC flow and you're looking at lots of other different sources, so you need to have this global view. And then whenever you see that, let's say, some univap pulls out of whack, you hit it there and skew a quote there. So generally, people that are competitive at this are also market makers, but they actually don't actively

move quotes on chain. So they take on chain but are generally also market makers. That being said, there's a bit of an initiative on Ethereum right now to actually enable faster updates of being able to quote liquidity on chain. So that's something exciting that's in the works, which I'm actually quite excited about, because I think that's going to just make Ethereum more competitive as an ecosystem for actually interacting and trading on chain. But other than that, which is not live yet, the active liquidity provisioning is not as active because, currently is just too expensive to do. Under which EIP kind of is the improvement for the intra-block quoting? Oh, so that's actually not an EIP. And the V-Zero is also not something that would happen intra-block.

I think intrablock, anything that happens inter-block, should almost be viewed as a based roll-up that's synchronously composable or some sort of synchronous composability layer. that can basically advance dates while and then when the 12 seconds slot time ends, then settle to Ethereum. But what we are enabling now is basically just making sure that if you have, let's say, something like a prop EMM on Ethereum, which is like your contract, you have priority ordering when it comes to feeding an Oracle update into your smart contract before someone can actually take liquidity,

which just makes sure that, you know, you are prevented. from toxic takers, which then should obviously result in tighter spreads. And then that's just net beneficial for everyone. Okay. So basically you allow kind of the originator of a smart contract to act on the state of the smart contract first before kind of anyone else is allowed to. Is that correct? Yes, correct. It's basically akin to the broader ACE or application controlled execution sort of, you know, strategy where you give apps more fine granular control of how their transactions get executed.

Okay. If you now kind of look at your average block, so I mean, there's obviously also kind of of a lot of really vanilla transactions, right? Kind of like if you kind of had to classify kind of the block in terms of what it contains, how much of it would you say is just kind of like vanilla transactions that kind of like you don't actually make a lot on? What's the distribution of revenue for you? So kind of I assume you get most revenue from just a couple of old.

orders per block. Is that correct? Yes. So I would say overall, it's quite spiky. So the priority fee-based transactions that actually are contentious or contending for specific state. So I don't have a specific stat in mind, but it is definitely skewed to, especially if you look at like the really, really big blocks or the, it's very similar to volatility. Usually have like these big volatility events, right? happen and then there's a lot of activity on chain and everything is full gas prices out of whack right which is then where a lot of value gets passed through and then you have just normal conditions which are a lot more mellow that being said they're still at least if priority fees are at least

a little bit high enough even with transfers and sort of non-contentions transactions there's still a lot that can be done by optimizing for latency, getting transactions in quick towards the end of the slots, by making sure that you have the right connectivity across the globe, across different sources and stuff. So there's the sort of contentious auctioning off and handling that really well during spiking situations. But as long as there is some priority fee attached to it, there's still lots of optimizations that are not just ordering based, that also affect the overall black value. Can you give me an idea of kind of optimizations that kind of can still affect the value?

Yeah. So I would say a very simple example would be like a latency-based use case. So let's say towards the end of the slots, because transactions come in continuously as well, it's not like they only come in at a chunk of time and then they stop, right? Towards the end of the slots, if let's say, you know, the proposer is in, let's say, northeast Virginia, where a lot of the US-based validators are, there's a transaction that originated from Tokyo, right? That's maybe just a transfer, but it's urgent,

so it's paying a little bit more priority fees. If you manage to get a transaction to your builder that is in North Virginia quicker and have enough sophistication to incorporate it into the block, usually probably easier because it's at the end of the block because it's non-contentious. But just as a simple example, if you will then have more priority fees

that another builder who is not as well, fast tasks and then that again needs to hire a block and more revenue potential. Okay. So if I were to become a builder, what I've kind of like now learned from the conversation is kind of what's important is kind of I need reliable physical infrastructure that kind of gets me the order flow reliably and in a timely manner. Then kind of I need private order flow because I assume that's also where a lot of the meat is on the bone, right?

And there kind of I need to be kind of a trusted party in the sense that kind of people are actually willing to share their private order flow with me. Then I assume, kind of, I also need to be very good at simulating outcome, right? Because kind of like, obviously, if you have a thousand transactions in a block, there's a thousand factorial ways of kind of placing it, right? Ordering them. So kind of like you have some heuristics, kind of like, which generally can go in the back. And then kind of, I assume, but I assume there's a lot of simulation going on. And then kind of kind of the fourth one I heard is latency, being able to send the block at the last possible millisecond. How would you rank them kind of in importance? Yeah, that's a difficult one.

So I would say if you don't have any transactions, then obviously there's nothing to optimize, right? So you need to have a set of transaction that is significant enough. And as you said correctly, there's, there are the transactions that are just available to everyone in the public mempool and the private sources. For the private sources, you now need to go to like these RPC providers and like these order flow auction platforms and you basically need to demonstrate that you're not going to do anything nefarious, right, if you are running it in a sort of trust decentralized setup. There's also an alternative, something like BuilderNet, right, where you do a block builder net and then people can verify the code that you're actually running. And so then it probably

will be much easier if you're just up and coming to get that order flow. But at the same time, you're making a trade-off because now you're running a T, which means you're very constraints and sort of like compute capacity in terms of like what data centers you can provide, deploy your infrastructure in, and also in terms of your alpha, because if you need to actually show what you're running, that means like, you know, all the proprietory, juicy stuff is probably not something you can put in there. So there are some constraints on that at least depending on the setup. So there's the trusted part and so getting the order flow. And so I would say overall there's sort of a minimum hurdle of transactions that you need to see in order to be competitive.

And then it really depends on the market sentiment as well. So, for example, if there's a lot of volatility on centralized exchanges and the price are moving all the time, during those market regiments, you need those big C-Fi-D-Fi trading firms, right? then during when it's more quiet and there's not a lot of activity then it doesn't matter as much right so I think the key is probably just in any other market when you're starting off you want to find like one niche that you're good ads and sort of make sure it works well and that also gives you some time in the market and establish yourself and so on and so forth and then expand to broader sources of order flow going back to your original question if you don't have the order flow there's obviously nothing to build with but then you also don't need to have all the order flow. So just being a little bit more strategic in trying to find some sources of transactions that you can get access to and then really make sure you start optimizing the rest from there.

And then in terms of optimizing latency versus your local simulation and your ordering algorithms and their heuristics, again, this all depends. You can sort of choose your specialty first and then optimize for one sort of. sort of regimen, which is then for the use cases that are very latency sensitive, then you build better blocks than others, for example, right? And so in general, it's just like, these are all sources of alpha, so to speak. And so the more alpha you can stack, the more competitive, like, it makes you. And as in any industry, my recommendation is always, you know, find your thing that you can

specialize on and that you can do really, really well. And then if you're really good at that thing, try to expand from there versus trying to be the best at everything because that's just very hard. Yeah, I think that's generally a very good recommendation, kind of like being the best at everything. It's something I constantly fail at. So it's, uh, um, tell me about your relationship with, um, the searches. So kind of the searches are basically parties that send bundles to you.

Um, that then may or may not be included in the block. Um, how is that relationship rooted? So kind of is it rooted in trust or kind of do you have some sort of contractual agreement? And how does the searcher know you didn't already have this bundle, right? Because kind of like I could just submit trivial bundles and then be outraged about the fact that you're not paying me for them. How does it work? Yeah. So I would say overall, the way we approach it is it's a category of customers, right?

And then the question is, what are they optimizing for and how can you serve them best? And then in terms of how you actually maintain this relationship, you have different categories. of players as well within, let's say, the broader searcher category. And you have like smaller sort of anon teams that maybe are just on Discord and Telegram. And some of those guys like we've never seen before. Like we have a Discord so anyone could just DM us, ask us some questions, ask for some debugging or whatever it is. Some relationships are just of that matter of that nature.

And there are some that are well-established players, like some of the brands that like, you know, most people in the space already know. and they'll just straight go to us and say, hey, can you give us this feature? And like with any other product, if a customer asks for a feature, you build it, and then you have a better service and, you know, it's win-win for everyone. I think even though crypto overall is maturing and the industry is maturing, the number of players that actually want like formal contracts and so on and so forth is very small, but that still does exist to a degree.

but then given that the block bill itself is also permissionless and sort of anyone can use it and, you know, all of those things taking into account it's sort of like a big mix of, you know, there's this crypto-native, like, permissionless, sort of, okay, you just send something to an endpoint to, hey, I have a very specific requirement and maybe can you give me some uptime guarantees and so on and so forth. I mean, it's also very much a repeat game, right? So kind of like if I'm a searcher and kind of like I send my bundle to various block builders and kind of one of them never pays me despite the fact that they may include my bundle,

I just stop sending the bundles, right? Yeah, I mean, in terms of payments, so often it just works permissionlessly, right? Because like there's something that gets paid to the Coinbase and then there's like fixed refunds or like something you can specify on how it should be sent back. But then there's also this idea of batched payments, which, is because every transfer on a per block basis obviously consumes base fees. So that basically then eats into like how much you can get paid back. So there's this idea so you can batch payments together and say basically after one week of aggregating

these payments, just send it at once. And of course, if for whatever reason after a week or whatever period a day, the originator chose and you didn't make the payment, then obviously, yeah, they will no longer be working with you. Cool. So you already said that kind of you also search. how much of the bundles that you include kind of do you create yourself and how much is that parties?

So as I said before, when we launched the builder, we actually stopped all trading activities so we do zero bundle origination. We haven't since 20, 22, basically. Okay. So the answer is kind of like it's kind of, it's just, okay.

Just external parties. It's just because of the conflict of interest. And so we believe strongly long term, that's just not incentive-competable. Okay. What do you think about kind of a role converges or some sort of vertical integration between builder and validator? Because kind of like that would

make a lot of sense too, right? The broader idea of PBS, which was meant to give everyone access to competitive blocks, right? And so that prevents basically this centralization

force being exerted onto the broader valetator. which is what keeps the entities that actually vote on the validity of blocks and do the attestations. That's the core protocol itself and that needs to be maximally decentralized. So from that perspective, PBS had been quite successful. Now, given that PBS already exists, if a builder was to integrate with a validator, and that actually has happened and somewhat open about it, some are not, I don't see as much of a concern anymore because everyone still has access to these competitive blocks, right?

And so unless this really gives you like a big, big edge that no one else has, overall, I don't think it's as much of a risk anymore. Now, if this market structure didn't exist and only some had access to these very, very competitive blocks and some didn't, imagine just having vanilla local blocks or like M.VUWB-Stile blocks, obviously, you know, that will be really, really centralizing. So if it happens now, I see it as way less of a concern. Okay. What about kind of being a builder and a solver at the same time? So kind of for intent-based protocols, kind of obviously it also makes a lot of sense, kind of to not just send this as order flow, but to kind of, because you're leaking

value on the server side, right? Yeah, that's a great question. So it's something we have actually also thought about quite a bit. I think the edge as a builder really is that you can find the optimal solution at the time of execution versus just top of block. Well, because the solvers that currently operates via lots of other, like Kauswap, for example, you operate on the state of the world that's based on the end of the last block. Yeah. But then just as we discussed before, the top of the block oven is very caveat. Then, you know, taking by others, that means now the prices have changed.

And so the route is no longer optimal. So we have been thinking about how to best reconcile that because ideally we don't want to get into solving business because solving itself, like being up to date with all the liquidity pools, potentially having internal liquidity and offering that via like some or versus passive AMMs, that starts to then become more of a trading firm. But so what we're currently exploring is basically if there's a way we can give either something like off-chain. sort of execution parked within the builder. So if you can give us some sort of logic that we can park and have executed as part of the block construction process. So when we are evaluating your bundle, we won't just evaluate it as is, but we evaluate it by taking that off-chain sort of component into account, which raises some potential proprietary binary questions from the solvers. There's also this potential TE approach, but there has a lot of latency over. overhead, which is a problem.

And something else we're also exploring is basically the solution being submitted to us as the sort of the floor and then basically giving us almost like a... Kind of like an intent-based... It's kind of like intent inception. So kind of... Yes, exactly. And then being able to then sift through potential other solutions that we might swap that original solution out for, but only if it improves the price. So those can all be sort of hybrid

solutions. And the question is, can we make this as efficient as if we actually had a solver running on states? And it might not be like 100% the same efficiency, but even if we can get up to 90 plus percent, that should be good enough. So we haven't settled on a specific approach, but we're actively exploring that. And that's super interesting, I think, in terms of, again, improving prices for everyone and making easier and more competitive. Yeah, 100%. Cool. So if you now kind of zoom out and look at the larger Ethereum roadmap, so kind of there's a couple of things that are very relevant to you guys looming on the horizon.

So there's enshrined proposability separation. There's inclusion lists and kind of there's still talk of pre-confirmations. What do you make of those and what are you looking forward to? I would say looking forward to all of them. Now, there are some nuances in terms of the implementation detail. So what are the design specifics and how are these being rolled out? I guess the first one you mentioned was EPBS. So the exciting part about EPVS is actually formally enshrining this market structure

that currently is all like out of protocol in the core protocol, which means and specifically with the fair exchange part, right? So the fair exchange problem is the part where you have, let's say, in a two-sided markets, especially if it's permissionless and, not trusted someone has this digital goods and in this case it's the block if the builder were to just give it to a proposal a proposal could just you know take all the value not paid the bill or anything and if the builder were just to give them the bid without actually proving that they have the block then it could just lie about it and with epbbs you basically solve this fair exchange problem

through trustless payments so that's exciting so the idea that a bunch of this centralized infrastructure now has like an in-protacle fallback path for whatever reasons like robustness, if something fails, then the entire pipeline just doesn't degrade and everything reverts back to the public mempool, which will be like the dark ages, right? I guess the tradeoff here is though the complexity of the specific implementation, how it's being done. And then the other question is in terms of priority, there's so many things that we have to do as Ethereum. Like, what's, what are we prioritizing? All of this aside, I think, you know, it's gone through the process. And you know, it's been usified.

And so it's coming in the next hard work. So overall, I have always been excited about EPVS. There are some nuances around this specific implementation detail. But I think the fact that Ethereum as a core protocol actually can handle this market structure, which has existed for four years and is obviously doing the majority of the heavy lifting now. As part of the block construction process, it absolutely makes sense that there's an improtical path for it. Talking about fossil. So excited about the part that.

The core protocol itself has a say on how a block should be constructed and that it really strengthens the censorship resistance guarantee because you no longer have one monopoly that decides the entirety of the block. The fundamental incentives, which are like, okay, if you don't build a more valuable block, your block doesn't win. But there are all these side effects of holistically as a protocol, what is Ethereum trying to offer us a service. and is there always incentive compatible all the time.

And so with fossil, that's quite interesting because you start having multi-party block construction as part of the core protocol where the core particle feeds into the block construction process itself. But the heavy lifting of simulating everything fast and all of that stuff can still be outsourced. So it's sort of the best of both worlds. There is some pushback here,

especially from node operators or stakers that run in certain jurisdiction where certain transactions are allowed to be led into the block. And so there's a bit of a tension between, hey, as a neutral infrastructure layer here, Ethereum obviously needs to support like non-sensorship, right? But then there are also these specific parties that are in specific jurisdictions. And what does that mean for operators like that if now they have to process their transaction, right? It also gives you an element of defense, right? So if you have to do it, if your hands are bound, it's kind of like this entire legal argument about billing being not willfully but actually blind and kind of like you are the pipes.

You can't see it. You can't do anything against transactions. They're just forced down your throat in some sense. And I think actually kind of I think it actually bolsters the legal defense of validators and block builders, no? I agree. But then it always depends on the sensibility of the regulator. Right. Some might just go all overborne and be like, okay, fine, you can't participate then, right? Which also would not be great. But yes, I agree.

Okay. So how do you see block building change over the next year? So it's been around for three and a half four years. Let's give it another three and a half four years. What do you think changes and do you think who captures the value will change? So we've already enumerated some of the changes, right? So just being. part of the core protocol or EPBS itself just changes the market structure a little bit. Nothing fundamentally changes, but there are some nuances and some technical details here. With fossil now, you actually start having more constraints. So today you already have constraints when you're building a block as a builder.

So for example, a bundle is a constraint. You can't just include these transactions anyhow. They have to be in this order and they can't revert, for example, right? And there are a bunch of other like softer constraints. And so now the constraint of, hey, this is a transaction that you absolutely have to include, right? Then you can go even further, which is also the other thing that we haven't talked about pre-confirmations, for example, right? Which is someone issuing the execution or inclusion of a transaction ahead of time, that forms yet another constraint on the block. So I think it's going to become more complex from that perspective.

There's going to be more inputs that you have to take into account when running these plans. block construction processes, but it is all basically just evolving to a market structure where you, and even with ACE, right, that's another constraint, right, where now the application also has a specific requirement and how like a transaction gets sequenced and how it gets, how the block essentially then gets constructed with that. We're basically just incorporate more and more use cases of different players in the ecosystem and that all feed into the block construction process. And that's just understandable because the block construction process is just so fundamental to the core protocol itself.

So I think it all makes sense. But it's also mostly on the vanilla side, right? So kind of like if you kind of look at kind of like the vanilla transactions and the non-vanilla transactions, kind of, for instance, fossil, this only applies to transactions in the mempool. So kind of it's just kind of like a set off. It's just a committee of random validators that say, oh, I've seen these list of 20 transactions.

So kind of like you need to make sure that they are included in the next block. But if they've been in the mempool, probably not. not the most contentious transactions, right, that siphon of value elsewhere. And equally kind of on the Oracle updating, yeah, maybe a little bit there, but kind of it's not the super meaty part of the order flow, right? Yes, that's correct. The more meaty part of the order flow would be things like pre-confirmation, especially execution pre-confirmation, right?

Especially when you think about things like swaps or other kinds of, of things that then affect status contentious, right? And so then being able to price what is access to that state worth ahead of time and being able to like, you know, then make these constraints correctly such that the yield for the validator is not impacted negatively and other kinds of things. That's going to be a very interesting problem. Do you think I'm kind of, I mean, you already said that kind of like there's more constraints coming for block builders.

Do you think the dynamic of power is going to shift, kind of like either two away from the block builder? That's a good question. I think fundamentally both the proposer and the originators have power, although the proposer is on a per slot basis, clearly the monopolist. And the originators need to band together to get more power, right? Because there's basically this world where proposer can say, hey, if you're not paying me enough as a transaction originator,

I'm just going to not include your transaction, well, until fossil at least. Right? And so then force, you can always think about a proposal setting some sort of reserve price almost, right? So because they have that monopolistic power. But then on the originator side, the more originators bound together in an aggregation,

the fees are higher. The more power they have to say like, hey, look, there's this total pie that we together will pay you. And so almost a little bit like a union. Like if you if you want all of it, then we are not going to give you that much and you'd rather take some of it than nothing kind of thing. And so what does I mean in the long term as there are more constraints and so on and so forth. I think the block build has always been a little bit of a mediator in the middle and always like kind of playing this dance like most marketplaces are. And so I think that's just going

to continue. And then I think generally depending on what the market structure does and so on and before. As long as none of the sites go too much out of whack, it's going to, you know, this dance is going to keep happening. Otherwise, maybe something more drastic. Cool. Kobe, this was super interesting. If people want to learn more about Gattaca or blockbuilding, where can you send them? We don't have that much educational materials yet, although we have, with a bunch of other teams in this space, started to work on this initiative called the Blockspace Forum. And so if you go to blockspace.forum, we've started to work on just some very, very high level educational material on the state of the pipeline and what block builders and all other kinds of actors do.

So that probably would be a good place to check it out. Cool. Fantastic. Thank you so much. Yeah.