What it is today. A Rust service that connects to a Kaspa node over gRPC, tracks the recent BlockDAG, and serves a live dashboard of DAG health: tip width, block rate, blue-score spread across tips, a stress index, and an animated DAG view where blocks flow left→right by blue score and current tips glow. Runs against live mainnet or testnet nodes.
cargo build --release
./target/release/stitchbot # uses config.toml
KASPA_RPC=192.168.4.33:16110 ./target/release/stitchbot # or point at any node via env
# then open http://localhost:8899/config.toml controls the node endpoint, dashboard port, poll cadence, DAG window, and fracture
thresholds. KASPA_RPC=host:port overrides the endpoint without editing the file.
Honesty about scope. This is the observability half of the original StitchBot concept, and it
works. The incentive half described below — a signed p2p side-channel that pays miners to reference
specific tips — is not implemented and is not viable as originally specified: in Kaspa the node,
not the miner, selects a block's parents (calc_block_parents), the parent set already merges all live
tips up to max_block_parents, and a custom p2p message does not traverse the real consensus network.
The only genuine lever on parent selection is node-side policy. The metrics here are observational,
not a consensus signal. The original design thesis is preserved below for reference.
StitchBot directly attacks the single biggest practical weakness of high-throughput BlockDAGs like Kaspa: topological fragility under load. It does this with an extremely lightweight, incentive-compatible mechanism that is provably effective, economically rational, and future-proof across all known Kaspa consensus upgrades (GHOSTDAG → DAGKnight). The core problem being topological high throughput stress fractures. Security and liveliness in a blockDag are governed by bluescore convergence, under a so-called poisson process. A fracture is two high blue score blocks that are mutually within eachothers anticone (not yet ordered). The probability of deep reorgs grows with time at an exponential rate with the width (the number of parallel high blue scoring tips) and duration of the fracture. [Sompolinsky, Zohar, Wyborsky: “The security threshold degrades gracefully with the degree of parallelism… the higher the honest throughput relative to the adversary, the larger the tolerated parallelism.”] Fractures waste honest work and create SPV deception vectors, which will ultimately impact the so-called normie market, truly a disaster.
Stitchbot detects a fracturing of the dag (an anomaly of high-betweenness nodes with large blue delta scores), broadcasts a signed p2p request to reference both tips for a modest reward, incentivizing timely reconvergence of the dag. Note, this is not a consensus change per say, but rather an economic consideration.
From ghostDag theorem 1 (security against balance attacks): "The probability that an attacker can create a violating chain of length ℓ is bounded by exp(−ℓ² / (2 · λ · T)) where λ is honest throughput and T is network delay." Fractures increase effective T because honest blocks are spread across parallel tips. Miners are rational profit maximizers. A miner sees the cost of adding an extra parent {~0 ( bandwidth + extra header hash ) & the modest reward upon inclusion }. Every miner who recieves the p2p request will include both parents if the reward is greater than the cost of missing it. Miners already build on multiple parents aggressively, so why not prioritize the right ones at the right times.
A wider dag induces more sybil/partition attack surface areas, a relatively narrow enough dag means fewer paths leading to reduced SPV attack effectivity and indeed the dagKnight protocol is concerned with this problem. Let W = average tip width, D = average fracture duration. Reorg probability ≈ exp(−c · blue_score / (W · D)) for some constant c. StitchBot reduces W
dag stability
A full P2P DAG healer for Kaspa
Detects topological fractures → broadcasts stitch requests → pays miners to heal the network.
Zero on-chain footprint. Sub-second healing. Secure by default.
λ = honest block propagation rate (blocks/sec); μ = adversarial block rate (we assume μ ≤ 0.5λ for security); Δ = network delay bound (Kaspa ≈ 0.9 s in practice); W(t) = number of live tips at time t; D_f = duration of a fracture (time two high-blue blocks remain unordered); B(t) = blue score growth rate of the selected chain ≈ λ · (1 – orphan_rate); P_reorg(ℓ) = probability of an ℓ-block reorg;
-
Max Tips (W_max) Without StitchBot Tips grow as a branching random walk with birth rate λ and death rate λ / Δ. Steady-state expected tips in high-load regime (λΔ >> 1): W ≈ λΔ + √(λΔ) (from King–Altman approximation for birth–death processes in DAGs) Kaspa at 100 BPS → λ = 100, Δ ≈ 0.9 s → W ≈ 90 + 30 = 120 tips possible in bursts Real mainnet peaks ~45–55 → matches the model. With StitchBot Every fracture with blue_delta ≥ δ triggers a stitch that removes at least one tip within τ ≈ 1.5–3 s (observed P2P + miner response). StitchBot imposes an extra death rate on tips: γ_stitch ≈ (average fractures per second) × (probability miner responds) ≈ (λ²Δ² / 2)⁻¹ × 0.95 ≈ 0.33–0.66 tip-deaths/sec at 100 BPS New steady-state: W_stitch ≈ λΔ / (1 + γ_stitch · τ) → W reduced by factor 3–5× Observed: 45–55 → 10–14 tips → reduction 71–78 %
-
Orphan Rate An orphan occurs when a block’s parent set is no longer in the selected chain (i.e., its blue score falls behind). From the GHOSTDAG analysis (Theorem 3, 2021): Orphan probability for a block ≈ 1 – exp(−W · Δ / T_blue) where T_blue ≈ 1 / (λ – μ) is blue-score growth. When W is large → orphan rate explodes. Quantitative derivation d(orphan_rate)/dW > 0 and convex ↑ Using mainnet calibration at W = 12 → 3.8 % orphans At W = 45 → 7.2–8.1 % At W = 14 (StitchBot) → 2.0–2.2 % (observed 2.1 %) Proof of 45 % reduction Because orphan_rate ≈ 1 – exp(−c / W), reducing W by factor 3.5 moves us from the steep part of the curve to the flat part → disproportional drop in orphans.
-
Max Reorg Depth From GHOSTDAG security theorem (Sompolinsky et al., 2021): P(reorg ≥ ℓ) ≤ exp(−ℓ² / (2 · λ · T_convergence)) where T_convergence ≈ D_f + Δ is the time for honest majority to order conflicting blocks. D_f (fracture duration) is the dominant term under load. Without StitchBot: D_f ≈ 8–40 s (observed during bursts) With StitchBot: D_f ≤ τ_stitch ≈ 2–3 s (because a stitch block merges the tips) → T_convergence drops by factor 5–15× Therefore the exponent increases by 25–225× → reorg probability drops exponentially. Observed:
Without: deepest reorg in 2025 = 14 blocks (rare) With StitchBot simulation on same data = 6 blocks maximum Probability of ≥10-block reorg drops from ~10⁻⁴ to <10⁻⁹
- Effective Finality (time until P(reorg) < 10⁻⁶) Finality time τ_fin is the time until blue-score difference exceeds the security threshold: τ_fin ≈ (ℓ_crit) / B(t) where ℓ_crit ≈ √(2 · λ · T_convergence · ln(10⁶)) Because StitchBot reduces both:
T_convergence by ~10× W → orphan_rate → B(t) increases by ~7 %
→ ℓ_crit drops and B(t) rises → τ_fin drops quadratically.
Unified Mathematical Summary (One Equation) Define the fracture load Φ = λ² · Δ · D_f (StitchBot attacks every term in Φ)
# 1. Clone
git clone https://github.com/ezrasisk/stitchbot.git
cd stitchbot
# 2. Build
cargo build --release
# 3. Run bot
./target/release/stitchbot