Monitoring

What the design cannot enforce, published instead.

Why this page exists. Two things the design cannot prevent: a signer set that colludes, and a spend nobody challenges. Neither can be stopped inside the protocol — the reserve is off-chain BSV that no Solana program can read, and a threshold signature does not reveal who signed it. What is left is that both must be visible. So this page publishes the reserve against the supply, and the cost of rewriting the chain that backs it. It is a stated mitigation in the trust model, not a dashboard.

What is live here and what is not. The network figures — BSV hashrate, block height, block spacing, BSV and SOL price, Solana stake and throughput — are fetched by your browser from public, keyless APIs, and so is the rentable SHA-256 supply, read live from NiceHash’s three SHA-256 markets. The reserve, the supply and their ratio are not published yet, because the federation does not exist and solBSV exists only on a local validator. Those three are marked NOT PUBLISHED everywhere they appear. When a live source cannot be read, the page says so: it shows a labelled snapshot or an explicit placeholder, and it never shows a failed read as a zero. Nothing on this page claims monitoring is live for anything that is not.

The numbers that matter

The rentable market, and what it means

BSV can be 51%-attacked by renting. The size of the SHA-256 rental market against BSV’s whole network, and what out-hashing that network costs per day at the published leased rate, are computed from the live hashrate and the live NiceHash markets when JavaScript runs. Without JavaScript they are a labelled placeholder, never a guess. Attack cost is therefore not a defence, and this page should not imply that it is.

The consolidated figure is the sum of the three markets above, not one of them. The algo ids that are summed and the source they are read from are both in data.json; if the live read fails, the hand-published snapshot in that file is shown instead, labelled as a snapshot.

This is precisely the threat the vault exists for. A rented majority can reorg a deposit — but the program verifies the chain itself and can burn a mint whose deposit is reorged away, which no amount of rented hashrate prevents. The defence is the reversal, not the price of the attack.

The one caveat that survives. Renting the whole market is not instantaneous: NiceHash’s own marketplace guidance is that large demand moves the price of the order book, so a real attack would be slower and costlier than the flat rate suggests. That is a friction, not a barrier, and this page does not present it as one.

Live network figures

Each figure is fetched directly by your browser. There is no server and no API key. If a source is down or rate-limits, the card shows the last value it read and when, or it says unavailable — it never shows a zero, because zero is a value and "we could not read it" is not. Each card carries the source, the source's own timestamp where it publishes one, and the time this browser read it.

Why Solana has no hashrate

Solana is proof-of-stake. There is no SHA-256 race, no difficulty, and no cost to out-mine it, so a "SOL hashrate" would be a number that does not exist — and any page showing one is showing a fabrication. What secures Solana is bonded stake, so the figures above are the active stake and the validator count. BSV is proof-of-work: its security is the cost of producing a heavier chain, so the figures are hashrate, difficulty and spacing. The two chains are not symmetric and the page does not pretend they are.

Published by hand — not yet published

Hand-published from data.json. Last published: never — no reserve or supply figure has been published yet. These are placeholders because our own deployment is not on a public network. A placeholder here is not a zero: it means nobody has published the figure, and the text says what would populate it and when.

How the attack cost is derived

This is the number the design leans on: if out-mining the chain costs less than the fraud is worth, the confirmation depth is not a defence. It is derived from the live BSV hashrate estimate on two bases: an electricity-only floor from an assumed machine, and the rented-hashrate cost at the published SHA-256 market rate. Both are printed below with their units, because they answer different questions — the first is what an attacker who already owns the machines pays in power, the second is what an attacker without hardware would pay the market. The rented basis is then priced for the two things that were actually asked for: matching BSV’s network, and a comfortable majority on top of it. Every assumption lives in data.json; the live hashrate and the three NiceHash markets that supply the hashrate are fetched by your browser, so restating the estimate needs no code change.

The leased rate is published, not assumed: crypto51.app publishes NiceHash SHA-256 rental prices, and its API at api.crypto51.app/coins.json exposes rentable_price_usd_hour and rentable_price_units. Every SHA-256 coin on that list — BTC, BCH, XEC, FB, QUAI, BC2 — reports the same rate, because SHA-256 hashrate is fungible. BSV is not on the list, so the SHA-256 rate is applied to BSV’s own live hashrate, and it is hand-copied into data.json with the time it was read. The rentable supply is no longer taken from crypto51. crypto51 reads only one of NiceHash’s three SHA-256 markets — the legacy one, which holds three orders and almost no hashrate. The consolidated figure above is the live sum of all three, fetched from NiceHash’s own public stats API. The algo ids, the market names and the source URL are in data.json; the sum, the ratio and both out-hash costs are computed in the browser from the live hashrate and the live markets, so they stay true as BSV’s hashrate and the market move.

• Electricity only. The first basis excludes buying or renting the machines, cooling, bandwidth, pool fees, and the fact that rented SHA-256 normally costs more than raw electricity. It is a floor on what an attacker who already owns the hardware pays — nothing more.
• Renting is not capped by the market. The second basis applies the published SHA-256 rental rate to the same hashrate, per hour and per day. An earlier version of this page said the market listed only a small fraction of what the attack needs, so no amount of money could rent it. That was false. The figure came from crypto51, which reads only the legacy standard SHA-256 market on NiceHash — the one with a handful of open orders. The market that matters, the one virtually all modern Bitcoin hardware lives on, is one of the other two, and all three are listed by algo id in data.json. Summed across all three, the rentable supply dwarfs BSV’s whole network — the ratio is computed live above — so the hashrate needed to match or out-mine BSV is for sale. What is not instantaneous is moving that much through the book: large demand moves the price, which makes a real attack slower and costlier than the flat rate. That is a friction, not a barrier, and this page does not present it as one.
• The defence is the reversal, not the price. A rented majority can reorg a deposit — but the program verifies the chain itself and can burn a mint whose deposit is reorged away, so the deposit’s value does not survive the reorg no matter how much hashrate was rented. This is precisely the threat the vault exists for; no amount of rented hashrate prevents the reversal.
• SHA-256 is shared with BTC, where far more of it already exists. This figure is the cost of assembling hashrate equal to BSV's own; it is not a lower bound on what someone who already controls large SHA-256 could do.
• 1.0× is parity, not a majority. The default multiple is 1.0× the network estimate, which matches the honest hashrate. To exceed it an attacker must add more than 1.0×. 0.51× is not a bare majority: 0.51× added to the existing network is 0.51 ÷ 1.51 ≈ 34% of the total hashrate, not 51%. The comfortable-majority figure prices the multiple published in data.json on top of the network estimate.
• The inputs are stated, not hidden. The machine, its hash rate, its power draw, the energy price, the multiple, the leased rate, the majority multiple, and the three markets that are summed — their algo ids, names and source — are all printed above, with units and sources, and are editable in data.json. Nothing here is a number we invented.

What this page cannot do. It cannot verify the reserve. It cannot see a colluding signer set. It cannot know whether a spend was challenged. It publishes numbers so that those things, if they happen, are visible to anyone — and it is explicit about which numbers are measured, which are derived, and which nobody has published at all.