RPC / Explorer Potentially Returning False Information

[BenKurrek]

Describe the bug
RPC shows a receipt where more GAS is being refunded than what was attached to the transaction.

To Reproduce
near call counter.examples.testnet get_num --accountId YOUR_ACCOUNT_ID --gas 200000000000000 This will sign a super simple transaction using the rust counter where you query for the current value of the counter.

You attach 200 TGas which is: 200 * 10^12 * GAS_PRICE where GAS_PRICE was queried using RPC and returned 100000000. This results in 200 * 10^12 * 100000000 = 2*10^22 yoctoNEAR which is 0.02 $NEAR. The initial balance of the account was measured to be 99999413298725965200000000 using a near state and the final balance was measured to be 99998898898475407300000000. This means that the account balance went down by roughly 0.0005144 $NEAR.

When looking at the explorer (linked here, it shows the following execution outcome:

Converting the txn to a receipt cost roughly 0.000242 $NEAR and the get_num receipt cost roughly 0.000283 $NEAR which sum to roughly 0.000525 $NEAR which is close enough to the 0.0005144 $NEAR that my account balance went down by. This means that i'm correctly being refunded for the excess GAS that is left unused (which in this case is 200 TGas - roughly 5 TGas that was burnt) which is close to 195 TGas. This means that I should be refunded by the system for close to 0.0195 $NEAR.

Upon looking at the explorer, there is a receipt where I'm refunded by the system for 0.06773 $NEAR which is roughly 677 TGas. Since my account balance ended up going down by the correct amount, I'm pretty sure everything is working behind the scenes. This also isn't an explorer issue since doing a POST to the RPC for testnet showed the incorrect value being reported as transferred:

"receipts": [
            {
                "predecessor_id": "system",
                "receipt": {
                    "Action": {
                        "actions": [
                            {
                                "Transfer": {
                                    "deposit": "67729788128956281735558"
                                }
                            }
                        ],
                        "gas_price": "0",
                        "input_data_ids": [],
                        "output_data_receivers": [],
                        "signer_id": "counter.examples.testnet",
                        "signer_public_key": "ed25519:4Q9XcytELrFdBtLTQragmWPVr9Kf3inFYsgnp9FQSuhr"
                    }
                },
                "receipt_id": "CU4fToH74uYViXn55udfgAFfNXeGYbFns8BYyD7itd3q",
                "receiver_id": "counter.examples.testnet"
            }
        ],

Using the following JSON body:

{
  "jsonrpc": "2.0",
  "id": "dontcare",
  "method": "EXPERIMENTAL_tx_status",
  "params": ["8s7joSCstJRHYfYPYzyFcdA2STjEWSCkscYJ9z2yHyhV", "benji"]
}

Expected behavior
I think that 0.02 - 0.0005144 should have shown up as being transferred to my account rather than 0.06773 $NEAR.

Screenshots

Version (please complete the following information):

• testnet

[jakmeier]

This is the same thing that I debugged last week. I filed a ticket at the explorer: near/near-explorer#904

The good new is, it is only a problem of displaying the information, everything on chain happens exactly as intended and documented (if you dig deep enough). The bad news is that it is fundamentally more complex than the current explorer UI suggests.

To fix your calculations, there are two points.

• The price you initially pay for gas is pessimistically inflated and therefore a higher number than 10^12 . How much exactly depends on the attached gas.
• The total amount of gas attached to the transaction is slightly higher than what is attached to the function call. 200 Tgas is attached to the function call, some extra is attached to the transaction to cover everything that happens before the function call gets executed.

Please refer to the details in the linked issue to learn how exactly the formula should look.

[bowenwang1996]

@BenKurrek please reopen the issue if anything remains unclear