Transaction Priority

Overview

In fee markets, users express urgency through fee rate, priority fee, or bid. Producers compare the economic value of eligible transactions while respecting resource limits and ordering constraints.

Priority can be restricted by dependencies. An account transaction with nonce 15 cannot execute before nonce 14, even if it offers a higher fee. A child UTXO transaction can depend on an unconfirmed parent. Builders may evaluate the combined value of related transactions.

Private order flow and bundles add another layer. A transaction can receive favorable ordering through a builder relationship rather than public mempool fees. Sequencers may apply first-seen, auction, or application-specific rules.

Applications use internal priority for payouts, refunds, and customer service. An urgent withdrawal may receive a higher fee budget, while routine treasury consolidation waits for cheaper conditions. Internal priority should not silently override security or approval requirements.

Monitoring should compare requested priority with actual inclusion time and cost. Overpaying for every transaction wastes funds, while low priority can create long delays and nonce queues.

Transaction priority allocates scarce processing opportunity. It determines relative ordering pressure, but validity, state, capacity, and producer behavior still decide the final outcome.

Priority policies should avoid unfair or unsafe starvation. Low-priority maintenance transactions may still be necessary for nonce continuity, account rent, or security operations. A queue that always serves high-fee customer requests can leave critical background tasks blocked indefinitely. Scheduling can reserve capacity by class and escalate aging transactions. This provides predictable service without treating every urgent request as permission to bypass validation or approval.