Gas Optimization

Gas pricing on MultiversX determines both transaction cost and confirmation speed. Use real-time statistics from mx-relayer to submit transactions at the right price.


Background: gasPrice and PPU on MultiversX

Every MultiversX transaction specifies a gasPrice in atomic EGLD units (10^-18 EGLD) and a gasLimit in gas units. The total fee is approximately:

fee = gasPrice * gasUsed

The network enforces a minimum gasPrice of 1,000,000,000 (10^9). Validators prioritize higher-priced transactions, so submitting at the minimum during congestion may delay or miss inclusion.

PPU (Price Per Unit) is the effective cost per gas unit of computation. For transactions with a non-empty data field, each byte costs an additional 1,500 gas units at the current gasPrice. PPU accounts for this, making it a more accurate comparator across transactions with different data sizes.

For swap transactions, arb-algo's txData populates the data field, often adding several hundred bytes. PPU is therefore higher for swaps than for a plain EGLD transfer at the same gasPrice.


How the Sliding Window Works

Gas statistics are computed over a 30-minute sliding window of 10-second buckets (180 buckets total).

Time β†’
β”œβ”€ bucket[179] ─ bucket[178] ─ ... ─ bucket[1] ─ bucket[0] ──
│←────────────────── 30 minutes ─────────────────────────────►│
                                                               now

As time advances, the oldest bucket expires and drops from the window. Each bucket records all transactions observed in that 10-second interval.

Spam resistance. Spam attacks typically flood the mempool with minimum-price transactions in a short burst. A 10-second spike influences the window for at most 30 minutes before being evicted. The bucketAvg metric weights each bucket equally regardless of transaction count, so a single high-volume spam bucket does not distort the 30-minute average.

Percentiles (p50, p75, p90) are computed across all transactions in the full window using reservoir sampling. Because spam transactions cluster at the minimum price, p50 reflects the median including spam, while p75 and p90 reflect what legitimate transactions actually paid.

Metric
What it measures
Effect of spam

avg

Simple mean over all transactions in 30-min window

Biased low by spam volume

bucketAvg

Mean of per-bucket averages

Less sensitive to volume spikes

p50

50th percentile gas price

Often at or near minimum during spam

p75

75th percentile gas price

Spam-resistant; typical legitimate tx price

p90

90th percentile gas price

Upper bound; used during high congestion


When to Use p50 vs p75 vs p90

Scenario
Recommended metric
Rationale

Non-urgent background operations

p50

Cheapest that has historically been included

Standard user-initiated swaps

p75

Reliable inclusion without significant overpay

Time-sensitive arbitrage or liquidations

p90

Competitive even during congestion

Mempool pressure > 0.5 (see below)

One tier higher than baseline

Elevated pressure warrants elevated price

Shard has no recent transactions

1000000000 (minimum)

Shard is idle; minimum is sufficient

circle-info

When a shard reports all gas price fields as 1000000000 and PPU as 0, it has no recent transaction history. The shard has spare capacity and the minimum price is sufficient.


Using mempool.pressure from networkStats

The networkStats stream (available at wss://relayer.xoxno.com/ws/stats, pushed every 250ms) includes a mempool.pressure value per shard β€” the current queue depth relative to the shard's throughput capacity.

Use mempool.pressure to escalate the gas price percentile dynamically:


Block Time Expectations

Swap transactions to a DEX contract on the sender's shard finalize in one block time (approximately 6 seconds on mainnet). Cross-shard transactions require two block times: one on the initiating shard and one on the receiving shard.

The blockTimeMsP50ByShard field in networkStats gives the current median block time per shard. For cross-shard transactions, sum the two relevant shards to estimate confirmation time.


Cost vs. Confirmation Speed Tradeoff

The following table shows expected behavior at each gas price tier under different network conditions. Values are illustrative; actual behavior depends on current validator inclusion policy.

Gas price tier
Metric
Low congestion
Moderate congestion
High congestion

Minimum

1000000000

Included in 1-2 blocks

May wait 5-10 blocks

Risk of dropping

p50

median tx

Included in 1-2 blocks

Included in 2-4 blocks

May wait 10+ blocks

p75

legitimate txs

Included in next block

Included in 1-2 blocks

Included in 2-4 blocks

p90

high-priority txs

Included in next block

Included in next block

Included in 1-2 blocks


Adaptive Gas Pricing: Full Example

The following function subscribes to both gasStats and networkStats and returns a gas price that adapts to current shard conditions.


Practical Guidelines

For swap integrations:

  • Subscribe to gasStats before the first transaction. The first message arrives immediately on subscription.

  • Default to p75. It provides reliable inclusion without significant overpay under most conditions.

  • Check mempool.pressure from networkStats. If pressure exceeds 0.5, step up to p90 for user-facing transactions.

  • For background or non-urgent operations (e.g., periodic rebalancing), bucketAvg is sufficient.

Avoid:

  • Using the raw avg field for pricing decisions. Spam volume biases it low and it may underestimate the price required for inclusion.

  • Setting gasPrice below the network minimum of 1,000,000,000. The network rejects transactions with lower prices.

  • Caching gas stats for more than a few seconds. Market conditions on MultiversX can shift within a single block.


Last updated

Was this helpful?