diff --git a/docs/base-chain/flashblocks/app-integration.mdx b/docs/base-chain/flashblocks/app-integration.mdx
index d7b417fe8..673f2e960 100644
--- a/docs/base-chain/flashblocks/app-integration.mdx
+++ b/docs/base-chain/flashblocks/app-integration.mdx
@@ -61,6 +61,23 @@ Base targets a **< 0.1% Flashblock reorg rate** — meaning a preconfirmation wa
 
 If Flashblocks become unavailable, the sequencer continues operating normally and confirmation falls back to standard 2-second blocks. Build your app to handle both cases gracefully.
 
+For apps that use public RPCs or third-party node providers, treat Flashblocks and `pending` reads as an optimistic UX layer. Keep canonical `latest` block polling and transaction receipt polling as the source of truth for balances, settlement, and irreversible user actions.
+
+Use a fallback path when any of these conditions are met:
+
+- No `newFlashblocks` event arrives within your expected update window.
+- The `pending` block number stops advancing while `latest` continues to progress.
+- The `latest` block number is several blocks ahead of the pending snapshot you are rendering.
+- A WebSocket subscription disconnects, rate limits, or reconnects repeatedly.
+
+When the fallback path is active:
+
+- Continue showing pending state when it is available, but label it as preconfirmed or optimistic.
+- Show the transaction hash immediately after submission so users can inspect progress independently.
+- Poll `eth_getTransactionReceipt` against canonical state until the transaction is included.
+- Refresh balances and final UI state from `latest` after the receipt is available.
+- Avoid blocking critical buttons or irreversible confirmations on `pending` state alone.
+
 ## Library Examples
 
 You will need to use a Flashblocks-aware RPC endpoint to use Flashblocks with the following libraries: