7

I am using the following formula and associated constants to calculate fees: https://tezos.gitlab.io/protocols/003_PsddFKi3.html#more-details-on-fees-and-cost-model

Also referenced here: https://tezos.stackexchange.com/a/107/5237

Since the Delphi protocol upgrade my calculated fees result in transactions which often take 15-60 blocks to confirm, assuming because baker's de-prioritize transactions with fees too low.

The constants I was using before Delphi:

minimal_fees = 100 000 nanotez (100 mutez)
minimal_nanotez_per_gas_unit = 100 nanotez
minimal_nanotez_per_byte = 1000 nanotez (1 mutez) 

After Delphi:

minimal_nanotez_per_byte is given by the node, and is now 250 nanotez. Other values are the same (hard-coded).

My formula, using consumed_gas given by run_operation:

fee = minimal_fees + 
      (minimal_nanotez_per_gas_unit * consumed_gas) +
      (minimal_nanotez_per_byte * tx_size_in_bytes)
fee = fee * 1.05 // 5% padding

I added a somewhat arbitrary 5% padding (prior to Delphi) to resolve transactions occasionally not getting picked up by bakers within a reasonable time or sometimes not until they expire from the mempool. After Delphi I am seeing this happen more regularly despite the 5% added.

Is there a better formula or updated constants I should be using to calculate fees to ensure operations are confirmed consistently?

3
  • We are seeing something similar as of Delphi, although I haven't been using a 5% buffer. I was considering to add one. One thing to check anyway is that tx_size_in_bytes needs to be both the number of transaction bytes + the signature bytes, not just the transaction on its own
    – Simon McLoughlin
    Nov 26, 2020 at 10:20
  • Yes tx_size_in_bytes does include the signature bytes.
    – ewerx
    Nov 30, 2020 at 21:59
  • As mentioned by Klassare in his answer below. The new 250 nanotez constant only applies to paid_storage_size_diff that comes back from the estimation. You need to continue using 1000 nanotez for tx_size_in_bytes
    – Simon McLoughlin
    Dec 1, 2020 at 10:23

1 Answer 1

0

You should use gas_limit instead of consumed_gas in that calculation. gas_limit is often set a bit higher than consumed_gas (from the simulation). minimal_nanotez_per_byte have not changed to 250 nanotez, should still be 1000 nanotez (assuming baker default configuration). cost_per_byte has changed to 250 mutez, but this has nothing to do with the fee. It's used to determine the storage cost.

6
  • gas_limit is whats set on the outgoing operation. The estimation will come back with consumed_gas, that is the value to use when figuring out what the gas_limit should be. Does the new 250 nanotez storage cost apply to the storage_cost when computing the baker fee? Doing some testing on Delphi, I need to continue using 1000 nanotez for the storage cost, and 250 nanotez for paid_storage_size_diff, otherwise my transactions never seem to get picked up. Looks like there might be a bug in the baker default config, not updating to 250 nanotez
    – Simon McLoughlin
    Nov 26, 2020 at 16:08
  • Updated my answer to address your comment. Let me know if you think it can be improved further.
    – Klassare
    Nov 26, 2020 at 19:54
  • Thanks. What is a bit higher add 100?, add 500? add 5%? Estimating fees is a critical piece needed for applications to run on the network. There needs to be more detailed information on it to avoid people guessing and causing issues.
    – Simon McLoughlin
    Nov 27, 2020 at 9:58
  • Thanks for clarifying the 1000 nanotez vs 250 nanotez, but again this needs better info. The announcement was all storage costs are being reduced by 75%. Its going to lead to a lot of confusion for developers to see a calculation mention "storage cost" and expect them to know that this one is different to the other storage cost. Some different terminology would be great, and maybe an updated estimation doc with each release, even if nothing changed
    – Simon McLoughlin
    Nov 27, 2020 at 10:01
  • Using 1000 for minimal_nanotez_per_byte instead of 250 (the cost_per_byte) and my original formula put the calculated fees back into an acceptable range. As for gas_limit, I set this value to consumed_gas (given by run_operation) with a 10% buffer added, and also use the padded value for the fee calculation.
    – ewerx
    Dec 3, 2020 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.