Incident response is a discipline you either write down before the incident or improvise during it. EmpoorioChain wrote it down after its first few. This post covers the playbooks and, in the ecosystem's habit of stating what went wrong, the incidents.
The playbooks
INCIDENT_RESPONSE_PLAYBOOKS.md defines procedures for:
Validator compromise. Stop the service. Remove the validator from the active set when possible. Rotate session keys. Move funds controlled by potentially exposed keys. Preserve logs. Redeploy from clean infrastructure. Every external operator counted as independent must accept this sequence.
Finality stall. Alert on empoorio_finalized_head_age_seconds; identify which validator is silent; on a two-validator network this is a page, not a ticket. Aura continues authoring; clients show included without finalized — the three-state model is the user-facing part of this playbook.
Bad runtime upgrade. Every upgrade manifest carries a rollback plan. The emergency class allows a 1,200-block timelock (~2 hours) and requires a post-mortem. try-runtime against a snapshot before any storage migration is the preventive half.
Key exposure. Rotate on reinstall, shared credentials, a possibly leaked backup, unknown sessions. Seeds never in shell history, documents or chat.
Public RPC abuse. The public nodes run fail2ban with a rate rule (~10 requests/s per IP, one-hour ban). Legitimate heavy users run their own node.
The incidents
July 2026 — cryptominer. A Monero miner (dhpcd) was found running on the Ailoos server and removed. Its hash is kept so its return would be detected. Server reinstalled; the reinstall procedure is documented.
August 2026 — leaked backend key. A Firebase Admin service-account key was found committed in the Empoorio Manager app repository. Revoked; the functionality moved to server-side functions that authenticate the caller. The four commerce apps' keystore password files were also found world-readable (mode 644) on the build machine and tightened to 600.
August 2026 — wallet audit. Aephoron's audit found a remote-code-execution path in its updater and a wallet store decryptable without a password. Both fixed before any store release.
September 2026 — rootkit. An active rootkit was found on a production server during the Ailoos audit. Handled under the compromise playbook.
September 2026 — the non-incident. The discovery that the testnet had never carried a signed transaction was not a security incident, but it was handled like one: root cause written up byte by byte, five misattributed symptoms reconciled, fix verified against the live chain, lesson turned into a rule.
What is not on this list
A loss of user funds. A wallet exploit affecting users. A chain halt. The testnet has two validators and zero fault tolerance, so a halt is possible and would be reported here.
Why publish incidents
The previous version of this page reported another ecosystem's wallet breach. This ecosystem's own record is smaller and entirely its own: two server compromises, one leaked key, several pre-release audit findings, all fixed, all dated. A project that publishes that list is telling you how it will behave when the next one happens.
Based on INCIDENT_RESPONSE_PLAYBOOKS.md, VALIDATOR_GUIDE.md, the server incident records (2026-07-22, 2026-09-05) and the app security fixes (2026-08).