StitchBot
A real-time DAG-health monitor for Kaspa. It watches the BlockDAG live — tip width, merge latency, orphaned work, and headroom to the merge-depth cliff — and turns the network's behaviour into evidence. Built as an instrument for the road to 100 BPS.
Open source · Rust + a zero-dependency dashboard · self-host against your node or the public node network.
What it measures
Every metric is observational — read straight off a node over RPC, never a consensus signal.
Tip width & fracture
How many parallel tips the DAG carries, and when high-blue tips stay unordered — the topological-stress signal.
Merge latency
For every block, how many blue-score rounds it waits before a chain block merges it — the direct test of the "log rounds" convergence conjecture.
Orphan / red rate
Share of mined work that falls out of the blue set — the real efficiency cost, computed from ghostdag mergeset data.
Merge-depth headroom
Distance to the hard cliff (bps × 3600 rounds) past which a block is orphaned forever. The sharpest high-BPS risk metric.
Confirmation coupling
Whether merge lag feeds through into confirmation time — measured from block production, correlated live.
Live DAG canvas
The recent DAG flowing by blue score, tips glowing, orphaned work tinted — the network, as it happens.
What the data says — so far
Run live against Kaspa mainnet at ~10 BPS, StitchBot doesn't just draw pretty graphs — it settles claims. The headline: at today's block rate, the DAG is healthy in a way you can measure, not assume.
Tip spikes are absorbed with zero waste
Bursts up to the 16-parent merge cap are fully merged — orphan rate stays at 0.00%. GHOSTDAG absorbs the width exactly as designed.
Enormous merge-depth headroom
The worst straggler used ~0.2% of the merge-depth budget. Blocks have effectively an hour (in rounds) of slack before the permanent-orphan cliff.
Merge lag does not delay finality
Correlation between merge lag and confirmation time is ≈ 0 — lag is negligible against the confirmation depth. (An early version reported a spurious −0.78; the tool caught and fixed its own measurement bug.)
"Fractures" are benign
Multi-tip events self-heal in ≤2 seconds with no orphaned work — what the whitepaper frames as fragility is, at 10 BPS, routine and cheap.
The 100 BPS question
The merge cap is hard-frozen at 16 — and the Kaspa consensus source says why: as block rate climbs past 10 BPS, blocks will reference fewer parents than there are tips, and merging falls back on randomness between peers, converging (it's conjectured) after a logarithmic number of rounds.
That conjecture is unproven, and the source names the resolution: raise GHOSTDAG K, or move to the parameterless DAGKnight. Either way, 100 BPS is the regime where topological efficiency stops being free — and nobody is independently instrumenting it.
StitchBot is that instrument. Point it at a high-BPS testnet and the merge-latency, merge-depth-headroom, and orphan-rate metrics answer the conjecture empirically — before mainnet gets there.
// rusty-kaspa · config/bps.rs“As BPS might grow beyond 10 … blocks will reference less parents than the average number of DAG tips … relying on randomness … We conjecture that with high probability every block will be merged after a log number of rounds … or moving to the parameterless DAGKNIGHT.”
Watch the DAG for yourself
One binary. Point it at your node or the public node network, open the dashboard, and read the network live.
Research prototype · metrics are observational, not a consensus signal · not affiliated with the Kaspa core team.