Livre blanc annoté

Cette affirmation doit être nuancée. Selon l’architecture décrite, Bitcoin Hyper prévoit de publier des engagements d’état sur Bitcoin. Cet ancrage ne garantit pas à lui seul l’exactitude de l’état, la disponibilité des données ni la sécurité du bridge. En outre, la conservation des BTC dans le bridge est décrite comme fédérée ou centralisée au lancement ; une défaillance ou une compromission du bridge pourrait donc mettre les actifs en danger.

La documentation du projet décrit un environnement d’exécution fondé sur la SVM et une compatibilité avec les outils de l’écosystème Solana. La compatibilité effective du code, d’Anchor, de la CLI et des programmes système devra être vérifiée au moyen d’une documentation technique publique et de tests indépendants. Les frais seraient payés en $HYPER, et non en SOL.

L’architecture proposée est cohérente avec l’exécution parallèle de Sealevel, mais aucune mesure de performance spécifique à Bitcoin Hyper n’a été publiée. La capacité effective dépendra également du sequencer, de la disponibilité des données et de l’implémentation finale.

Non respecté à la date indiquée. Au 28 avril 2026, la mainnet n’était toujours pas opérationnelle. La documentation publique disponible ne permet pas d’attribuer avec certitude ce retard à une cause unique ; les jalons encore en attente concernant le bridge, les audits et les autres composants devront être vérifiés avant le lancement.

Au 28 avril 2026, deux rapports publics concernant le contrat ERC-20 de $HYPER avaient été identifiés, mais aucun rapport public d’audit du protocole Layer 2 ou du bridge. L’engagement de publier des audits avant le TGE restait donc à vérifier pour ces composants.