Transaction Fees

Several resources in a blockchain network are limited, for example, storage and computation. Transaction fees prevent individual users from consuming too many resources. Polkadot uses a weight-based fee model as opposed to a gas-metering model. As such, fees are charged prior to transaction execution; once the fee is paid, nodes will execute the transaction.

The fee system used by Cere was originally designed (by Web3 Foundation) with the following objectives:

• Each Relay Chain block should be processed efficiently to avoid delays in block production.
• The growth rate of the Relay Chain should be bounded.
• Each block should have space for special, high-priority transactions like misconduct reports.
• The system should be able to handle spikes in demand.
• Fees should change slowly so that senders can accurately predict the fee for a given transaction.

Fee Calculation

Fees on the Polkadot Relay Chain are calculated based on three parameters:

• A Weight fee: Base weight, Call(s) weight
• A Length fee
• A Tip (optional)

As a permissionless system, the Polkadot network needs to implement a mechanism to measure and to limit the usage in order to establish an economic incentive structure, to prevent the network overload, and to mitigate DoS vulnerabilities. Polkadot enforces a limited time-window for block producers to create a block, including limitations on block size, which can make the selection and execution of certain extrinsics too expensive and decelerate the network. Extrinsics which require too many resources are discarded by the network.

Polkadot defines a specified block ratio ensuring that only a certain portion of the total block size gets used for regular extrinsics. The remaining space is reserved for critical, operational extrinsics required for the functionality by network itself.

This is handled by a weight system, where the cost of the transactions (referred to as extrinsics) are determined before execution. Weights are a fixed set of numbers used in Substrate-based chains to manage the time it takes to validate a block. Each transaction has a base weight that accounts for the overhead of inclusion (e.g. signature verification) and a dispatch weight that accounts for the time to execute the transaction. All weights, even the base weight, are a measure of time to execute on some standard hardware.

The runtime converts weight units to balance units as part of the fee calculation.

The weight fee is the sum of the base weight and the sum of the total weight consumed by call(s).

Transactions can include multiple calls

For instance, a batch can contain bond and nominate, and the weight would be one base weight and then the sum of the weights for bond and nominate.