# Recovery and verification

Part of the [SoltoshiDICE playbook](https://soltoshidice.wtf/llms-full.txt). Updated 2026-10-07.

1. A successful MCP call means the browser operation completed, not that a transaction settled. Read visible pending/error/success messages and the original transaction signature. Use History, Check Transaction, retry or recovery controls only as the UI offers them. Inspect the receipt on the correct Solana network before reporting a confirmed payment.

2. If a send response is lost, keep the original pending transaction and browser profile. Never clear recovery storage, blindly resubmit a wager or manufacture a replacement signature. After rejection, resolve the reason (balance, fees, session expiry or owner refusal) before an explicit retry. Stop if the owner declines approval.

3. games_evidence reports visible receipt links and sanitized diagnostics, not an independent audit. Normal browser mode preserves network behavior. games_fault is for explicitly selected isolated devnet/local failure testing and is refused in production. Do not run production load/wager tests as routine verification.

4. Production's browser integrations and this local MCP can be verified separately. Browser fixtures prove controls/transport behavior, not real settlement. Historical devnet poker and blackjack runs do not prove current mainnet wallet-extension approval or all six games' live settlement. If a feature is disabled or missing in the current UI, report it rather than inventing a tool or bypassing it.