The operator's signed advisory channel

Beacon is an authenticated channel for the protocol operator. It carries short, signed messages — upgrade advisories, technical notices, V14/V15 announcements — each one cryptographically tied to the operator's key and to a point in time.

What Beacon is

• A way for the operator to say something and have every node prove it really came from the operator, without trusting any website or middleman.
• Phase II-A (single-signature advisory notices) is active from V13 (block 12,000). Phase III (peer-to-peer gossip that relays notices between nodes) is active at V13 too.

What Beacon is NOT

• It is not consensus. It does not affect block validity.
• It cannot stop the chain, reorg it, or fork it.
• It cannot slash a miner, freeze funds, or move coins.
• It cannot force any node to do anything.
• It can only display a signed message. What you do about it is your choice.

ADVISORY ONLY  Phase II-B (3-of-5 threshold signatures) is implemented and tested but ships default-off (BEACON_IIB_THRESHOLD_ACTIVATION_HEIGHT = INT64_MAX) until five independent custodians exist.

• The operator writes a notice and signs it with the Beacon private key. That key lives offline, AES-256-encrypted with a passphrase, on an encrypted USB — it never touches a networked machine.
• The operator's node broadcasts the signed notice over the SOST peer-to-peer network (Phase III gossip).
• Peer nodes receive it, verify the signature, and keep it if it checks out.

The signature is ECDSA over SHA-256 of the notice's canonical payload — the same primitive used for SOST transactions. Because only the private key can produce a signature that the public key accepts, a valid signature is proof of authorship.

Each node ships with the Beacon public key hardcoded in the binary (BEACON_PUBKEY_HEX in src/beacon.cpp). When a signed notice arrives, the node, on its own, with no configuration:

• computes sha256 of the notice's canonical payload,
• verifies the signature against the hardcoded public key,
• if the signature is valid → accepts the notice (advisory) and shows it as a banner on node / miner startup (also available via the getbeaconnotices RPC),
• if the signature is invalid → silently drops it and logs a warning.

It never forks, never slashes, never restarts anything. A verified notice only informs the operator of that node. If you want to act on it (pause mining, double-check an upgrade, etc.), that is entirely your decision — Beacon does not act for you and cannot compel you.

A. The published key fingerprint matches the source code

Pull the public key straight from the source on GitHub and hash it — it must equal the canonical fingerprint:

curl -s https://raw.githubusercontent.com/Neob1844/sost-core/main/src/beacon.cpp \
  | grep -A3 'BEACON_PUBKEY_HEX =' | grep -oE '"[0-9a-f]+"' | tr -d '"\n' | openssl dgst -sha256
# expected:
# bbb560e3ec86114a59762d467d645c88cfe0497a8f7ca542c973e2e0def8186b

(sha256sum works too — openssl dgst -sha256 is just the portable equivalent on macOS / Windows. Only the 64-hex value matters, not the label.)

B. The on-chain anchor matches the published manifesto

The fingerprint is also anchored on the SOST chain. Download the manifest and hash it — its first 16 hex are the value carried in the on-chain capsule:

curl -s https://sostcore.com/api/sost-protocol-beacon-iia-v13-fingerprint-v1.json | openssl dgst -sha256
# expected:
# ceb19dd6b5fd676f0ec8aa97d1514f09b01a8b000f183afa9a8a0aaf9c135c48
# the first 16 hex (ceb19dd6b5fd676f) are the anchor inside the on-chain capsule:
#   sost-protocol beacon-iia-v13 ceb19dd6b5fd676f   (block #11,034)

If both values match, the Beacon key in your binary is the genuine operator key — and it is timestamped on the chain itself. If either does not match, do not trust that copy.