> 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` 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 optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.