Annotated whitepaper

A guide to reading the Bitcoin Hyper whitepaper (version of 04.01.2026) critically. Based on Appendix D of Michele Stefanelli's book.

How to read the whitepaper: a whitepaper is a technical marketing document, not a formal specification. It should be read critically: separating independently verifiable claims from promises, identifying the gaps, and reading it alongside the team's later updates.

A framework for active reading

1

Read the structure

Map the structure of the document before going into the detail: what are its central propositions? Which sections are missing? A whitepaper that says nothing about data availability or about decentralising the sequencer is avoiding the uncomfortable subjects.

2

Identify the claims

Distinguish between (a) technical claims that can be verified independently (“the SVM supports parallel execution”), (b) contestable claims (“Bitcoin-level security”) and (c) promises about the future (“we will decentralise the sequencer”).

3

Cross-check against the updates

A whitepaper is a static snapshot. The team's updates (blog, Twitter, forums) carry more recent information. If an update contradicts the whitepaper, which version holds?

4

Analyse the gaps

What is left unsaid? Silence on data availability, forced inclusion, the proof system and a firm timeline for decentralisation matters as much as the information that is presented.

The principal claims — a critical analysis

“Bitcoin-level security for assets held on Hyper”

Partly true. Finality is anchored to Bitcoin. But custody of the BTC held in the bridge is federated at the outset, which is to say centralised. If the bridge is compromised, the assets are at risk however secure Bitcoin itself may be.

⚡ Partly true

“Immediate compatibility with Solana: same code, same tooling”

Broadly true as far as core functionality goes. The SVM runtime is the same. Anchor and the Solana CLI work. The differences: fees are paid in $HYPER rather than SOL, and some of Solana's system programs may not be available in the same form.

✓ Broadly true

“Higher throughput thanks to the SVM and Sealevel”

The architecture is plausible: Sealevel makes parallel execution possible. No benchmarks specific to Bitcoin Hyper have been published. Actual throughput also depends on the data availability layer and on the sequencer.

◎ Architecturally plausible

“Mainnet expected in Q4 2025”

Not met. As at 28 April 2026 mainnet was not live. The delay is attributed mainly to completing the audits and stabilising the bridge — much as any careful analyst would expect.

✗ Not met

“Security audits before the TGE”

A public undertaking that had not been met as at 28 April 2026. No public audit report could be identified. This should be treated as a decisive signal.

○ Verification required

📖 For the full reading

Appendix D of Michele Stefanelli's book «Due Diligence of a Layer 2 – The Bitcoin Hyper Case» gives a complete guide to reading the whitepaper: its structure, the claims analysed chapter by chapter, how to identify the gaps, and a summary. Open the book →