Covenant je podmínka, která může určit nejen to, kdo smí bitcoiny utratit, ale také podobu jejich dalšího převodu. Například může požadovat, aby peníze nejprve prošly výstupem s čekací dobou. Omezení je součástí pravidel daného výstupu, ne pouhým nastavením aplikace. Covenants označuje celou rodinu konstrukcí a návrhů, nikoli jednu funkci dostupnou v každé peněžence.
Anna má úspory v Bitcoinu. Peněženka je aplikace nebo zařízení pro přijímání a odesílání bitcoinů. Zůstatek, který vidí v peněžence, tvoří dosud neutracené výstupy dřívějších transakcí, označované UTXO. Každý takový výstup obsahuje částku a podmínky pro její utracení. Ty jsou zapsány v krátkém programu zvaném Bitcoin Script. Digitální podpis dokládá oprávnění k platbě pomocí soukromého klíče, tajného číselného údaje, aniž by jej odhalil. Multisig může vyžadovat více podpisů a Timelock, tedy časový zámek, přidává čekání. Covenant může navíc omezit podobu následující transakce, třeba výstupy, do kterých musí peníze přejít. Takové pravidlo by musel splnit i zloděj se správným klíčem. Rozhodují ovšem všechny dostupné cesty utracení: pokud jiná větev dovolí omezení obejít, nelze na něj spoléhat. [1] [5] [9] [11]
Představme si, že Anna uloží úspory do trezoru s prodlevou. Trezorem zde nemyslíme zvláštní zařízení, ale uspořádání pravidel utrácení. Její běžný klíč by mohl zahájit výběr, peníze by však nejprve přešly do čekacího výstupu. Teprve po uplynutí prodlevy by je šlo poslat zamýšlenému příjemci. Kdyby výběr zahájil zloděj, Anna by během čekání mohla využít předem připravenou záchrannou cestu a přesunout prostředky pod bezpečnější podmínky. Musí si ale výběru všimnout a dostat záchrannou transakci včas do bloku. Blok sdružuje transakce do dávky, která se připojuje ke společné historii. Nejde o vrácení dokončené platby ani o automatickou záchranu bez jejího zásahu. Přesné možnosti závisejí na konstrukci trezoru. [6] [10]
Slib aplikace, že s výběrem počká, může zůstat jen slibem jejího provozovatele. Pravidlo v bitcoinovém skriptu naproti tomu kontrolují uzly, tedy programy ověřující transakce podle společných pravidel sítě. U odpovídající covenantové konstrukce mají odmítnout převod, který omezení poruší. Příkladem návrhu je OP_CHECKTEMPLATEVERIFY, zkráceně CTV. Popisuje jej BIP119; BIP je dokument s návrhem pro Bitcoin. CTV by porovnal hash vybraných údajů o právě ověřované transakci s otiskem uloženým předem. Hash si zde lze představit jako krátký kontrolní otisk dat. Změna předepsaného příjemce nebo částky by změnila tento otisk, takže převod neodpovídající šabloně by kontrolou neprošel. Samotný název „trezor“ v aplikaci takové vynucení nezaručuje. [2]
CTV váže transakci na předem připravenou šablonu, včetně jejích výstupů. Není to ale jediný zkoumaný přístup. BIP443 s příkazem OP_CHECKCONTRACTVERIFY navrhuje práci s výstupy, které nesou ověřitelný závazek k určitým údajům. Závazek zde znamená, že se k údajům nelze dodatečně přihlásit s jinou hodnotou, aniž by kontrola odhalila nesoulad. Údaje mohou popisovat stav kontraktu, například aktuální rozdělení společných prostředků; navazující výstup pak může nést aktualizovaný stav, pokud splní předepsaná pravidla. CTV a tento návrh proto nejsou dvě jména stejné věci. U každého je třeba zjistit, co musí být určeno předem, co se smí měnit později a jaké další nástroje celá konstrukce potřebuje. [2] [7]
Rekurzivní varianta dokáže požadovat, aby další výstup nesl znovu určité omezení. Pravidlo se tak může přenášet přes více transakcí, například při postupné změně stavu kontraktu. Neznamená to nekonečnou smyčku při ověřování jednoho skriptu. Výzkumníci Russell O’Connor a Marta Piekarska popsali takové konstrukce ve své práci z roku 2017; schopnost opakování je třeba posuzovat u konkrétního návrhu. [3]
Některá omezení lze připravit předem podepsanými transakcemi, časovými zámky a správou klíčů. Taková sestava však může vyžadovat spolehlivé smazání klíče, uchování všech transakcí nebo další spolupráci. Multisig spoléhající na to, že druhý podepisující odmítne nevhodnou platbu, má zase jiný předpoklad důvěry. Podobný uživatelský výsledek ještě neznamená stejné vynucení ani stejné možnosti obnovy. [5] [6]
Vedle trezorů se zkoumá sdílení UTXO a příprava plateb, jejichž vypořádání se rozloží v čase. Smyslem může být menší potřeba průběžné spolupráce nebo lepší využití prostoru v blocích. Z toho ale neplynou neomezené transakce ani jistota nízkých poplatků. Návrh musí popsat i odchod jednotlivého účastníka, nedostupnost ostatních a zaplacení poplatku při zahlcení sítě. [2] [7]
K 17. říjnu 2026 mají BIP119 a BIP443 stav Draft, tedy rozpracovaný návrh. Starší BIP345, OP_VAULT, má stav Closed, tedy uzavřený návrh, a uvádí BIP443 jako navrženou náhradu. Uzavření tohoto dokumentu neznamená konec výzkumu trezorů. Stejně tak přidělení čísla BIP neznamená, že síť změnu přijala. Zkušební síť nebo ukázková peněženka mohou funkci předvádět, i když pravidla hlavní bitcoinové sítě, mainnetu, nejsou změněna. U služby nabízející covenantový trezor proto ověřujte, na jaké síti a podle jakých pravidel skutečně funguje. [6] [8]
Příliš úzká šablona nebo chyba v částce, skriptu či poplatkovém postupu může znemožnit zamýšlené utracení. Další operace také rozšiřují to, co musí implementace bezpečně ověřovat. Změny konsenzu se proto posuzují podle přesné specifikace a chování při chybě. Covenant sám nedává cizímu člověku právo dodatečně změnit podmínky vašich již existujících UTXO. [4] [8]
U konkrétního řešení se ptejte, kdo může spustit výběr, kdo obnovu, jak dlouho lze reagovat a zda někdo musí průběžně sledovat řetězec. Zajímejte se také o zálohy, poplatky, možnost odejít a o síť, na které řešení opravdu funguje. Covenants mohou rozšířit vlastní kontrolu nad penězi; samotné slovo v popisu produktu ji ale nedokazuje. [3] [6]
Pro nejúplnější obraz čtěte toto heslo společně s Bitcoin Script, OP_CHECKTEMPLATEVERIFY, Timelock, Konsensuální pravidla, UTXO, Multisig. Opačným směrem na něj odkazují také OP_CHECKTEMPLATEVERIFY, Bitcoin Vault, OP_CAT, Ark.