Gives operational transactions (like set_weights) higher priority by computing a virtual tip based on their fees, ensuring critical network operations are processed before normal transactions.
Current Value
5The Big Picture
Not all transactions are equally urgent. Substrate classifies transactions into classes: Normal, Operational, and Mandatory. Operational extrinsics (like set_weights for validators) are critical for network function. This multiplier creates a virtual tip that boosts their priority without requiring actual tips, ensuring validators can always update weights even during congestion.
Why This Matters
When the network is congested, which transactions get included? This multiplier ensures operational transactions (like validator weight updates) are prioritized even without tips. A value of 5 means operational txs get priority as if they had a 5x virtual tip.
Example
OperationalFeeMultiplier is 5. A set_weights transaction with 0.001 TAO fee gets priority calculated as if it had a 0.005 TAO tip (5 * fee). A normal transfer would need a real 0.005+ TAO tip to front-run it.
Common Questions
- What makes a transaction 'operational'?
- The pallet defines it. Typically: validator weight updates, consensus-critical operations, and governance actions. Normal user transfers are 'Normal' class.
- Do operational transactions still pay fees?
- Yes, they pay normal fees. The multiplier only affects priority calculation, not fee payment. The virtual tip is for ordering, not an actual cost.
- Can this be changed?
- It's a runtime constant, so changes require a runtime upgrade. The value (5) was chosen to ensure network-critical operations have significant priority advantage.
- Does a higher multiplier mean faster inclusion?
- Yes, for operational transactions. They get a priority boost proportional to their fee times this multiplier. Higher values = stronger priority over Normal transactions.
From Chain Metadata
A fee multiplier for `Operational` extrinsics to compute "virtual tip" to boost their `priority` This value is multiplied by the `final_fee` to obtain a "virtual tip" that is later added to a tip component in regular `priority` calculations. It means that a `Normal` transaction can front-run a similarly-sized `Operational` extrinsic (with no tip), by including a tip value greater than the virtual tip. ```rust,ignore // For `Normal` let priority = priority_calc(tip); // For `Operational` let virtual_tip = (inclusion_fee + tip) * OperationalFeeMultiplier; let priority = priority_calc(tip + virtual_tip); ``` Note that since we use `final_fee` the multiplier applies also to the regular `tip` sent with the transaction. So, not only does the transaction get a priority bump based on the `inclusion_fee`, but we also amplify the impact of tips applied to `Operational` transactions.
Use Cases
- Understand priority ordering of transactions
- Debug why certain transactions are included first
- Build transaction priority estimation tools
- Analyze block inclusion patterns
How to Use This Constant
- → Factor into transaction priority calculations
- → Understand why operational transactions get included first
- → Build mempool analysis tools
Value History
| Version | Block | Change | Value |
|---|---|---|---|
| v101 | #1 | Added | 1 |
| v210 | #4,345,556 | Changed | 1 → 5 |
Code Examples
import { ApiPromise, WsProvider } from "@polkadot/api";
import { stringCamelCase } from "@polkadot/util";
const provider = new WsProvider("wss://entrypoint-finney.opentensor.ai:443");
const api = await ApiPromise.create({ provider });
// Query OperationalFeeMultiplier constant
const value = api.consts[stringCamelCase("TransactionPayment")][stringCamelCase("OperationalFeeMultiplier")];
console.log("OperationalFeeMultiplier:", value.toHuman());Type Information
- Type
- u8
- Byte Size
- 1 bytes
- Encoding
- fixed
- Raw Hex
- 0x05
Version History
Runtime Info
- Pallet
- TransactionPayment
- First Version
- v101
- Latest Version
- v101
- Current Runtime
- v393