# Private Blob Submission — Use Cases

### Authors
And by authors I mean, "These people answered my question on twitter and I put their replies into ChatGPT"
- **dmarz ⚡️🤖** (@DistributedMarz)
- **ChatGPT** (OpenAI)
- **mteam.eth 🗼** (@mteamisloading)
- **Sam Laf** (@samlafer)
- **K ⟠ 🧲** (@Kautukkundan)
- **Moncesco** (@fra_mosterts)
- **Terence** (@terencechain)
- **Sacha 🦣** (@ssaintleger)
- **dataalways.eth ⚡️🤖** (@Data_Always)
- **Antony Denyer** (@tonydenyer)

---

## 0 · Core Assumption Being Questioned
> **Assumption:** *Distributed blob-building protocols can rely on blobs being published to a **public** mempool before inclusion.*

The list below collects reasons why rollups **might prefer private submission routes** (e.g., encrypted channels to a block builder or permissioned relay) that violate this assumption and therefore need to be designed for.

---

## 1 · Motivations for Private Blob Submission

- **MEV front-run protection** — Searchers reading clear-text blob data could reorder or sandwich user transactions before the rollup proof executes. Private blobs mitigate this risk. _{(@Kautukkundan)}

- **Compliance & regulatory privacy** — Certain financial applications are legally required to keep transaction contents private until final settlement. _{(@Kautukkundan)}

- **Permissionless posting risk / PGA¹** — If an L2 treats any posted blob as canonical, a public mempool becomes a priority-gas-auction arena; blobs can be censored, cancelled, or reordered. _{(@terencechain)}

- **Blob-aggregation cost savings** — Rollups aggregating multiple smaller blobs into a single “mega-blob” want to avoid competitors unbundling their bundle in the public mempool, preserving intrinsic-gas sharing. _{(@tonydenyer)}

- **Revert / replacement protection** — During gas-price spikes a rollup might repost a blob with a higher tip; public exposure lets others snipe the low-tip blob before it can be cancelled. _{(@Data_Always)}

- **PvP over scarce blob slots** — Competing L2s could spam or pre-occupy blob space, delaying rivals’ state commitments. Hidden demand curves give an advantage. _{(@DistributedMarz, @terencechain)}

- **Unbundling prevention** — Builders could peel apart aggregated payloads and resell the parts; private hand-off keeps the bundle intact until finalized. _{(@tonydenyer)}

- **Dark-pool style order flow** — Analogous to dark pools in TradFi, a perp-DEX may hide order flow to prevent copy-trading or liquidation sniping. _{(@cz_binance quote-tweet)}

_{¹ Priority Gas Auction}

---

## 2 · Design Implications

1. **Builder APIs** should offer optional encrypted blob channels or authenticated rollup-specific endpoints.
2. **DA guarantees** must remain intact: private submission should not weaken data-availability or censorship-resistance once the blob is included.
3. **Sequencing economics** need to balance the negative externality of hidden blobs against MEV-reduction benefits.
4. **Monitoring & auditing** should allow reconstruction of the privacy window (Δt) to detect withholding attacks.
5. **L2 strategy landscape** will range from fully public to fully permissioned; builder marketplaces should price these preferences explicitly.

---

## 3 · Open Questions

- How long can blobs remain private (in seconds/slots) before liveness or fork-choice is jeopardized?
- Can builders enforce sane privacy windows without learning the data (e.g., ZK commit-reveal)?
- Should the protocol subsidize blob aggregation to reduce fee pressure instead of relying on private channels?
- What telemetry is needed to study private-blob adoption without deanonymizing strategies?
- Do we need a standardized “blob privacy intent” flag in the submission envelope?

---

## 4 · Relevant Data

Unclear if intentional or RPC failure, but we currently see that Taiko and occasionally Base use private Blob submission.