Background

In simulations on the client, if a transaction simulation indicates a change in the user's balance for a non-native token , we rerun the simulation but sandwich the original transaction between two other transactions that check the user's balance before and after the transaction for the given token.

This "sandwich" method is thought to be more reliable than the original simulation's trace logs.

Problem

In the case of a transaction that would mint an NFT, the token id does not exist before the transaction runs and checking the user's balance for a non-existing token id will revert.

This is causing simulation errors on the client because the client is not anticipating a revert since the original transaction did not revert.

Furthermore, since Sentinel correctly reports the revert, this issue is contributing to a current large error-rate discrepancy between client and server (double-digit percent vs half-a-percent).

Here is what a revert looks like for a token ID that does not exist yet:

{
  "jsonrpc": "2.0",
  "result": {
    "transactions": [
      {
        "error": "execution reverted: ERC721: invalid token ID",
        "return": "0x08c379a0000000000000000000000000000000000000000000000000000000000000002000000000000000000000000000000000000000000000000000000000000000184552433732313a20696e76616c696420746f6b656e2049440000000000000000",
        "status": "0x0"
      }
    ],
    "blockNumber": "0xd02556",
    "id": "0bbcda56-afaa-479a-ab46-4171cc33ef13"
  },
  "id": "5"
}