Priority fees on Solana vs Ethereum, Base and Polygon: same word, different auctions

Every multichain sender eventually writes a function called estimatePriorityFee(chain), and it is easy to get wrong on at least one chain. The word is shared, but the mechanisms are not. On Solana it is a price per unit of compute. On EIP-1559 chains it is a tip on top of a burned base fee. On a first-come, first-served sequencer it is a field that wallets fill in and the sequencer ignores for ordering. On Stellar it is a bid in an auction where everybody pays the clearing price.

Helius's guide to Solana priority fees (read 2026-09-22) explains the Solana side in depth and stays on Solana. This post puts the models side by side, with the RPC method that estimates each one and the case where paying more does nothing. The underlying term, gas, is in the glossary.

Solana: a price per compute unit, per contended account

A Solana transaction pays a base fee per signature and, optionally, a prioritization fee. Solana's fee documentation gives the formula for the second: ceil(compute_unit_price * compute_unit_limit / 1,000,000) lamports, where the compute-unit price is set in micro-lamports per unit. The base fee is 5,000 lamports per signature, split 50% burned and 50% to the validator; the prioritization fee goes 100% to the validator. What it buys, in the documentation's words, is that it "increases the likelihood that the current leader schedules your transaction ahead of competing ones."

Two consequences for estimation:

• Your fee depends on your compute limit. The same price costs more on a transaction that requests more compute units. Requesting a realistic limit (the documentation lists a default of 200,000 units per instruction and a maximum of 1,400,000 per transaction) is part of fee control.
• Contention is per account. getRecentPrioritizationFees takes up to 128 addresses and returns samples "filtered to transactions that lock a set of writable accounts", one value per recent slot, in micro-lamports per compute unit. A node's cache holds up to 150 blocks. Passing the accounts your transaction will write gives you the fees paid by transactions competing for the same state, which is the number that matters.

A chain-wide query with no addresses can return long runs of zeros — our own call on 2026-09-22 did — and a zero for a slot says nothing about the account you are about to write. Taking the median of that list can tell you to pay nothing, even when the pool you are trading against is contested. Filter by accounts, drop zeros if your policy calls for it, and pick a percentile that matches urgency.

Triport also answers a single-number estimator, getPriorityFeeEstimate. It is a Beta method whose response schema may still change, and it is not part of what our plans sell; the raw samples from getRecentPrioritizationFees are the stable input.

Ethereum and Polygon: EIP-1559 tip on a burned base fee

EIP-1559 splits the price of gas in two. The protocol sets a base fee per block, which "is always burned (i.e. it is destroyed by the protocol)", and moves by at most one eighth per block depending on how full the previous block was. On top of it, the sender offers a priority fee, and the block producer "only receives the priority fee". The priority fee actually paid is:

priority_fee_per_gas = min(max_priority_fee_per_gas, max_fee_per_gas - base_fee_per_gas)

So a transaction sets two numbers: a tip it is willing to pay, and a ceiling on the total. If the base fee rises past max_fee_per_gas, the transaction waits; if it rises into the headroom, the tip shrinks first.

Two RPC methods feed an estimate:

• eth_feeHistory returns, for a range of recent blocks, the base fee per block (plus one projected block), the gas-used ratio and — if you pass rewardPercentiles — the tips paid at those percentiles. This is the input for a policy: "the 50th percentile of the last 10 blocks for normal sends, the 90th for urgent ones".
• eth_maxPriorityFeePerGas returns the node's own single suggestion. It is convenient and opaque; our reference calls it "a node-side suggestion derived from recent block history, not a guarantee of inclusion".

Polygon PoS uses the same fields and the same two methods (eth_maxPriorityFeePerGas on Polygon). The mechanics carry over; the numbers do not. Tips that are normal on one network are wildly off on another, which is the main reason a shared estimatePriorityFee should take its inputs from each chain's own fee history rather than from a constant.

Base: EIP-1559 execution fee plus an L1 data fee

Base's documentation describes two costs on every transaction: "an L2 (execution) fee and an L1 (security) fee". The L1 fee is "the estimated cost to publish the transaction on the L1", and Base notes it is typically the larger of the two. Base also documents a minimum base fee of 5,000,000 wei.

The execution part is EIP-1559, so eth_feeHistory and eth_maxPriorityFeePerGas on Base work as on Ethereum. Base's specification says that "transactions are ordered based priority fee and arrival time", and adds that transactions are ordered by fee at the time of selection, not globally across everything that arrives. So on Base the tip does buy position, but only against the transactions competing at that moment. What the tip cannot do is reduce the L1 data fee, which depends on how many bytes your transaction publishes. For a Base sender, the useful levers are compact calldata for cost and the tip for ordering — two separate knobs.

Robinhood Chain: first-come, first-served, so the tip buys nothing

Robinhood Chain's documentation states that it uses "a first-come, first-served sequencing model, where the order is determined strictly by the arrival time at the sequencer", and that "no transaction can bypass others by paying higher fees".

The EIP-1559 fields still exist, and wallets still fill them in. Our eth_maxPriorityFeePerGas reference for Robinhood Chain says to pay the priority fee "for compatibility with wallets and tooling that expect the field, not to buy position". When we called the method on 2026-09-22 it returned 0x0. The right policy on a first-come, first-served chain is to set a valid fee that covers the base fee and to compete on submission, not on price. A bidding strategy copied from Ethereum simply overpays.

Stellar: an inclusion bid that clears at the lowest accepted price

Stellar has a fourth model. Each operation carries an inclusion fee, which the documentation defines as "the maximum amount the submitter is willing to pay for the transaction to be included in the ledger", with a network minimum of 100 stroops per operation. When ledgers are full, transactions are sorted by their bids, and "the user pays the minimum inclusion fee in their transaction set" — everyone included pays the lowest accepted bid, not their own maximum.

That changes the estimation problem: bidding high is insurance, not a cost you necessarily pay. The Soroban RPC method getFeeStats returns recent inclusion-fee distributions, separately for classic and Soroban transactions, "because they have independent surge pricing". Smart-contract transactions also pay resource fees, which come from simulation rather than from fee statistics.

Estimation methods by chain

On Triport, every method in the last column is part of the ordinary read budget of its network, available from the 7-day trial upward; see the pricing page for the per-plan rates. The Base and Robinhood Chain landings, /base-rpc and /robinhood-rpc, list the rest of each network's surface.

When this is the wrong approach

• Your transaction fails, not waits. A priority fee does not fix a transaction that runs out of compute, exceeds its gas limit or reverts. Simulate first.
• You are on a first-come, first-served chain. Fee bidding logic is dead weight there; invest in submission reliability instead.
• You need a guarantee. No estimator guarantees inclusion in a specific block. For time-critical flows, set a ceiling you can afford and monitor confirmation against the chain's finality levels.
• You fee-bump by resending blindly. On EIP-1559 chains a replacement must reuse the nonce with a higher fee; on Solana a resend is a new transaction. Mixing the two models produces duplicates or stuck nonces.

Sources

1. Solana, Fees — https://solana.com/docs/core/fees, read 2026-09-22 (prioritization-fee formula, 5,000 lamports per signature, 50/50 base-fee split, 100% of the prioritization fee to the validator, default and maximum compute limits).
2. Solana, getRecentPrioritizationFees — https://solana.com/docs/rpc/http/getrecentprioritizationfees, read 2026-09-22 (writable-account filter, 128 addresses, micro-lamports per CU, 150-block cache).
3. Triport, getRecentPrioritizationFees. Called on production 2026-09-22 without addresses. getPriorityFeeEstimate is Beta on Triport and not part of the plan registry's available capabilities.
4. EIP-1559 (status Final) — https://eips.ethereum.org/EIPS/eip-1559, read 2026-09-22 (base fee burned, priority fee to the block producer, effective-tip formula, one-eighth maximum change).
5. Triport, eth_feeHistory, eth_maxPriorityFeePerGas on Ethereum, on Polygon and on Base. Ethereum eth_feeHistory, Polygon and Base eth_maxPriorityFeePerGas answered on production on 2026-09-22.
6. Base, Network fees — https://docs.base.org/base-chain/network-information/network-fees, read 2026-09-22 (L2 execution fee and L1 security fee, minimum base fee).
7. Base, Transaction ordering — https://docs.base.org/specifications/transactions/transaction-ordering, read 2026-09-22 (ordering by priority fee and arrival time, fee compared at the time of selection).
8. Robinhood Chain documentation — https://docs.robinhood.com/chain/, read 2026-09-22 (first-come, first-served sequencing; no bypass by higher fees). Triport, eth_maxPriorityFeePerGas on Robinhood Chain; returned 0x0 on production on 2026-09-22.
9. Stellar, Fees, resource limits and metering — https://developers.stellar.org/docs/learn/fundamentals/fees-resource-limits-metering, read 2026-09-22 (100-stroop minimum, inclusion fee as a maximum bid, surge pricing at the lowest accepted fee). Triport, getFeeStats; answered on production on 2026-09-22.
10. Helius, "Priority Fees: Understanding Solana's Transaction Fee Mechanics" — https://www.helius.dev/blog/priority-fees-understanding-solanas-transaction-fee-mechanics, read 2026-09-22 (no comparison with EIP-1559 chains, Base, Polygon, Robinhood Chain or Stellar).