Glossary

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

A Bitcoin script opcode that allows up to 80 bytes of arbitrary data to be embedded in a transaction, rendering it provably unspendable. Used to anchor state commitments.

A Bitcoin upgrade (BIP 341/342, activated November 2021) that introduces Schnorr signatures and MAST. It improves the privacy, efficiency and flexibility of scripts, and is relevant to more efficient anchoring mechanisms.

Unspent Transaction Output. Bitcoin’s accounting model: instead of “accounts”, there are “unspent coins” of specific amounts. This differs from the account model used by the SVM and Ethereum.

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

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

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

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

A rollup that uses zero-knowledge cryptographic proofs to demonstrate mathematically the validity of every state transition. It offers immediate finality, but is computationally expensive.

An execution runtime developed by Solana Labs. It enables parallel execution by requiring each transaction to declare explicitly the accounts it touches. Bitcoin Hyper uses it as its execution environment.

The SVM’s parallelisation runtime. It analyses transactions in advance and executes them in parallel when they do not share accounts. It is the main source of the high throughput of Solana (and of Bitcoin Hyper).

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

A library of standard programs on the SVM: tokens (SPL Token), staking, governance and so on. Bitcoin Hyper aims for SPL compatibility, allowing Solana tokens and programs to be reused.

The rollup component that orders transactions before execution. Whoever controls the sequencer can determine the ordering (with implications for MEV and censorship). At Bitcoin Hyper’s launch it is expected to be centralised.

Value that can be extracted by reordering, inserting or omitting transactions within a block or batch. A centralised sequencer has full access to the rollup’s MEV.

A mechanism that lets users “force” the inclusion of a transaction through the Bitcoin L1, bypassing a censoring sequencer. Still under development in Bitcoin Hyper as at 28/04/2026.

Bitcoin Hyper’s official bridge for moving BTC from the L1 to the rollup and back. At launch: federated/centralised custody. The roadmap envisages progressive decentralisation.

A mechanism that lets users withdraw funds from the rollup even when the sequencer or bridge is uncooperative, using the Bitcoin L1. A critical safety feature, still under development.

The guarantee that the data for all transactions is publicly accessible. If the data is missing, no one can reconstruct the rollup’s state. A definitive solution is still under research in Bitcoin Hyper.

A compressed representation (typically a Merkle root) of the rollup’s complete state at a given moment. It is periodically published to Bitcoin for anchoring.

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

Bitcoin Hyper’s native token. Total supply: 21 billion (a nod to Bitcoin’s 21 million BTC). Used for transaction fees, staking and governance. Allocation: 25% Treasury, 30% Development, 20% Marketing, 15% Rewards, 10% Listings.

A mechanism for releasing tokens gradually over time, in order to align the incentives of the team and investors with the project’s long-term success. The $HYPER presale has a seven-day vesting period.

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

The total value of assets deposited in the DeFi protocols on a network. A metric used to gauge adoption of, and confidence in, an ecosystem.

A DeFi protocol that uses mathematical formulas (typically x*y=k) to set exchange prices, removing the need for a traditional order book.

A service that brings real-world data (prices, events) onto the blockchain. Critical for DeFi: lending, derivatives and many contracts depend on reliable external prices.

A cryptographic proof demonstrating that a state transition is invalid. Used in optimistic rollups to challenge fraudulent states within the challenge window.

A review of the source code by a specialised third-party firm, with the aim of identifying vulnerabilities. For Bitcoin Hyper: promised before the TGE, but not yet published as at 28/04/2026.

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

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

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 relative to initial expectations.

A Bitcoin sidechain with EVM compatibility and merge-mining. Live since 2018. A small ecosystem. It uses RBTC (pegged BTC) as gas.