Monitoring

Status projektu

Aktualizacja redakcyjna: 2026-10-10.

Aktualności · Testnet Bitcoin Hyper

Harmonogram uruchamiania testnetu

Zespół zapowiedział stopniowe uruchamianie przez sześć tygodni. Ogłoszony plan i zweryfikowana dostępność są przedstawione osobno.

Tydzień 1

Sieć testnet i RPC

Dostępne

Punkt dostępu do odpytywania sieci testowej.

Tydzień 2

Explorer

W przygotowaniuUruchomienie przewidziane w programie zespołu

Explorer: przeglądanie aktywności i stanu sieci.

Tydzień 3

Wallet

W przygotowaniuUruchomienie przewidziane w programie zespołu

Wallet: wyświetlanie natywnych sald HYPER w testnecie.

Tydzień 4

Faucet

W przygotowaniuUruchomienie przewidziane w programie zespołu

Faucet: otrzymywanie próbnych tokenów do testów.

Tydzień 5

Bridge

W przygotowaniuUruchomienie przewidziane w programie zespołu

Bridge: testowanie połączeń z Ethereum, Solana i Bitcoin.

Tydzień 6

Panel stakingu

W przygotowaniuUruchomienie przewidziane w programie zespołu

Panel do testów stakingu.

Zielony: potwierdzono dostęp do RPC. Żółty: planowane uruchomienie, dostępność jeszcze niezweryfikowana. „W przygotowaniu” opisuje ogłoszony program, nie techniczną kontrolę rozwoju.

Tygodnie odnoszą się do ogłoszenia zespołu i nie są pewnymi datami. Program jest odrębny od roadmapy na 2027 rok.

Zobacz pełny harmonogram →

Oficjalne ogłoszenie ·

Obecny etap

Testnet

Publiczne RPC · Stopniowe udostępnianie

Planowany mainnet

Q2 2027

Planowane · Źródła sprawdzone: 2026-10-10

Audyty · ocena historyczna

Opublikowano audyty tokena

SolidProof / Coinsult; nie zidentyfikowano w pełni publicznego audytu protokołu ani bridge'a

RPC Testnet

Dostępne

Obserwacja sieci przez RPC

Status kluczowych komponentów

Nowość: RPC testnetu jest dostępne, a ekosystem otwiera się stopniowo. Pozostałe karty zachowują wcześniejszy obraz devnetu; nie potwierdzają dostępności tych samych narzędzi na nowym testnecie.

✓ Na devnecie

Warstwa wykonawcza SVM

Według dokumentacji projektu programy SVM działają natywnie na devnecie. Projekt deklaruje, że przetestowano tokeny SPL, mechanizmy escrow oraz konfiguracje multisig.

◉ W toku

Sequencer (scentralizowany)

Według projektu jest on operacyjny na devnecie. Przy uruchomieniu mainnetu ma być scentralizowany i utrzymywany przez zespół.

✓ Na devnecie

Devnet explorer

Projekt utrzymuje publiczny devnet explorer.

◎ W budowie

Canonical bridge

Według dokumentacji projektu canonical bridge jest obecnie testowany na devnecie. Funkcja forced exit nie została jeszcze wdrożona, a początkowy model przechowywania środków ma charakter federacyjny.

◎ W budowie

Zakotwiczenie na Bitcoinie

Dokumentacja opisuje zakotwiczenie za pomocą OP_RETURN lub Taproot. Adaptacyjna częstotliwość zakotwiczenia jest wciąż w budowie.

◎ W budowie

Dostępność danych

Docelowe rozwiązanie jest wciąż przedmiotem analiz. Wśród rozważanych podejść znajdują się zewnętrzne warstwy dostępności danych, erasure coding oraz rozproszone węzły.

○ Planowane

Forced inclusion i forced exit

Mechanizm odporności na cenzurę. Wciąż w budowie i niedostępny na devnecie.

◎ W budowie

System dowodowy (ZK/fraud)

Projekt deklaruje, że rozwija hybrydowy model łączący fraud proofs i validity proofs. Według jego dokumentacji system ten nie miałby być aktywny przy początkowym uruchomieniu.

○ Planowane

Audyty bezpieczeństwa

Zidentyfikowano publiczne audyty kontraktu tokena, przeprowadzone między innymi przez SolidProof i Coinsult. Audyt SolidProof dotyczy wyłącznie pojedynczego kontraktu tokena, a nie protokołu Layer 2, bridge'a ani innych kontraktów. W ramach niniejszej analizy nie zidentyfikowano w pełni publicznego audytu protokołu ani bridge'a.

◉ W toku

Publiczny testnet

Zespół ogłosił RPC testnetu oraz stopniowe udostępnianie eksploratora, portfela, faucetu, mostu i stakingu. Nasze niezależne obserwatorium odczytuje aktywność sieci bez portfela.

○ Planowane

Mainnet

Wstępny plan, opisany przez projekt, zakłada scentralizowany sequencer oraz bridge działający w modelu federacyjnym. Uruchomienie zależy przede wszystkim od zakończenia audytów i budowy canonical bridge.

○ Planowane

Decentralizacja sequencera

Mapa drogowa przewiduje okres 2–4 lat po uruchomieniu mainnetu: rotację, aukcje oraz wybór lidera.

Oś czasu kluczowych aktualizacji

Październik 2026 Publiczny testnet · RPC

Testnet otwiera się na społeczność. Zespół ogłosił RPC testnetu oraz stopniowe udostępnianie eksploratora, portfela, faucetu, mostu i stakingu. Przeczytaj oficjalne ogłoszenie ↗

Lipiec 2026 Książka

Premiera angielskiego wydania tomu I książki „Due Diligence of a Layer 2 – The Bitcoin Hyper Case” autorstwa Michele Stefanellego: niezależna analiza techniczna projektu — 523 strony i 24 rozdziały; całość dzieła obejmuje 36 rozdziałów.

Marzec 2026 Komunikat zespołu

Według komunikatu opublikowanego przez projekt, docelowe rozwiązanie w zakresie dostępności danych było wciąż przedmiotem analiz, a rozważano już kilka podejść.

Koniec 2025 Devnet

Według dokumentacji projektu programy SVM działają natywnie, z aktywnym explorerem oraz pierwszymi testami implementacji DeFi, tokenów SPL, escrow i multisig, prowadzonymi z wybranymi deweloperami.

II–IV kw. 2025 Przedsprzedaż i staking

Token $HYPER jest oferowany w publicznej, wieloetapowej przedsprzedaży. Według projektu staking jest aktywny, a wybranym partnerom i deweloperom udostępniono selektywny devnet.

II kw. 2025 Fundamenty

Wstępna architektura, whitepaper v1 oraz utworzenie głównego zespołu projektu.

Zautomatyzowany przegląd kontraktu

GoPlusLabs · maj 2026

✓ Zebrane dane

✓
Kod źródłowy zweryfikowany Kod źródłowy opublikowany i zweryfikowany na BscScan
✓
Brak proxy Kontraktu nie można zaktualizować za pomocą wzorca proxy
✓
Brak funkcji mint Nowe tokeny nie mogą być tworzone po wdrożeniu kontraktu
✓
Zrzeczenie się własności Adres właściciela: 0x000…0000 (dead address)
✓
Brak ukrytego właściciela Brak ukrytej funkcji przenoszenia własności
✓
Brak funkcji self-destruct Kontrakt nie może zostać jednostronnie zniszczony
✓
Brak blacklisty Brak mechanizmu blokowania konkretnych adresów
✓
Brak whitelisty Brak selektywnych ograniczeń transferów
✓
Opłata 0% przy zakupie, sprzedaży i transferze Od transakcji nie jest pobierana żadna opłata
✓
Opłat nie można zmieniać Opłaty nie mogą zostać podwyższone po wdrożeniu kontraktu
✓
Mechanizm anti-whale niemodyfikowalny Zespół nie ma możliwości zmiany limitu posiadanych tokenów

⚠ Kwestie wymagające szczególnej uwagi

⚠
Ryzyko związane z wywołaniami zewnętrznymi Kontrakt wykonuje wywołania zewnętrzne. GoPlusLabs sygnalizuje ryzyko re-entrancy lub nieoczekiwanego działania w przypadku aktualizacji jego zależności.
⚠
Możliwy honeypot Automatyczna weryfikacja GoPlusLabs zwróciła podczas symulacji wskaźnik możliwego honeypota. Nie było możliwe niezależne zweryfikowanie sprzedaży.
⚠
Obecność mechanizmu anti-whale Mechanizm anti-whale — limit posiadania — jest obecny, choć nie można go modyfikować. Może to wpływać na płynność we wczesnej fazie.

Nota redakcyjna

Automatyczne kontrole GoPlusLabs nie zastępują formalnego audytu przeprowadzonego przez wyspecjalizowaną, niezależną firmę (na przykład CertiK, Quantstamp czy Hacken). Wskaźnik „possible honeypot” wymaga ręcznej weryfikacji: kontrakt może zwrócić wynik pozytywny w symulacji ze względu na logikę warunkową powiązaną z płynnością lub z blokadą (lock). Brak funkcji mint oraz zrzeczenie się własności to strukturalnie pozytywne sygnały, nie gwarantują one jednak ogólnego bezpieczeństwa protokołu, które zależy również od canonical bridge, stakingu i governance — żaden z tych elementów nie został zbadany w niniejszej analizie. Ponadto tę automatyczną kontrolę należy odróżnić od audytów kontraktu tokena na Ethereum publikowanych przez wyspecjalizowane firmy.

Dane pobrano za pomocą GoPlusLabs Token Security API (BSC, chain 56) — maj 2026. Ten przegląd jest aktualizowany ręcznie; po najbardziej aktualne dane prosimy sięgnąć do serwisów GoPlusLabs i BscScan.

Punkty do obserwacji

Kolejne kluczowe kamienie milowe, w porządku ważności:

  1. 1. Publikacja pełnych audytów protokołu Layer 2 oraz bridge'a, przeprowadzonych przez uznane niezależne firmy
  2. 2. Określenie i udokumentowanie rozwiązania w zakresie dostępności danych
  3. 3. Wdrożenie i przetestowanie forced inclusion oraz forced exit na testnecie
  4. 4. Udostępnienie publicznego testnetu deweloperom spoza grona wybranych uczestników
  5. 5. Publikacja specyfikacji technicznej decentralizacji sequencera
  6. 6. Publikacja repozytorium GitHub z kodem źródłowym rdzenia systemu