Tezos Emergency Alert System and Critical Threat Coordination

Critical threat notifications are broadcast through designated off-chain channels to core developers, bakers, and exchanges

Bakers, exchanges, custodians, wallet providers, infrastructure operators

Verify your team is subscribed to the canonical alert channels and that contact lists are current

Alerts include cryptographic signatures or other authenticity proofs to prevent social-engineering attacks during emergencies

All recipients acting on alert instructions

Confirm your operational playbook requires signature verification before executing emergency procedures

Core developers and key ecosystem participants coordinate to assess threat severity and decide whether an emergency upgrade is required

Governance delegates, large bakers, exchange security teams

Map the decision-making flow and identify who in your organization is authorized to act on emergency directives

A critical threat may trigger an accelerated amendment process or out-of-band patch deployment bypassing standard governance cycles

Node operators, bakers, exchange infrastructure teams

Test your ability to deploy emergency Octez patches rapidly and validate rollback procedures

Primary and fallback channels are maintained to ensure alert delivery during partial infrastructure outages or targeted attacks

All ecosystem participants

Document your inbound alert paths and ensure at least one backup channel is monitored by a secondary team

Bakers may be instructed to halt block production, pause endorsements, or switch to a patched client under coordinated timing

Baking infrastructure operators, staking providers, institutional bakers

Rehearse coordinated halt and restart procedures with your baking infrastructure team

Exchanges may need to suspend deposits and withdrawals, update node software, or revalidate chain state after an incident

Exchange engineering teams, custodial staking providers, fiat on-ramps

Integrate emergency suspension procedures into your exchange operations runbook and test them regularly

After an emergency upgrade, participants must verify chain consistency, finality resumption, and correct client version adoption

All node operators, indexers, block explorers, data teams

Define your post-incident health-check checklist including RPC consistency checks and version attestation

An attacker spoofs an emergency alert on a core developer communication channel, triggering a premature or malicious network halt by bakers.

Bakers, exchanges, custodians

Bakers must verify alerts through a secondary, out-of-band channel (e.g., PGP-signed email, verified social media) before acting. Exchanges should pre-establish a list of trusted core developer public keys.

A critical threat requires an emergency upgrade, but a quorum of bakers cannot be reached quickly due to fragmented communication or offline operators, delaying the patch.

All network users, DeFi protocols, stablecoin issuers

Baking infrastructure teams should participate in emergency drills and maintain a dedicated, secure out-of-band coordination channel. Exchanges and large bakers should have a 24/7 on-call rotation for emergency protocol actions.

An exchange fails to monitor the emergency alert channel, continuing to process deposits and withdrawals on a soon-to-be-forked or compromised chain, leading to financial loss.

Exchange users, the exchange itself

Exchanges must integrate monitoring of the canonical emergency broadcast channel into their NOC. They should have a pre-authorized playbook to halt deposits/withdrawals upon verified alert receipt.

Details of a critical zero-day vulnerability are shared over the coordination channel before a patch is ready, and the information leaks to an attacker who exploits it before the network can upgrade.

All network participants, DeFi TVL

The emergency coordination protocol must enforce strict need-to-know dissemination. A tiered alert system should be used, with technical details only shared after a supermajority of hashpower/stake has upgraded.

A critical patch is released via the emergency alert system, but a significant portion of bakers fail to apply it correctly or in time, causing a persistent chain split.

Bakers, exchanges, application developers

Node operators must have an automated, tested pipeline for applying hotfixes to baking infrastructure. The alert system should include explicit checksums and binary verification steps.

The emergency alert system is used to push a change that is not a critical security fix but a contentious governance decision, undermining the formal on-chain amendment process.

Protocol governance, all stakeholders

The scope of the emergency system must be strictly defined by social consensus. Bakers and exchanges should independently evaluate if an emergency upgrade is a genuine security necessity before activating it, treating any overreach as a protocol attack.

During a coordinated threat response, a malicious dApp mimics an emergency alert UI to trick users into signing a wallet-draining transaction.

All Tezos wallet users

Wallet providers must implement transaction simulation and human-readable parsing for all operations, especially during high-stress network events. Users should be educated to never trust an alert that asks for a signature without clear, parsed transaction details.