Development of an Ethereum Gas Price Prediction System

A user wants to send a transaction but doesn't know how much it will cost in 30 minutes or 2 hours. The simple answer 'check the current baseFee' doesn't work — it changes every 12 seconds and is useless over longer horizons. We develop gas price prediction systems turnkey for DeFi projects, using ML and on-chain analysis. Our experience: 5+ years, 10+ projects. The system collects historical data over several months, builds a model based on XGBoost or Prophet, and delivers predictions via REST API. We provide documentation, training, and support after deployment. We guarantee forecast accuracy and integration into your stack. Get a consultation on choosing the right prediction model for your project.

How gas pricing works after EIP-1559?

The gas mechanism became two-component:

• baseFee — algorithmically determined base fee, permanently burned. Changes by a maximum of ±12.5% from block to block depending on whether the previous block was filled more or less than 50% (target_gas_used = block_gas_limit / 2).
• maxPriorityFee (tip) — tip to the validator. The user sets it themselves; the market determines the minimum acceptable level.
• maxFeePerGas — maximum the user is willing to pay. Actually paid is baseFee + min(tip, maxFeePerGas - baseFee).

The formula for baseFee change:

baseFee_new = baseFee_old * (1 + 0.125 * (gas_used - target_gas) / target_gas) 

This is key: baseFee is deterministically computed from on-chain data. If you know the gas utilization of each block, you can accurately reconstruct historical baseFee and build a model. More details in the EIP-1559 specification.

What data is needed for forecasting?

Minimum data set for each block:

interface BlockGasData { blockNumber: bigint; timestamp: number; baseFeePerGas: bigint; gasUsed: bigint; gasLimit: bigint; utilizationRate: number; // gasUsed / gasLimit // from transactions in the block: medianPriorityFee: bigint; p25PriorityFee: bigint; p75PriorityFee: bigint; p95PriorityFee: bigint; txCount: number; mempoolSizeAtBlock?: number; // if mempool data is available } 

Step-by-step data collection guide

1. Connect to an Ethereum archive node (Alchemy/QuickNode Archive) or use public datasets (Dune Analytics, BigQuery).
2. Set up a WebSocket to newHeads and for each block additionally request eth_getBlockByNumber with the flag true to get transactions.
3. Collect data for at least 3-6 months — enough to capture different market conditions (bull/bear, NFT-mints).
4. Optionally: subscribe to the mempool via Mempool.space API or Blocknative for more accurate short-term forecast.

How does the short-term forecast (1-10 blocks, ~12-120 seconds) work?

Deterministic model: the next baseFee is computed exactly from the current one plus current utilization. For 5-10 blocks, we can apply a Markov chain based on historical utilization patterns.

def predict_next_basefee(current_basefee: int, utilization: float) -> int: change = 0.125 * (utilization - 0.5) # -0.0625 to +0.0625 return int(current_basefee * (1 + change)) 

This is deterministic for the next block. For a horizon of 5-10 blocks, we use Monte Carlo simulation with utilization distribution from historical data.

How does the medium-term forecast (10 min - 2 hours) work?

Here determinism ends, ML begins. XGBoost / LightGBM with time features work well for tabular data:

• Features: current baseFee, rolling average over 10/30/60 blocks, time of day (sin/cos encoding), day of week, pending tx count in mempool, recent utilization trend
• Target: baseFee after N blocks

LSTM / Transformer — better capture long-term patterns but are more complex to maintain. For a practical system, gradient boosting often suffices.

Quality metric: not RMSE but practical — what % of the time a user who set the recommended gas got into the next block vs. overpaid vs. got stuck.

On one DeFi project, we reduced failed transactions by 40% and saved users 25% on gas fees by integrating medium-term prediction.

How does the long-term forecast (2-48 hours) work?

At such horizons, time seasonality dominates. Prophet (Facebook) handles daily and weekly patterns well:

from prophet import Prophet model = Prophet( daily_seasonality=True, weekly_seasonality=True, changepoint_prior_scale=0.05 ) model.fit(df[["ds", "y"]]) # ds=timestamp, y=basefee_gwei forecast = model.predict(future_df) 

Practical accuracy on a 24h horizon: ±30-50% of the median value. Enough to give advice like “gas will be significantly lower tomorrow morning UTC”. More details at Prophet.

Table 1: Comparison of prediction models

Table 2: Comparison of data sources

Recommendations for specific scenarios

The system should convert forecasts into actionable recommendations:

interface GasRecommendation { scenario: "fast" | "standard" | "economy"; maxFeePerGas: bigint; // in wei maxPriorityFee: bigint; // in wei estimatedInclusionTime: number; // seconds confidence: number; // 0-1 usdCostFor21000Gas: number; // for a simple transfer } 

Economy scenario: “if not in a hurry — wait until UTC 04:00, gasWei will be ~40% of current”. Use historical percentiles for hourly segments.

API and integration

Prediction results are provided via REST API:

GET /v1/gas/current — current prices + short-term forecast GET /v1/gas/forecast?hours=24 — forecast for a period GET /v1/gas/recommend?speed=economy — recommendation for a scenario WS /v1/gas/stream — updates every block 

We cache results: current data — TTL 12 sec (one block), short-term forecast — TTL 1 min, long-term — TTL 15 min. Redis.

What is included in the work

• Architecture and API documentation (Swagger/OpenAPI)
• Access to forecast accuracy monitoring dashboard (Grafana)
• Training of the client’s team on using the system
• Technical support for 1 month after deployment
• Integration with existing infrastructure (cloud, CI/CD)

Realistic development timeline for a system with ML forecasting and API: 8-12 weeks. Cost is calculated individually. Contact us to discuss your project — we will prepare an estimate within 2 days.