Bot Titles
PLS-MEM-BACKRUN-V1Performance So Far
PLS-MEM-BACKRUN-V1Recent Fire Attempts
PLS-MEM-BACKRUN-V1Token Reverters (24h)
PLS-MEM-BACKRUN-V1Biggest Block
PLS-MEM-BACKRUN-V1Status 2026-05-25 (verified via tmux): PAUSED — backrun-exec not running. Snapshot below from 2026-05-20, when it was last live but idle.
Fleet status 2026-05-20: RUNNING · IDLE — 0 fires, 0 sims, 0 events in last 24h. Sentinel WS feed alive (13h+ uptime). Bot heartbeats but the mempool isn't producing qualified victim txs above the size+net floor it's gated on.
The dominant block: threshold/signal mismatch. The bot waits for a pending swap tx that, after we backrun the same pair in the opposite direction, nets > MIN_NET_WPLS. Today's mempool flow has many small-victim txs (<25K WPLS) but few large enough to leave a backrun profit after gas. Two interpretations:
1. Threshold is too high. Lower MIN_NET_WPLS gate to test whether smaller backruns are profitable in practice (currently the gate may be set assuming gas cost / inclusion premium that doesn't actually apply on the sentinel-routed direct broadcast path).
2. Mempool truly is starved. Other backrun bots are first-mover advantaged; by the time pulse-sentinel sees the victim, the candidate spread is already filled by competing bots that subscribe to the same sentinel feed (or run their own).
To distinguish (1) vs (2): drop net-floor to 50% of current and observe for 48h. If sim-attempts go up but actual fires don't land, that's (2) — competitor congestion. If fires land but net is below the original threshold, recalibrate the threshold downward. Either way you learn something cheap.
Different signal source from PLS-TRI-ARB-V1 (2-leg vs 3-leg) so this is a diversification slot, not a duplicate. Keeping for now.
Fantasy
PLS-MEM-BACKRUN-V1If we had some way to instantly remove this bot's biggest constraint — capital, latency, signal coverage, or counterparty risk — what would the world look like? (Pending creative assessment.)
Suggestions for Improvement
PLS-MEM-BACKRUN-V1- 01HIGHLower MIN_NET_WPLS gate by 50% for 48h and observe. Bot has 0 fires in 24h — either threshold is set too high for current mempool flow or competitor density is eating opportunities. Lowering the floor cheaply distinguishes the two cases. If sim-attempts go up but no actual fires land = competitor congestion; if fires land below threshold = recalibrate.
- 02HIGHStamp pulse-sentinel-receive-ts vs victim-confirm-ts on each scan. If sentinel sees the victim AFTER it lands on chain (post-mine), our backrun is too late by definition. If sentinel sees it pre-mine, measure the propagation gap — anything >500ms gives competitor backrun bots a window.
Conclusion
PLS-MEM-BACKRUN-V1Status 2026-05-25 (verified): PAUSED — backrun-exec tmux not running.
Verdict: keeper slot for diversification; signal-starved in current mempool regime. Mempool backrun on PulseChain. At its last live snapshot it logged 0 fires + 0 sim events in 24h despite the sentinel WS being alive 13h+. Either mempool flow has no qualified victims today OR threshold is set too high relative to actual sustainable net.
Fixable? Probably, two cheap experiments: (1) drop MIN_NET_WPLS by 50% for 48h and watch what happens to sim-attempts vs fires (distinguishes "no opps" from "competitor congestion"); (2) stamp sentinel-receive-ts vs victim-confirm-ts to measure if we're seeing victims BEFORE or AFTER they land (latter = lost race by definition).
Place in fleet: keeper #7 (PulseChain diversification). Different signal mechanism from PLS-TRI-ARB-V1 (2-leg vs 3-leg) so this isn't a duplicate. Cheap to keep running; gas burn is near-zero when 0 fires. If neither experiment produces fires within a week, demote to PAUSED — the surface may be genuinely closed by faster bots.