Ordlista

Periodisk publicering av ett State Commitment från rollupen på Bitcoins baslager. Förankringen fastställer ett tillståndsåtagande och gör det möjligt att upptäcka senare ändringar; i sig själv garanterar den dock varken tillståndets korrekthet, datatillgängligheten eller säkerheten i bridgen.

Opcode i Bitcoins skriptspråk, med vilken upp till 80 byte godtyckliga data kan bäddas in i en transaktion, varvid outputen bevisligen görs omöjlig att förbruka. Den kan användas för att förankra State Commitments.

Uppgradering av Bitcoin (BIP 341/342, aktiverad i november 2021) som introducerar Schnorr-signaturer och MAST. Den förbättrar sekretessen, effektiviteten och flexibiliteten i skripten och är intressant med tanke på mer effektiva förankringsmekanismer.

Unspent Transaction Output (oförbrukad transaktionsoutput). Bitcoins bokföringsmodell: i stället för « konton » finns det « oförbrukade outputs » som motsvarar bestämda belopp. Den skiljer sig från kontomodellen som SVM och Ethereum använder.

Layer 2-lösning som utför transaktioner off-chain och periodiskt publicerar ett komprimerat tillstånd på baslagret (L1). Den kombinerar off-chain-skalbarheten med en säkerhet som — beroende på vald modell — bygger på L1.

Oberoende blockchain som är ansluten till L1 via en bridge. Dess säkerhet beror främst på dess egen konsensusmekanism och bridgens design, inte direkt på L1:s säkerhet.

Arkitektur som liknar en rollup och där de data som krävs för att rekonstruera tillståndet lagras utanför L1. Den kan sänka kostnaderna och öka kapaciteten, men inför ytterligare antaganden om datatillgängligheten: blir dessa data otillgängliga kan användarna förlora möjligheten att verifiera tillståndet eller ta ut sina medel.

Rollup som utgår från att tillståndsövergångarna är giltiga — därav beteckningen « optimistisk ». Den bygger på bedrägeribevis, med vilka felaktiga övergångar kan bestridas inom ett tidsfönster, på Ethereum vanligtvis sju dagar.

Rollup som använder giltighetsbevis — ofta baserade på zero-knowledge-kryptografi — för att påvisa att tillståndsövergångarna följer protokollets regler. Den kan förkorta bekräftelsetiderna jämfört med en Optimistic Rollup, även om den faktiska finaliteten likaså beror på L1 och systemets design.

Exekverings-runtime utvecklad av Solana Labs. Den möjliggör parallell exekvering genom att kräva att varje transaktion explicit deklarerar de accounts den använder. Enligt projektet använder Bitcoin Hyper den som exekveringsmiljö.

Paralleliserings-runtime i SVM:en. Den analyserar de accounts som varje transaktion deklarerar och gör det möjligt att exekvera de transaktioner parallellt som inte står i konflikt med varandra. Den är en av de byggstenar som bidrar till Solanas prestanda och — enligt projektet — till den avsedda designen av Bitcoin Hyper.

Rust-framework för utveckling av SVM-program. Det tillför makron, konventioner och testverktyg som underlättar utvecklingen på Solana. Enligt projektet vill Bitcoin Hyper erbjuda en motsvarande toolchain; den faktiska kompatibiliteten återstår ännu att verifiera.

Bibliotek med standardprogram på SVM:en: tokens (SPL Token), staking, governance med mera. Enligt projektet eftersträvar Bitcoin Hyper kompatibilitet med SPL, vilket skulle möjliggöra återanvändning av tokens och program från Solana.

Komponent i rollupen som ordnar transaktionerna före deras exekvering. Den part som driver sequencern kan bestämma denna ordningsföljd — med konsekvenser för MEV och censur. Vid lanseringen av Bitcoin Hyper är det förutsett att den är centraliserad.

Värde som kan utvinnas genom att omordna, infoga eller utelämna transaktioner inom ett block eller en batch. En centraliserad sequencer kan förfoga över betydande möjligheter att skumma eller påverka rollupens MEV.

Mekanism som ger användarna möjlighet att « framtvinga » att en transaktion tas med via Bitcoins L1 och därigenom kringgå en sequencer som skulle utöva censur. I Bitcoin Hyper var denna funktion den 28 april 2026 fortfarande under utveckling.

Bitcoin Hypers officiella bridge som möjliggör överföring av BTC från L1 till rollupen och omvänt. Vid lanseringen: federerad eller centraliserad förvaring med de därtill knutna tillitsantagandena. Roadmapen förutser en gradvis decentralisering som ännu återstår att verifiera.

Mekanism som ger användarna möjlighet att ta ut sina medel ur rollupen, även när sequencern eller bridgen inte medverkar, genom att använda Bitcoins L1. Det rör sig om en kritisk säkerhetsfunktion som fortfarande är under utveckling.

Garanti för att data från alla transaktioner är offentligt tillgängliga. Saknas dessa data kan ingen rekonstruera rollupens tillstånd. Hos Bitcoin Hyper undersöks den slutgiltiga lösningen fortfarande.

Komprimerad representation — vanligtvis en Merkle-rot — av rollupens fullständiga tillstånd vid en given tidpunkt. Den publiceras periodiskt som förankring på Bitcoin; denna publicering motsvarar inte en fullständig verifiering av tillståndet.

Trädformad datastruktur där varje föräldranod motsvarar hashen av sina barnnoder. Den möjliggör effektiva bevis — Merkle-bevis — för att data ingår i mängden, utan att avslöja hela mängden.

Token som projektdokumentationen framställer som Bitcoin Hypers native token. Det annonserade totala utbudet uppgår till 21 miljarder. Enligt den offentliggjorda dokumentationen är det avsett att användas för att betala avgifter, delta i staking och — vid en senare tidpunkt — i governance-mekanismerna. Den annonserade fördelningen är följande: 25 % Treasury, 30 % utveckling, 20 % marknadsföring, 15 % belöningar och 10 % listningar.

Mekanism för gradvis frisläppning av tokens över tid. Enligt de villkor som offentliggjorts för förförsäljningen skulle $HYPER ha en vesting-period på sju dagar.

Händelse där ett token skapas och distribueras för första gången. Enligt whitepapret ska säkerhetsgranskningarna vara avslutade före Bitcoin Hypers TGE.

Det samlade värdet av de tillgångar som är placerade i ett nätverks DeFi-protokoll. Det rör sig om en indikator som används för att mäta spridningen och tilliten inom ett ekosystem.

DeFi-protokoll som använder matematiska formler — vanligtvis x*y=k — för att fastställa priserna vid växling utan att använda en traditionell orderbok.

Tjänst som för in data från den verkliga världen i blockchainen — priser, händelser och så vidare. Den är av central betydelse för DeFi: lån, derivat och talrika kontrakt är beroende av tillförlitliga externa prisdata.

Kryptografiskt bevis som påvisar att en tillståndsövergång är ogiltig. Det används i Optimistic Rollups för att bestrida bedrägliga tillstånd under bestridandeperioden.

Granskning av källkoden utförd av oberoende experter i syfte att identifiera möjliga sårbarheter. I Bitcoin Hypers fall har projektet aviserat offentliggörande av granskningar före TGE; per den 28 april 2026 kunde ingen offentlig granskningsrapport om protokollet eller bridgen konstateras.

Den tidpunkt från vilken en transaktion enligt systemets regler och antaganden betraktas som oåterkallelig. I den design som beskrivs för Bitcoin Hyper skulle tillståndsåtagandena efter sin publicering samla bekräftelser på Bitcoin; detta garanterar inte i sig själv vare sig tillståndets giltighet eller möjligheten att ta ut medlen.

Betalningsnätverk på Bitcoin baserat på kanaler. Det är först och främst utformat för snabba och billiga betalningar och erbjuder inte en universell smart contract-miljö som kan jämföras med en virtuell maskin. Det har varit i produktion sedan 2018.

Smart contract-nätverk som är anslutet till Bitcoin och använder PoX-mekanismen (Proof of Transfer). Det förfogar över ett eget språk, Clarity, och lagrar information om sina block i Bitcoin.

Bitcoin-sidechain som är kompatibel med EVM och använder merge-mining. Den använder RBTC, en tillgång knuten till BTC, som token för betalning av gas. Den har varit i drift sedan 2018.