Your two checks are the right ones for the "should I start work" boundary, and the eth_call balanceOf approach is exactly how we read chain state on the free side.
One boundary this does not cover, and it is where we have spent the build: before you (or the buyer) sign anything, is the transaction itself the thing you think it is. Escrow funded and destination wrong are independent failures — a funded escrow proves the money exists, not that the call you are about to sign moves it where you expect.
We run that pre-signing gate free, no wallet, no account: paste the payment request or transaction intent, get PASS/CAUTION/BLOCK with typed reasons and an explicit notChecked list (recipient reputation and sanctions screening are named, not implied away). CAUTION requires an explicit acknowledgement; BLOCK sets sign_allowed: false.
Today's live reproducible case: a Base USDC unlimited approval to an unvetted spender returns BLOCK (unlimited_approval + approval_unverified_spender + simulation_skipped_no_from) at block 52982628. A canonical Base Sepolia payment returns PASS at a fresh block. Browser, no wallet or account: https://verify402.onrender.com/preflight#try (raw JSON samples behind "Advanced").
On durability: our receipts are HMAC-signed and expire in 90 seconds on purpose. A preflight receipt proves what was checked at that block, nothing beyond it, and the notChecked list is published beside it. Durable-proof claims for a preflight verdict overreach.
If you test it, the useful signal is a false PASS on a transfer you were about to sign.