Why this chain.

A timestamp substrate, not a database.

An anchor writes one transaction carrying a single small OP_RETURN data output — a commitment of a few dozen bytes, never your content. The chain’s entire job is to make that commitment public, ordered, and expensive to rewrite: a miner includes it in a block, the block timestamp bounds when the fingerprint was held, and every later block makes the entry harder to alter. Everything else a verifier needs — the canonical document, the transaction id, the chain name, and (for manifest proofs) every leaf with its Merkle path — travels in the portable .mbnt bundle, not on the chain.

What a reorg does to an anchor — and what the 2021 attacks tested.

A confirmation means the anchor transaction is included in a mined block; each later block buries it one level deeper. On BSV a block is mined roughly every ten minutes under normal load. In a reorganization, blocks at the chain tip are replaced by a longer competing branch. For an anchor, the consequences are narrow:

• What the bundle commits to does not change. The transaction id and the commitment it carries are derived from the transaction’s own bytes, so no reorganization can alter them. What a reorganization can change is the transaction’s inclusion and depth at the chain tip — exactly the property a verifier reads live rather than taking on trust (next point). If the containing block changes, the block timestamp can shift by minutes; a proof claims block-level timing to begin with (see what a proof proves).
• Depth is read live, never baked in. The bundle’s manifest is written once at anchor time and deliberately carries no confirmation count — depth is a property of the public chain, checked at verify time. A conformant verifier that finds zero confirmations reports “broadcast, awaiting confirmation”, not verified (spec-bundle §7.4).
• The depth policy is yours. The verification spec frames the residual risk in exactly these terms: a chain reorganization below the verifier’s confirmation policy. Pick the depth your threat model needs — the docs CI gate (a curl+jq poll of any explorer) and the hosted verifier both read depth live and wait for depth ≥ 6. How much assurance a given depth buys depends on the chain underneath it — on this chain, that question has a concrete history, taken up next.

The hashrate question, answered plainly.

BSV shares its proof-of-work algorithm (SHA-256) with the much larger BTC network and carries a small minority of the total hashrate that hardware produces. The implication deserves stating rather than softening: an attacker needs no new hardware to contest this chain — redirecting a slice of existing SHA-256 capacity is enough — and rewriting a given number of blocks here costs a small fraction of rewriting the same depth on the majority chain. Depth 6 on BSV is not the settlement assurance depth 6 would be on BTC. Set your depth policy with that asymmetry in front of you.

This is not hypothetical. In 2021 the chain was the target of deliberate block-reorganization attacks: hostile miners built competing branches to displace recently mined blocks. The network withstood the episode — honest miners kept extending the chain, the attacking branches did not become the lasting chain, and the chain kept operating. We raise it here not to file it away as survived-therefore-solved, but because it is concrete evidence of what an attack of this kind does — and does not do — to an anchor:

• A contested tip is visible, not silent. Depth is read live at verify time (above), so during such an episode a verifier applying a confirmation-depth policy reports an anchor near the contested tip as below policy — awaiting depth, not verified. An attack of the 2021 kind surfaces in the verification result as “wait”, not as a false pass.
• An anchor is a bystander, not the payoff. Its data output carries no spendable value, so a reorganization has nothing to collect from the anchor itself. An anchor is disturbed only as a side effect — its containing block displaced or re-timed — and only if the reorganization reaches deeper than the anchor’s confirmation count at that moment.
• The honest answer to minority hashrate is depth, not denial. The docs’ CI example waits for depth ≥ 6. If your threat model includes a well-resourced adversary willing to attack the chain itself, set your confirmation-depth threshold deeper and wait longer before relying on the anchor — depth costs time, not money, and the policy is yours.

Beyond your chosen depth, what protects an anchor is the cost of redoing that much proof-of-work on this chain — a finite, chain-specific cost, not a slogan. This section exists so your reviewers can price it with the history on the table.

Already-issued proofs do not need Satsignal to exist.

With the original item and its .mbnt bundle in hand, verification needs no Satsignal account and no Satsignal service: re-hash the item, check it against the bundle, and check the transaction on any copy of the chain. That is the whole dependency set. Download the bundle when you anchor — server-side copies last only until you delete them (or until an explicit per-anchor retention window expires), and your copy is the durable one.