[Ethereum] Is 21,000 Gas Limit Fixed Only for Ethereum

etherfeesgastransactions

I was reading a comment on another post on Ethereum SE and found the following statement:

21,000 is for sending Ether, not anything else.

The user suggested to "just set it to a large enough value (which you are willing to pay in the worst case)"

I'm perplexed. When sending ECR20 tokens (such as USDC and USDT) is the gas limit arbitrary? Or is it fixed? Setting it to an arbitrarily large number and hoping it will get accepted by the network might work but it doesn't address the fundamental question of how gas fees are calculated when sending ECR20 based tokens?

Another user suggested in a different thread that the gas fee is in fact fixed by the creator of the token:

You will have control over the gasPrice however a standard ERC20 token
transfer's gasUsed will be "fixed" (or at least out of your control).

What is the right answer? How should I calculate the gas fee when sending USDT and USDC?

Best Answer

The base number of gas needed for any transaction is 21,000 gas. Like you mentioned, sending Ether from an EOA to an EOA, without any data in the transaction, will always take exactly 21,000 gas.

Any gas on top of that is determined by a few things:

Transaction data: any zero byte of data costs 4 gas for example, and any non-zero byte costs 68 gas.
Contract execution: the cost of running code on the blockchain. This is determined by the opcodes that are used in the contract execution.

How much gas an ERC-20 token transaction takes depends on the contract implementation. A more complex contract, will result in a higher gas cost. There's no fixed number for token transfers, since the gas cost can depend on many different factors. For example, if someone never received tokens before (balance = 0), the cost for contract execution will be slightly higher because you're changing a number (balance) from zero to a non-zero value.

The cost of each operation is specified in the Ethereum Yellow Paper. To get an estimate of how much gas you need for a transaction, you can use the eth_estimateGas JSON-RPC function.

Summary

I have sent a test transaction (#1) to firstly find out how much gas a successful smart contract transaction uses. From the results of this transaction, the gas required for a successful transaction is 26747.

I then used this 26747 gas amount in my going-to-be-successful transaction (#2). And gasUsed == gas.

I then use this same 26747 gas amount in my going-to-be-UNSUCCESSFUL transaction (#3). And gasUsed == gas.

The only reliable way I have found so far to easily check if a smart contract transaction is successful is to use debug.traceTransaction and check the last error message. If this is "" then no error occurred. If this is "Out of gas" or "invalid jump destination (PUSH1) 2", then an error occurred.

And here's a short bit of code to determine the status of your transaction.

> var status = debug.traceTransaction("0xd23219e2ea10528b245deb9e47993cae2ffd3ffe9fc27aeb808e94fc4e75d37b")
undefined
> if (status.structLogs.length > 0) {
  console.log(status.structLogs[status.structLogs.length-1].error)
}
"invalid jump destination (PUSH1) 2"

The return value above will be "" if there are no errors, or "Out of gas" if you run out of gas.

UPDATE 29/07/2016 - the geth --fast blockchain download does not contain the information for debug.traceTransaction(...) to display.

Details

I'm using the following example for a smart contract that throws an exception if _value < 12345:

contract TestStatus {
    uint public value;
    function setValue(uint256 _value) {
        value = _value;
        if (_value < 12345) {
            throw;
        }
    }
}

I flattened the source to:

var testStatusSource='contract TestStatus { uint public value; function setValue(uint256 _value) { value = _value; if (_value < 12345) { throw; } }}'

I compiled and inserted the contract into the blockchain:

var testStatusCompiled = web3.eth.compile.solidity(testStatusSource);

var testStatusContract = web3.eth.contract(testStatusCompiled.TestStatus.info.abiDefinition);
var testStatus = testStatusContract.new({
  from:web3.eth.accounts[0], 
  data: testStatusCompiled.TestStatus.code, gas: 1000000}, 
  function(e, contract) {
    if (!e) {
      if (!contract.address) {
        console.log("Contract transaction send: TransactionHash: " + contract.transactionHash + 
          " waiting to be mined...");
      } else {
        console.log("Contract mined! Address: " + contract.address);
        console.log(contract);
      }
  }
})
Contract transaction send: TransactionHash: 0x4de11cc54484333036f45a2441563d6badae43d2e2789e0b113b6703a582a879 waiting to be mined...
undefined
...
Contract mined! Address: 0x87847eb0f944fbb6d5c5a4891e3b103a63cee45c
[object Object]

I sent a transaction that won't cause an error to determine the gas required:

# Not an error
testStatus.setValue(123456, eth.accounts[0], {
  from:web3.eth.accounts[0], 
  data: testStatusCompiled.TestStatus.code,
  gas: 41747
});
...
> eth.getTransactionReceipt("0x727cb3c6846bbb05c8437e97aa32db39a252426b09ed837a76bb364748ce73c4")
{
  blockHash: "0x293b4d357d72615c409ba37a6430253d64b4646e0366ac987d1364a258cf81fa",
  blockNumber: 2465,
  contractAddress: null,
  cumulativeGasUsed: 26747,
  from: "0xa7857047907d53a2e494d5f311b4b586dc6a96d2",
  gasUsed: 26747,
  logs: [],
  root: "fbb29f9eff2340aa8d7df7feec74671c2b693fb9e7b6ec3b710ca6d64813da0e",
  to: "0x87847eb0f944fbb6d5c5a4891e3b103a63cee45c",
  transactionHash: "0x727cb3c6846bbb05c8437e97aa32db39a252426b09ed837a76bb364748ce73c4",
  transactionIndex: 0
}

The gas required is 26747.

I sent a transaction with value=123456 that will NOT fail, and gas==gasUsed:

testStatus.setValue(123456, eth.accounts[0], {
  from:web3.eth.accounts[0], 
  data: testStatusCompiled.TestStatus.code,
  gas: 26747
});
0xc0ab94adfe473811d055f98528a625dbebf66026b7ec5ad8eab939de862bc2d1

I'm using debug.traceTransaction to confirm that this transaction has not encountered an error.

> var status = debug.traceTransaction("0xc0ab94adfe473811d055f98528a625dbebf66026b7ec5ad8eab939de862bc2d1")
undefined
> status.structLogs[status.structLogs.length-1].error
""

And in this situation gas(26747) == gasUsed(26747)

eth.getTransaction("0xc0ab94adfe473811d055f98528a625dbebf66026b7ec5ad8eab939de862bc2d1")
{
  blockHash: "0x961277e2bebfe8332a23d240672b2658eced493b70fd145c99991c3c8651adcc",
  blockNumber: 2475,
  from: "0xa7857047907d53a2e494d5f311b4b586dc6a96d2",
  gas: 26747,
  gasPrice: 20000000000,
  hash: "0xc0ab94adfe473811d055f98528a625dbebf66026b7ec5ad8eab939de862bc2d1",
  input: "0x55241077000000000000000000000000000000000000000000000000000000000001e240",
  nonce: 66,
  to: "0x87847eb0f944fbb6d5c5a4891e3b103a63cee45c",
  transactionIndex: 0,
  value: 0
}
eth.getTransactionReceipt("0xc0ab94adfe473811d055f98528a625dbebf66026b7ec5ad8eab939de862bc2d1")
{
  blockHash: "0x961277e2bebfe8332a23d240672b2658eced493b70fd145c99991c3c8651adcc",
  blockNumber: 2475,
  contractAddress: null,
  cumulativeGasUsed: 26747,
  from: "0xa7857047907d53a2e494d5f311b4b586dc6a96d2",
  gasUsed: 26747,
  logs: [],
  root: "f850e1e5c99352f47e3409e4e9f966a49c13152e63aaa7bb3765f0b37bfe09e5",
  to: "0x87847eb0f944fbb6d5c5a4891e3b103a63cee45c",
  transactionHash: "0xc0ab94adfe473811d055f98528a625dbebf66026b7ec5ad8eab939de862bc2d1",
  transactionIndex: 0
}

I then sent a transaction with value=123 that failed, and gas==gasUsed:

testStatus.setValue(123, eth.accounts[0], {
  from:web3.eth.accounts[0], 
  data: testStatusCompiled.TestStatus.code,
  gas: 26747
});

0x9ee86a200528de32a695f1e2dd0d94a3871fefc7e49c5fd24a4a37eab1b99f7a
> var status = debug.traceTransaction("0x9ee86a200528de32a695f1e2dd0d94a3871fefc7e49c5fd24a4a37eab1b99f7a")
undefined
> status.structLogs[status.structLogs.length-1].error
"invalid jump destination (PUSH1) 2"

> eth.getTransaction("0x9ee86a200528de32a695f1e2dd0d94a3871fefc7e49c5fd24a4a37eab1b99f7a")
{
  blockHash: "0x22fb5fcaef27dd017efcde8c3f78df7f5168c505210f5d08872a9c2877146044",
  blockNumber: 2484,
  from: "0xa7857047907d53a2e494d5f311b4b586dc6a96d2",
  gas: 26747,
  gasPrice: 20000000000,
  hash: "0x9ee86a200528de32a695f1e2dd0d94a3871fefc7e49c5fd24a4a37eab1b99f7a",
  input: "0x55241077000000000000000000000000000000000000000000000000000000000000007b",
  nonce: 67,
  to: "0x87847eb0f944fbb6d5c5a4891e3b103a63cee45c",
  transactionIndex: 0,
  value: 0
}
> eth.getTransactionReceipt("0x9ee86a200528de32a695f1e2dd0d94a3871fefc7e49c5fd24a4a37eab1b99f7a")
{
  blockHash: "0x22fb5fcaef27dd017efcde8c3f78df7f5168c505210f5d08872a9c2877146044",
  blockNumber: 2484,
  contractAddress: null,
  cumulativeGasUsed: 26747,
  from: "0xa7857047907d53a2e494d5f311b4b586dc6a96d2",
  gasUsed: 26747,
  logs: [],
  root: "ab51ab81c19eb8da7f8d0216d6c2f1d8946e88842b758ff0af13c28ff7e181b4",
  to: "0x87847eb0f944fbb6d5c5a4891e3b103a63cee45c",
  transactionHash: "0x9ee86a200528de32a695f1e2dd0d94a3871fefc7e49c5fd24a4a37eab1b99f7a",
  transactionIndex: 0
}

So the only easy reliable way I've found to determine if a smart contract transaction has succeeded or failed is to use debug.traceTransaction.

Here's the output of debug.traceTransaction for the last transaction that failed.

debug.traceTransaction("0x9ee86a200528de32a695f1e2dd0d94a3871fefc7e49c5fd24a4a37eab1b99f7a")
{
  gas: 26747,
  returnValue: "",
  structLogs: [{
      depth: 1,
      error: "",
      gas: 5280,
      gasCost: 3,
      memory: null,
      op: "PUSH1",
      pc: 0,
      stack: [],
      storage: {}
  }, {
      depth: 1,
      error: "",
      gas: 5277,
      gasCost: 3,
      memory: null,
      op: "PUSH1",
      pc: 2,
      stack: ["0000000000000000000000000000000000000000000000000000000000000060"],
      storage: {}
  }, {
  ...
  }, {
      depth: 1,
      error: "invalid jump destination (PUSH1) 2",
      gas: 129,
      gasCost: 8,
      memory: ["0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000000", "0000000000000000000000000000000000000000000000000000000000000060"],
      op: "JUMP",
      pc: 66,
      stack: ["0000000000000000000000000000000000000000000000000000000055241077", "0000000000000000000000000000000000000000000000000000000000000022", "000000000000000000000000000000000000000000000000000000000000007b"],
      storage: {
        0000000000000000000000000000000000000000000000000000000000000000: "000000000000000000000000000000000000000000000000000000000000007b"
      }
  }]
}

And here's a short script to check if the transaction passed or failed:

> var status = debug.traceTransaction("0x9ee86a200528de32a695f1e2dd0d94a3871fefc7e49c5fd24a4a37eab1b99f7a")
undefined
> status.structLogs[status.structLogs.length-1].error
"invalid jump destination (PUSH1) 2"

[Ethereum] How to build an Ethereum hot wallet for an exchange

The most Ethereum friendly solution would be

Create and deploy a controller smart contract. This co-ordinates that we have deterministic addresses for payment forwarded smart contracts.
For each new deposit address deploy a payment forwarded smart contract using CREATE2 from depositor controller. You need deploy a batch of these smart contracts upfront and then assign them to the customers as they come in.

The smart contract has only one function - forward deposited ETH and tokens to a hot wallet. The exchange fee wallet calls this function and the exchange pays the fees.

An overview of Coinbase merchant non-custodial architecture. An example forwarder contract. Other CREATE2 users are most of mobile smart contract based wallets that support "recover wallet by friends" and non-ETH fee markets e.g. Pillar, Gnosis, Argent.

Pros

Can handle ERC-20 transfer() transactions from centralised exchanges that do not support ERC-20 approve() and transferFrom() mechanism
Using CREATE2 EVM opcode, the contract can be retroactively deployed to a deterministic address where the user already sent the payment even if the deployer system is down for some reason

Cons

May use more gas (see CREATE2 gas cost stats)
Needs a centralised co-ordinator for allocating payment forwarder addresses
Extra gas cost for the merchant to deploy forwarded contract per user and then calling this contract to forward its contents ETH and tokens to a centrally managed wallet

Difference over plain Ethereum account forwarders

You do not need to top up plain Ethereum forwarding accounts with gas money, as gas for the forwarder contracts can be centrally paid
Non-custodial logic - even if the deployer private key is compromised the system as a whole is not compromised
Smart contract can interact with payment forwarder contracts

However plain Ethereum accounts with hierarchically deterministic private keys may work as well, as long as you figure out how to keep them topped up for gas money.

Best Answer

Related Solutions

[Ethereum] How to the transaction status from a thrown error be detected when gas can be exactly the same as the gasUsed for a successful transaction

Summary

Details

[Ethereum] How to build an Ethereum hot wallet for an exchange

Related Topic