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.
Where it lands in Jayverse
- Wallet: never collapse accepted-by-provider, included, and final into one status. The simulate-before-sign screen should show all three distinctly and use an explicit timeout with a provider-side cancel path, since a private submission removes the public-mempool heartbeat the UI might otherwise assume.
- Verex: reconcile private-submission status from an unrelated public node. If order or settlement transactions ever route through a protected RPC to avoid frontrunning, the submitting provider's own acknowledgement is the least independent witness — check inclusion and finality separately.
- Auditor: log which channel a critical transaction used. "Accepted by provider" is one party's view, not consensus; mark it as such in any audit trail rather than treating it as equivalent to a receipt.
Key expressions
| Expression | 뜻 · 쓰이는 자리 |
|---|---|
| existence proof | 존재를 증명해주는 근거 · 트랜잭션이 살아있다는 것을 확인시켜주던 신호를 가리킬 때. "your existence proof" |
| flatline | (신호가) 뚝 끊겨 평평해지다 · 감시하던 신호가 사라지는 상황을 비유할 때. "that heartbeat flatlines" |
| false negative | 실제로는 있는데 없다고 잘못 판단하는 것 · UI가 실패로 잘못 결론 내릴 때. "a false negative manufactured by a monitoring assumption" |
| manufactured by | ~때문에 (인위적으로) 만들어진 · 진짜 문제가 아니라 잘못된 전제가 낳은 오류임을 말할 때. "manufactured by a monitoring assumption" |
| rung | (사다리의) 한 단, 단계 · 상태 기계에 새로 추가된 한 단계를 가리킬 때. "gains one rung and loses one observation channel" |
| collapse (두 개념을) | 구분해야 할 것을 하나로 뭉뚱그리다 · 서로 다른 상태를 같은 것으로 착각하는 버그. "Collapsing any two of those is the exact bug" |
| swap X for Y | X를 Y로 맞바꾸다 · 하나의 위험을 다른 종류의 위험으로 교환했다는 뜻. "You swapped an open-mempool threat for a trust-and-availability relationship" |
| price (동사, 위험을) | (위험·비용을) 값으로 따져보다, 계산에 넣다 · 아무도 고려하지 않는 비용을 지적할 때. "The cost nobody prices" |
| mental model | 머릿속에 박힌 사고방식·전제 · 더 이상 통하지 않는 관행적 가정을 가리킬 때. "the usual replace-by-fee mental model" |
| gotcha | 예상치 못한 함정, 문제점 · 가장 까다로운 부분을 짚을 때. "Cancellation is the sharpest gotcha" |
| MEV | 최대추출가능가치(Maximal Extractable Value) · 공개 멤풀 노출로 발생하는 프론트러닝 등 위험을 가리킴. "MEV-protected RPCs avoid broadcasting a transaction" |
| Flashbots Protect | MEV 보호 기능을 제공하는 프라이빗 트랜잭션 전송 서비스 · 공개 멤풀을 우회해 제출하는 대표적 프로바이더. "equivalent small swaps through a public endpoint and Flashbots Protect" |