> For the complete documentation index, see [llms.txt](https://hub.bsvblockchain.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hub.bsvblockchain.org/wiki/the-network/the-bitcoin-network/alert-system.md). # Alert System The **Alert System** is a network-wide messaging mechanism operated by the BSV Association that allows signed messages to be broadcast to all participating nodes on the BSV network. It was reintroduced to SV Node in version 1.1.0, drawing its name and general concept from the original Bitcoin alert key mechanism first implemented by Satoshi Nakamoto in Bitcoin v0.3.10 (see Alert Key), but it is architecturally distinct and purpose-built for the BSV network's current governance model. 1. Purpose The Alert System allows the BSV Association, acting as the network's steward, to broadcast two categories of signed message to node operators: * **Informational messages** - for example, software update announcements or notices of technical issues affecting the network. * **Directive messages** - binding instructions such as freezing, unfreezing, or reassigning specific transaction outputs, issued only pursuant to a valid court order as part of the Digital Asset Recovery (DAR) process. The Network Access Rules state that it is expected that all nodes in the network process validly signed Alert Messages broadcast to the network. 1. Architecture Unlike the original Bitcoin alert key, which piggybacked on the standard P2P relay used for block and transaction messages, the BSV Alert System uses [libp2p](https://libp2p.io/), a modular peer-to-peer networking stack, with a distributed publish/subscribe (pubsub) messaging model. This is the same peer-to-peer protocol planned for use in Teranode. * **Alert Generator** - the publisher role, operated by the BSV Association, which signs and publishes alert messages to a predefined topic. * **Alert System nodes** - the subscriber role, run alongside SV Node by node operators, which receive and validate alert messages published to that topic. Each network has its own dedicated topic and libp2p protocol ID: | Network | Topic | Protocol ID | | ------- | ------------------------------- | ----------------------------------- | | Mainnet | bitcoin\_alert\_system | /bitcoin/alert-system/1.0.0 | | Testnet | bitcoin\_alert\_system\_testnet | /bitcoin-testnet/alert-system/0.0.1 | | STN | bitcoin\_alert\_system\_stn | /bitcoin-stn/alert-system/0.0.1 | The reference implementation is maintained as a Go microservice, [go-alert-system](https://github.com/bsv-blockchain/go-alert-system), which runs as a companion process alongside SV Node. 1. Digital Asset Recovery (DAR) The Alert System is the delivery mechanism for Digital Asset Recovery, a process that allows stolen, lost, or misappropriated digital assets on the BSV ledger to be frozen, unfrozen, or reassigned. The process works as follows: 2. A court order recognised as valid and enforceable under Swiss or English law is submitted, along with supporting evidence. 3. A designated notary translates the court order into a machine-readable directive. 4. The directive is broadcast to the mining network via the Blacklist Manager tooling and, ultimately, the Alert System. 5. Node operators receive and validate the directive. Upon sufficient consensus among honest nodes, the freeze, unfreeze, or reassignment is enforced at the network level. Every node in the network maintains a Blacklist containing the asset freeze and recovery directives issued under this process. The BSV Association does not act as a judge in this process - directives are only issued in response to an applicable, validated court order. 6. Operational implications for node operators Node operators are expected to run the Alert System alongside SV Node so that they can validate and act on directive messages, particularly DAR freeze/unfreeze/reassignment orders. Non-mining node operators who do not run the Alert System can instead configure `enableassumewhitelistedblockdepth=1` and `assumewhitelistedblockdepth=6` to remain synchronised with a chain that has already had validated DAR alert messages applied by other nodes. 7. See Also * Alert Key * Nakamoto Consensus --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://hub.bsvblockchain.org/wiki/the-network/the-bitcoin-network/alert-system.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.