MEV-Boost Community Call #1 - 9 Mar 2023

let’s have another community call!

Meeting Info


  • capella hard fork readiness
    • sepolia recap
    • goerli readiness
      • goerli shapella fork scheduled for 3/14/2023, 10:25:36 PM UTC
  • testing updates
  • research updates
    • optimistic relay discussion
  • open discussion
    • relay sustainability, funding models

Notes from zoom chat

09:01:38 From Alex Obadia to Everyone:
09:02:11 From Justin Drake to Everyone: · GitHub
09:02:16 From Alex Obadia to Everyone:
ty for your coordination Alex
09:02:25 From stokes to Everyone:
Thanks for stopping by!
09:03:10 From stokes to Everyone:
MEV-Boost Community Call #1 - 9 Mar 2023
09:03:26 From Alex Obadia to Everyone:
0-indexing is the way
09:03:30 From Chris Hager to Everyone:
09:07:36 From Chris Hager to Everyone:
GitHub - flashbots/builder at capella
09:08:34 From Chris Hager to Everyone:
mev-boost summary issue: Next release v1.5.0 -- Capella (withdrawals) & more · Issue #451 · flashbots/mev-boost · GitHub

details about the update across the stack:

09:09:01 From Chris Hager to Everyone:
GitHub - flashbots/prysm: Our custom Prysm fork for boost relay and builder CL. Sends payload attributes for block building on every slot to trigger building.
09:09:16 From terence to Everyone:
SSE event end point should be in our next release
09:09:31 From sukoneck to Everyone:
Reacted to “SSE event end poin…” with :tada:
09:09:32 From Max Birge to Everyone:
Reacted to “SSE event end point …” with :tada:
09:10:01 From Chris Hager to Everyone:
09:10:02 From Chris Hager to Everyone:
Reacted to “SSE event end point …” with :tada:
09:11:07 From Alex Obadia to Everyone:
09:11:11 From Robert Miller to Everyone:
09:11:16 From Robert Miller to Everyone:
Test in prod
09:11:38 From Alex Obadia to Everyone:
no he aint
09:14:10 From Max Birge to Everyone:
09:14:34 From Alex Obadia to Everyone:
what would be the email tho
09:15:02 From Alex Obadia to Everyone:
ty sir, i was more jokingly asking about what we’d name it
09:15:38 From Chris Hager to Everyone:
optimistic-relay-documentation/ at main · michaelneuder/optimistic-relay-documentation · GitHub
09:16:59 From Justin Drake to Everyone: · GitHub
09:17:29 From Alex Obadia to Everyone:
Optimistic Relay by michaelneuder · Pull Request #285 · flashbots/mev-boost-relay · GitHub
09:17:34 From Alex Obadia to Everyone:
optimistic-relay-documentation/ at main · michaelneuder/optimistic-relay-documentation · GitHub
09:22:59 From Alex Obadia to Everyone:
justin could you call out the link again plz?
09:23:10 From Justin Drake to Everyone:
Rated Network Explorer
09:24:23 From Alex Obadia to Everyone:
is someone from bloxroute on this call? :wink:
09:25:09 From phil to Everyone:
how do they get this stat? there’s no objective tag for what relay something came through and we probably re-relay many of those
09:25:38 From Robert Miller to Everyone:
In the early days they weren’t simulating blocks from their builder. Their builder had a bug and then they publicly added simulations.
09:26:15 From Chris Hager to Everyone:
they did significantly increase their winning slots recently though, could easily be that disabling validation again helped boost it
09:27:55 From Chris Hager to Everyone:
09:29:30 From Robert Miller to Everyone:
@Justin how does the system work when reported block values are above 1 ETH?
09:29:40 From stokes to Everyone:
Fallback to status quo
09:31:56 From Alex Obadia to Everyone:
go Mike
09:32:05 From terence to Everyone:
Congrats mike!
09:32:06 From phil to Everyone:
09:32:07 From phil to Everyone:
09:32:09 From Chris Hager to Everyone:
:tada:"enshrined pbs coordinator"
09:32:19 From austonst to Everyone:
Reacted to “Congrats mike!” with :clap:
09:33:40 From Alex Obadia to Everyone:
mike wen ePbs
09:35:25 From Alex Obadia to Everyone:
it makes simulation-based censorship less successful right?
09:36:46 From stokes to Everyone:
09:37:37 From Alex Obadia to Everyone:
mostly a PR one it feels
09:37:44 From Alex Obadia to Everyone:
PR / optics
09:38:24 From Michael Neuder to Everyone:
sorry lost my wallet in uber have to drop for a sec
09:38:30 From Alex Obadia to Everyone:
oh no sir
09:40:12 From phil to Everyone:
any plans to release raw data?
09:40:18 From phil to Everyone:
also we should collab x flashbots data
09:40:31 From Max Birge to Everyone:
Reacted to “sorry lost my wallet…” with :sweat_smile:
09:43:12 From Toni Wahrstaetter to Everyone:
i’ve put up the data behind mevboost pics ( | Open Data). it’s basically the data you described, justin, with builders (aggregated by most common extra data) and validators (aggregated by deposit address + heusristics)
09:43:50 From Chris Hager to Everyone:
public bulk data ++ :heart_eyes_cat:
09:44:28 From Alex Obadia to Everyone:
09:44:55 From Alex Obadia to Everyone:
just a bunch of bats
09:45:11 From Alex Obadia to Everyone:
Justin – how long would sending_collateral phase exist for tho?
09:46:17 From phil to Everyone:
what about creatie solutions like they hand you a tx you can only spend if they cheat you but otherwise never goes back to them… may solve the “deposit” issue
09:46:33 From phil to Everyone:
always goes back to them*
09:46:58 From phil to Everyone:
but still some centralizing qs, also qs about whether that constitutes financial activity vs eg network / infra
09:47:31 From stokes to Everyone:
Bonded builders + optimistic fault proofs, and try to do everything on-chain
09:48:05 From phil to Everyone:
→ the EF adopts a team to do this and eventually becomes ultra financialized :trollface:
09:48:58 From stokes to phil(Direct Message):
“We’d be happy to hold your collateral :upside_down_face:
09:49:11 From terence to Everyone:
Bonded builders + optimistic fault proofs, and try to do everything on-chain
Sounds like this: Rollup-relay - HackMD
09:49:13 From phil to stokes(Direct Message):
hahahahaha send me that eth any time sir :stuck_out_tongue:
09:50:30 From austonst to Everyone:
I’ll also mention here, they recently had a talk at ethdenver that described an optimistic-style design w/ contracts but code and docs still not available
09:53:35 From Max Birge to Everyone:
Ultimately the worry here is we accidentally bring down the drawbridge and create a class of super-relay super-builders that make it much harder for the smaller builders to compete. If we want to be anti fragile, reputation and trust are not words we should be too comfortable with medium long term.
09:54:24 From phil to Everyone:
super important perspective max, I agree accelerating super actors is the worst case scenario (am a protecting decentralization maxi, plus there’s enough incentive for that to happen without us haha)
09:55:46 From stokes to Everyone:
You could only do that one-off though
09:56:18 From terence to Everyone:
Reducing challenge times in rollups - Layer 2 - Ethereum Research
09:56:49 From Max Birge to Everyone:
One thing not discussed: should we give a proposing validator the option of ignoring an optimistic block?
09:57:21 From stokes to Everyone:
I think thats an interesting feature to explore as we get closer to having an upstream OR implementation
09:58:28 From phil to Everyone:
interactions w inclusion lists is a great research point
09:59:20 From Freddy Zwanzger to Everyone:
I have to drop but really enjoyed the discussion!
09:59:54 From terence to Everyone:
We probably should host another session that’s just for optimistic relayer. This type of discussion is very useful
10:00:15 From stokes to Everyone:
We have another 30 mins!
10:00:26 From terence to Everyone:
Ah ok, thought it’s just an h our
10:00:28 From Robert Miller to Everyone:
What happens if the builder lies about their bids
10:00:41 From Robert Miller to Everyone:
e.g. says “this is worth 0.99 ETH” but is worth more to the proposer
10:00:50 From Robert Miller to Everyone:
Kinda weird edge case
10:02:40 From Alex Obadia to Everyone:
gotta drop, ty all :smile: and ty Alex for organizing!
10:02:46 From stokes to Everyone:
10:03:46 From Kody Sale to Everyone:
Great info, glad I was able to hop in.
10:04:29 From phil to Everyone:
will definitely think hard about the points this month!
10:10:57 From austonst to Everyone:
Talking with bloXroute and blocknative at ETHDenver recently, both teams suggested to me that their relay operations are a pure money sink and that they are looking to monetize and are otherwise unsure why they’re still running this thing.
10:15:00 From Chris Hager to Everyone:
:fire: :crossed_fingers:
10:17:15 From Chris Hager to Everyone:
:heart:aestus (
10:17:40 From Chris Hager to Everyone:
clickable now lol
10:18:37 From Chris Hager to Everyone:
code of conduct, for public funding?
10:19:58 From stokes to Everyone:
Btw dm me if you want to get on a google calendar invite for the future calls
10:21:16 From Pedro G to stokes(Direct Message):
Thank you,
10:23:39 From Chris Hager to Everyone:
validation code is here btw: builder/api.go at capella-1.11.3 · flashbots/builder · GitHub
10:24:56 From Max Birge to Everyone:
Reacted to “clickable now lol ht…” with :heart:
10:25:30 From Max Birge to Everyone:
clickable now lol
Thanks. Persuade your builders to send us some blocks plz :wink:
10:25:32 From Chris Hager to Everyone:
Decentralized crypto needs you: to be a geographical decentralization maxi
10:26:44 From Toni Wahrstaetter to Everyone:
nice call! see ya
10:26:46 From rt to Everyone:
Thank you!
10:26:51 From Brian Stout to Everyone:


Below you will find is rough transcript of the call. Due to the character limit the transcript is broken into two posts. Thank you to @ralexstokes for organizing and all of the participants. Please call out any omissions or mistakes.

Pt. 1

Capella Hardfork readiness

  • Stokes: This is the second mev-boost community call. The first thing we want to do is go over upcoming hard fork readiness for capella.


  • Stokes: Go over upcoming hard fork readiness for capella, we just had the Sepolia hardfork and it went pretty well. I don’t know if anyone here wants to ad anything else to how that went. Maybe Chris, how did things go for the Sepolia fork?

  • Chris Hager: For Sepolia it went well, our stack worked. From our end, the relay main branch everything is working, mev-boost has an alpha release out that is also linked. We had an issue setting the correct Shanghai override so it only worked a few hours later. And I will also link that document again where we summarize the Capella changes. All is in order from our stack. We are in the process of merging builder and Prysm into the default branches but for both mev-boost and the relay this is already done.

  • Stokes: Okay great. So after we fix the configuration issues, everything is going to be working fine with Sepolia?

  • Chris Hager: Yes, and expect it will be on Goerli too. Everything code wise is pretty finalized. We are investigating updating to the latest geth version but that’s not necessary on the builder that you need to set the Shanghai override then manually. I will post an update about this the latest on Monday.

Goerli readiness

  • Stokes: Okay sounds good. I think that’s probably it for Sepolia and we’ll just keep moving right into Goerli. So this Hardfork on the 14th in just a few days here. Any relay operators on the call? We had said we could use this call to do any coordination required for Goerli, any relays here who want to chime in? Do you feel ready? Do you know what to do? It sounds like Chris has notes on what releases to use and how to do the upgrade, If your using the flashbots relay?

  • Austonst (Aestus): - It sounds like the mev-boost relay code is good to go. I have been following that pretty closely. I am a little uncertain about the block validation geth status. I saw there is a shapella fork or branch. So hearing from Chris its not necessarily necessary to have Geth updated for that, just wondering, a little more details there?

  • Chris Hager: On test-nets we are using builder code base as validation node and a builder at the same time. So you can enable the validation logic in the builder project itself. I will double check if the validation gets repository is also updated. But what is for sure working is the builder repository, in particular the Capella tree. So you can use the Capella tree of builder to run it as a block validation gets.

  • Austonst: Will this be the main source for validation going ahead? Should I consider block validation geth to be kind of deprecated at this point?

  • Chris Hager: Do we want to maintain two repositories that are largely overlapping but not quite? Or if we are fine with having the additional builder overhead in the code also running as a part of the validation geth which would simplify the maintenance and upgrading, but It’s not decided yet. I will certainly post an update going forward. But for Goerli I would recommend running the builder project.

  • Austonst: Got it thank you.

  • Stokes: Chris you said you would put together a document with what exactly relays need to do?

  • Chris Hager: I will try to write this up a bit more concisely for relay operators specifically. Keep in mind that you also need the FB Prysm fork because we implement to getWithdrawals endpoint that you kind of want the relay to validate that withdrawals are correct. This is a temporary solution until the SSE events are implemented in hopefully a few weeks. Until then our relay needs this Prysm fork to provide the withdrawals.

  • Stokes: To be clear, Will anyone need to supply a Shanghai override? Or if they used the right branches and releases everything will be good to go?

  • Chris Hager: On Prysm it’s good to go.

  • Stokes: I thought you mentioned something with the builder, but that might not be an issue.

  • Chris Hager: Yeah, I will post more updates. We are currently not yet on the latest Geth release that wouldn’t require the Shanghai override.

  • Stokes: I see

  • Chris Hager: I will certainly post an update tomorrow about the details.

  • Stokes: Just to elaborate, Basically the Goerli configuration is hard coded in later geth releases, the builder code it sounds like is not using that yet. Sounds like code is ready to go, again if you are relay operator and hopefully you feel prepared, if you don’t please reach out to me or FB or someone you trust. It should be pretty exciting. One question I could ask is How will we think about testing this? We will just Look at the usual mev-boost metrics and see if it works? I don’t know if anyone has thoughts on that? I guess relays will know quickly if everything stops working at the fork.

  • Chris Hager: Yeah the relays internally will throw errors if there is something not working or builder submissions not accepted. I think Paritosh runs a large number of goerli proposers. W/e relays are configured there we should be quick to know any issues that arise through Paritosh.

  • Stokes: Right that’s a good point. I don’t think Pari is on this call is he? No that’s okay, but I can follow up with him. Anything else for Goerli is everyone else ready it sounds like there might be a few more details on the exact software releases and how to run them that Chris will work on, but otherwise sounds like we are ready to go.

  • Terence: I have a question. What is the best communication channel for relayers these days. If I have an alert system that’s going on and I want to look in a relay channel to see if they are recording anything, where is the best place for that, where are relays hanging out?

  • Stokes: That’s a good question does somewhere here want to chime in? My understanding is that most relays have a web interface from their website. Perhaps there is a status page link there. I think It’s up to relays how they communicate. Separately if you see something and need to push to everyone, I suggest using the ETH R&D discord channel or maybe the flashbots channel. But that being said do any relays on the call have anything more specific here?

  • Justin Drake: There is a relay chanel on the FB discord that I constantly monitor.

  • Max Birge: Yes I monitor that as well

  • Chris Hager: Block construction channel on Ethereum R&D channel (discord) is a place all the relays are aware of.

  • Stokes: Okay FB relay channel. Do we know exactly the name of that one?

  • Justin Drake: Relays, under general.

  • Stokes: Great I can grab a link to that in the notes after and the ETH R&D channel Block construction. One thing to consider, we con consider a mailing list of sorts for critical issues. I know this is something a lot of the client teams do both at both the EL and CL layer. This could be one quick way to get very urgent things in front of everyone as we need to.

  • Anything else on Shapella? Alex asked in the chat about this e-mail list. We could just make one and people could subscribe as they want to. I’ll let you come up with the name.

Research update ~ optimistic relay

  • Stokes: I think the next point we will move to is the optimistic relay. I don’t know if Justin or Mike if you want to give an update on where things are at there. There has been a lot of progress since last call. Maybe something is on the way to being rolled out

  • Mike: Yeah I can give a quick update here. Just so everyone is on the same page, Let me link to the PR here.

  • This is the context. For anyone who was not on the last call this is a change we are proposing for relays where instead of validating the block submissions as they come in before marking those bids as eligible to win the auction, we defer that block validation till later. This should hopefully improve block submission latency. We have in terms of status we are getting close to launching in prob. We have been running in Goerli quite smoothly, just working out last details of getting code rebased on capella changes. We Have been in contact with a few builders who are interested in piloting for us and have an initial interest there.

  • One other link I want to plug. Justin Linked the builder on-boarding docs. Which can show what the process is on the builder side as far as posting collateral and signing up for this roll of optimistic relaying. And the last thing I wanted to share is the broader roadmap are have been working on.

  • This hopefully should help contextualize what we think of Optimistic relaying and how it fits into the broader enshrined PBS landscape. We are thinking hopefully next week we will have some optimistic relaying begin. That may shift depending on if we can make sure everything is working on the software side. That is the main update, do you have anything to add Justin?

  • Justin Drake: Yeah I guess one thing we have been doing, we have been doing is dramatically reduce the amount of simulation errors we are seeing on the relay. There are two things we have done.

  • We have found various edge cases in the relay infra that lead to simulation errors that shouldn’t happen. For example there was an artificial constraint on the block size. Valid blocks considered to be invalid because of their size. That should improve the liveness of Ethereum. It means these bigger blocks will make it on chain more easily going forward. There is a long tail of such edge cases we found, maybe 10 or so that were in the process of fixing or have already fixed. We are pushing some PRs upstream to FB repo as well to reduce these edge cases.

  • Another set of edge cases is on the builders side. It turns out that various builders have bugs in the sense that when they create their blocks there are just some issues. We have very meticulously gone through every error on the builder side and told them about these errors. I’m in contact with most builders. If you are a builder that I have not approached yet please contact me because its more likely than not you are producing some invalid blocks This should help the whole ecosystem because it means there is less spam on the relays and things run smoother. Generally speaking the signal to noise is higher.

  • All of this work is Part of the legwork to optimistic relay up and running, we don’t want any simulation errors.

  • One thing I do want to highlight again; If there is a builder bug, more likely than not it will be caught extremely early and lead to an early demotion without a bad block ever winning the auction. I am still not expecting bad bids to lead to on-chain incidents with missed slots. If that were to happen as described in the doc I linked were going to write a post mortem which will be public. Basically we are trying to be as transparent as possible about these on chain events, and they should happen exceedingly rarely.

  • Stokes: From experiments on Goerli it sounds like you haven’t run into too many issues yet?

  • Mike: Right so basically we have been addressing simulation errors on the relay end or the builder end. Now we have several days worth of blocks, thousands of submissions without simulation errors. We are confident that the fixes are working as intended. Up-streaming which ones seem relevant, making tweaks on the relay on our end and, communicating with builders if it seems to be on the builder end.

  • Stokes: That sounds good, at a high level if one of you can call out these PRs to the relay code at least this would be really good so we can get more eyes on it. I understand there can be edge cases but we should just make sure there are reasons to remove these edge cases and they weren’t there in the first place.

  • Mike: I’ll follow up with a link to PRs.

  • Stokes: Great. I think another good question is up-streaming the whole optimistic relay into the mainstream FB relay code. Last time there was some discussion around is this a Good idea, not good idea? I don’t know if anyone here on the call wants to chime in further on that? I believe this is still the plan of the ultrasound team is to upstream this code.

  • Justin Drake: So one data point I want to put forward. If you go on its a knew dashboard that’s been built by the guys. Basically what they do is for every builder they show the relay distribution of winning blocks. It’s very interesting, One data point that stands out to me is the fourth row, bloXroute. The builder is connected to many diff relays. As you can see the blue portion which is BloXroute is 96.6%. Most of their blocks are being won by their own relay.

  • Now I don’t know 100% for sure, but my suspicion is there is some vertical integration going on. The relay is not re-simulating the blocks that come from the builder. They are running in optimistic mode essentially and that’s The power of Optimistic relaying. It dramatically changes the equation. What I think will happen is that once we set up optimistic relaying for some of these builders, The Ultrasound relay will be winning most of the auctions. It will almost be a forcing function for the whole ecosystem to move onto optimistic relaying. So that might be a good reason eventually at least to merge in the optimistic relaying logic in the FB repo.

  • Phil: So at least from my perspective we are definitely open to having the conversation about up-streaming. I think it’s an early stage conversation. I think the work and experimentation going on is super interesting. Our worry or concerns would be from market integrity and market structure side. We view our role in the mev-boost ecosystem and MEV in general as standard setting in some way. So we need to think through what are all the possible affects on market structure. The key vector I would be thinking about that myself is centralization. What are the additional centralization pressures of capital requirements and also possibly opening new games by making certain changes to the relay. We do need to do that analysis and have those conversations. We just started thinking about this stuff, putting out content and engaging with the people who are working on it so I see it as a starting point. We are definitely not against up-streaming it especially if some of these concerns can be mitigated or resolved.

  • A few practical concerns I have that are low hanging fruit. One is I would still very strongly advocate for a path to win a full block without needing collateral. I think Preserving the one off permissionless nature of block construction and allowing for re-simulation is an important market property to allow for new entrants, people who have edges that are not latency related to enter the market. That’s a low hanging fruit and there are some deeper questions Collateral, latency, up-streaming to L1 and I think those are still early research questions. I do appreciate everyone who has been providing content. I am reading it and thinking about this now.

  • My long term dream this is somewhat relevant for mev-boost is to move towards a relay-less system. Obviously there will always be relays from a network perspective, but I don’t think we should have trusted party that exert any centralization pressure in a network role called quote-un-quote relay and that includes flashbots. Eventually the goal would be to deprecate that functionality.

  • The other angle other than decentralization pressure that I would want to reason about; Does this require any changes that would obviate our ability to later upstream this role or w/e else we want to do with it? Does it remove any flexibility for mev-boost development. Those are my angles and I wish I had a better answer, but I’m thinking about it very hard and like I’m sure the next month will be interesting in exploring these things.

  • Justin Drake: So a couple points on what you brought up. I think no1 is the low hanging fruit that you highlighted has already been picked. So by default builders are in non-optimistic mode meaning that they don’t need any collateral and that will always be the case. You can think of the optimistic mode as being an ultra high priority Que. SO we already have the low priority, high priority, and there is this optimistic priority which is a new priority almost. It’s opt in and right now we are capping collateral requirements at 1 eth, to keep the collateral requirements low. 1 eth is sufficient to capture the vast majority of blocks from a quantitative standpoint.

  • Phil: I think that’s great, and the low hanging fruit approach is great. We do also need to take into account that mev is super spiky and many black swan blocks for which the validator really does want to check with high assurance because there is significant incentive to cheat them. I do want to preserve that just for network robustness, but it sounds like that’s already in there. I do still worry about the centralizing affect of having this more privileged set that’s my vague fear but Id on’t think its a total deal breaker, just something to reason through.

  • Justin Drake: On the point of the spikiness, whenever there is a block with more than 1 eth of value in the bid it gets simulated the current way its not optimistic relayed. The thing we are trying to optimize for is more blocks being relayed by non-censoring relays. One of the reasons why changes in market structure, Optimistic relaying is pretty bad for censoring relays. The reason is that In order to know whether or not you want to censor a block you need to simulate it. You can do some string matching and look at sender addresses and recipient addresses without simulation but that won’t give you the deep call stack inspection which is currently happening on censoring relays. Optimistic version V2 we will optimistically relay bids without even downloading the data. It turns out it takes another 100 ms just to download the block, just the bits and bytes. With Optimistic relay V2 which is already implemented you are saving 100 ms and that really completely removes the censorship opportunity even for the easy string matching on the sender and recipient addresses.

  • Another big market structure we want to push for and it’s the one you have highlighted is this dream of removing the relays all together. From an EF research perspective, the way that we achieve this dream is through Enshrined PBS. Actually we made a hire recently, we hired Mike to join the Ethereum foundation. His title is Enshrined PBS coordinator. His sole mission is in a way to remove the need for relays. We see optimistic relaying as steps towards enshrined PBS. What is ePBS? It’s basically just the removal of the relays. Optimistic relaying is the partial removal of relays. The removal of the relay from simulation standpoint in V1, the removal of the relay in downloading the data and verifying the availability of the payload is V2, and then we have this V3 version of op relaying where the critical path from a networking perspective doesn’t even involve the relay. There can be a direct TCP connection from the builder to the proposer and the relay only acts as a DA oracle as a mediator and custodian of the collateral in no way is it in the critical path. That’s essentially what enshrined PBS is except The custodian is the Beacon chain itself and the DA oracle is a crustless committee instead of being a trusted relay that acts as the oracle. We kind of see optimistic relaying as being an accelerationism for enshrined PBS and the removal of relays.

  • Phil: Yeah, I fully buy into the narrative I just worry more about practical details. For example, I agree its great to make changes that make censorship more difficult, I think if we were actually to entrench ourselves and reaches sum sub-optimal Moloch like Bitcoin has or ETH L1 did for a while and we are stuck with mev-boost status quo and ePBS takes a long time, we still do need to consider the current market structure. Im not sure that if we freeze that game theory this change actually does necessarily penalize… is good for market structure viz a viz censorship. I think maybe it is maybe it’s not, I am less strongly convinced than you are. For example let’s say censoring actors say they cannot comply with anything other than censorship, this is not FB opinion just gaming out game theory with you, you may in this change require more of a permission less or side channel validation of transactions, different forms of liability on the builder or etc. Regulators may look at diff are of the stack.

  • From a technical perspective it does make censorship harder in some ways. From my analysis I am very hesitant to project that out into we end up in economic game with less actual censorship. The affect seems less clear to me than it would to you. I do think we will analyze this. I will commit to the next month and work on this and come up with some opinion. Do I feel there are any clear centralization risks for the market structure or anything like that. If there aren’t and I don’t see any, I would personally support up-streaming the change. My North Star there would be let make sure we don’t remove any optionality from enshrined PBS. We all agree ePBS is the most important thing we are iterating towards as a mev-boost community and protecting that is the most important goal at least for me. I will support this if it does play out in the game theory I see as this path to ePBS and does make censorship m ore difficult. I think those are all great things.

  • Justin Drake: On the topic of censorship the ultrasound team has recently deployed new dashboards that provide insights. If you go to and scroll down a bit there is relay censorship dashboard, Lido operator censorship dashboard (we started with Lido because they had a grant but we will expand to more operators), and builder censorship. For example On the builder side of things we tell you how many pubkeys each builder has and also if any pub keys are censoring and we tell you the dominance and things like that. We also look at the impact of censorship on the network. In the last seven days 326 txs suffered a delay from censorship and the average delay was 48.8 seconds. In the grand scheme of things the impact of censorship is very low nowadays. But least now we have the data.

  • Phil: How do you calculate delay?

  • Justin Drake: we have mempool data which looks at when a tx is first seen in mempool in 3 diff geographies; Asia, US and EU. Then we look at the timestamp of when the tx was confirmed and take the delta between these timestamps.

  • Phil: I would say that’s not an entirely accurate statistic and the delay is probably much better than that. What you really need to look at is when otherwise it would have been mined. I would suggest refining the statistic when is there a different bid for that relay slot that would have had that tx that got beaten by a censored block. What is the delta from that block being mined to the block where the censored tx eventually gets mined.

  • Justin Drake: That is exactly right, so what you are saying is that the delay should be computed in blocks, basically where the tx could have been included but for some reason was not included.

  • Phil: I also like doing it in seconds but just at the block level.

  • Justin Drake: Yeah for sure we actually prioritized in one of the widgets if you search for tx delay we measure delay in blocks and seconds. If you scroll towards the bottom of the website you can see the delay in blocks if you unselect unsanctioned and only have the sanctioned ones you will see the delay txs there, and for each one you have delay in blocks.

  • Phil: I think that’s super interesting thanks for building that.

  • Justin Drake: Now at least from a data standpoint we have a database which has all of the metadata we think could be relevant. For each block who was the proposer, who was the builder, which relays relayed that block and we also know if it contains OFAC or other censored txs. We also have all the mempool data. If you want to do some data analysis we have done heavy lifting of building database and we can give you access to the database to run your own queries.

  • Jolene D: I remember on the last call we had some relay operators who expressed concerns about the additional responsibilities that up-streaming this change would incur for them. Things like holding collateral and managing that, potential legal implications because of that. I was just wondering if any of those people are here today and would like to talk about what this change for them. That seems like something that should be taken into consideration weather up-streaming this is going to affect who is able to run relays at the moment

  • Max Birge (Aestus) - we have been thinking about OR stuff very carefully, we have had a couple chats with Justin about it. I think Some of this is inevitable because latency wants to be optimized. In many ways we are supportive because it will reduce relays operating cost much of which is the simulation stuff. On the other hand there are some dynamics at play here which Phil pointed out around centralization. Some of them are pretty difficult to reason about at the moment. Certainly on the relay side we have effectively become a financial entity which is responsible for some type of collateral and are there KYC/AML requirements? We are not clear about that, we are not lawyers. So on the one hand you can see It does reduce censorship but on the other hand it puts relay in a bind of a position because it’s not really clear who the builders are. So what we think likely happen here is you will form quite tight coupling relationships between relays and builders to navigate these additional responsibilities and that does have a tendency to create barriers to entry on both sides of this. It may reduce some of the network resilience we’ve seen where builders are shooting out blocks to multiple relays at once. We are still thinking about this, have not gotten to the end of this. We will publish something soon.

  • Phil: I think those are great points would love to point out Potential collaborations we’d love on our side. One of them is the data you pointed out Justin, can we help analyze refine crate more dashboards, collaborate somehow on that? We are doing many things on the data side, so happy to see if that makes sense. Also, I think Max’s points are amazing on market structure and different requirements for the roles. I was speaking more from a technologist network POV but I think those things need to be carefully thought through and would be happy to have more conversations about that too.

  • Justin Drake: Full disclosure we have been talking to a lot of builders about this. On the builder side of things there is a lot of excitement. There was one exception, one of the smaller builders in a more conservative jurisdiction told us from their perspective it may may create more accounting headaches or there are some legal questions precisely around sending collateral to us.

  • They suggested in order to send money to us there would need to be some sort of legal contract. The ultra sound relay operators is not incorporated, we are just a bunch of random people on the internet so in terms of setting up contracts its not straightforward and it’s not necessarily something that we want to do. Just wanted to point that out that the concern on the relay side is a concern for at least one of the builders

  • Phil: We wouldn’t want to make it harder for a bunch of random dudes on the internet to start a new relay which is what you all have done and I think its super valuable and I want to protect that on both relay and builder side.

  • Austonst: Along these line, in the current Optimistic relay builder on boarding guide it seems like it’s a bit of a manual process right now which involves the builder posting 1 eth of collateral to relay.ultrasound.eth. I haven’t checked if that’s a regular address or if there is some contract there. What are the thoughts on the long-term future of this? If enshrined PBS is long ways out are there some kind of solutions that involves some more complicated system like a sort of multi-sig that’s accessible to multiple relays or a contract of some sort? Can we off load the collateral responsibility to another group of entities? Could there be reduction in legal concerns or make things simpler for technically on-boarding more relays into the process?

  • Justin Drake: right now relay.ultrasound.eth doesn’t point to anything. It will point to simple EOA, not a contract. In terms of fancy things, yes you can have a multi-sig. You can also have simply a standard address and no multisig and the custodian is some third party custodian. If someone wants to step up, someone with reputation like etherscan or rocket pool, I have no idea just trusted entities that want to step up as relay custodians I think that could be a new role created which could help reduce some of the concerns for relay operators who don’t want to touch financial side at all.

  • On that note, we are also happy to be custodian for other relays. We’re happy to hold custody of funds for your relay. I think what I also told you is that we are happy to be a guarantor for most of the builders. What do I mean by guarantor? I mean that we would actually provide collateral for the builder using our own funds. We wouldn’t be receiving funds externally we would just be putting up our own collateral. We trust most of the builders. We believe that reputation of the builder is worth orders of magnitude more than one eth. If there is an event , a builder bug, the builder would be more than happy to directly refund the proposer as opposed to buying their reputation and running away with this one bad block. We are happy to be a guarantor which means that if you trust us then you don’t need to receive collateral from the builders. If and when a bad block happens you don’t need to touch any money because the builder can directly refund the proposer fee recipient. It’s a direct transfer from the builder to the proposer and the relay does not need to be a financial intermediary in that transaction.

  • Stokes: I think it’s worth calling out that there are smart contract designs, different things we can do on chain that move a lot of this responsibilities away from centralized parties like the ultrasound team. That being said I think it comes down to jurisdiction as to what it actually means to custody funds here or there and anyway its definitely an interesting question.

  • Alex Obadia: A question for Justin and Mike, I’m looking at the Towards enshrined PBS - an optimistic roadmap from Mike, and I’m trying to ascertain at which point would you not have this centralized escrow anymore? It sounds like it exists in multiple steps right?

  • Mike: We would need escrow in all three V1, V2 and V3 as described. Even in V3 where the optimistic relay is behaving as an oracle for signed header appearing on-time and the block body appearing on time. If the builder commits a header that wind but doesn’t publish the block on time, then the proposer is still missing that slot and needs to be refunded. So in that case where the messages are happening over the p2p layer and the relay is just observing the p2p layer, the relay still needs to hold that collateral in case the block is not published on time. All three of the iterations require that collateral still being there.

  • Alex Obadia: Maybe a stupid question but a follow-up is, Once you go to ePBS and have a committee do you expect committee to be holding collateral?

  • Mike: So in ePBS I guess this behaves slightly differently in that there will need to be some form of unconditional payment. If the builder submits a bid that gets signed and not produced then that’s only going to damage the builder. So whatever mechanism we end up doing in ePBS, the proposer won’t necessarily be refunded but it will be and unconditional payment from the builder. Does that answer your question?

  • Justin Drake: In other words the beacon chain is holding the collateral, the beacon chain itself is trust-less custodian.

  • Alex Obadia: Okay, I have more questions but there is others on the call, I will ask after, thank you both.

  • Stokes: I think we can have a follow-up call and get updated on some of these details, specifically there.


Pt 2.

  • Chris Hager: I just wanted to ask Potuz what is your opinion as you have been commenting on PRs too with some strong opinions and I would love to hear you maybe outline your way of thinking about this.

  • Potuz: I have a personal and Arbitrum different opinion on this. So let me tell you what I think. If we didn’t have PBS at all no FB or Mev-Boost and I wanted to submit a block with a tx someone didn’t want to be on chain then unless you hold a lot of stake you cannot fork it out. You either are the next proposer with a lot of stake and try to fork it out or you hold a lot of stake to be able to fork out several blocks in a row. With FB now, the soft PBS we have at this moment, the realer can cheat you. The relay can tell you I am going to produce for you a block not trigger w/e form you have for going back to local execution. For example, we would go back to local execution If the local payload would pay us more. So if there is a tx that is censored but its paying a lot and the builder wants to censor it, it won’t be able to because the relay checks that the bid has to be higher than the local block. But the Relay can lie to us, and the relay can not produce the block and then we ar replacing our trust assumption with the relay. With optimistic relay this trust assumption goes to the builder.

  • This is a killer for many reasons because now any builder that wants to censor a tx will just have to steak 1 eth and trigger w/e salvage we have on our clients to fall back to local execution, he will produce an invalid block, slash himself 1 eth and eclipse a block that would not be possible otherwise. This kills a lot of statistical analysis we want to do on chain for an L1. Now speaking as an employee at an L2 why we want to have this and rollups need this. Yes you could do that one off and let me tell you why one off is already good enough. A simple statistical analysis says that if you hold 60% or less of the stake which is a lot. That means 60% of ppl are willing to fork blocks and 90% of people are willing to censor. These are strong numbers. Even under those circumstances in less than half an hour only 10% of people are not censoring and 40% of people are not willing to fork. In those circumstances you will see two blocks in a row missing in a period of less than a half an hour. This is w/o optimistic relay. With optimistic relay this does not need to happen because the builder will slash himself one eth and produce another builder and slash himself one eth.

  • The problem with this is that If a rollup wants to reduce challenge period to say half an hour, then the sequencer himself can actually produce himself as a builder, slash himself 1 eth and take out billions from the rollup. It moves trust assumptions from relay at this moment to builder and this is unacceptable.

  • Justin Drake: I don’t completely understand because if a builder wants to censor one block the next block they just need to pay a bribe to be the top bid and then they can make an empty block or w/e. Or even better they create a block that does extracts mev but doesn’t include the one tx they want to censor. It just seems very sub-optimal to create a bad block.

  • Potuz: Right but they need to avoid triggering the local execution changes that we want. For example if we had inclusion lists on FB then we would want them to be enforced, that would be one thing. The other thing, we see a local payload is paying a lot then the bidder is going to have to pay more than w/e the local payload is paying.

  • Justin Drake: Okay, so you are assuming a world where there is some sort of inclusion list that is implemented.

  • Potuz: That would be optimal, but even without inclusion list even this will work. I want to fall back whenever the bid is not high enough. This will force the builder to pay as high as the censoring tax is willing to pay. At least this much.

  • Justin Drake: That is already the case no?

  • Potuz: Now if the. Builder doesn’t want to pay this he cannot get away with this but with your system the builder is have to pay up to one eth. Because he could just lie about the bid and not produce any block and since the block has not been checked, this puts a bound on the number he has to pay.

  • Justin Drake: I don’t completely understand. Even with optimistic relaying if the censored tx is willing to pay x eth to be included then the bid needs to be at least > xETH, that doesn’t change with optimistic relaying.

  • Potuz: With op relaying the builder can send you the bid and say I will pay 32 eth and never pay it.

  • Justin Drake: No that doesn’t work. And the reason is because if X> 1 eth, 1 eth being the amount of collateral we are capping at at the moment then we fall back to the full simulation.

  • Potuz: This is better we are putting a cap on the builders bid.

  • Justin Drake: This is necessary if someone bids 1 million eth we need a guarantee they can pay 1 million eth.

  • Potuz: At least this kills that and it leaves me with the point that it’s impossible to implement inclusion lists but at least it kills one of the grieving vectors. But you see my endpoint is with this systems a builder can eclipse a block, which I’m hoping we eventually have systems where a builder cannot arbitrarily prevent a block from being produced.

  • Justin Drake: Right I understand your endgame and I understand your use case as a Layer 2 optimistic rollup. My understanding is Arbitrum has 7 day challenge period and even if 10% of validators don’t use mev-boost you will get inclusion of fraud proof extremely quickly. I do understand your goal now and will think about it.

  • Potuz: Its not even for this, this is about creating a censorship on chain a censor oracle on chain. There is a big difference b/w 700-800 blocks missing assuming arbitrary forking to 130 blocks missing assuming not arbitrary forking. But also for concepts that will be very useful on chain, the notion of safe head also is much better without the trust assumption of builders vs. validators being able to eclipse arbitrary blocks. It’s easier to prove the last head was not workable without optimistic relay. These kind of things I think should be thought about more and there should be a public discussion and not in channels with 24 people like this one about optimistic relay. It should be the full community involved in this. It may decrease the censoring of OFAC txs and we might see Tornado Cash txs getting in earlier, but I think it prevents it doesn’t help with censorship where censoring particular txs may be more expensive.

  • Justin Drake: I don’t think it changes anything. If we were to have it tomorrow I don’t think it changes anything but happy to hear a counter argument for sure.

  • Stokes: This is a public call and anyone can attend so we are recording them to get them as widely distributed as possible. So I think this is a good forum for having these conversations. If there are other people you think should be involved or should see this feel free to direct them here.

  • Stokes: So we have about 30 min left. It sounds like there has been much thought on design, a rollout on Goerli, and a gradual scale up and we’ll see how it goes. It’s been a great conversation and there are other things to consider that’s why we are here to find those points and make that happen.

Relay Sustainability

  • Stokes: One other point to bring up is essentially around relay sustainability. Relays run this as a pure cost there is no funding model or sustainability model and many relay teams have reached out to me wanting to discuss this and brainstorm ways to make this sustainable in the long run. While we are working towards ePBS, it could very much be the case that we have mev-boost in place for some time. So it is definitely important. Are any relays on the call who want to chime in on this point?

  • Justin Drake: My POV is that I try to make assessment of the cost, I agree that it is a public good that needs to be funded by public goods funding and then the question is how much does it cost? My rough estimate is 100k per per year per relay. If we had 10 relay operators which we don’t, and let’s be extra conservative and say it takes 5 years to get to ePBS. $100,000/year * 10 relays * 5 years ~ $5 million, which in the grand scheme of things is not a large amount of public goods funding, especially if its a cost that is spread out over 5 years.

  • I think what we have seen, we already have funders, flashbots funding its own relay and effectively is providing PGF for its relay, same for ultrasound, Aestis, and agnostic. These could be different entities. For agnostic maybe it’s funded by Gnosis who has a large treasury. In some cases it’s individuals funding this and in some cases its institutions. I don’t think we have a public goods funding problem. Partly because the amounts are relatively small for our space, and because empirically we have seen for several months now, that these relays are being funded.

  • Stokes: I think that makes a lot of sense. Justin, do you have any thoughts on relays charging for their services? At that point we can move out of the domain of public goods and have this be more of a very typical business, charge for API access or something like this?

  • Justin Drake: Yeah I think it’s very difficult because there is this race to zero in terms of fees and if you start charging then you have fewer builders and you start losing. And I think some of the relay operators don’t want to charge. We don’t want to charge, FB doesn’t want to charge, then it becomes very difficult to compete. I also think that going through the work of being a financial institution to the previous point of AML/KYC bc you start receiving funds from these unknown builders, I think this is a much more relevant point than the collateral which is just meant to be sitting there and returned after a period of time, not going to third parties and being returned to the sender. Also just the engineering work of setting up everything sounds not worth the effort. And also from our perspective the ultrasound project is about building public goods. It’s not really in our ethos to be charging for this.

  • Stokes: Yeah I think that all makes sense. To that extent that different organizations want to provide this as a public good then there will be relay options that do not charge and it does enforce a ceiling almost 0 of what a relay could charge. That being said I think we want to keep an eye on how things evolve because I think we get to a place where there are some relays today that operate as a for profit another arm of their business and we get to a place where they say this is not profitable. This means there are fewer relays and that might not be a world we want. I guess it’s just this tradeoff we will keep exploring.

  • Phil: I both agree and disagree with Justin. Its not necessarily a burning issue and I agree with the market dynamic analysis of charging fees being difficult. Also the reason that we’ve avoided ourselves going in this direction because my meta-game theory is that its easier to upstream public good then a business just from an evolutionary point of view if we are stuck with this market structure for a long time. That being said I don’t think it’s totally outside the scope of relays and or if people want to experiment with that it’s whatever. That’s my FB native analysis so far. I do think it’s still worth the question of can we do better even though there are parties that are interested and aligned with running this infrastructure. What if a new entrant comes in and is super aligned but they don’t have the means. It seems to me there is no path right now that is super obvious and maybe that’s like a low hanging fruit that we can fix if we do want to view it and promote it as a public good.

  • I’m even thinking you Justin or Agnostic, it took some time for agnostic to run a relay and we were trying to prod them into that for a while. Its understandable there’s a lot of devops work, its distracting, its infrastructure heavy work that not a lot of teams are set up to do even if they want to or are aligned with it, plus its expensive and politically complex in the limit of having to come and present positions to other relays and things like that. I think there are barriers and we can reduce this more and that would be good so things like teams like ultrasound don’t relay on a big external treasury. Or agnostic doesn’t have to make as much of a business decision on how distracting this is to our core focus, kind of lessen that burden To get started maybe it’s worth doing.

  • Max Birge : Justin I think $100k per year is probably right if you take people away from that. The Aestus perspective is Austin and I are directly funding this with no funding at the moment. Our time is quite dedicated as well, we have looked for public goods funding for this from a variety of sources and have been turned down at every ask because I think there is a real fear of funding because they might impact the market. The role of the relay is ideally to be as neutral as possible. If we start excepting money from builders who are sometime keen to pay on side channel then we compromise on neutrality. I think if you look through the list of relays at the moment most of them are funded by a builder, side channel deal, or a company that’s making a profit through their own ERC-20 token. If we want to get past that we have to have this conversation at some point. At the same time I understand the engineering is tricky and you could just incentivize some kind of centralization which might be difficult. So I don’t know what the answer is but it’s a struggle for Aestus. I know when Austin was in Denver both BloXroute and Blocknative were talking about this being a burning issue as well. I think we should explore it further.

  • Phil: I think another way around this is to have alternative paths. So you could provide funding or maybe it comes with strings or requires a certain organizational structure to accept that kind of funding so new entrants have a choice. Do we want to immediately get into this market, take this funding and run a public good or we don’t want to run a public good and we have to find another path to make this work? But I do agree that public good option seems like very hard to make work today.

  • Justin Drake: One side note here on public goods funding. I have been invited to be a so-called badge holder for optimism and they basically have this retroPGF round number 2 and it’s roughly $25M. Maybe some of those $25M could be routed to relays, that’s like five lifetimes worth of funding for all the relays across five years. I acknowledge that maybe getting funding so far has been difficult, but this could change very quickly with things like the optimism retorPGF.

  • Phil: It is also an option to be more of an activist about this on the mev-boost side. Not to derail the conversation completely but it relates to the early per-cursor conversations of this call like should there be a foundation specifically for MEV public goods, how do we govern mev-boost, etc? I think these are intertwined questions because there are some universes where the mev-boost community leaders play more of an activist role in kind of building these funding rails and distributing capital and things like that. And there are worlds where governance and that side of things are more separate.

  • Max Birge: relays are in a privileged position right and it would be ideal if all the relays were transparent about how they are funded. Because if they are making side channels with builders the rest of the Ethereum community and validators may suspect that comes wit some compromises and it would be ideal to get that out there. Having a public channel for funding these things seems far preferential from putting relays in a position where they need to go and ask.

  • Austonst: Yeah, building on that just a bit more, I know talking with Blocknative this is one of there concerns. The lack of universal charge are the builders equally public funding model means that relays are pushed to create these side channel deals and Blocknative shared a couple of those with me. They made deals with certain builders to get prioritized access. This is an incentive that occurs because of the lack of a more universal funding method. I guess just reiterating that it’s worth considering the impact on neutrality that that may have.

  • Stokes: These are all really interesting points. One vision Phil was kind of painting is there is some entity going around going to Optimism, going to Gitcoin for quadratic funding rounds and these different PGF services and saying hey relays need x per year to run their relays here is why this is important and sort of doing that fundraising. Yeah its a real interesting point, probably preferable to keep it more decentralized so if relays could kind of figure out how to do this on their own independently that might be preferable, but yeah that being said if the mev-boost community would greatly benefit form more precise coordination there I think that’s very important to explore.

  • Phil: I agree, I will asterisks with I don’t think just creating a sustainable funding model with relays is enough to side-step the side channel incentives Blocknative mentioned. Like if the side channels offered you way more than the fees there is no inventive not to take the side channels especially if the current status quo for a lot of these are housed in for profit or ad hoc entities continues, there is not obligation not to make those deals. I think it would help a little but I don’t think it completely solves the problem.

  • Stokes: Yeah it certainly doesn’t solve it for reasons you gave but maybe it can make it easier for new relays to enter or existing relays to maintain just covering their base cost.

Call End, Open Discussion

  • Stokes: Anything else? This has been a great call, there has been a lot of good conversation. I suppose we will just open it up unless there is more on the relay funding point we could just open it up to discussion if nothing there we can go ahead and wrap up early.

  • Justin Drake: I do have one question around the validation node. Right now the ultrasound relay only runs a fork of geth as a validation node, simulation node. I think, I’m not sure, I think the FB codebase has only been built with geth in mind. At the relay level seems like there is some consensus bug with geth we don’t benefit from client diversity we have established at the validator level. Is it correct that the FB codebase only supports geth and if so are there steps to have more diversity?

  • Chris Hager: The FB infra built on geth, the validation logic itself though is rather straightforward and its a single additional JSON-RPC method that would be conceivably be easy to port to other clients like Nethermind or others. I think any of the teams can do that with kind of low effort and it would be great to have more diversity here

  • Phil: Just to give some additional color, the reason that is the case and its built that way, as we looked at merge landscape it looked like Geth would by form be the dominant execution layer client and so the ad hoc logic was like its less severe than the resulting network break would be and you probably would want to be conforming to the dominant logic in that chain split scenario anyway. I do think give that a lot of people have written execution clients it probably time to multiplex that. But that’s historically why it was built that way.

  • Justin Drake: One reason why relays may be especially interested in having other clients is performance. Geth is one of the slower simulation execution clients and so whenever you are not in optimistic mode and the value is greater than the collateral or the builder doesn’t have the collateral then having a very fast EL client is very important. I know Reth is quite a bit faster than Geth or Netheremind as well or Erigon.

  • Phil: I do believe Reth is being purposefully designed for that, speed. I do agree it will be useful to swap in with asterisks of consensus failures being possible if some of the optimizations shouldn’t really be there.

  • Justin Drake: One of things we have been thinking about is a multi-execution client system where by when a bid comes it you immediately simulate it with your ultrafast simulation engine which could be rethought then a few hundreds of milliseconds later you simulate it on Geth, but that’s kind of outside of the critical path. If for w/e reason there is a mismatch b/w Reth and Geth then for the next slots going forward you disable Seth and you just use geth. So in the worst case there will be one slot with a bad block. It’s kind of like optimistic relaying but for the execution clients.

  • Phil: Yeah that’s a good idea. To make this concrete Is the action item here to port this RPC to various clients? Does anyone want to do that work/who is going to do that work?

  • Stokes: I can definitely take the charge here. Yeah so there is a couple things. Chris has been pushing for block validation and there is this SSZ endpoint for building the block and agree with everything we said, t is important to have client diversity at other parts of the stack. I can definitely see what’s there. I have also been talking with @gakonst about this use case with Reth and yeah I think it would be really cool to see through. This sort of multi-client, multi-proof thing that Justin just described all sounds like good ideas. Anything else anyone has?

  • Phil: Maybe I want to pump my post about Geographic decentralization, I want to spread the meme and probably a broad conversation to have there but I’m curious to hear peoples feedback on the post also if you have some time to read it.

  • Stokes: There is a forum post in the chat, please take a look. I will go ahead and call it, thank you everyone for participating. I think this was a really interesting call, we covered all sorts of things. Again as we see there is a lot here to work through and discuss and thanks for everyone being orderly. And yeah and thanks again. Here’s hoping Goerli goes well . I feel hopeful for it, I will keep having these calls as we need them. I will see some of you around.


As promised, here’s the a writeup of software versions to use for proposers / relays / builders:

As of now (Fri, March 10):