Reference
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
SettlementThe 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.
OP_RETURN
Bitcoin L1A 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.
Taproot
Bitcoin L1A 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.
UTXO
Bitcoin L1Unspent 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.
Rollup
Layer 2A 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.
Sidechain
Layer 2A 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.
Validium
Layer 2An 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.
Optimistic Rollup
Layer 2A 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).
ZK Rollup
Layer 2A rollup that uses zero-knowledge proofs to demonstrate mathematically that each state transition is valid. It gives immediate finality, but is computationally expensive.
SVM (Solana Virtual Machine)
ExecutionThe 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.
Sealevel
ExecutionThe 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.
Anchor
ExecutionA 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.
SPL (Solana Program Library)
ExecutionThe 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.
Sequencer
SequencingThe 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.
MEV (Maximal Extractable Value)
SequencingThe 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.
Forced inclusion
SequencingA 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.
Canonical Bridge
BridgeThe 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.
Forced exit
BridgeA 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.
Data Availability (DA)
Data AvailabilityThe 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.
state commitment
SettlementA 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.
Merkle tree
CryptographyA 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.
$HYPER
TokenomicsThe 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.
Vesting
TokenomicsA 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.
TGE (Token Generation Event)
TokenomicsThe 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.
TVL (Total Value Locked)
DeFiThe 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.
AMM (Automated Market Maker)
DeFiA DeFi protocol that uses mathematical formulas (usually x*y=k) to set exchange rates, dispensing with the traditional order book.
Oracle
DeFiA 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.
Fraud proof
SecurityA cryptographic proof showing that a state transition is invalid. It is used in optimistic rollups to challenge a fraudulent state during the dispute window.
Security audit
SecurityA 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.
Finality
SettlementThe point after which a transaction can no longer be reversed. In Bitcoin Hyper, ultimate finality is Bitcoin's own (N blocks after anchoring).
Lightning Network
Comparable projectsA 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.
Stacks
Comparable projectsA 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.
Rootstock (RSK)
Comparable projectsA Bitcoin sidechain that is EVM-compatible and uses merge-mining. Live since 2018. A small ecosystem. It uses RBTC (pegged to BTC) for gas.
No matching entry found.