Bankovní sítě se potřebují domluvit. Cacti ukazuje, proč propojení vyžaduje i jasnou odpovědnost

Tokenizované aktivum může v jedné síti fungovat bezchybně a přesto být obtížně použitelné u jiné instituce. Problém nemusí spočívat v rychlosti. Každá strana může jinak určovat oprávněného vlastníka, okamžik dokončení převodu nebo postup při výpadku. Spojení dvou technologií tak otevírá otázky, které jednotlivé systémy samostatně řešit nemusely.

Zářijové zprávy kolem LF Decentralized Trust připomínají dvě souběžné změny: do otevřeného vývoje vstupují další finanční instituce a infrastruktura Cacti rozšiřuje nástroje pro spolupráci nezávislých sítí. Pro firmy je podstatná schopnost bezpečně dokončit konkrétní obchod a doložit jeho výsledek. Počet propojených databází je až pomocným ukazatelem.

Shrnutí pro čtenáře

• LF Decentralized Trust oznámila 24. září patnáct nových členů včetně Swiftu a Wells Fargo; členství samo nedokládá jejich ostré nasazení Cacti.

• Cacti 3.0 přináší nástroje pro převod aktiv, sledování událostí a audit mezi různými sítěmi. Verze byla zveřejněna již v srpnu, zářijové zprávy ji představují širšímu trhu.

• Související protokol SATP je k datu ověření stále ve standardizačním procesu IETF. Technická kompatibilita neřeší automaticky smlouvy, přijatelnost aktiv ani odpovědnost provozovatelů.

Dvě zprávy, které se nemají slévat

Oznámení LF Decentralized Trust z 24. září uvádí patnáct nových členů a vedle toho shrnuje vývoj několika projektů. Mezi členy figurují Swift a Wells Fargo. Dokument zmiňuje i Cacti 3.0, nové iniciativy a odborné akce.

Z takového souběhu nelze vyvodit, že všechny jmenované banky používají všechny prezentované produkty. Členství představuje účast v ekosystému otevřeného vývoje. Doklad konkrétního provozu by musel uvést použité řešení, roli instituce, rozsah transakcí a provozní podmínky.

Stejně důležitá je časová přesnost. Repozitář eviduje vydání Cacti 3.0.0 dne 19. srpna, zatímco podrobný blog projektu vyšel 10. září. Zářijová členská zpráva tedy neznamená, že software vznikl až v den jejího zveřejnění.

Co se mění při přenosu mezi sítěmi

Cacti 3.0 podle projektového přehledu posiluje převody přes SATP-Hermes, přidává práci s ověřitelnými pohledy na více sítí a rozšiřuje sledování událostí. Provozní nástroje zahrnují auditní rozhraní a uchování záznamů. Oddělení samotného protokolu od adaptérů jednotlivých sítí má usnadnit jejich připojování.

Představme si modelovou situaci: podnik vlastní digitálně evidovaný nárok v systému své banky a potřebuje jej použít u jiné instituce. Nestačí odeslat zprávu, že nárok existuje. Přijímající strana musí vědět, zda je převod dovolený, zda původní záznam nezůstává současně volně použitelný a jak pozná konečný výsledek.

Právě koordinace změn stavu je jiný problém než prosté sdílení informací. Zobrazení zůstatku může pomoci při kontrole. Samo ještě nepřevádí práva. Tato odlišnost vysvětluje, proč má infrastruktura více součástí a proč univerzální tvrzení „sítě jsou propojené“ neposkytuje dost podkladů pro obchodní rozhodnutí.

Protokol počítá s provozovateli, kteří něco garantují

Návrh architektury SATP pracuje s bránami mezi sítěmi. Předpokládá identifikované vlastníky těchto bran, podepisování zpráv a odpovědnost provozovatelů za příslušné jednání. Před převodem se ověřuje vlastnictví aktiva, oprávnění k převodu a přijatelnost jeho druhu na cílové straně.

To je pro neprogramátora zásadní informace. Propojení nespočívá v tom, že by technika odstranila potřebu důvěry. Důvěra dostává konkrétní místa a kontrolní podmínky. Smlouva musí určit, kdo za bránu odpovídá, co přesně potvrzuje a jak se řeší spor mezi technickým záznamem a právním nárokem.

V podnikové praxi proto dává smysl začít jednoduchým přehledem rolí. Kdo požadavek zadává, kdo jej schvaluje, kdo potvrzuje dokončení a kdo komunikuje při neúspěchu? Pokud dodavatelé odpovídají odlišně, není projekt připraven jen proto, že se mezi jejich systémy podařilo poslat testovací zprávu.

Zkouška výpadku řekne více než hladká ukázka

Dokumentace SATP-Hermes a vydání Cacti popisují nástroje, které mají pomoci sledovat průběh přenosů. Návrh architektury IETF se věnuje také obnově po pádu brány. Rozsah konkrétní implementace a její ověření však zůstávají samostatnou otázkou.

Pro objednatele je vhodným testem okamžik, kdy první systém převod zahájil, ale druhý ještě nepotvrdil konec. Musí být možné určit, zda aktivum čeká, bylo převedeno, nebo se má proces vrátit. Opakovaný pokyn nesmí bez kontroly vytvořit druhý obchod. Obsluha potřebuje jednoznačný postup a dohledatelnou historii.

Tyto požadavky jsou redakčním návrhem přejímací zkoušky, nikoli tvrzením, že zveřejněná verze automaticky pokrývá každou kombinaci sítí. Otevřený zdrojový kód umožňuje kontrolu a úpravy. Nenahrazuje odpovědnost integrátora za konkrétní konfiguraci, zabezpečení a provozní podporu.

Standard vzniká postupně

Pracovní skupina IETF SATP zveřejňuje návrhy protokolu, architektury a případů použití. K 25. září jsou příslušné dokumenty stále návrhy v probíhajícím procesu. Označení Internet-Draft se proto nemá v článku ani nabídce služby změnit na hotový schválený standard.

Základní návrh protokolu usiluje o společný způsob koordinace převodu mezi bránami. Pro investici do integrace je to užitečný směr, ale také důvod pracovat s verzemi. Smlouva a technická dokumentace by měly pojmenovat konkrétní podporovanou podobu protokolu a pravidla její aktualizace.

Firma se tak vyhne situaci, kdy dva dodavatelé oba slibují podporu stejné zkratky, ale každý myslí jinou verzi nebo jinou část funkcí. Praktická kompatibilita vzniká až ověřením společného scénáře, nikoli porovnáním log na prezentaci.

Co si z toho mohou odnést české a slovenské firmy

Při výběru řešení má cenu požadovat popis jednoho skutečného toku: odkud aktivum přichází, kdo jej přijímá, jaké právo přetrvává po převodu a jak se doloží výsledek. Následuje cena propojení, náklady jeho údržby a postup při změně poskytovatele. Obecná podpora velkého množství sítí je užitečná teprve tehdy, když odpovídá potřebám firmy.

Dobře navržený pilot může začít jediným druhem aktiva a dvěma známými protistranami. Vedle úspěšné transakce má obsahovat odmítnutí, přerušení a obnovu. Měřit lze počet ručních zásahů, dobu blokace aktiva a schopnost rekonstruovat průběh. Tyto výsledky jsou pro vedení firmy srozumitelnější než počet technických konektorů.

Cacti přináší konkrétní stavební prvky pro takové ověřování. Jeho širší význam spočívá v posunu pozornosti od izolovaného zápisu k řízenému přenosu mezi institucemi. O tom, zda se tento přenos hodí pro reálný obchod, rozhodnou společně technologie, smluvní uspořádání a lidé odpovědní za provoz.

Zdroje

LF Decentralized Trust: patnáct nových členů, 24. 9. 2026

LF Decentralized Trust: Hyperledger Cacti v3, 10. 9. 2026

GitHub: vydání Cacti v3.0.0, 19. 8. 2026

Cacti: dokumentace SATP-Hermes

IETF: pracovní skupina SATP a stav dokumentů

IETF: návrh Secure Asset Transfer Protocol

IETF: návrh Secure Asset Transfer Interoperability Architecture

IETF: návrh případů použití SATP, verze 10

Cacti: pravidla přispívání a otevřeného vývoje

Ledger Insights: Cacti, Swift a Wells Fargo — redakční podnět

Metodická poznámka

Stav zdrojů je uzavřen k 25. 9. 2026. Text rozlišuje datum vydání softwaru, zářijovou komunikaci projektu a aktuální stav návrhů IETF. Členství institucí není vydáváno za doklad jejich produkčního nasazení. Modelový převod a přejímací zkoušky jsou autorskou interpretací. Nebyl proveden bezpečnostní audit Cacti ani ověření konkrétní bankovní implementace.

Disclaimer

Článek má informační a vzdělávací charakter. Nejde o investiční, právní ani technologické doporučení pro konkrétní projekt. Použití uvedených nástrojů vyžaduje samostatné posouzení práv, rizik a provozních podmínek.