Status do projeto

Data de acesso hoje — Fontes: a documentação publicada pelo projeto e as confirmações externas citadas nesta página. Site oficial: bitcoinhyper.com

Fase atual

Devnet

Acesso seletivo

O intervalo de lançamento da mainnet indicado na documentação monitorada

T3–T4 2026

Prazo orientativo, a verificar conforme as auditorias e o andamento dos trabalhos

Auditorias públicas

Auditorias de token publicadas

SolidProof / Coinsult; não foi identificada nenhuma auditoria pública completa do protocolo ou do bridge

SVM na devnet

Indicada como operacional

Segundo as declarações do projeto; foram testados programas Rust/Anchor

Status dos principais componentes

✓ Na devnet

A camada de execução SVM

Segundo a documentação do projeto, os programas SVM rodam nativamente na devnet. O projeto afirma que foram testados tokens SPL, mecanismos de escrow e configurações multisig.

◉ Em andamento

O sequencer (centralizado)

Segundo o projeto, está operacional na devnet. No lançamento da mainnet, seria centralizado e administrado pela equipe.

✓ Na devnet

O explorador da devnet

O projeto mantém um explorador público de devnet.

◎ Em construção

Canonical bridge

Segundo a documentação do projeto, o canonical bridge está em teste na devnet. A função de forced exit ainda não foi implementada, e o modelo inicial de custódia dos fundos é do tipo federado.

◎ Em construção

A ancoragem no Bitcoin

A documentação descreve a ancoragem via OP_RETURN ou Taproot. A frequência adaptativa de ancoragem ainda está em construção.

◎ Em construção

A disponibilidade dos dados

A solução final ainda está em análise. Entre as abordagens consideradas estão camadas externas de disponibilidade de dados, erasure coding e nós distribuídos.

○ Planejado

Forced inclusion e forced exit

O mecanismo de resistência à censura. Ainda em construção e indisponível na devnet.

◎ Em construção

O sistema de provas (ZK/fraud)

O projeto afirma que desenvolve um modelo híbrido, que combina fraud proofs e validity proofs. Segundo a sua documentação, o sistema não estaria ativo no lançamento inicial.

○ Planejado

As auditorias de segurança

Foram identificadas auditorias públicas do contrato do token, realizadas entre outras pela SolidProof e pela Coinsult. A auditoria da SolidProof diz respeito exclusivamente a um único contrato de token, e não ao protocolo Layer 2, ao bridge ou a outros contratos. No âmbito desta análise não foi identificada nenhuma auditoria pública completa do protocolo ou do bridge.

○ Planejado

Testnet pública

Segundo o roadmap, o projeto pretende abrir a testnet para desenvolvedores e para a comunidade antes do lançamento da mainnet.

○ Planejado

Mainnet

O plano inicial descrito pelo projeto prevê um sequencer centralizado e um bridge federado. O lançamento depende, em primeiro lugar, da conclusão das auditorias e da construção do canonical bridge.

○ Planejado

A descentralização do sequencer

O roadmap prevê um intervalo de 2 a 4 anos após o lançamento da mainnet: rotação, leilões e eleição do líder.

A cronologia das principais atualizações

Julho de 2026 O livro

Publicação da edição em inglês do volume I de “Due Diligence of a Layer 2 – The Bitcoin Hyper Case”, de Michele Stefanelli: análise técnica independente do projeto — 523 páginas e 24 capítulos; a obra completa reúne 36 capítulos.

Março de 2026 Comunicado da equipe

Segundo um comunicado publicado pelo projeto, a solução final para a disponibilidade dos dados ainda estava em análise, com várias abordagens já sendo consideradas.

Fim de 2025 Devnet

Segundo a documentação do projeto, os programas SVM rodam nativamente, com um explorador ativo e com os primeiros testes de implementações DeFi, tokens SPL, escrow e multisig, realizados com desenvolvedores selecionados.

T2–T4 2025 Pré-venda e staking

O token $HYPER é oferecido em uma pré-venda pública, em várias etapas. Segundo o projeto, o staking está ativo, e o acesso seletivo à devnet foi concedido a parceiros e desenvolvedores escolhidos.

T2 2025 Os fundamentos

A arquitetura inicial, o whitepaper v1 e a formação da equipe principal do projeto.

Verificação automática do contrato

GoPlusLabs · maio de 2026

✓ Dados coletados

Código-fonte verificado Código-fonte publicado e verificado no BscScan
Sem proxy O contrato não pode ser atualizado por um padrão do tipo proxy
Sem função de mint Não podem ser criados novos tokens após a implantação do contrato
Renúncia ao direito de propriedade Endereço do proprietário: 0x000…0000 (dead address)
Sem proprietário oculto Nenhuma função oculta de transferência da propriedade
Sem função de self-destruct O contrato não pode ser destruído unilateralmente
Sem blacklist Nenhum mecanismo de bloqueio de endereços específicos
Sem whitelist Nenhuma restrição seletiva sobre as transferências
Taxa de 0% na compra, na venda e na transferência As transações não são taxadas
As taxas não podem ser alteradas As taxas não podem ser aumentadas após a implantação do contrato
Mecanismo anti-whale não modificável A equipe não pode alterar o limite de posse

⚠ Aspectos que exigem atenção

Risco ligado às chamadas externas O contrato executa chamadas externas. A GoPlusLabs sinaliza um risco de re-entrancy ou de comportamento inesperado em caso de atualização das suas dependências.
Possível honeypot A verificação automática da GoPlusLabs retornou, em simulação, um indicador de possível honeypot. A venda não pôde ser verificada de forma independente.
A presença de um mecanismo anti-whale O mecanismo anti-whale — o limite de posse — existe, embora não possa ser alterado. Pode afetar a liquidez na fase inicial.

Nota editorial

As verificações automáticas da GoPlusLabs não substituem uma auditoria formal realizada por uma empresa independente especializada (por exemplo, CertiK, Quantstamp ou Hacken). O indicador “possible honeypot” exige uma verificação manual: um contrato pode retornar um resultado positivo em simulação por causa de uma lógica condicionada pela liquidez ou por um mecanismo de bloqueio (lock). A ausência da função de mint e a renúncia ao direito de propriedade são sinais estruturalmente positivos, mas não garantem a segurança do protocolo como um todo, que depende também do canonical bridge, do staking e da governança — nenhum desses elementos foi examinado nesta análise. Além disso, esta verificação automática deve ser distinguida das auditorias do contrato do token no Ethereum, publicadas por empresas especializadas.

Os dados foram obtidos pela GoPlusLabs Token Security API (BSC, chain 56) — maio de 2026. Esta verificação é atualizada manualmente; para os dados mais recentes, consulte GoPlusLabs e BscScan.

O que vale a pena acompanhar

Os próximos marcos essenciais, em ordem de importância:

  1. 1. A publicação de auditorias completas do protocolo Layer 2 e do bridge, realizadas por empresas independentes reconhecidas
  2. 2. A definição e a documentação da solução para a disponibilidade dos dados
  3. 3. A implementação e o teste do forced inclusion e do forced exit na testnet
  4. 4. A abertura da testnet pública a desenvolvedores fora do grupo selecionado
  5. 5. A publicação da especificação técnica sobre a descentralização do sequencer
  6. 6. A publicação de um repositório GitHub com o código-fonte do núcleo do sistema