Glossário

Publicação periódica de um state commitment do rollup na camada de base da Bitcoin. A ancoragem regista um compromisso de estado e permite detetar modificações posteriores, mas não garante, por si só, a exatidão do estado, a disponibilidade dos dados nem a segurança da bridge.

Opcode da linguagem de script da Bitcoin que permite inserir até 80 bytes de dados arbitrários numa transação, tornando a saída demonstravelmente não gastável. Pode ser utilizado para ancorar state commitments.

Atualização da Bitcoin (BIP 341/342, ativada em novembro de 2021) que introduz as assinaturas Schnorr e o MAST. Melhora a privacidade, a eficiência e a flexibilidade dos scripts e é relevante para mecanismos de ancoragem mais eficientes.

Unspent Transaction Output (saída de transação não gasta). Modelo contabilístico da Bitcoin: em vez de «contas», existem «saídas não gastas» correspondentes a montantes precisos. Difere do modelo de contas utilizado pela SVM e pela Ethereum.

Solução Layer 2 que executa as transações fora da cadeia e publica periodicamente um estado comprimido na camada de base (L1). Combina a escalabilidade fora da cadeia com uma segurança que, consoante o modelo adotado, se apoia na L1.

Blockchain independente ligada à L1 por uma bridge. A sua segurança depende principalmente do seu próprio mecanismo de consenso e do design da bridge, e não diretamente da segurança da L1.

Arquitetura próxima de um rollup na qual os dados necessários à reconstrução do estado são conservados fora da L1. Pode reduzir os custos e aumentar a capacidade, mas introduz pressupostos adicionais de disponibilidade dos dados: se estes se tornarem inacessíveis, os utilizadores podem perder a capacidade de verificar o estado ou de levantar os seus fundos.

Rollup que considera por defeito que as transições de estado são válidas — daí o termo «otimista». Apoia-se em provas de fraude que permitem contestar as transições incorretas durante uma janela temporal, geralmente de sete dias na Ethereum.

Rollup que utiliza provas de validade — frequentemente baseadas em criptografia de conhecimento nulo — para demonstrar que as transições de estado respeitam as regras do protocolo. Pode reduzir os prazos de confirmação face a um optimistic rollup, ainda que a finalidade efetiva dependa também da L1 e do design do sistema.

Runtime de execução desenvolvido pela Solana Labs. Permite a execução em paralelo ao exigir que cada transação declare explicitamente as contas que utiliza. Segundo o projeto, o Bitcoin Hyper emprega-o como ambiente de execução.

Runtime de paralelização da SVM. Analisa as contas declaradas por cada transação e permite executar em paralelo aquelas que não entram em conflito. Constitui um dos elementos que contribuem para o desempenho da Solana e, segundo o projeto, do design previsto para o Bitcoin Hyper.

Framework Rust destinado ao desenvolvimento de programas SVM. Acrescenta macros, convenções e ferramentas de teste que facilitam o desenvolvimento na Solana. Segundo o projeto, o Bitcoin Hyper pretende propor uma cadeia de ferramentas semelhante; a compatibilidade real deverá ser verificada.

Biblioteca de programas padrão na SVM: tokens (SPL Token), staking, governação, entre outros. Segundo o projeto, o Bitcoin Hyper visa a compatibilidade com o SPL, o que permitiria reutilizar tokens e programas da Solana.

Componente do rollup que ordena as transações antes da sua execução. A entidade que controla o sequencer pode determinar essa ordem, com implicações em matéria de MEV e de censura. No lançamento do Bitcoin Hyper, prevê-se que seja centralizado.

Valor que pode ser extraído reordenando, inserindo ou omitindo transações dentro de um bloco ou de um lote. Um sequencer centralizado pode dispor de uma capacidade significativa para captar ou influenciar o MEV do rollup.

Mecanismo que permite aos utilizadores «forçar» a inclusão de uma transação através da L1 da Bitcoin, contornando um sequencer que exerça censura. No Bitcoin Hyper, esta função encontrava-se ainda em desenvolvimento em 28/04/2026.

Bridge oficial do Bitcoin Hyper que permite transferir BTC da L1 para o rollup e vice-versa. No lançamento: custódia federada ou centralizada, com os pressupostos de confiança que tal implica. O roadmap prevê uma descentralização progressiva, que permanece por verificar.

Mecanismo que permite aos utilizadores levantar os seus fundos do rollup mesmo quando o sequencer ou a bridge não cooperam, utilizando a L1 da Bitcoin. Trata-se de uma função de segurança crítica, ainda em desenvolvimento.

Garantia de que os dados de todas as transações são acessíveis publicamente. Se os dados faltarem, ninguém pode reconstruir o estado do rollup. No Bitcoin Hyper, a solução definitiva permanece em estudo.

Representação comprimida — geralmente uma raiz de Merkle — do estado completo do rollup num dado momento. É publicada periodicamente na Bitcoin como ancoragem; a sua publicação não equivale a uma verificação completa do estado.

Estrutura de dados em árvore na qual cada nó ascendente corresponde ao hash dos seus nós descendentes. Permite provas eficientes — provas de Merkle — de inclusão de dados sem revelar o conjunto completo.

Token que a documentação do projeto apresenta como nativo do Bitcoin Hyper. A oferta total anunciada é de 21 mil milhões. Segundo a documentação publicada, prevê-se a sua utilização para pagar as taxas, participar no staking e, numa fase posterior, nos mecanismos de governação. A alocação anunciada é a seguinte: 25 % Tesouraria, 30 % Desenvolvimento, 20 % Marketing, 15 % Recompensas e 10 % Listagens.

Mecanismo de libertação progressiva dos tokens ao longo do tempo. Segundo as condições publicadas para a pré-venda, o $HYPER teria um período de vesting de sete dias.

Evento no decurso do qual um token é criado e distribuído inicialmente. Segundo o whitepaper, as auditorias de segurança devem estar concluídas antes do TGE do Bitcoin Hyper.

Valor total dos ativos depositados nos protocolos DeFi de uma rede. É um indicador utilizado para medir a adoção e a confiança num ecossistema.

Protocolo DeFi que utiliza fórmulas matemáticas — geralmente x*y=k — para determinar os preços de troca, sem recorrer a um livro de ordens tradicional.

Serviço que introduz na blockchain dados provenientes do mundo real — preços, eventos, etc. É essencial para a DeFi: os empréstimos, os derivados e numerosos contratos dependem de dados de preços externos fiáveis.

Prova criptográfica que demonstra que uma transição de estado não é válida. É utilizada nos optimistic rollups para contestar estados fraudulentos durante o período de contestação.

Exame do código-fonte por especialistas independentes com o objetivo de identificar eventuais vulnerabilidades. No caso do Bitcoin Hyper, o projeto anunciou a publicação de auditorias antes do TGE; em 28 de abril de 2026 não tinha sido identificado qualquer relatório público de auditoria do protocolo ou da bridge.

Momento a partir do qual uma transação é considerada irreversível segundo as regras e os pressupostos do sistema. No design descrito para o Bitcoin Hyper, os compromissos de estado acumulariam confirmações na Bitcoin após a sua publicação; tal não garante, por si só, a validade do estado nem a possibilidade de levantar os fundos.

Rede de pagamentos sobre a Bitcoin baseada em canais. Foi concebida principalmente para pagamentos rápidos e de baixo custo e não oferece um ambiente generalista de smart contracts comparável a uma máquina virtual. É utilizada em produção desde 2018.

Rede de smart contracts ligada à Bitcoin que utiliza o mecanismo PoX (Proof of Transfer). Dispõe da sua própria linguagem, Clarity, e regista informação relativa aos seus blocos na Bitcoin.

Sidechain da Bitcoin compatível com a EVM e que utiliza merge-mining. Utiliza o RBTC, um ativo indexado ao BTC, como token para o pagamento do gas. Está operacional desde 2018.