Migrated from research forum. Original author: mikeneuder
hey kydo! thanks for the post. :-) a few comments
Some relays have tried to monetize, though unsuccessfully. I think generally relays were intended to be a short-term solution, so those who jumped in to run them in the first place didn’t plan on trying to make a business out of it. That doesn’t imply that there isn’t a viable monetization path, its just that it hasn’t matured that much.
We haven’t seen the 3 large builders of titan, rsync, and beaver running their own relays as of yet! Some relays spun up with vertically integrated builders – flashbots, blocknative, bloxroute. But the majority of blocks are built by non-relay entities, which is nice for now. Certainly this could not be the case for long though.
I think the stable equilibrium here is that all the builders decide not to send their blocks to the partial block relay. They are incentivized to do this because the full-block auction presents no risk of unbundling, so strictly dominates the partial relay. From the proposer perspective, they will see that all top blocks come from the full-block relay, and thus be incentivized to just go with the status quo instead of “paying” significantly to reclaim some agency over their block space.
I still think that there might be better intermediate solutions that leverage the relay trust more! Writing about this now 
PEPC is much more flexible!
interesting idea, but i think this is just way too much latency to add to the block production pipeline. if the mev-boost relays of today still exist, i find it hard to imagine a mev-boost++ relay competing with the latency of these centralized service providers.
One potential issue here (and maybe also in enshrined IL designs) – the proposer might *not want* agency back. If we view them as service providers, they just want the dumb job of signing the highest paying header completely blind and then landing their block onchain. In the same way that an ISP doesn’t want to know the contents of the TCP packets flowing through their infra, proposers might like to stay in the dark. Any out-of-protocol “opt-in” scheme takes the burden of responsibility and places it back on the shoulders of the validators. This might be better than having it in the hands of the relays and builders (I think it probably is), but it is still worth considering the other side of the coin. All of the CR proposals so far require someone explicitly conveying the intent to include a censored transaction. I am trying to think about ways we could make it more “passive” and less “active”, but nothing super concrete yet.