Appendix D
Annotated whitepaper
A guide to the critical reading of the Bitcoin Hyper whitepaper (v. 04/01/2026). 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 with critical attention: distinguishing independently verifiable claims from promises, identifying the gaps, and comparing it against the team's subsequent updates.
An active-reading framework
Read the structure
Before going into the detail, you need to understand the structure of the document: what are its central theses? Which sections are missing? A whitepaper that addresses neither data availability nor the decentralisation of the sequencer leaves important questions for assessing the system unanswered.
Identify the claims
Distinguish between: (a) independently verifiable technical claims (“the SVM supports parallel execution”), (b) contestable claims (“Bitcoin-level security”), and (c) future promises (“we will decentralise the sequencer”).
Compare against the updates
The whitepaper is a snapshot at a single point in time. The team's updates (blog, Twitter, forums) contain more recent information. When an update contradicts the whitepaper, which version should be treated as authoritative?
Gap analysis
What is not specified in detail? The absence of information on data availability, forced inclusion, the proving system or a concrete decentralisation timeline can be just as important as the information actually provided.
Key claims — a critical analysis
“Bitcoin-level security for assets on Hyper”
This claim needs to be qualified more precisely. Under the architecture as described, Bitcoin Hyper intends to publish state commitments to Bitcoin. This anchoring does not, in itself, guarantee the correctness of the state, data availability or the security of the bridge. In addition, custody of the BTC within the bridge at launch is described as federated or centralised; a failure or compromise of the bridge could therefore put those assets at risk.
⚡ Requires clarification“Drop-in compatibility with Solana: same code, same tooling”
The project documentation describes an SVM-based execution environment and compatibility with the tooling of the Solana ecosystem. The actual compatibility of the code, Anchor, the CLI and the system programs should be verified against the public technical documentation and independent testing. Fees are expected to be paid in $HYPER rather than SOL.
○ Awaiting full confirmation“Higher throughput thanks to the SVM/Sealevel”
The proposed architecture is consistent with Sealevel's parallel execution, but no performance benchmark has been published relating specifically to Bitcoin Hyper. Actual throughput also depends on the sequencer, on data availability and on the final implementation.
◎ Conceptually consistent“Mainnet planned for Q4 2025”
Not met by the announced date. As of 28 April 2026, the mainnet was not yet live. The available public documentation does not allow this delay to be reliably attributed to any single cause; the interim milestones still outstanding — the bridge, the security audits and other components — should be verified before launch.
✗ Not met by the announced date“Security audit before the TGE”
As at 28 April 2026, two public reports on the $HYPER ERC-20 contract had been identified, but no public report on a security audit of the Layer 2 protocols or the bridge. The commitment to publish audits before the TGE therefore remains unverified for these components.
○ Awaiting confirmation📖 For the full reading
Appendix D of Michele Stefanelli's book ‘Due Diligence of a Layer 2 – The Bitcoin Hyper Case’ contains a complete guide to reading the whitepaper: structure, claims analysed chapter by chapter, gap identification and synthesis. Go to the book →