Glossary

Based on Appendix A of Michele Stefanelli's book “Due Diligence of a Layer 2 – The Bitcoin Hyper Case”. 33 entries across 12 categories.

33 terms

Anchoring

Settlement

The periodic publication of a rollup's state commitment to the Bitcoin base layer (L1). It secures immutability and a finality derived from Bitcoin's own security.

Chapters 11–12

OP_RETURN

Bitcoin L1

A Bitcoin script opcode that allows up to 80 bytes of arbitrary data to be attached to a transaction and marks the output as provably unspendable. It is used to anchor state commitments.

Chapter 12

Taproot

Bitcoin L1

A Bitcoin upgrade (BIP 341/342, activated in November 2021) that introduced Schnorr signatures and MAST. It improves the privacy, efficiency and flexibility of scripts, and matters for more efficient anchoring mechanisms.

Chapter 12

UTXO

Bitcoin L1

Unspent Transaction Output. Bitcoin's accounting model: “unspent coins” of fixed amounts rather than “accounts”. It differs from the account model used by the SVM and by Ethereum.

Chapter 1

Rollup

Layer 2

A Layer 2 solution that executes transactions off-chain and periodically publishes a compressed state to the base layer (L1). It combines off-chain scalability with security inherited from L1.

Chapters 4–6

Sidechain

Layer 2

A separate blockchain connected to L1 by a bridge. Unlike a rollup, it has its own independent security: if the sidechain fails, the risk is real and L1 does nothing to mitigate it.

Chapter 4

Validium

Layer 2

An architecture like a rollup, but with off-chain data availability (the transaction data is not held on L1). More scalable, but less secure: if the data becomes unavailable, users cannot prove their balances.

Chapter 14

Optimistic Rollup

Layer 2

A rollup that assumes state transitions are valid by default (hence “optimistic”). It relies on fraud proofs to challenge invalid transitions within a fixed window (usually seven days on Ethereum).

Chapter 6

ZK Rollup

Layer 2

A rollup that uses zero-knowledge proofs to demonstrate mathematically that each state transition is valid. It gives immediate finality, but is computationally expensive.

Chapter 6

SVM (Solana Virtual Machine)

Execution

The execution runtime developed by Solana Labs. It makes parallel execution possible because every transaction has to declare explicitly which accounts it will touch. Bitcoin Hyper uses it as its execution environment.

Chapters 7–8

Sealevel

Execution

The SVM's parallel processing runtime. It analyses transactions in advance and runs them in parallel when they share no accounts. It is the main source of the high throughput of Solana — and of Bitcoin Hyper.

Chapter 8

Anchor

Execution

A Rust framework for developing SVM programs. It adds macros, conventions and testing tools that make writing smart contracts for Solana and Bitcoin Hyper markedly simpler.

Chapter 9

SPL (Solana Program Library)

Execution

The library of standard SVM programs: tokens (SPL Token), staking, governance and so on. Bitcoin Hyper aims at SPL compatibility so that Solana tokens and programs can be reused.

Chapter 9

Sequencer

Sequencing

The component of a rollup that fixes the order of transactions before execution. Whoever controls the sequencer controls the ordering, with consequences for MEV and for censorship. At the launch of Bitcoin Hyper it is expected to be centralised.

Chapters 15–17

MEV (Maximal Extractable Value)

Sequencing

The value that can be extracted by reordering, inserting or removing transactions within a block or batch. A centralised sequencer has full access to a rollup's MEV.

Chapter 15

Forced inclusion

Sequencing

A mechanism that lets users force the inclusion of a transaction by way of Bitcoin L1, bypassing a sequencer that is censoring them. In Bitcoin Hyper it is still in development as at 28.04.2026.

Chapter 21

Canonical Bridge

Bridge

The official Bitcoin Hyper bridge, which moves BTC from L1 to the rollup and back. At launch: federated, which is to say centralised, custody. The roadmap envisages gradual decentralisation.

Chapters 31 and 34

Forced exit

Bridge

A mechanism that lets users withdraw funds from the rollup by way of Bitcoin L1, even when the sequencer or the bridge will not cooperate. A decisive safety feature, and one still in development.

Chapter 21

Data Availability (DA)

Data Availability

The guarantee that the data for every transaction is publicly available. Without the data, nobody can reconstruct the rollup's state. In Bitcoin Hyper the final solution is still under study.

Chapter 14

state commitment

Settlement

A compressed representation of the rollup's entire state at a given moment (usually a Merkle root). It is published periodically to the Bitcoin network for anchoring.

Chapter 11

Merkle tree

Cryptography

A tree-shaped data structure in which each parent node is the hash of its children. It allows efficient proofs of membership (Merkle proofs) without revealing the whole dataset.

Appendix A

$HYPER

Tokenomics

The native token of Bitcoin Hyper. Total supply: 21,000,000,000 (a nod to Bitcoin's 21 million BTC). Used for transaction fees, staking and governance. Breakdown: 25% Treasury, 30% development, 20% marketing, 15% rewards, 10% listings.

Chapters 30–33

Vesting

Tokenomics

A mechanism for releasing tokens gradually over time, so that the interests of the team and of investors are tied to the long-term success of the project. The $HYPER presale has seven days of vesting.

Chapter 33

TGE (Token Generation Event)

Tokenomics

The event at which a token is first created and distributed. According to the whitepaper, the security audits are to be completed before the Bitcoin Hyper TGE.

Chapter 33

TVL (Total Value Locked)

DeFi

The total value of the assets deposited in a network's DeFi protocols. It is the measure used to gauge how far an ecosystem has been taken up and trusted.

Appendix A

AMM (Automated Market Maker)

DeFi

A DeFi protocol that uses mathematical formulas (usually x*y=k) to set exchange rates, dispensing with the traditional order book.

Appendix A

Oracle

DeFi

A service that brings real-world data (prices, events) onto a blockchain. Decisive for DeFi: lending, derivatives and many smart contracts depend on trustworthy external values.

Appendix A

Fraud proof

Security

A cryptographic proof showing that a state transition is invalid. It is used in optimistic rollups to challenge a fraudulent state during the dispute window.

Chapter 19

Security audit

Security

A review of source code by a specialist third party, intended to identify vulnerabilities. In the case of Bitcoin Hyper: promised before the TGE, but no report on the protocol or the bridge had been published as at 28.04.2026.

Chapter 34

Finality

Settlement

The point after which a transaction can no longer be reversed. In Bitcoin Hyper, ultimate finality is Bitcoin's own (N blocks after anchoring).

Chapter 13

Lightning Network

Comparable projects

A Bitcoin Layer 2 based on payment channels. Optimised for fast, inexpensive micro-payments between two parties. It does not support complex smart contracts. In production since 2018.

Chapters 25–26

Stacks

Comparable projects

A Bitcoin Layer 2 that uses the PoX (Proof of Transfer) mechanism. It has its own smart contract language (Clarity) and anchors its blocks to Bitcoin. Its ecosystem has remained limited compared with early expectations.

Chapter 27

Rootstock (RSK)

Comparable projects

A Bitcoin sidechain that is EVM-compatible and uses merge-mining. Live since 2018. A small ecosystem. It uses RBTC (pegged to BTC) for gas.

Chapter 28