Guide de référence
Qu’est-ce que Bitcoin Hyper ?
Bitcoin Hyper se présente comme une proposition de rollup Layer 2 pour Bitcoin qui utiliserait la Solana Virtual Machine comme environnement d’exécution. Cette page en présente les fondements et l’architecture proposée.
⚠ Documenté ou annoncé
Ce site distingue systématiquement ce qui est documenté et vérifiable — par exemple les éléments observables sur la devnet — de ce qui est annoncé ou encore en développement. Cette distinction est indiquée explicitement tout au long de la page.
L’architecture à trois couches
Bitcoin — la couche de règlement
Dans l’architecture proposée, Bitcoin remplit la fonction de couche de règlement et d’ancrage. Selon la documentation du projet, le rollup Hyper publierait périodiquement sur Bitcoin son state commitment — une racine de Merkle de l’état courant — via OP_RETURN ou Taproot. Cet ancrage permettrait d’enregistrer des engagements d’état et de détecter des modifications ultérieures, mais il ne garantit pas à lui seul l’exactitude de l’état, la disponibilité des données ni la sécurité du bridge.
État déclaré : architecture décrite dans le livre blanc | ancrage périodique en développement
Hyper Rollup — la couche d’exécution
L’architecture proposée comprend quatre composants principaux : l’exécution (la SVM avec la parallélisation de Sealevel), le séquencement (l’ordonnancement des transactions, centralisé au lancement), la disponibilité des données (l’emplacement des données complètes des transactions, encore à l’étude) et le bridge (le Canonical Bridge BTC↔Hyper, en phase de test sur la devnet).
État déclaré : SVM opérationnelle sur la devnet selon le projet | disponibilité des données et inclusion forcée en développement
Applications — la couche utilisateur
La couche destinée aux applications telles que les protocoles DeFi, les DEX, les marchés de NFT, les prêts, les stablecoins, les jeux et les outils de conformité réglementaire. Selon la documentation du projet, les programmes seraient développés en Rust avec Anchor et une chaîne d’outils similaire à celle de Solana. La compatibilité réelle et les adaptations nécessaires devront être vérifiées au moyen d’une documentation technique et de tests indépendants.
État déclaré : premiers programmes SVM testés sur la devnet selon le projet | écosystème d’applications en cours de formation
Les quatre composants d’un rollup
Tout rollup, et pas seulement Bitcoin Hyper, repose sur ces quatre piliers.
Exécution
La machine virtuelle qui exécute les smart contracts. L’architecture proposée pour Hyper utilise la SVM avec le runtime Sealevel pour la parallélisation. Les transactions affectant des comptes distincts peuvent être exécutées en parallèle, ce qui peut accroître la capacité de traitement.
◎ Opérationnelle sur la devnet selon le projetSéquencement
Le composant qui détermine l’ordonnancement des transactions. Il en fixe la séquence, avec des implications pour le MEV et la censure. Le projet prévoit initialement un sequencer unique et centralisé. Selon la feuille de route, la décentralisation interviendrait dans un délai de deux à quatre ans.
⚠ Centralisé au lancementRèglement
L’ancrage périodique du state commitment sur Bitcoin. Chaque ancrage publierait la racine de Merkle de l’état mis à jour. La documentation décrit une fréquence adaptative : un ancrage plus fréquent pourrait réduire le délai jusqu’à la finalité, mais augmenterait le coût des frais sur Bitcoin.
◎ En développementDisponibilité des données
La disponibilité des données détermine où sont stockées et comment sont mises à disposition les données nécessaires pour reconstruire les transactions et l’état. Si ces données n’étaient pas accessibles publiquement, le système s’éloignerait du modèle de rollup à disponibilité publique des données et se rapprocherait d’un schéma de type validium. Au 28 avril 2026, la solution définitive était encore à l’étude.
⚠ À l’étude💡 Points clés
- • Bitcoin Hyper se présente comme un rollup avec exécution hors chaîne et engagements d’état ancrés sur Bitcoin
- • Selon le projet, la SVM vise à apporter programmabilité et compatibilité avec l’écosystème de développement de Solana ; ces deux éléments devront être vérifiés
- • La conception initiale prévoit un sequencer centralisé et un bridge fédéré, avec une feuille de route de décentralisation sur deux à quatre ans
- • La disponibilité des données et l’inclusion forcée restent en développement : ce sont des jalons critiques avant la mainnet
- • Le projet le présente comme un rollup, et non comme une sidechain. Le niveau de sécurité hérité de Bitcoin dépendra de la conception effective de l’ancrage, de la disponibilité des données, du bridge et des mécanismes de vérification