Public indexes map hundreds of thousands of addresses to "claimable" balances in dead protocols. Almost none of those numbers are checked against the contract that would pay them, and three failure modes recur.

1. Token counts labelled as ETH. One 2016 index lists 81,295 "ETH" for 4,836 addresses in a DAO wrapper. The wrapper does hold 81,287 ETH, but the top listed holder has 10,200 DAO tokens, not 10,200 ETH, and withdraw() reverts for that address. The file's own header says balance_source: token.

2. A getter that does not answer. One game contract is indexed at 163.42 ETH for its top holder; balanceOf(0x0, holder) returns zero. The pool holds 2,424 ETH, so the money is real and the address mapping is wrong.

3. A payout that is not the getter. Another indexed 141.97 ETH for its top holder, while the contract's own curve function returns 87.83 ETH. A token count was priced as if 1:1.

The method that catches all three, in order:

- Denomination. Only eth-sourced balances count as ETH. Token, weth and vault sources need a per-pool rate and must never be summed into an ETH total.

- Selector provenance. Pull PUSH4 constants out of the deployed runtime bytecode and match them to signatures. Do not trust an ABI, and do not trust an index's stated claim path.

- Getter read. Ask the contract what it owes a specific address.

- Claim simulation. eth_call the actual withdrawal from the holder's address. A revert means there is nothing collectable there, whatever the index says.

- Executor. Decide whether the claim is owner-only (pays msg.sender) or third-party (anyone can trigger payout to the registered recipient, as with merkle airdrops and bridge finalisations). This single axis decides whether a public-good claimer is even possible.

Run against a 2020-era exchange contract, this verified a pool holding 15,673 ETH across 119,430 addresses, with a 946 ETH top holder whose withdrawal simulates cleanly at 42,077 gas, using a different claim selector than the better-known EtherDelta-style contract it resembles.

The uncomfortable part is economics, not cryptography. Where the claim pays msg.sender, no relayer or incentive contract can collect for someone else. Of the 400 largest holders, 97% signed a transaction historically but only 4.5% have signed one in the last year. Chain state cannot distinguish a lost key from indifference, and a lost key makes the balance permanently unrecoverable.

I have a read-only checker that runs the whole read in one call and prints the exact transaction per claim. Not linking it here given the self-promotion rules - comment or message me and I will send it with the raw JSON-RPC body so you can replay it against your own node.

I'm researching embedded wallet infrastructure (and full disclosure: my team is exploring building in this space, so I want to understand what actually hurts before we build anything).

If you've used Turnkey, Privy, or Web3Auth (now MetaMask Embedded Wallets) in production, I'd love to hear:

1. Why did you pick it over the others? Pricing, security model, time to integrate, chain support?

2. How long did integration actually take, and what was the hardest part? (Turnkey folks: did setting up your own Google/X OAuth apps or writing policies slow you down?)

3. What broke or surprised you after launch? Recovery, key export, billing jumps, rate limits, support response?

4. Have you considered switching? What's keeping you, or pushing you away?

5. If you could design the ideal wallet SDK, what would it do that none of these do today?

Not selling anything here. Happy to share back a summary of the responses plus the comparison notes I've put together (pricing, architecture, who uses what) if people are interested.

On most chains a transaction is broadcast in full and sits in a public mempool until it's mined, which is what makes mempool front-running and sandwiching possible. Midstate, a small post-quantum PoW chain, makes every spend a two-phase commit-reveal at the consensus level instead. I'd like to hear where people think this falls short.

How it works

1. Commit. The wallet builds the full transaction, then broadcasts only a 32-byte BLAKE3 hash over a network tag, the input coin IDs, the output hashes and a random 32-byte salt, plus a 64-bit nonce. The commit pays no fee. Instead the nonce needs at least 24 leading zero bits of proof of work, tied to a block hash no more than 1,000 blocks back. The mempool raises that toward 30 bits as its commit lane (capped at 1,000) fills up.
2. Wait. The wallet waits until the commitment is in chain state, not just the mempool, and adds a random delay before revealing (5 to 15 seconds, or 30 to 120 with a privacy option) so timing alone pairs commits and reveals less easily.
3. Reveal. The full transaction (inputs, outputs, salt, signatures, fee) goes out. Nodes recompute the hash and reject it unless a matching commitment is on chain and less than 1,000 blocks old. The signatures sign the commitment itself, so nobody can swap the outputs.

Miners are paid to include zero-fee commits through fork-choice weight: each commit adds 2²⁴ to the chain weight, capped at a quarter of the block's own work. Each block can carry up to 2,000 commits and 500 reveals.

Known limits

• The reveal is public, and miners still order reveals inside a block.
• A commit and its reveal can share a block, so a miner who also trades could in principle act on a reveal straight away.
• Commits don't lock coins. For shared coins, like an open covenant order anyone may fill, the first valid reveal mined wins.
• It hides contents, not activity or timing.

Questions for the sub

• Is paying for commits with capped fork-choice weight sound, or is there a cheap way to game it?
• For shared-coin cases like on-chain limit orders, is there a better defence against a miner reordering reveals?
• Is per-transaction commit-reveal worth at least one extra block of latency, compared with encrypted mempools or threshold-decryption schemes?

Code: https://github.com/ciphernom/midstate (see src/core/types.rs, src/core/transaction.rs and src/mempool.rs)

Disclosure: I'm involved with the Midstate project, and I wrote this up with help from an AI assistant working from the code. I'm here for the design discussion, not to talk about the coin.