Monitoring

Projektstatus

Zugriffsdatum heute — Quelle: offizielle Mitteilungen des Bitcoin-Hyper-Teams, veröffentlicht auf bitcoinhyper.com

Aktuelle Phase

Devnet

Selektiver Zugang

Geschätztes Mainnet

Q3–Q4 2026

Abhängig vom Audit

Öffentliche Audits

Token-Audits veröffentlicht

Coinsult / SolidProof (Token-Contract); ein vollständiges öffentliches Audit des Protokolls oder der Bridge wurde nicht identifiziert

SVM im Devnet

Funktionsfähig

Nach Angaben des Projekts; Rust-/Anchor-Programme getestet

Status der Kernkomponenten

✓ Im Devnet

SVM-Ausführungsebene

Nach der Dokumentation des Projekts laufen SVM-Programme nativ im Devnet. Das Projekt gibt an, dass SPL-Token, Escrow und Multisignatur-Konfigurationen getestet wurden.

◉ Läuft

Sequencer (zentralisiert)

Nach Angaben des Projekts im Devnet funktionsfähig. Zum Mainnet-Start soll er zentralisiert und vom Team betrieben sein.

✓ Im Devnet

Devnet-Explorer

Für das Devnet steht ein öffentlicher Explorer zur Verfügung.

◎ In Entwicklung

Kanonische Bridge

Nach der Dokumentation des Projekts wird die kanonische Bridge im Devnet getestet. Der Forced Exit ist bislang nicht implementiert. Das Verwahrmodell ist föderiert.

◎ In Entwicklung

Verankerung an Bitcoin

Die Architektur ist definiert (OP_RETURN/Taproot). Die adaptive Verankerungsfrequenz befindet sich in Entwicklung.

◎ In Entwicklung

Data Availability

Die endgültige Lösung ist weiterhin Gegenstand der Forschung. Untersuchte Ansätze: externe DA-Ebenen, Erasure Coding, verteilte Knoten.

○ Geplant

Forced Inclusion / Forced Exit

Mechanismus zur Zensurresistenz. Weiterhin in Entwicklung und im Devnet nicht verfügbar.

◎ In Entwicklung

Proving System (ZK/Fraud)

In Entwicklung ist ein hybrides Modell aus Fraud Proofs und Validity Proofs. Nach der Dokumentation des Projekts soll es zum Start nicht aktiv sein.

○ Geplant

Sicherheitsaudits

Das Projekt gibt an, dass die Audits vor dem TGE vorliegen sollen. Öffentliche Audits des Token-Contracts wurden identifiziert (Coinsult, SolidProof); das SolidProof-Audit betrifft ausschliesslich einen einzigen Token-Contract, nicht das Layer-2-Protokoll, die Bridge oder weitere Contracts. Ein vollständiges öffentliches Audit des Protokolls oder der Bridge wurde nicht identifiziert.

○ Geplant

Öffentliches Testnet

Öffnung für Entwickler und die breitere Community. Phase vor dem Mainnet.

○ Geplant

Mainnet

Zentralisierter Sequencer, föderierte Bridge. Abhängig vom Abschluss der Audits und der Bridge.

○ Geplant

Dezentralisierung des Sequencers

Roadmap von 2–4 Jahren ab Mainnet. Rotation, Auktionen, Leader-Wahl.

Zeitleiste der wichtigsten Aktualisierungen

Juli 2026 Buch

Erscheinen des Buches „Due Diligence of a Layer 2 – The Bitcoin Hyper Case, Band I“ von Michele Stefanelli — die erste unabhängige technische Analyse des Projekts (523 Seiten, 24 Kapitel; Gesamtwerk: 36 Kapitel). In Vorbereitung.

März 2026 Mitteilung des Teams

Offizieller Beitrag: Die endgültige Lösung für die Data Availability ist weiterhin Gegenstand der Forschung. Mehrere Ansätze werden geprüft.

Ende 2025 Devnet

Nach der Dokumentation des Projekts laufen SVM-Programme nativ. Der Explorer ist in Betrieb. Erste Tests zu DeFi, SPL-Token, Escrow und Multisignatur mit ausgewählten Entwicklern.

Q2–Q4 2025 Presale und Staking

Verteilung des Tokens $HYPER. Nach Angaben des Projekts ist Staking aktiviert. Das selektive Devnet wurde für ausgewählte Partner und Entwickler geöffnet.

Q2 2025 Gründungsphase

Ursprüngliche Architektur, Whitepaper v1, Bildung des Kernteams.

Prüfung des Contracts

GoPlusLabs · Mai 2026

✓ Erhobene Daten

✓
Verifizierte Quelle Quellcode auf BscScan veröffentlicht und verifiziert
✓
Kein Proxy Der Contract lässt sich nicht über ein Proxy-Muster aktualisieren
✓
Keine Mint-Funktion Nach dem Deployment können keine neuen Token erzeugt werden
✓
Eigentum aufgegeben Adresse des Eigentümers: 0x000…0000 (Dead Address)
✓
Kein verdeckter Eigentümer Keine verborgene Funktion zur Übertragung des Eigentums
✓
Kein Self-Destruct Der Contract kann nicht einseitig zerstört werden
✓
Keine Blacklist Kein Mechanismus zum Sperren bestimmter Adressen
✓
Keine Whitelist Keine selektive Beschränkung von Transfers
✓
0 % Steuer bei Kauf/Verkauf/Transfer Auf Transaktionen wird keine Gebühr erhoben
✓
Steuer nicht veränderbar Gebühren können nach dem Deployment nicht erhöht werden
✓
Anti-Whale nicht veränderbar Das Team kann die Haltegrenze nicht ändern

⚠ Punkte, die Aufmerksamkeit erfordern

⚠
Risiko externer Aufrufe Der Contract führt externe Aufrufe aus. GoPlusLabs weist auf das Risiko von Re-Entrancy oder unerwartetem Verhalten hin, falls abhängige Contracts aktualisiert würden.
⚠
Möglicher Honeypot Die automatisierte Prüfung von GoPlusLabs meldete bei der Simulation einen möglichen Honeypot. Ein Verkauf konnte nicht unabhängig verifiziert werden.
⚠
Anti-Whale vorhanden Ein Anti-Whale-Mechanismus (Haltegrenze) ist vorhanden, wenngleich er nicht veränderbar ist. Er kann die Liquidität in der frühen Phase beeinflussen.

Redaktioneller Hinweis

Die automatisierten Prüfungen von GoPlusLabs ersetzen kein formales Audit durch eine spezialisierte unabhängige Prüfgesellschaft (etwa CertiK, Quantstamp oder Hacken). Der Hinweis „possible honeypot“ erfordert eine manuelle Überprüfung im Testnet: Ein Contract kann in der Simulation aufgrund bedingter Logik, die an Liquidität oder an einen Lock gekoppelt ist, ein positives Ergebnis liefern. Das Fehlen einer Mint-Funktion und die Aufgabe des Eigentums sind strukturell positive Indikatoren, garantieren jedoch nicht die Gesamtsicherheit des Protokolls, die auch von den Contracts für Bridge, Staking und Governance abhängt, die in dieser Übersicht nicht untersucht werden.

Daten erhoben über die GoPlusLabs Token Security API (BSC, Chain 56) — Mai 2026. Diese Übersicht wird manuell aktualisiert; die aktuellsten Angaben finden Sie bei GoPlusLabs und BscScan.

Signale, die es zu beobachten gilt

Die nächsten kritischen Meilensteine (nach Wichtigkeit geordnet):

  1. 1. Veröffentlichung der ersten Sicherheitsaudits durch anerkannte unabhängige Prüfgesellschaften
  2. 2. Festlegung und Dokumentation der Data-Availability-Lösung
  3. 3. Umsetzung und Test von Forced Inclusion / Forced Exit im Testnet
  4. 4. Öffnung des öffentlichen Testnets für Entwickler ausserhalb der ausgewählten Gruppe
  5. 5. Veröffentlichung der technischen Spezifikation zur Dezentralisierung des Sequencers
  6. 6. Veröffentlichung des GitHub-Repositorys mit dem Kern des Codes