Status

Where the proof of concept has got to — what has been proven, and what has not.

Implementation plan

What this page is. A proof of concept measured against reality rather than asserted — and the most useful thing it has produced is a correction. The light client, the one component we believed finished, was built on a difficulty rule that does not exist: BSV does not retarget every 2016 blocks, it recalculates every block, so the client would have rejected its first real header. It was found by replaying 324 real mainnet headers against the implementation, and it is now correct on all 324.

Below, "Done" means done and tested; everything described as designed is a specification. The vault is now built — every mint lands in a program-owned account, and release_mint and burn_staged are permissionless. The federation, the reserve script and peg-out are still specified and not built.

What changed since this page was last accurate. The design moved from an operator-less model to a bonded federation following the architecture of RenVM — the bridge that issued wrapped ZEC — with a second quorum of trusted third parties that must co-sign every reserve movement. What we add to that reference is reorg protection it does not have: our host chain verifies BSV rather than trusting a committee to report it.

Phase 0 · Environment Complete

One x86_64 VM, provisioned by a single script. doctor reports 19 ok, 1 warning, 0 failures.
SV Node v1.1.1 in regtest, Rust, Solana CLI 4.1.2, Anchor and solana-test-validator — all installed and running.

Phase 1A · Peg-in, BSV side Complete

A BSV deposit produces a portable mint instruction: 202 bytes, byte-identical on every run, verifiable from the file alone.
51 tests, including tampered proofs, inflated amounts, replays, malformed deposits, and a chain reorg that discards a deposit.
Needs no node — a generated chain — so it runs anywhere.

Phase 1B · Against a real SV Node Complete

Every byte format matched the node: transaction id, transaction codec, block header, Merkle root and Merkle branch.
21 live checks. The node's raw response is committed, so the format is a fact in the repository rather than something someone remembers.

Phase 2 · Solana token and light client In progress

Done: the light client on-chain. A checkpoint and a rolling 32-hour window (192 records, sized by what the difficulty rule needs and the account cap allows, not picked), each record storing the block hash, its cumulative chainwork and its timestamp. Linkage, proof of work and the cw-144 difficulty retarget — verified against 324/324 real mainnet headers. 34 tests passing, including a full mint and a hostile-advancer suite.
Done: the two implementations agree. The on-chain client derives the same header hash as the Phase 1A Python reference, from the same fixture, unmodified.
Done: a hostile advancer cannot reorder, replay or rewind. The worst it can do is stall, which is what the design claims.
Done: the client follows a legitimate reorg. A competing branch is staged and committed only if it is strictly heavier, so a tie keeps the incumbent. Already-minted deposits are not reversed — the confirmation depth is the protection, and the token has no freeze authority, so a reversal is impossible by design rather than merely unimplemented.
An adversarial review found and we fixed: a vacuous proof-of-work check, an unauthenticated checkpoint path, an unconstrained mint, a replay key that double-minted after a reorg, and a fork-staging point that could be spliced. The most serious was that the difficulty target was read from the header being checked, so proof of work was vacuous — anyone could append headers and mint with no hashpower. Three further fixes are now built: the unspent-outpoint hole (replay is a nullifier per deposit, not a fragile list with a 200-entry ceiling), the initialise race, and a timelocked authority so one key can no longer rewrite the trusted checkpoint instantly. The difficulty bootstrap, the reported spent-outpoint record, and the upgrade authority are documented as the remaining soft spots rather than hidden.
Done: the deposit verifier. It consumes the fixture's 202-byte instruction — Merkle fold, on-chain transaction parsing, exact output script, confirmation depth, and replay refusal. It accepts the real deposit and refuses four tampered versions of it.
Done: the mint. A verified deposit stages a mint and issues solBSV into a program-owned vault — not to the depositor directly. The recipient is named in the OP_RETURN and is who release_mint pays. Eight decimals, one base unit per satoshi, no scaling. The token has no freeze authority and its mint authority is a program PDA, so no operator key can create supply.
Done: the spent-outpoint record (N5). verify_deposit proves an output paid the deposit script — it cannot prove that output is still unspent, and under the federation the deposit script is the reserve. So a member could spend a deposit output and the deposit would still mint, unbacked. The program now refuses a mint whose outpoint has been reported spent, and the record is permanent — closing it would re-open the mint of an already-spent deposit. The reporter is the program's upgrade authority, standing in for the federation, which does not exist yet: the hole is closed in mechanism and unchanged in trust. The permissionless alternative was rejected deliberately — making the record writable by anyone turns mint availability into an attack surface, not just mint correctness.
Done: the client follows a real chain's difficulty. The retarget is cw-144, computed per block from the node's src/pow.cpp and verified against 324/324 real mainnet headers. Still open (X3): the rule is hard-coded, and BSV's own documentation says it will change, so the algorithm needs a way to change without a redeploy.

Phase 3 · Peg-out Built, with one dependency

Done: the redemption flow. initiate_redeem escrows the holder's solBSV and names a BSV address; cancel_redeem returns it unchanged if no payout happens by the deadline; claim_payout proves the payment through the existing light client; settle_redeem burns the escrow once the payout is deep enough and the challenge window has passed.
Escrow, not an immediate burn — because a burn is final and the payout might never happen. A holder whose tokens were burned at step one would have lost their claim on the reserve and hold nothing. Escrowing keeps supply ≤ reserve true at every point in between.
The fee needs no account. The holder redeems A and receives A − fee; the reserve falls by A − fee, the supply falls by A, so the reserve-to-supply ratio improves by the fee. The members keep it in BSV, inside the reserve they already hold.
The deadline is in Solana slots, not BSV height — deliberately. A height deadline would never expire if the header feed stalled, and the holder's funds would freeze with no way out.
And the escrow cannot latch. A claim whose payout block has left the light client's window can no longer be settled — so it is no longer live, and cancel_redeem returns the holder's tokens. Without that, a holder could reach a state where settle fails, cancel fails, and their solBSV is stuck permanently. Re-claiming is possible only with a payable proof, and it re-locks cancellation only while the claim is genuinely live.
But the payout is made by a member, not the program. The program can verify that BSV moved; it cannot move BSV. Until there is a federation, nobody is obliged to pay, so every redemption would time out into cancellation. That is a configuration rather than a defect — a holder is never stuck, only delayed — but it means peg-out cannot be demonstrated end to end until Phase 4 exists.

Phase 4 · The federation Designed, not built

The federation holds the reserve. Members bond BSV — working capital for transfers, the float, not capital sized against the vault. Sizing the bond against the vault produced an impossible inequality twice, so every capacity figure is withdrawn with the reason recorded.
A second quorum co-signs every reserve movement. The reserve script is a 2-of-2: the members' threshold key and the second quorum's key. Neither can move funds alone, and that is what actually constrains the reserve. The second quorum is trusted third parties with reputations to lose, not node operators.
The design follows RenVM deliberately. A bonded member set, a second quorum, epochs for membership — the precedent is good, and it is the bridge that issued wrapped ZEC. What we add is reorg reversal, which the reference does not address at all.
Open, and recorded as open. A member who leaves retains a valid share of the reserve key, so the effective threshold degrades with churn. Resolving it needs key rotation (the reserve moves on-chain) or proactive re-sharing (needs the departing member's cooperation) — both real work, neither done. The PoC does not finalise this.
Genesis is settled. Members post their bond in BSV at genesis, so no solBSV needs to exist first. The alternative — a capped, explicitly unbonded first mint — is recorded as a later option, not taken.
One accepted oracle, stated plainly. Reorg depth and block time come from the BSV headers and deadlines from Solana slots — but Solana cannot read the BSV UTXO set, so the federation reports spent outpoints. That is not a new trust: the federation is already trusted with the reserve.

Phase 5 · Public monitoring Built

Done: the monitoring page. It publishes, live and keyless in the reader's browser, BSV block height, hashrate and observed block spacing (mean and median over the ten newest headers), BSV and SOL prices, and Solana validator stake and throughput. Every figure shows its source and when it was fetched.
Reserve against supply — the figures that matter most, and they are not published yet. The protocol cannot check this: the reserve is off-chain BSV, and the mint exists only on a local validator. So the page shows them as "NOT PUBLISHED" rather than as zero or a dash, because "we have not published this" and "this is zero" must not look alike. Each says what would populate it and when.
Done: the cost to rewrite the chain, derived from live hashrate against a stated machine and energy price, printed with its units and labelled an electricity-only floor. That is the number the whole design leans on, so the assumptions live in a data file a reader can inspect rather than inside the page.
Sourced, and it says something unwelcome. NiceHash's public API exposes the SHA-256 rental market in three markets that must be summed — SHA256AsicBoost (BTC), SHA256AsicBoost_USDT (USDT) and the legacy SHA256. Together they hold roughly 25 EH/s against BSV's ~0.21 EH/s — a surplus of about 120×. So BSV can be 51%-attacked by renting, for roughly $9,000 a day. That is stated plainly because it is true, and because attack cost is not a defence and nothing here treats it as one.
What answers it is the vault. A rented majority can reorg a deposit, but the program verifies the chain itself and burns 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.
Why this is a security feature and not a dashboard. For the two things the design cannot enforce — a colluding signer set, and a spend nobody challenges — public visibility is the only remaining defence. It turns a hidden theft into a visible one.

What is proven so far

21 instructions built 66 on-chain tests 4 of 4 peg-out steps 21 live SV Node checks all passing

What is not proven

Nothing has run on a public network. The light client and the token are built and tested against a local Solana validator — Solana's regtest — and nothing more. Testnet is a later step, done with a team.
Redemption is not built. It is the trust-minimised half, and the hardest part — see the trust model in the documentation.
Nothing is independently audited. The critical defects above were found by an adversarial review run against our own code, which is not the same thing as an audit by someone with no stake in the answer.

This page is temporary. It exists so a small group can see exactly what is real — every claim above is a test you can run yourself from the repository. It will be removed before any wider release.

← Back to SOLBEAM