Web3 Gas Cost Hindsight: How to Compare L1, L2, and Solana

Gas is a workload measurement, not a durable dollar price. In a Web3 product, the cost users or sponsors pay depends on the executed program, transaction data, current fee markets, native-token price, fee sponsorship, and the network's active rules. A table of fixed USD prices or universal L1-to-L2 multipliers becomes stale quickly.

This article replaces aggregate percentages and chain-wide recommendations with a reproducible decision method. Use production-shaped transactions, current RPC estimates, official fee formulas, and explicit assumptions about settlement, finality, data availability, bridging, upgrades, custody, and operations.

Where does cost accrue?

On Ethereum, gas measures computational work. The paid fee is gas used multiplied by the applicable base and priority fee, and an execution that runs out of gas can revert state while still consuming the provided gas. A simple ETH transfer uses 21,000 gas, but token transfers and application calls execute contract code and vary by implementation and state. See the official Ethereum gas documentation.

• Deployment and upgrades. Contract creation stores bytecode and runs initialization. Proxy deployment, implementation changes, migrations, and verification add separate costs and risks.
• User writes. Transfers, mints, swaps, claims, approvals, account-abstraction validation, and application state changes consume network resources on every execution.
• Failed or replaced transactions. Included failures can still charge fees. Retries, nonce replacement, slippage, simulation mismatch, and sponsorship policy belong in the operating model.
• Data publication and settlement. Rollups commonly charge for both execution on the child chain and data or settlement-related resources on the parent chain.
• Off-chain services. RPC, indexing, relaying, paymasters, oracles, keepers, signing, observability, and support are not gas, but they belong in total cost.

Ordinary read-only RPC calls do not create an on-chain transaction, but providers may charge for API usage. A contract cannot make a free RPC read during execution: on-chain reads and storage access consume gas as part of the transaction.

Why a static chain fee table is misleading

Dollar estimates combine several moving inputs. At minimum, record the transaction or user operation, gas or compute units, calldata or compressed size, base fee, priority fee, parent-chain or blob fee, operator fee where applicable, sponsorship overhead, native-token price source, block or slot, timestamp, and success status. Re-run the same fixtures at several demand levels.

Base states that each transaction includes an L2 execution fee and an L1 security fee; the latter estimates publication to Ethereum. See the current Base fee documentation. OP Mainnet documents execution, L1 data, and, after applicable upgrades, operator-fee components in its transaction-fee guide.

Arbitrum documents a child-chain resource component and a parent-chain poster component derived from estimated compressed size and parent-chain pricing. See Arbitrum gas and fees. These formulas explain why an assertion such as “all EVM L2 transactions are 50 to 200 times cheaper” is not durable.

How should Polygon PoS and Solana be compared?

Polygon's documentation describes Polygon PoS as an EVM-compatible sidechain that periodically anchors state to Ethereum. Its EIP-1559 documentation explains base and priority fees, while its gas station exposes current estimates. Use the official Polygon PoS EIP-1559 guide and record the current gas token and network parameters. Do not treat Polygon PoS as interchangeable with an Ethereum rollup merely because both can offer lower transaction fees than Ethereum at a sampled time.

Solana uses a different execution and fee model. Its current documentation describes a per-signature base fee and an optional prioritization fee. The priority charge depends on the requested compute-unit limit, not actual compute consumed, so an unnecessarily high limit can waste funds. The documentation currently lists 5,000 lamports per signature, but that value is a dated network parameter to re-check before budgeting. See the official Solana fee structure.

Neither low sampled fees nor short block times alone establish application latency, finality, availability, censorship resistance, bridge safety, or operating cost. Test confirmation and recovery behavior under the commitment level and failure cases the product will actually use.

What does Wavect's project history establish?

Wavect has delivered products across EVM and Solana environments, but those engagements are not a normalized benchmark dataset. Different contracts, transaction frequencies, token prices, fee sponsorship, market periods, and client requirements make aggregate gas percentages unsuitable as a general rule.

• Scramble Pay provides context for a multi-chain payment product.
• Quivr provides context for a Solana-based consumer product.
• Account abstraction work illustrates sponsored and smart-account flows in EVM environments.
• Lightbridge illustrates cross-chain messaging requirements.
• MetaMask Snap work illustrates wallet-extension integration.

Use these as engagement context, not evidence that one network is cheapest or correct for the next product.

"Chain selection is a product and risk decision. Measure the real workload, then compare the settlement, finality, data, custody, upgrade, and operating assumptions that come with each route."

How should a founder compare networks?

1. Define the user and settlement outcome. Specify who submits, signs, sponsors, receives, disputes, or recovers each action and where users and assets already exist.
2. Create production-shaped fixtures. Include common, worst-case, failed, batched, sponsored, account-creation, bridge, DeFi, NFT, and upgrade paths. Record contract versions and state assumptions.
3. Estimate native units first. Use current RPC simulation and official network formulas. Keep gas, bytes, compute units, signatures, and storage or account funding separate from fiat conversion.
4. Sample over time. Capture block or slot, timestamp, fee parameters, token-price source, and percentile policy. A single quiet-period snapshot is not a budget.
5. Model total lifecycle cost. Add RPC, indexing, relaying, sponsorship, bridges, monitoring, incident response, upgrades, audits, liquidity, reconciliation, and user support.
6. Review security and control assumptions. Compare finality, data availability, sequencing, proof or checkpoint design, admin keys, pauses, upgrade path, bridge exposure, and exit path.
7. Choose a primary route deliberately. Multi-chain support can expand reach but also multiplies contracts, integrations, liquidity, monitoring, and failure modes. Add routes only when the product case justifies them.

If dedicated blockspace is under consideration, compare native and based rollup architecture. Sequencing, verification, data availability, interoperability, governance, and operations are separate choices.

What should a dated benchmark include?

A useful benchmark is reproducible. Publish the review date, network and chain ID, transaction hashes or executable fixtures, exact contracts and state, RPC method, gas or compute estimate, L1-data calculation, fee parameters, native-token and fiat-price sources, inclusion or confirmation rule, and whether account creation, bridge, failed transaction, sponsorship, or service costs are included.

Do not label a wallet estimate as a guaranteed fee or extrapolate one transfer to an NFT mint, DeFi call, or account-abstraction user operation. For sponsored flows, show both the user's displayed price and the sponsor's actual network and service cost.

Is Ethereum mainnet ever the right first deployment?

There is no universal answer. Ethereum mainnet may be appropriate when users, assets, protocols, settlement requirements, or governance already require it. An L2, sidechain, or Solana may better fit another workload. Low fees do not compensate for missing users, liquidity, integration support, security requirements, or recovery options, and higher fees do not by themselves prove stronger application-level security.