Why
Applications often use public-mempool visibility as evidence that a submission exists. Private order flow breaks that assumption and requires provider-specific status plus ordinary chain finality.
MEV-protected RPCs avoid broadcasting a transaction to the public mempool. That may reduce frontrunning, but it also removes the public observation path many applications quietly use to decide that submission worked.
How it works
Submit equivalent swaps through a public RPC and Flashbots Protect, record where each hash is observable, test cancellation and timeout behavior, and reconcile both against canonical receipts.
PoC
Submit equivalent small swaps through a public endpoint and Flashbots Protect. Observe both from an unrelated public node, record provider acknowledgement and inclusion latency, test cancellation or replacement, and stop waiting at a fixed deadline. Reconcile both flows against canonical receipts and finality.
What it proves
Private submission adds a provider-specific state between "signed" and "included." It does not eliminate dropped, expired, reverted, or reorged transactions. The UI must distinguish accepted-by-provider from visible-in-mempool and included-on-chain.
Reference: Flashbots Protect documentation.
Review clarification
The hidden assumption: "visible in the mempool" was your existence proof
Most apps never say it out loud, but they treat "I can see my tx hash in the public mempool" as evidence that submission worked — a free, provider-agnostic heartbeat. Go private (Flashbots Protect) and that heartbeat flatlines, and here is the trap: absence of the signal is not evidence of failure. The transaction may be perfectly alive, sitting in a builder's private order flow, invisible to your poller. A naive UI then either spins "pending" forever or wrongly declares failure — a false negative manufactured by a monitoring assumption, not by anything wrong with the transaction. The title's point is exactly this: privacy changed the monitoring path, not the state machine.
Privacy adds a state, it does not remove any
The honest lifecycle gains one rung and loses one observation channel — for you, not for the chain:
| State | Who tells you | What it means | What it is NOT |
|---|---|---|---|
| signed | you | bytes exist | not submitted |
| accepted-by-provider | Flashbots ack | received, will try to include | not consensus, not inclusion |
| in public mempool | any node | broadcast (public flow only) | not included |
| included | canonical receipt | landed in a block | not final |
| final | finality | reorg-safe | — |
Private RPC deletes the "in public mempool" row for you and inserts "accepted-by-provider." That new rung is exactly the shape of bundler-paymaster-dependencies: a provider-specific acknowledgement that is availability/policy, not settlement. Flashbots saying "got it" is one party's view — pure rpc-view-not-consensus — which is why the card insists you observe from an unrelated public node: the submitting provider's own status is the least independent witness you have.
The only ground truth is downstream — and it is still not the receipt
Reconcile both flows against canonical receipts and finality, because a receipt is receipt-is-not-settlement all over again — a view until it is final. So the discipline is three separations the UI must never collapse: accepted-by-provider ≠ included-on-chain ≠ final. Collapsing any two of those is the exact bug the PoC is built to force into the open.
Why the fixed deadline is load-bearing
With no public heartbeat you cannot watch the transaction stay alive, so you need an explicit timeout and then a decision: cancel via the provider (not by broadcasting a replacement to a mempool that never saw the original), re-price, or refund. That is the same fallback state machine as bundler-paymaster-dependencies and x402-settlement-retry, and its durable-execution home is temporal-durable-execution. Cancellation is the sharpest gotcha: the usual replace-by-fee mental model assumes a public mempool that, here, does not have your transaction.
The cost nobody prices: a public adversary traded for a private dependency
Private order flow reduces frontrunning — that is the point — but it routes your intent through one operator who sees it first and decides whether and when to forward it. You swapped an open-mempool threat for a trust-and-availability relationship with Flashbots. Not necessarily worse, but a different bet that should be written down as one — the same "who did you end up depending on" question as bundler-paymaster-dependencies and layerzero-default-is-a-choice.
One law, four faces
This card, rpc-view-not-consensus, receipt-is-not-settlement, and bundler-paymaster-dependencies are four faces of one law: every step from "I clicked" to "it is final" hides a different assumption about who observes and who decides — reading state, trusting a receipt, getting accepted, staying visible. This card is the staying-visible face.