Turnkey Gas Tracker Development: Blockchain Gas Monitoring System

Developing a gas tracker seems straightforward at first glance: just fetch eth_gasPrice and display it. In practice, DeFi protocols lose up to 30% on fees due to poor timing or ignoring EIP-1559 components. We build not a dashboard but an engineering system: we collect baseFee and priorityFee per block, store them in TimescaleDB, predict 5–10 blocks ahead, and serve via REST API with WebSocket. Over 5 years, we've built gas trackers for 30+ projects, including major DEXs and research groups. Here's what's under the hood and what you get turnkey.

How a Gas Tracker Works Under the Hood?

EIP-1559: The Core Formula

After EIP-1559 (London hard fork), gas price consists of two parts:

• baseFeePerGas — the base fee, burned. Determined by protocol: if a block is >50% full, base fee increases by 12.5%; if <50%, it decreases. Predictable 1–2 blocks ahead.
• maxPriorityFeePerGas (tip) — tip to miner/validator. Market-driven: you compete for block inclusion.

Real transaction cost: min(maxFeePerGas, baseFeePerGas + priorityFee) * gasUsed. A gas tracker must track both components separately, not just the final price.

Data Collection: Collector and Storage

The primary source is eth_feeHistory. It returns baseFee, gasUsedRatio, and percentile statistics of priorityFee over a block range. We use viem:

import { createPublicClient, http } from 'viem' import { mainnet } from 'viem/chains' const client = createPublicClient({ chain: mainnet, transport: http(RPC_URL) }) const feeHistory = await client.getFeeHistory({ blockCount: 100, rewardPercentiles: [25, 50, 75, 95], }) // feeHistory.baseFeePerGas: BigInt[] // feeHistory.reward: BigInt[][] // feeHistory.gasUsedRatio: number[] (0..1) 

eth_gasPrice gives the current price at request time. Mempool data (pending transactions) is used for real-time competition analysis.

We store data in TimescaleDB, ideal for time-series:

CREATE TABLE gas_stats ( time TIMESTAMPTZ NOT NULL, block_number BIGINT NOT NULL, base_fee_gwei NUMERIC(20, 9) NOT NULL, tip_slow NUMERIC(20, 9), tip_standard NUMERIC(20, 9), tip_fast NUMERIC(20, 9), tip_instant NUMERIC(20, 9), gas_used_ratio NUMERIC(5, 4), network VARCHAR(50) NOT NULL DEFAULT 'ethereum' ); SELECT create_hypertable('gas_stats', 'time'); 

Retention policy: per-block data for 7 days, hourly aggregates for 1 year, daily aggregates indefinitely.

What’s Included in a Turnkey Gas Tracker?

We also guarantee data accuracy: we write tests for the collector, monitor via Tenderly, and use Slither for smart contract verification (if contracts are part of the system).

What Types of Data Does a Gas Tracker Collect?

Beyond basic components, we collect per-block metrics: number of transactions, average and median priority fees by percentile, block fullness (gasUsedRatio). This allows not only real-time recommendations but also historical distributions — for example, the probability of being included in a block with a given tip. For multichain systems, L1 data fee (for L2s) and bridge costs are also logged. All data goes into TimescaleDB with automatic aggregation.

How We Predict Gas?

Simply displaying the current baseFee is insufficient. We need to estimate: “How much should I set to be included in the next block with X% probability?”

The next baseFee can be predicted accurately:

function predictNextBaseFee(currentBaseFee: bigint, gasUsedRatio: number): bigint { const targetRatio = 0.5 const maxChangeDenominator = 8n const delta = gasUsedRatio - targetRatio const change = (currentBaseFee * BigInt(Math.round(delta * 1000))) / (maxChangeDenominator * 1000n) return currentBaseFee + change } 

Priority fee is market-driven and harder to predict. We use EMA over the last N blocks:

def calculate_priority_fee_estimate( recent_tips: list[float], alpha: float = 0.3, ) -> float: ema = recent_tips[0] for tip in recent_tips[1:]: ema = alpha * tip + (1 - alpha) * ema return ema 

We also account for time patterns: gas is cheaper during UTC 02:00–08:00. We show an “optimal window” for non-urgent transactions.

Why Choose TimescaleDB for Storage?

TimescaleDB is a PostgreSQL extension for time-series. It automatically partitions by time, creates continuous aggregates, and allows fast window queries. Alternatives (InfluxDB, ClickHouse) require separate stacks; TimescaleDB integrates into a familiar relational database — less overhead.

Storage Comparison

API and Integration

REST endpoints:

• GET /api/gas/current — current recommendations {slow, standard, fast, instant}
• GET /api/gas/history?period=24h — aggregated history
• GET /api/gas/predict?blocks=5 — forecast for N blocks
• GET /api/gas/networks — data by network

WebSocket delivers updates on each new block without polling. Multichain support: a separate collector per network; for L2s (Arbitrum, Optimism, Base), we account for two-component gas.

Integration process:

1. Audit — analyze load and required networks.
2. Architecture — select RPC providers, database schema.
3. Collector — deploy in Docker, set up monitoring.
4. API — generate OpenAPI documentation.
5. Testing — cross-check data with Etherscan for one week.
6. Deployment — to your Kubernetes cluster or bare-metal.

Timelines and Cost

Basic version (Ethereum mainnet, history + current recommendations) — 5–8 days. Multichain with predictions and detailed analytics — 2–3 weeks. Cost is calculated individually based on your needs — contact us for a project estimate. Get in touch now and receive an engineer consultation on gas tracker architecture. Order development — we'll start with analyzing your data.