# In Defense of the Free Option Problem

I acknoledge the [free option problem](https://collective.flashbots.net/t/the-free-option-problem-in-epbs/5115) exists, but I don't think it's a solid legitimate reason for killing [EIP-7732](https://eips.ethereum.org/EIPS/eip-7732) with reasons below.

- The free option problem exists because of the tradeoff with scaling. Nobody talks about this today because the deadline to broadcast/verify blocks + blobs is 4s, leaving **8s of the slot unused**. Any design that wants to maximize a slot's potential should extend blob broadcast time from 2s to 10s, that's when the free option problem becomes worth considering.
Thought exercise: In EIP-7732, we could limit the bandwidth scaling benefits and reduce the blob deadline to 6s, which would basically eliminate talk about the free option problem. But I don't think that's the right approach.

- The free option is hard to pull off in practice. Typical builders have relationships to maintain on two sides, searchers and proposers. We focus on searchers here. To exercise the free option, a builder might have to break previous agreements with searchers unless they only sell single-sided results. To break previous agreements, builder may need to refund the searchers which takes away profit gained from free option. The free option can only be exercised after the payload is revealed, so everyone already sees the transaction context and versioned hash, which is another disincentive.

- Anti-sybil is a weak argument, but I'd say builders do have reputations to maintain. P2p bids aside, proposers won't just add random RPC endpoints to get bids from. But I acknowledge proposers should be treated as rationally driven actors who will take the highest bid.

- If we want, we could implement more discouragement against the free option problem, like asymmetric payment, which wouldn't be difficult to add to the spec.

Feel free to DM me if you have any questions or concerns about the free option problem. I'm keen to hear them.