fix(backend): widen TPS window to ~3.33 blocks for 300ms block time

[dak-agent]

Motivation

The backend TPS metric (TPSTracker::get_tps in backend/src/lib/server.rs) hardcoded an assumption that average block time is ~400ms. It approximated one second of throughput by summing 2.5 blocks of transaction counts (2.5 × 400ms = 1s).

With the block time change from 400ms → 300ms, a 2.5-block window now covers only ~750ms, so reported TPS is ~25% too low (750ms / 1000ms).

Modifications

• Added a fourth tracked block (block_4_txs) to TPSTracker.
• get_tps() now sums the three most recent full blocks plus one third of the block before them — an effective window of ~3.33 blocks (3.33 × 300ms ≈ 1s).
• Updated the doc comment to reflect the 300ms assumption.

Result

TPS again approximates one second of throughput at the new 300ms block time. No other part of the app needed changes — the frontend (block execution times, timeline, block-state tracker, transaction-volume chart) is derived entirely from live execution-event data and normalizes dynamically.

Greptile Summary

This PR adjusts the backend TPS estimate for a 300 ms block cadence. The main changes are:

• Adds a fourth completed-block counter to TPSTracker.
• Uses three full blocks plus one third of the preceding block.
• Updates the TPS documentation to describe the new window.

Confidence Score: 5/5

This looks safe to merge.

• No blocking issues found in the changed code.

Important Files Changed

Filename	Overview
backend/src/lib/server.rs	Extends TPS history and updates its rotation and weighting for the shorter block cadence.

_{Reviews (1): Last reviewed commit: "fix(backend): widen TPS window to ~3.33 ..." | Re-trigger Greptile}

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
monode	Ready	Preview, Comment	Jul 23, 2026 4:30pm