Skip to content

Fees & Fuel

Overview

Wasichain separates fuel from fees.

  • Fuel is the execution meter used by Wasmtime.
  • Fees are what users actually pay.

Some fees come directly from fuel consumption. Others are charged for things that are not just "Wasmtime fuel used", such as uploads, compilation, and emitted event bytes.

Fee components

The chain limit and fee schedule includes:

Field Meaning
intrinsic_tx_fee Flat base fee for every transaction
fuel_price Price per unit of Wasmtime fuel
base_upload_fee + upload_byte_price Cost to upload code
base_compile_fee + compile_byte_price Cost to validate and prepare code
compile_class_prices Extra flat surcharge by blob-size bucket
event_byte_price Cost per byte of emitted event data

How execution fees work

For ExecContract, the signer declares a fuel_limit.

The chain:

  1. charges the intrinsic transaction fee
  2. pre-charges the maximum execution fee implied by fuel_limit * fuel_price
  3. executes the contract in Wasmtime
  4. refunds unused execution fee
  5. separately charges event-byte fees

If execution traps or runs out of fuel, the max execution charge is kept.

Instantiation and migration

Instantiation and migration currently use an internal fixed fuel budget of 1_000_000 units for the contract init call rather than a user-supplied fuel limit.

Their total charge is still a combination of:

  • the intrinsic transaction fee
  • execution fuel actually consumed
  • event-byte fees

Upload and admission fees

Contract code admission has its own fee path.

When a code manifest is announced on-chain, the signer pays:

  • the intrinsic transaction fee
  • upload fees based on blob size
  • compile and admission fees based on blob size
  • any compile-class surcharge for larger blobs

These costs exist even though compilation itself happens in admissiond, not in the consensus execution path.

Fuel versus non-fuel charges

Not everything is reducible to fuel_consumed * fuel_price.

Examples of non-fuel charges:

  • intrinsic transaction overhead
  • code upload byte pricing
  • compile and admission byte pricing
  • compile-class surcharges
  • emitted event bytes

That distinction matters when estimating user cost: execution may be cheap in fuel terms while still carrying upload, compile, or event costs.

Validator rewards

Fees collected from transactions accumulate into the chain fee pool during block execution.

After block application, the fee pool is distributed to the active validator set in proportion to validator weight. The final validator in the distribution loop receives any rounding remainder so the full pool is paid out.

In other words:

  • users pay fees into the chain fee pool
  • the chain distributes the pool to validators
  • reward share is weight-based

Resource limits

The same schedule also carries several execution limits:

  • max_fuel_per_tx
  • max_fuel_per_block
  • max_tx_time_ms
  • max_blob_size

These are not just pricing knobs. They are part of the chain's safety model, because they bound how much work a single transaction, block, or upload can impose.