Why gas models matter

For users, gas is the “will this go through and how much will it cost?” question.

For developers, it’s “can wallets estimate this reliably so my UX doesn’t break?”

Predictable transaction costs keep users happy, and fair prioritization ensures your transactions get processed when network demand spikes.

What happens with gas cost calculation if a project sits at a unique crossroad between two chains?

Neon EVM delivers the Ethereum tooling on Solana, but EIP-1559’s per-gas tip doesn’t fully align with Solana’s priority mechanics.

Neon’s recent update addresses that mismatch.

‍

Neon gas fees

Before we dive into gas price calculations, here’s a quick remider on how gas fees work in Neon EVM:

1. The User pays for each transaction in NEON tokens to the Proxy Operator.
2. The Proxy Operator then pays the Solana Validator and the DAO Treasury.

Users of dApps built on the Neon EVM pay for all the resources they consume plus the Operator fees (these may differ between Operators). Operators pay for the resources they consume in SOL. Specifically, Operators pay Solana validators and governance fees in SOL. Operators pay the same amount for governance as they pay to Solana validators (for the signature validation).

The fee consists of gas amount and gas price: Gas fee = Gas amount × Gas price (shown in Galans = 1e-9 NEON).Where:

• Gas amount (Solana-style) = compute + signature + (if needed) storage allocation.
  • Signature: 5,000 lamports per tx (matched to DAO Treasury).
  • Storage (new/resized accounts): 6,960 lamports/byte (rent-exempt rule).
• Gas price (baseline) tracks the SOL:NEON rate plus an operator fee:
• gasPrice = (SOL price / NEON price) × (1 + operatorFee)

With that baseline, the rest of this article shows why moving Solana’s priority from gasPrice to gasLimit makes fees fairer and easier to estimate, and how Neon implements it.

‍

The limitations of Ethereum’s gas model on Solana

How EIP-1559 works (on Ethereum)

On Ethereum, total transaction cost ≈

• Base fee (burned, adjusts per block by up to ~12.5%)
• Priority fee / tip (to miners/validators)
• Gas used × (base fee + tip)
• transactionCost = gasUsage × (baseFee + priorityFee)

Wallets (e.g., MetaMask) optimize around this: estimate gas used and add a tip via maxPriorityFeePerGas.

In this model, your priority fee is baked into the gas price itself. The more complex your transaction (higher gas usage), the more you pay in priority fees. This makes sense in Ethereum's world, where execution and priority are tightly coupled.

Why that doesn’t map well to Solana

Solana separates priority fees (the compute unit pricing) from execution and storage costs. They're independent variables, not multiplied together.

• Priority ≠ a simple per-gas tip. On Solana, priority is primarily about compute units (CUs) priced via a CU price × CU limit, separate from other costs.
• No 12.5%/block smoothing. Ethereum base fee changes gradually; Solana doesn’t impose that specific bound, so prioritization reacts differently to load.
• Wallet heuristics misfire. When we represent Solana’s priority as a higher gasPrice, Ethereum wallets can over/under-shoot:
  • They treat the tip as “per-gas,” inflating the whole cost.
  • Estimators may become noisy (or conservative), yielding confusing UX.
• Storage/account effects are different. Solana’s account model and write locks don’t match per-gas economics. Priority is not “pay more per gas,” it’s “pay a separate, explicit tip for compute priority.”

This mismatch creates several problems when using Ethereum's model on Neon:

1. Storage allocation disparities

When a Neon transaction allocates storage, gas usage becomes higher. Without storage allocations, gas usage stays low. Using Ethereum's model means the gas price needs different values for transactions with and without storage allocations - a considerable challenge for accurate fee estimation.

1. Base fee adjustment limitations

Ethereum's base fee can only adjust by 12.5% per block, providing stability but limiting responsiveness. Solana has no such restrictions: priority fees can swing dramatically based on real-time network conditions. The rigid Ethereum model can't keep pace with Solana's dynamic fee market.

1. Wallet compatibility issues

Standard Ethereum wallets like MetaMask aren't designed to handle this hybrid scenario reliably. They expect priority fees to work the Ethereum way, leading to confusing user experiences and in some cases - even failed transactions.

Bottom line: tying Solana priority to gasPrice isn’t very well aligned with the economics and can produce inaccurate estimates.

‍

Transaction cost calculation: from Solana to Neon

A typical Solana transaction’s cost is composed of:

1. Signature cost: lamports per signature.
2. Account storage/allocation costs: e.g., rent-exempt balance for new or resized accounts (not every tx, but relevant when accounts change).
3. Priority fee via Compute Budget: CU price × CU limit, where:
   • CU limit caps how much compute the tx can consume.
   • CU price (in microlamports per CU) expresses your tip to move ahead in congested slots.

Solana transaction cost formula:

$transactionCost = 5’000 * numberSignatures + lamportsFor1BytePer2Years * allocatedStorage + computeUnitPrice * computeUnitLimit$

→ Key difference from Ethereum: Solana separates the “priority tip” from execution/storage. You explicitly set CU price and CU limit; the rest is fixed/deterministic given your program behavior.

For Neon EVM transactions, this simplifies to:

$transactionCost = 10'000 + 6'960 * allocatedStorage + cuPrice * cuLimit$Where:

• $numberSignatures$ = 1 on NeonEVM because Neon EVM uses only one signature from a Neon Operator
• 5,000 units for each transaction (Solana charges 5,000 lamports for the signature validation for each transaction) goes to the Solana validator. This computational cost is doubled to give the same amount of gas fees to the DAO Treasury.
• $lamportsFor1BytePer2Years$ = 6’960, it is a constant defined in the source code -  https://github.com/solana-labs/solana/blob/master/sdk/program/src/rent.rs#L27-L38
• $allocatedStorage$ - depends on the logic of a called contract
• $computeUnitPrice$, $computedUnitLimit$ - is a Solana Priority Fee passed to Compute Budget Program

The crucial insight: Solana's priority fee (compute unit pricing) stands alone. It doesn't multiply with storage or execution costs. This independence is what Ethereum's model doesn’t capture.

‍

Neon's update

Neon’s solution is elegantly simple: move the Solana priority fee from gasPrice into gasLimit. Instead of trying to force Solana's square peg into Ethereum's round hole, we're adapting to work the way Solana naturally operates.

The new formula: what changes

Practically, we convert your intended CU-based priority fee into an equivalent number of gas units and add those units to gasLimit. The baseline gasPrice stays stable and reflects non-priority cost.

This mirrors Solana’s reality:

• gasPrice ~ baseline per-gas cost (execution/storage mapping)
• gasLimit ~ execution gas plus a block of gas that represents your priority tip

As a result, the $gasPrice$($maxFeePerGas$) doesn’t contain a priority fee:

$gasPrice = solPrice / neonPrice * (1 + operatorFee)$

What this fixes in practice

• Wallets estimate gasLimit, so including priority there makes the total closer to reality.
• Users see a stable gasPrice, without hidden “multiply everything by the tip” behavior.
• Under congestion, you adjust priority (CU price/limit), and Neon reflects that as an explicit buffer - not as a scary per-gas surge.

Gas model price comparisons

1. The simple option - no storage allocations.

• Old model
  • $gasLimit$ = 30’000
  • Actual $computeUnitPrice$ = 52’500
  • $SOL = \$100$
  • $NEON = \$0.1$
  • $operatorFee = 0.25$
  • $profitableGasPrice = 100/0.1 * 1.25 = 1'250\ GAlan$
  • $gasPrice = profitableGasPrice + solanaPriroityFee = 1’250 + 52’500 * 1’400’000 / 10^6 * 1’250 / 10’000 = 1’250 + 9'187,5 = 10437,5\ GAlan$
  • estimated $transactionCost = 10’437,5 * 30’000 = 0,313125\ NEON$
• New Model
  • Base transaction with $gasLimit$ = 30’000
  • Actual $computeUnitPrice$ = 52’500
  • $SOL = \$100$
  • $NEON = \$0.1$
  • $operatorFee = 0.25$
  • $profitableGasPrice = 100/0.1 * 1.25 = 1'250\ GAlan$
  • $gasLimit = 30’000 + 3 * 52'500 * 1'400'000 / 10^6 = 245'500$
  • $gasLimit (w/\ packed\ cuPrice) = 260'087$
  • estimated $transactionCost = 1'250 * 260’087 = 0.32510875\ NEON$

1. The option with storage allocations for $1’000’000\ lamports$

• Old model
  • $gasLimit$ = $1’030’000$
  • Actual $computeUnitPrice$ = $52’500$
  • $SOL = \$100$
  • $NEON = \$0.1$
  • $operatorFee = 0.25$
  • $profitableGasPrice = 100/0.1 * 1.25 = 1'250\ GAlan$
  • $gasPrice = profitableGasPrice + solanaPriroityFee = 1’250 + 52’500 * 1’400’000 / 10^6 * 1’250 / 5’000 = 1’250 + 9'187.5 = 10'437.5\ GAlan$
  • estimated $transactionCost = 10’437.5 * 1'030’000 = 10.750625\ NEON$
• New Model
  • Base transaction with $gasLimit$ = $1’030’000$
  • Actual $computeUnitPrice$ = $52’500$
  • $SOL = \$100$
  • $NEON = \$0.1$
  • $operatorFee = 0.25$
  • $profitableGasPrice = 100/0.1 * 1.25 = 1'250\ GAlan$
  • $gasLimit = 1'030’000 + 3 * 52'500 * 1'400'000 / 10^6 = 1'250'500$
  • $gasLimit (w/\ packed\ cuLimit) = 1'251'319$
  • estimated $transactionCost = 1’250 * 1'251'319 = 1.56414875\ NEON$

Protection Mechanisms

With great flexibility comes the need for safeguards. The new model includes built-in protections against potential misuse:

1. Packed information validation: priority fee parameters are encoded directly into gasLimit, allowing transparent verification
2. Operator limits: maximum compute unit prices are enforced to prevent excessive fee extraction
3. Transparent estimation: Neon Proxy can explain the components of a gas estimate, ensuring accountability

‍

Developer & user benefits

• Accurate fee estimation. Priority is modeled where wallets actually look - gasLimit - so quotes align with on-chain reality.
• Solana-native alignment. We treat CU price × CU limit as a dedicated priority component, not a per-gas multiplier.
• Better wallet/tooling behavior. With a stable gasPrice, EVM tooling (MetaMask, ethers, web3.js) behaves more predictably.
• Fewer stuck/overpriced txs. You pay for the priority you request - no silent “multiply everything by the tip.”
• Clearer mental model. Developers can dial priority separately from execution without wrestling wallet quirks.

‍

Get involved

Ready to experience the new gas model? Here's how to get started:

1. Test it in your wallet: Try the updated gas model on both Neon devnet and mainnet
2. Dive into more examples of gas cost calculations in Neon’s docs
3. Share your feedback and questions in our Discord community
4. Follow @NeonEVM on X for the latest announcements

‍