claimsol.solhousesignal.com: multi-transaction requests always "Request blocked" (RELIABLE_SIMULATION_NOT_POSSIBLE)

[SimuZSkyNeT]

Hi Phantom team,

We run Claim SOL (https://claimsol.solhousesignal.com), a tool that closes empty token accounts and returns the rent to the user's wallet. Our full transaction code is public and matches production: https://github.com/SimuZSkyNeT/claimsol-tx

We followed the domain and transaction warnings guide:

• one signer per transaction (the user)
• each transaction ≤ 850 bytes, with CU headroom for Lighthouse
• every transaction is simulated with sigVerify: false before signing, and failures are dropped
• signAndSendTransaction, so Phantom submits and adds its protections
• following support's advice, closures and burns share one transaction on small claims

Single-transaction requests show a clean Confirm. Any request with 2 or more transactions (signAndSendAllTransactions / signAllTransactions) is blocked with "This dApp could be malicious", even for two trivial transfers. The simulation API returns block.kind = RELIABLE_SIMULATION_NOT_POSSIBLE for our domain, while other reclaim tools can batch normally. Users with many accounts have to approve 3 to 7 popups one by one.

We submitted the domain review form on Oct 10 and are in contact with support (review@phantom.com). We were told a vouch from a known Solana developer would help, but we don't have one. We're happy to verify in any other way: DNS TXT record, a message signed by our fee wallet, a call, or ID.

Could someone take a look at our domain for batch requests? Thanks!

[CCristi]

Thanks for flagging this! We found a bug in how we generate RELIABLE_SIMULATION_NOT_POSSIBLE warning. It should be fixed now.

[SimuZSkyNeT]

Thanks a lot for looking into it! Unfortunately we still get the block: at 14:31 UTC a request with 2 simple transactions (signAndSendAllTransactions) from claimsol.solhousesignal.com returned block.kind = RELIABLE_SIMULATION_NOT_POSSIBLE (Phantom extension 26.32). The same request from jup.ag shows a normal Confirm. Is the fix still rolling out, or is there something else we should check on our side?