Glossary

The periodic publication of the rollup’s state commitment to the Bitcoin base layer (L1). Anchoring records the state commitment and makes it possible to detect subsequent changes; it does not, in itself, guarantee the correctness of the state, data availability or the security of the bridge.

A Bitcoin script opcode that allows up to 80 bytes of arbitrary data to be embedded in a transaction, rendering the output provably unspendable. It can be 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 outputs” corresponding to 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 that, depending on the model chosen, draws on the L1.

A separate blockchain connected to the L1 through a bridge. Its security depends principally on its own consensus mechanism and the design of the bridge, rather than directly on the security of the L1.

An architecture similar to a rollup in which the data required to reconstruct the state is stored outside the L1. It can lower costs and increase throughput, but introduces additional data-availability assumptions: if the data becomes unavailable, users may lose the ability to verify the state or withdraw their funds.

A rollup that assumes state transitions are valid by default — hence “optimistic”. It relies on fraud proofs, which allow incorrect transitions to be challenged within a defined time window, typically seven days on Ethereum.

A rollup that uses validity proofs — often based on zero-knowledge cryptography — to prove that state transitions comply with the protocol’s rules. It can shorten confirmation times compared with an Optimistic Rollup, although actual finality here too depends on the L1 and on the design of the system.

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

The parallelisation runtime within the SVM. It analyses the accounts declared by each transaction and enables the parallel execution of transactions that do not conflict with one another. It is one of the building blocks that contribute to Solana’s throughput and — according to the project — to the planned design of Bitcoin Hyper.

A Rust framework for developing SVM programs. It introduces macros, conventions and testing tools that simplify development on Solana. According to the project, Bitcoin Hyper aims to offer an equivalent toolchain; actual compatibility remains to be verified.

A library of standard programs for the SVM: tokens (SPL Token), staking, governance and so on. According to the project, Bitcoin Hyper is working towards SPL compatibility, which would allow Solana tokens and programs to be reused.

The rollup component that orders transactions before they are executed. The party operating the sequencer can determine this 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 may have considerable scope to capture or influence a rollup’s MEV.

A mechanism that lets users “force” the inclusion of a transaction through the Bitcoin L1, thereby bypassing a censoring sequencer. In Bitcoin Hyper this feature was still under development as at 28 April 2026.

Bitcoin Hyper’s official bridge for moving BTC from the L1 to the rollup and back. At launch: federated or centralised custody, with the trust assumptions that entails. The roadmap envisages progressive decentralisation, which remains to be verified.

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

The guarantee that the data for all transactions is publicly accessible. Without this data, no one can reconstruct the rollup’s state. In Bitcoin Hyper, a definitive solution is still under study.

A compressed representation — typically a Merkle root — of the rollup’s complete state at a given moment. It is periodically published to Bitcoin as anchoring; that publication does not amount to a full verification of the state.

A tree-shaped data structure in which each parent node is the hash of its child nodes. It allows efficient proofs — Merkle proofs — that a piece of data belongs to a set, without revealing the entire set.

The token that the project’s documentation presents as Bitcoin Hyper’s native token. The stated total supply is 21 billion. According to the published documentation, it is intended to be used for payments, for participation in staking and — at a later stage — for governance mechanisms. The stated allocation is as follows: 25% Treasury, 30% Development, 20% Marketing, 15% Rewards and 10% Listings.

A mechanism for the gradual release of tokens over time. Under the terms published for the presale, $HYPER is stated to have a seven-day vesting period.

The event at which a token is first 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 and so on — onto the blockchain. It is essential for DeFi: lending, derivatives and many contracts depend on reliable external price data.

A cryptographic proof demonstrating that a state transition is invalid. It is used in Optimistic Rollups to challenge fraudulent states during the challenge window.

A review of the source code carried out by independent specialists to identify potential vulnerabilities. In the case of Bitcoin Hyper, the project announced that it would publish security audits before the TGE; as at 28 April 2026, no public audit report of the protocol or the bridge could be confirmed.

The point from which, under the system’s rules and assumptions, a transaction is regarded as irreversible. In the architecture described for Bitcoin Hyper, state commitments would accumulate confirmations in Bitcoin after publication; this does not, in itself, guarantee the validity of the state or the ability to withdraw funds.

A Bitcoin payment network based on channels. Designed primarily for fast, low-cost payments, it does not offer a general-purpose smart-contract environment comparable to a virtual machine. In production since 2018.

A smart-contract network connected to Bitcoin that uses the PoX (Proof of Transfer) mechanism. It has its own language, Clarity, and stores its block data on Bitcoin.

An EVM-compatible Bitcoin sidechain that uses merge-mining. It uses the RBTC token — an asset pegged to BTC — to pay for gas. Operational since 2018.