Verdict: 14 days, 5,306 attempts, 0 wins ever, −574K WPLS. Strategy never had edge. Currently shelved; recommend permanent decommission. Active 2026-04-07 → 2026-04-21. The thesis (EmpSeal aggregator as a price-discrepancy oracle) was empirically falsified by the operating data: 4,257 sim-fails (80%) + 1,049 thin (20%) = zero net-positive trades across the entire lifespan.

Failure mode #1 — the oracle was always slower than the venue. EmpSeal's queryAdapter() reads from the same pools we'd execute against, with at least one round-trip of latency. By the time the bot consumes the quote, parses it, sims, and submits, the spread either (a) has been claimed by a competitor with direct pool subscriptions or (b) drifted in normal pool state. Top revert reasons confirm the pattern: 2,265 "call failed" + 1,988 InsufficientProfit reverts — the contract's minProfit guard rejecting because actual output dropped below the encoded floor between sim and execution. Same disease as Monad cross-agg's "Return amount is not enough", same fix-class: only solvable by being closer to the venue than the oracle is.

Failure mode #2 — the addressable universe collapsed to zero. Final 9 scans (2026-04-21 14:51–14:53) show signals=0 / sim=0/0 / blacklisted=9. By end-of-life the bot was scanning 17 tokens × 10 adapters per cycle with 9 tokens already self-blacklisted, and producing zero signals for 5 consecutive cycles. The strategy effectively ran out of pairs it was willing to attempt before it ran out of capital.

Failure mode #3 — gas burned without ROI. 714,794 PLS lifetime gas spent (~$5–6 at PLS prices over the period) for zero return. That gas was paid on simulation overhead + the few sims that reached on-chain revert. Every additional day the bot ran was strictly negative.

Fixable? No — not as encoded. The decommission verdict stands. Replacing EmpSeal-as-oracle with mempool intel is a different bot (use backrun-exec / tri-backrun, which already do that). Tightening minOut, smaller bet sizes, more adapters — all bandaids on a strategy where the input signal is structurally too slow. The lesson kept from this bot: whenever a bot's signal source isn't the execution venue itself, you have a sim-vs-live gap that scales with latency. The bot itself, no. See pulsechain/notes/pulse-empseal-postmortem.md for the full forensic.

---

## Theoretical resurrection paths — and why none are "resurrection"

Every plausible path either turns it into a different bot, depends on something outside our control, or reduces it to a passive logger.

1. Rewire signal source: polling → mempool + pool Swap events. The only path with a realistic edge. But it's a complete rewrite — different daemon, different code, different state machine. EmpSeal contracts get used only as a fallback execution route. That's backrun-exec / tri-backrun v2, not empseal v2.

2. Repurpose EmpSeal's 10-adapter queryAdapter as INTEL, not as a TRIGGER. Run a stripped-down empseal cycle as a price-snapshot service: every cycle writes JSON of "cross-DEX gaps detected." Feed that into tri-backrun so when mempool sees a victim trade on token X, it already knows the current cross-DEX gap before pricing the arb. Genuinely useful and the lowest-cost way to recover value from the codebase. ~1 day of work. Not resurrection — empseal becomes a library, not a bot. This is the recommended salvage path.

3. Private mempool / Flashbots-style bundles on PulseChain. Would close the sim→land latency gap by atomically including the trigger and the arb. Doesn't exist on PulseChain today. If pulse-sentinel adds bundle submission (it has the relay infrastructure), revisit. Not actionable now.

4. Market structure shift — competition collapses. Wins would resume only if we're the only bot left running this surface. Counterfactual; not a strategy.

5. Different output thesis: empseal-detected spreads → momentum signal, not arb. "When 9X price diverges from PulseX V2 by >X bps, token Y is about to move." Feed into a directional bot. Untested hypothesis — would need 30+ days of backtest data; the existing trade log doesn't have the right shape (logs sim_fail / thin, not "did the token move in the next 30s").

Recommendation: Path 2 (intel-not-trigger). Path 1 is the "right" rewrite but a week of work for unproven uplift over tri-backrun, which already does the mempool-trigger thing. Paths 3–5 are theoretical. Don't restart the daemon. If we want to recover value: extract queryAdapter calling code into lib/empseal-quoter.js and let tri-backrun consume it. The daemon stays decommissioned.

Decommission status: PERMANENT as of 2026-05-19. The bot's place in the fleet is the Decommissioned row of the Bot Fleet Summary, not the active rotation.