Why Only 3 Builders Control All of Ethereum

Speaker A: Welcome to Epicenter, the show which talks about the technologies, projects and people driving decentralization in the blockchain revolution. I'm Fredericke Anz and today I'm speaking with Kubi Menzer, uh, who is the CEO and co founder of Gattaca. Gattaca builds the Titan Builder.

Speaker B: A lot of the edge that you actually get as a trading firm, uh, 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 FASC 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 trading activities and we went full on into block building. And yeah, I guess the, ah, the rest is really.

Speaker A: Thank you so much for coming on.

Speaker B: Hey, good to be here.

Speaker A: Cool. Um, maybe give us a little bit of backstory because uh, Gattaca and Titan are very much projects that don't dominate um, the discourse a lot. So people who are deep in the stack, they know who you are. Um, but maybe talk about how Gattaca got started and um, how Titan emerged and so on.

Speaker B: Yeah, sounds good. So Gattaca has been in the space for a while and we have our origins in um, 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 you know, the professional uh, traders from, you know, Tradfi hasn't moved, haven't or hadn't at least moved in at scale yet. They were there to some degree. And then we um, moved some of our resources from proprietary trading on centralized exchanges, such as market making, just the standard stuff, arbitrage, liquidity, provisioning, and moved some of those resources on chain. When we started seeing more activity on um, decentralized exchanges and the thinking basically was, hey, you know, um, the market structure might be a little bit different in crypto on centralized exchanges, but is still still very close to the traditional system. So most people will probably just be able to move over their playbook and then um, just dominate. And so probably not an ecosystem where we would have sustainable moats. But then when you look at decentralized exchanges, um, 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 uh, being one of the early adopters, uh, um, 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 exchanges. And a lot of the edge that you actually get as a trading firm uh, 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 fomo, so to speak, that we were uh, participants outside of the uh, cool stuff that is actually being built and almost this new industry. And we weren't actually part of that. We were just sort of on the sidelines, um, sort of trading on the layer but not actually being part of the layer itself. Then I remember a few months ahead of the merge and um, that was 2022 and um, I think it was uh, 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 uh, the capabilities that we sort of build up in house by becoming competitive traders were very much applicable to this problem, uh, set. But it's not just purely an optimization problem. There's also this service layer to it. And so I think um, that made it really, really interesting. And so when the merge happened and obviously PBS and the uh, block building market emerged from there, um, 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 um, into block building. And yeah, I guess the rest is really history.

Speaker A: Block building's 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. Um, so tell me about how blockbuilding has changed from your vantage point.

Speaker B: Yes. So I would say four years in crypto is actually really long. So um, there's that and I think uh, as with any other markets you, 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 um, the professionalism of the entities um, that are in crypto, as we just actually discussed before getting on, um, is um, increasing. So I think that applies, I think also to the broader industry. But then blockbuilding specifically is also very competitive uh, in its nature. And so if you put those two things together then you have this natural acceleration of what is required to be the best um, at this game. And so I think what has changed is basically on one side, uh, just from a pure technical perspective, the capabilities needed and the type of infrastructure, the performance, the latency, the, the uptimes, the consistency of processing transactions in different markets, scenarios, um, all of that, the bar has just gone a lot higher and the expectations from I would say block space consumers. So anyone who actually sends a transaction and wants that to be executed on chain, the requirements depending on the use case have also gone up. And so I think that put together has just increased the bar uh, so much. And yeah, that's uh, the state of the world. And happy to go into some more specifics.

Speaker C: Um, of course this episode is 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 offer more control over things like pricing, performance and operator selection. But they often come with added complexity and, and less flexibility. Lido V3 is changing that with STVaults. ST Vaults 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 SD ETH as a shared liquidity layer powering Ethereum's broader DEFI ecosystem. If you're just looking for a place to generate yield on your idle assets, LI twoearn makes it super simple. It offers curated defi strategies built around sdeth. You deposit once you choose a vault and manage everything from a single interface. To learn more and start building with SD Vaults, go to Lido fi SDvaults and get in touch with Lido. Contributors today.

Speaker A: Is Kattika today just a block builder? Uh, or do you have other parts, um, that kind of other projects that you're working on?

Speaker B: Yeah, um, so that'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 mempool. If you build a better block with these transactions, um, 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 um, the scope of what we do at Gattaca and so there's just a pure block building business which uh, 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 um, MEV Boost relay which is basically how validators connect to this out of protocol block construction market. The way to think about it is basically where price discovery for the wholesale of block space happens. Um, and then on the other side we also have something um, that falls into category of an OFA order or an order flow auction platform which serves both as ah, sort of privacy preserving endpoint to send transactions so you don't go to the public mempool but also um, a service where um, if you leak any mev the MEV 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 um, we've basically taken a more holistic approach where we see all of this together almost like as a bit of a platform where uh, from one side of you have, 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 um, the validator, so the core protocol that basically produces raw block space. And we are building sort of the 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.

Speaker A: That makes a lot of sense. So basically it's just kind of like uh, block builder adjacent services on either end that kind of you offer. In addition, um, maybe let's um, deep dive into block building itself. So kind of, I think a lot of people, even technical people in this space, um, 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 uh, the validator, uh, whose slot it is, kind of picks it up, um, and kind of uh, 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 nuance missing in kind of why the process of block building and proposing has kind of been divvied up between different parties. Um, and then secondly also kind of the role of the mempool and kind of how um, orders transactions actually get to the block builder. Because last time I checked, um, only about half of uh, 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, um, because obviously you make yourself extremely vulnerable to kind of leaking value there. Maybe give us your um, take of how block building actually works for someone. Explain for someone who knows how Ethereum works but who's never really thought about how the block building works kind of on a construction level.

Speaker B: Yeah, um, so I guess the way to think about it is uh, think about it like uh, 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 um, in order to facilitate this. And um, as you said before, um, 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, ah, 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. So even uh, if you just from a block builder's perspective, getting access to public mempool transactions is not just hey, I run one node locally and then I just subscribe to some websocket. But uh, it's operating multiple nodes globally across the world, making sure that they appeared with the right peers in the network to make sure the connectivity is high and then from each of those sort of funnel uh transactions to local builder instances. So that's the connectivity to the uh, public mempool. At the same time there are also some third party providers that have some optimizations and latency um advantages rather than just running nodes 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 MEM pool side of things. And then there's this other less transparent I guess um, part of the ecosystem which is a private mempool, a category of um 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 um, order flow auction platforms, uh, like I mentioned previously and you have things like Math Blocker for example, right? Or Blink or Flashbots Protect and a bunch of other services. Right. And similarly we also have an order flow auction platform and basically it's an endpoint where then you send your transaction to and it doesn't just forward it directly to builders so that um, your data doesn't get leaked, but it actually looks um, at what your transaction is doing. Let's say you are doing a swap and if that, that swap would cause an arbitrage opportunity it will also um, 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 um, originator who actually caused that transaction. There's also a gas optimization component because um, 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 um, these um, ofas so to speak often have a view not just of um, 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 um, some parameter around how much of the priority fee that are being paid uh, to the builder should actually be used to include a transaction and how much should be um 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 auction platforms actually combine multiple transactions into one Bundle because then combined transaction paying 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 techniques and optimizations that then completely get abstracted away from users but overall tend to give the user just better execution um, than if you send to the public mempool or even just directly via a private um, 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 um, scale consumers of blockspace. And big uh, example would be the um, CEFI defi arbitrage traders, right? So they basically look at prices off chain and then what the local prices let's uh, say within Ethereum are. And if, whether there's a discrepancy then um, they'll basically hit the order book on one side or um, the AMM on the other side. Trading firms generate quite a lot of transaction volume and so they have very, very specific needs, um, when it comes to the execution of those transactions. For example, um, 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 entire transaction because that means they have the latest information from the outside world where information is continuous. Often these um, traders also touch the top of the block, right? Which means that if you include one of their transactions you still, you can't just add it to the end of the block and you're done with the block and set 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 um, categories of players, like for example Telegram bots. That was like a big category of consumers of block space, um, at least last year for example where they have sometimes these bundles of hundreds of transactions that target a specific pool, they have requirements around 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, uh, all of their needs and execute optimally. And the better you are in aggregate across all these different services, um, the better you are as a block builder and the higher value blocks you can build which then in 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 as revenue because their revenue is dependent on basically the delta between what you build versus the second best builder.

Speaker A: Okay, there was a lot to unpack there. So kind of um, maybe let's go back to kind of the different kinds of transactions that you get. So kind of you, you get kind of the public transactions from the mempool, then you get the private transactions from the private mempools and kind of the bundles you also I assume get um, Udaflo from, from intent based dapps on. 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 decks arbitrage, why they want to sit um, at the top of the block. Uh, 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 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. Um, so how do they make it worth your while to kind of um, for them to become top of block? Because you said kind of like, okay, they will send at the last millisecond and then kind of like we need to reconnaissance, construct the block. You're not doing this out of the goodness of your heart because you feel for the arbitrageur. Right. How do the economics of that work?

Speaker B: So um, the economics is uh, a function basically of trying to collect as many fees as possible, expressed either directly as priority fees or direct builder payments. And builder payments are uh, basically just transfers to the coinbase, which is an EOA that's 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 you first of all win the auction and also how much revenue you make as a builder. And in a broader sense the way to think about it, as well as what a builder is essentially facilitating, it's basically optimally auctioning off specific states. Right. So now we talk about top of block. Um, but potentially you could auction off that piece of state 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 um, allows us to win the auction, uh, when it comes to the wholesale of block space.

Speaker A: Okay, I understand. Um, 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?

Speaker B: 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 the block. So um, in PBS proposer builder separation, the validator is basically just the proposer. So how it works is that the block builder sets the coinbase address to a wallet they 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 coinbase to the proposers fee recipients. And this is basically what is um, classed as the bid. Right. So the proposers or the relays on behalf of the proposers 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 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 proposer the most. And um, the proposer basically just signs off on that block the relay has picked for um, the proposer, and then the block gets propagated to the network.

Speaker A: Is there any optionality on the side of the validators or can I as a validator say, look, I really don't like this guy Kubi, I just don't, I don't want any Titan build blocks, so kind of give me whatever as next best.

Speaker B: So currently most relays don't have any sort of filtering logic Other than um, the OFAC SDN list. So some relays actually look at that list and if there's a block that includes OFAC transactions, they will not serve it to specific proposers. And the proposers can basically specify that when they register uh, with a relay that I only want to accept uh, those kind of blocks. Now in theory you could try to as a proposer filter for let's say I only want Quasar blocks or I only want Titan blocks or I only want build on it. That's definitely possible, but in general just not incentive, uh, compatible.

Speaker A: There's a lot of builders around, but kind of not a lot of builders actually build the majority of blocks. Right? So kind of if you look at the stats, kind of 90 plus percent of blocks are built by Titan plus Beaver plus fleshbots, right? Those are currently the biggest three. Why is there only this small handful of competitive builders?

Speaker B: Yeah, so actually currently we are the currently largest, the uh, second largest builder net by Flashbots. Um, and then the third is uh, a builder called Quasar. And so in I think they have like 15 to 20%, flashbots 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 effect to block construction and also the incentives, um, 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 mempool for a given slot and that was the only transaction on Ethereum that's willing to pay to get included. And let's say that transaction pays 1 ETH. If that transaction went to let's say 2 builders, now 2 builders will have exactly 1 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 an originator's perspective or blockspace consumer's perspective, you would want to pay as little as possible. Right? Which is sort of this fundamental tension between the producers of Blockspace 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 as 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 builder will have the Exact same amount of priority fee and then 100% of it will be paid. But um, if you send that transaction to a single builder 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 is paying is actually lower than the initial sort of one eth in that example. And so I think that is crux of it. And this realization was actually made by the old, um, the first block builders. There were also SEC Stacks trading firms. Um, so there was Beaver Build, um, and there was uh, Rsync, which were, which are both like 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 will be bid away. And so if they just kept it to their own builder, um, they could optimize on those fees. Right. And so that was sort of the starting point where different uh, players in the industry realized that, okay, us included obviously, um, 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 themselves? 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. Which then, but also has this flywheel effect of um, basically um, competing um, lots and lots of builders out of the market.

Speaker A: And this refund, is this something that is contractually kind of specified or is this kind of a handshake kind of agreement?

Speaker B: Yeah, I mean some of it is um, via just APIs and you can set sort of refund percentages and stuff like that. Um, some of it is also a bit bespoke, um, where if you have like one or two players across like a 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, um, so it's basically a mix of those.

Speaker A: 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, um, is typically a lot more expensive than being the taker. So kind of you have to make sure kind of your orders don't go stale. Basically the prices don't move under you. Um, 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 third parties the same, 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.

Speaker B: 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 there's the more sophisticated trading firm and now it looks into the block and sees what someone else is doing and there's all this conflict, uh, of interest and potential, um, use cases that arrive that might uh, be adversarial to the other side or serving the customer base more holistically. So it's something we absolutely don't do. What we have done, um, we have done a little bit of an experiment with flashbots where we basically streamed our state into a TE that was locked down. And um, the TE was configured such that the only data that was leaving the TE was at the bundle that is sent back only to our endpoints. So that was like end to end, under control. So under these conditions we were comfortable sharing that data within this trusted execution environment that 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 bundle that's 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 front running bundles and anything that might be again adversarial. But other than that we um, we don't give access to um, 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 Sextex 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 mids, but maybe you have some OTC flow and you know 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 uniswap pools out of whack you, 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 uh, move quotes on chain. So they take on chain but are uh, generally also market makers. Um, that being said, there's a bit um, of an initiative on Ethereum right now to actually enable faster updates of being able to quote liquidity on chain. Um, so that's something exciting that's in the works, um, which I'm actually quite excited about. Um, because I think that's gonna just make Ethereum more competitive as an ecosystem for actually uh, interacting and trading on chain. But um, yeah, other than that, which is not life yet, the active liquidity provisioning is um, not as active because currently it's just too expensive to do

Speaker A: under which EIP kind of is the um, improvement for the intra block? Um, quoting.

Speaker B: Oh, so that's actually not an EIP. Um, and the V0 is also um, not something that would happen intrablock. I think Intrablock, anything that happens interblock should almost be viewed as a based rollup that's synchronously composable or some sort of composition synchronous composability layer that can basically advance states um, while, and then when the 12 second slot time ends then settle uh, to Ethereum. But um, what we are enabling now is basically just making sure that if you have, let's say something like a prop AMM 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 are prevented from toxic takers, um, which then should obviously result in tighter spreads and then that's just net beneficial for everyone.

Speaker A: 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?

Speaker B: Yes, correct. It's basically akin to the broader ACE application controlled execution sort of um, strategy where you give apps more fine granular control of how their transactions get executed.

Speaker A: Okay, if you now kind of look at your average block. So I mean there's obviously also kind of a lot of really vanilla transactions right Kind of like um, if you kind of had to classify kind of the block in terms of what it contains, um, 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 orders per block, is that correct?

Speaker B: Yes. So I would say overall um, it's quite spiky. So the priority fee based um, transactions that actually are contentious or contending for specific states. So I don't have a specific stat in mind but it's definitely skewed to especially if you look at like the really really uh, big um blocks or the is very similar to volatility usually have like these big volatility events right that 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 um, gets passed through. Um, and then you have just normal conditions which are a lot more mellow. Um, that being said there's still at least if priority fees are ah, at least a little bit high enough. Um, even with transfers and sort of non contentious 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 um, 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 spiker 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 um, that also affect the overall block value.

Speaker A: Can you give me an idea of kind of optimizations that kind of can still um, affect the value?

Speaker B: Yeah, so I would say a uh, 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. Um towards the end of the slots if let's say you know the proposal is in let's say Northeast Virginia where you know a lot of the US um based validators are. Um, there's ah 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 blockchain block usually probably easier because it's at the end of the block because it's non contentious. Um, but just as a simple example, if you will then have more priority fees that another builder who is not as fast has and then that again leads to a higher block and more revenue potential.

Speaker A: 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. Um, 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 um, 1,000 transactions in a block, there's um, a thousand factorial ways of kind of placing it, right, ordering them. So kind of like you have some heuristics kind of like which, which um, generally can, 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 the fourth one I heard is, is latency being able to send the block at the last possible millisecond. How would you rank them? Kind of in importance.

Speaker B: 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 transactions that is significant enough. And as you said correctly, there are the transactions that are just available to everyone in the public mempool and they're 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 um, 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 te, which means you're very constrained in sort of like compute capacity, uh, in terms of like what data centers you can provide your um, deploy your um, infrastructure in. And also in terms of your alpha. Because if you need to actually show what you're running, that means all the proprietary 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 regimens, you need those big CFI, DeFi trading firms, um, 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 at 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 um, your local simulation and um, your ordering algorithms and their heuristics, um, again this all depends. You can sort of choose your specialty first and then optimize for one sort of regiment, 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 is just like these are all sources of alpha, so to speak. And so the more alpha you can stack, the more competitive it makes you. And as in any uh, industry, my recommendation is always 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.

Speaker A: Yeah, I think that's generally a very good recommendation. Kind of like being the best at everything. It's, uh, something I constantly fail at. So it's, uh, um. Um, tell me about your relationship with the searchers. So kind of the searchers 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 we have some sort of contractual agreement? 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?

Speaker B: Yeah, so I would say overall, um, 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, uh, sort of unknown teams that maybe are just on Discord and Telegram. And some of those guys, like we've never seen before, uh, 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, uh, of that nature. Then there are some that are well established players, like some of the brands that 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 it's win, win for everyone. Um, 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 builder itself is also permissionless and sort of anyone can use it and, you know, all of those things taking into account that it's sort of like a, uh, 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.

Speaker A: I mean, it's also very much a repeat game, right? So kind of like if I, 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 them bundles. Right?

Speaker B: Yeah, I mean in terms of payments, um, so often it just works permissionlessly. Right? Because there's something that gets paid to the coinbase and then there's fixed refunds or 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 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, uh, they will no longer be working with you.

Speaker A: 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 third party's.

Speaker B: So, um, as I said before, when we launched uh, the builder, we actually stopped all trading activities. So we do zero bundle origination. We haven't since 2022, basically.

Speaker A: Okay, so the answer is kind of like, it's just uh, okay, it's just

Speaker B: um, because of the conflict of interest and so we believe strongly long term that's just not uh, incentive compatible.

Speaker A: Okay, what do you think about kind of a role convergence or some sort of vertical integration between builder and validator? Because kind of like that would make a lot of sense too, right?

Speaker B: 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 validator set, which is what keeps the protocol, um, the entities that actually vote on the validity of blocks and do the attestations, that's the, the core protocol itself and that needs to be maximally decentralized. So from that perspective, um, 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 some are um, 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 is as much of a risk anymore. Now if that 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 mev m Woo style blocks, obviously you know that will be really, really centralized. And so if it happens now I, I see it as way less of a concern.

Speaker A: Okay, um, 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 um. Because you're leaking value on the server side, right?

Speaker B: 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 the that you can find the optimal solution at the time of execution versus just top of block because there are solvers that currently operate 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 that was mined. Right. But then just as we discussed before, the top of the block often is very caveat and taken by others. That means now the prices have changed. Yeah. 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 the solving business because solving itself like being up to date with all the liquidity pools, potentially having internal liquidity and offering that via uh, like some or versus passive AMMs that starts to then become more of a trading firm. But um, so what we are currently exploring is basically if there's a way we can give either something like um, off chain sort of execution parked within the builder. So if you can give us some sort of logic that we can uh, 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 that has a lot of latency overhead which is a problem. And something else we're also exploring is basically the solution being submitted to us as the sort of um, the floor and then basically giving us almost like

Speaker A: kind um of like an intent based kind of. It's kind of like intent inception. So kind of.

Speaker B: Okay, yes, exactly. And then being able to then sift through potential other, 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 State 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. Um, so we uh, 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 Ethereum more competitive.

Speaker A: 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 proposal builder separation, there's inclusion lists and kind of, there's still uh, talk of pre confirmations. What do you make of those and what are you looking forward to?

Speaker B: I would say looking forward to all of them. Now there are some nuances in terms of the implementation detail. So um, 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 EPBS is actually formally enshrining this market structure that currently is all like out of protocol in the core protocol, which means, and specifically with it the fair exchange part. Right. So the fair exchange problem is the part where you have, let's say in a two sided market, um, 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 take all the value and not pay the builder anything. And if the builder were just to give them the bid without actually proving that they have the block, then they could just lie about it. And with EPBs you basically solve this ah, fair exchange problem through trustless payments. So that's exciting. So the idea that a bunch of this um, centralized infrastructure now has like an in protocol fallback path for whatever reasons, liveness, robustness, um, 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 trade off 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 are we prioritizing? Um, all of this aside, I think it's gone through the process and it's been ossified and so it's coming in the Next. Hard work. So overall I have always been excited about EPBs. Um, there are some nuances around this specific implementation detail, but I think the fact that Ethereum as a core protocol actually can handle this um, 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 in protocol 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, um, 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 as a service and is it uh, 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 protocol feeds into the block construction process itself. But the heavy lifting of like 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 for, especially from node operators or stakers that run in certain jurisdiction where certain transactions are not allowed to be let into the blockchain block. And so there's a bit of a tension um, between hey, as a neutral infrastructure layer here, Ethereum obviously needs to support non censorship. 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.

Speaker A: 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 um, legal argument about billing being not willfully but actually blind and kind of like you're 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 it actually bolsters the legal defense of uh, validators and blockbuilders.

Speaker B: No, I agree, um, but then always depends on the sensibility of the regulator. Right. Some might just go all overboard and be like okay, fine, can't participate then. Right. Which also would not uh, be great. But yes, I agree.

Speaker A: Okay, um, so how do you see block building change over the next year? So it's been around for three and a half, four years um, 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?

Speaker B: So we've already enumerated some of the changes, right? So um, just being part of the core protocol or EPBS itself just changes the market structure a little bit. Nothing fundamentally changes. But um, there are some nuances um, and some technical details here. Um, 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 softer constraints. Um, and so now the constraint of hey this is a transaction that you absolutely have to include then you can go even further which is also the other thing that we haven't talked about pre uh, confirmations for example which is someone issuing uh, 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 uh, that you have to take into account when running these block construction processes. But um, 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 on how a transaction gets sequenced and how the block essentially then gets constructed. With that um, we're basically just incorporating 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 just so fundamental to the core protocol itself. So I think it all makes sense.

Speaker A: 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, um, this only applies to transactions in the M Mempool so kind of it's, it's just kind of like a set of uh, it's just a committee of random validators that say oh I've seen these list of 20 transactions. So kind of like you, you need to make sure or that they are included in the next block. But if they've been in the mempool probably um, not the most contentious transactions, right that siphon of value elsewhere. Um, 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?

Speaker B: Yes that's correct. Um, the more meaty part of the order flow would be things like pre confirmation especially execution pre confirmation. Right. Where especially when you think about things like um, swaps or other kinds of things that then affect state as contentious. Right. And so um, then being able to price what is access to that state worth ahead of time and being able to um, then make these constraints correctly such that the yield for the validator is not impacted negatively and other kinds of things um, uh that's going to be a very interesting problem.

Speaker A: Do you think kind of, I mean you already said that kind of like there's more constraints coming for blockbuilders. Do you think um, the dynamic of power is going to shift kind of like either two or uh away from the block builder?

Speaker B: That's a good question. I think fundamentally both the proposer and the originators uh have, 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. Um right. And so then force you can always think about a proposal setting some sort of reserve price almost Right. Um, so because they have that m Monopolistic um power but then on the originator side the more originators bound together in aggregation the fees are ah 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 want all of it then we are not going to give you that much and you rather take some of it than nothing kind of thing. And so what does that mean in the long term as uh, 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 so forth as long as none of the sites go too much out of whack, um, it's going to you know this dance is going to keep happening otherwise maybe something more drastic.

Speaker A: Cool Kobe. This was super interesting. If uh, people want to learn more about Gattaca uh, or blockbuilding, where can you send them.

Speaker B: We don't have that much educational materials yet, although, um, we have, um, with a bunch of other teams, um, in this space, started to work on this initiative called the Blockspace Forum. And so if you go to Blockspace Forum, um, we've started to work on just some very, very high level, um, educational material on, like, the state of the pipeline and what block builders and all, all other kinds of actors do. So that probably would be a good place to check it out.

Speaker A: Co. Fantastic. Thank you so much.

Speaker B: Yeah.