Co je potvrzená reference a co veřejný technický rozbor
EXCOIN dokončil zakázku týkající se ethereumového kontraktu pro kryptoměnové půjčky. Smluvní omezení neumožňují uvést klienta, veřejnou adresu kontraktu, přesné parametry, tokeny, objemy ani auditní zprávu. Proto níže popisujeme bezpečný návrhový prostor a rozhodnutí typická pro tento druh systému. Není to zveřejnění konkrétního produkčního kódu a jednotlivé vzory nelze automaticky připisovat anonymnímu klientovi.
Obchodní otázkou je, jak získat likviditu proti digitálním aktivům bez jejich prodeje a současně srozumitelně rozdělit riziko mezi dlužníka, věřitele a provozovatele. Tato studie se věnuje návrhu kontraktu pro prostředí Ethereum/EVM. Uvedené technické principy jsou obecné; nezveřejňují ani nedokládají konkrétní klientskou implementaci.
Role, ekonomické sliby a hranice kontraktu
Před Solidity je potřeba pojmenovat dlužníka, věřitele či pool, správce parametrů, cenový zdroj, likvidátora a provozovatele rozhraní. Každá role musí mít přesný seznam povolených akcí. Obchodní smlouva určuje, kdy půjčka vzniká, v jaké měně se splácí, kdo nese poplatky a co se děje při nesplnění. Kód může automatizovat jen pravidla, která lze vyjádřit a ověřit z dat dostupných na řetězci.
Kontrakt nemá tvrdit, že vyřešil off-chain vlastnictví, identifikaci klienta nebo právní vymáhání. Tyto oblasti zůstávají mimo řetězec a potřebují smluvní i provozní řešení. Architektura má výslovně popsat vztah mezi uživatelským rozhraním, podepsanou transakcí, smart kontraktem, indexerem, cenovým orákulem a případným registrátorem pohledávek. Bez takového rozdělení vzniká nebezpečná iluze, že vše řídí samotný kontrakt.
Model půjčky a stavový automat
Žádost, nabídka, vložená zástava, čerpaná jistina, narůstající úrok, splacení a uvolnění zástavy jsou různé stavy. Návrh stanoví povolené přechody a invarianty: zástava se neuvolní před úplným vyrovnáním; jistina se nevyplatí dvakrát; zrušenou nabídku nelze přijmout; likvidace nesmí pokračovat po definitivním splacení. Stavové změny musí být dohledatelné z událostí i uložených hodnot.
Částečné splátky potřebují pravidlo pořadí: poplatek, úrok, jistina nebo jiná smluvně schválená sekvence. Výpočet s celými čísly řeší zaokrouhlení a zbytky; desetinné hodnoty v uživatelském rozhraní nesmějí zakrýt hodnotu na řetězci. Pokud je úrok proměnný, kontrakt musí omezit, kdo a jak může parametr změnit a od kdy změna platí. Načasování bloků a timestampů se používá s vědomím jejich limitů.
Aktiva, tokeny a účetní jednotky
Kontrakt musí vědět, které tokeny lze použít jako zástavu a které jako měnu půjčky. ERC-20 rozhraní samo nezaručuje běžné chování: token může mít poplatek při převodu, omezení adres, změnu zůstatku nebo zvláštní návratovou hodnotu. Přijetí aktiva proto vyžaduje allowlist, test konkrétní implementace a rozhodnutí, zda se skutečně přijaté množství liší od požadovaného. Neznámý token se nesmí stát zástavou jen díky zaslání na adresu kontraktu.
Přesnost každého aktiva a cenového feedu se čte ze skutečného zdroje. Hodnota zástavy se počítá v jedné definované účetní jednotce a v konzervativním pořadí operací, aby zaokrouhlení nemohlo uměle zvýšit borrowing power. Kontrakt odděluje nominální zůstatek od ekonomicky dostupné hodnoty. U stablecoinu je potřeba počítat i s rizikem ztráty vazby na referenční měnu, nikoli jej považovat za bezrizikový dolar.
Zástava a poměr loan-to-value
Maximální počáteční LTV, výstražná hranice a likvidační hranice jsou tři odlišné parametry. Jejich hodnoty se nastavují podle konkrétního aktiva, volatility, likvidity trhu a mechanismu likvidace; tato studie žádnou číselnou hodnotu klienta nezveřejňuje. Zástava může být doplněna, částečně uvolněna nebo změněna jen tehdy, když po operaci zůstane splněn invariant bezpečného zajištění.
Při prudkém propadu ceny nemusí být možné prodat zástavu za cenu z orákulu. Návrh proto obsahuje rezervu na slippage, poplatky a prodlevu mezi zjištěním ceny a provedením likvidace. Uživatelské rozhraní musí odlišovat varování od skutečně vymahatelné podmínky v kontraktu. Upozornění e-mailem nebo notifikací pomáhá, ale jeho doručení nesmí být jedinou podmínkou ochrany systému.
Orákulum a selhání ceny
Kontrakt nemůže bezpečně odvodit tržní cenu z jedné snadno manipulovatelné spotové transakce. Cenový zdroj potřebuje výběr vhodného trhu, správné desetinné místo, stáří odpovědi, kladnou hodnotu a mechanismus při nedostupnosti. Pokud je feed starý nebo anomální, protokol nesmí bezmyšlenkovitě schválit nové čerpání ani likvidaci. Pravidlo pro stale data je součástí ekonomického návrhu, ne až reakce při incidentu.
Záložní feed není automaticky bezpečný. Přepnutí mezi zdroji může změnit přesnost, definici ceny nebo okamžik měření. Pro případ odchylky se definuje rozhodovací pravidlo a pozastavení rizikových akcí. Testy zahrnují prudký pohyb trhu, neaktualizovaný feed, manipulaci nízkou likviditou a výpadek poskytovatele. Přesnost se musí ověřit u skutečně zvoleného zdroje; nelze ji odvozovat ze zažitého čísla.
Výplata jistiny a bezpečné pořadí operací
Čerpání půjčky je nevratná finanční akce. Před odesláním se ověří stav nabídky, dostatečnost zástavy, platnost ceny, limit jistiny, oprávnění volajícího a dostupný zůstatek zdroje financování. Stav kontraktu se mění ve správném pořadí vůči externím převodům, aby opakované volání či callback tokenu nemohl získat druhou výplatu. Opakovaný požadavek se buď bezpečně odmítne, nebo vrátí již evidovaný výsledek.
Transakce může být v mempoolu, zahrnuta do bloku, reorganizována nebo definitivně potvrzena podle pravidel dané sítě. Off-chain služba nesmí uživateli ukázat definitivní čerpání po pouhém odeslání podpisu. Sleduje hash, síť, stav potvrzení a případnou změnu řetězce. Chyba v UI nesmí vést k automatickému znovupodepsání téže ekonomické operace bez ověření on-chain stavu.
Splácení, předčasné uzavření a uvolnění zástavy
Splátka musí určit dlužnou částku v přesném okamžiku, přijmout povolené aktivum a připsat ji podle schváleného pořadí. Částečné splacení snižuje dluh, ale nemusí okamžitě opravňovat k uvolnění zástavy. Předčasné splacení potřebuje jasné pravidlo úroku a poplatku; případná sankce nesmí být skrytá v matematice kontraktu. Přebytek platby se zpracuje výslovně, nikoli ztratí v zaokrouhlení.
Po úplném vyrovnání může dlužník zástavu vybrat nebo ji kontrakt vrátí podle zvoleného modelu. Preferovaný způsob musí předcházet riziku, že neúspěšný externí převod trvale zablokuje uzavření půjčky. Každý výběr emitovanou událostí a stavem doloží, jaká hodnota odešla a komu. Způsob obnovy přístupu při ztraceném klíči je součástí produktu; smart kontrakt sám nedokáže určit, kdo je právoplatný náhradní vlastník peněženky.
Likvidace a ochrana obou stran
Likvidace není jen porovnání dvou čísel. Musí být stanoveno, kdo ji může spustit, jak se ověří aktuální cena, kolik zástavy lze prodat, jak se vyrovná dluh, komu připadne přebytek a co nastane, když výnos nestačí. Příliš agresivní likvidace poškozuje dlužníka; příliš pomalá ztrácí ochranu věřitele. Návrh může volit částečnou likvidaci, aukci nebo jiný model, ale jeho ekonomika se musí otestovat v nepříznivém trhu.
Lze simulovat rychlý propad, nulovou likviditu, vysoký gas, front-running a zastavení orákula. Každá simulace musí ukázat, zda invariant zajištění stále platí a jaká ztráta je možná. Pokud kontrakt dovoluje emergency pause, jasně určuje, které funkce se zastaví a zda dlužník může splatit a získat zástavu zpět. Přepínač, který bez omezení zmrazí i bezpečné splacení, může vytvořit nové systémové riziko.
Přístupová práva, upgrade a správa parametrů
Privilegované role pro změnu rizikových parametrů, pauzu, upgrade a výběr poplatků jsou oddělené. Jejich držitelé, rotace klíčů a reakce na kompromitaci jsou stejně důležití jako Solidity kód. Pro produkční správu je vhodné zvážit multisig, časový zámek a veřejně dohledatelné návrhy změn. Oprávnění ke změně cenového feedu nesmí automaticky znamenat oprávnění odčerpat zástavu.
Upgradeability zvyšuje flexibilitu, ale vytváří možnost změnit ekonomická pravidla po uzavření půjčky. Je třeba rozhodnout, zda se mění jen nové půjčky, nebo také existující. Pokud je kontrakt neměnný, musí být plán migrace a uzavření starých pozic. Pokud je upgradovatelný, musí být schválená odpovědnost, časové okno, kompatibilita storage layoutu, audit změny a postup návratu tam, kde je technicky možný.
Bezpečnostní audit a testovací matice
Testy zahrnují reentrancy, neoprávněné čerpání, dvojí splátku, chybné zaokrouhlení, token s nestandardním chováním, stale oracle, manipulovanou cenu a závody mezi splacením a likvidací. Invariantní a fuzz testy ověřují vlastnosti napříč náhodnými sekvencemi, nikoli pouze několik šťastných cest. Nezávislá bezpečnostní revize je další vrstva, ale sama nezaručuje bezchybnost kontraktu.
Testovací prostředí má odpovídat produkčním verzím tokenů, feedů a sítí. Fork test pomáhá odhalit rozdíl oproti mockům; ekonomická simulace ověřuje stresovou likvidaci. Každé zjištění auditu má závažnost, opravu, retest a rozhodnutí o zbytkovém riziku. Bez veřejné zprávy o této zakázce netvrdíme, že konkrétní anonymní kontrakt prošel určitým externím auditem nebo certifikací.
Indexace, provoz a incidenty
Aplikační indexer čte on-chain události a vytváří rychlý pohled na půjčky. Události se zpracovávají opakovatelně a s možností návratu při reorganizaci řetězce. Zdroj pravdy pro finanční stav zůstává kontrakt; databáze může být zpožděná a musí zobrazovat čas posledního potvrzení. Monitoring sleduje cenu, stáří feedu, zdraví RPC, nevyřízené transakce, likvidační pozice a odchylky mezi indexem a řetězcem.
Incidentní postup rozlišuje chybu UI, výpadek RPC, kompromitovaný administrátorský klíč, chybnou cenu a exploataci kontraktu. Pauza má podmínky spuštění i uvolnění a určené držitele oprávnění. Komunikace s uživateli nesmí tvrdit, že prostředky jsou bezpečné dřív, než je to ověřeno. Zálohy off-chain dat nepředstavují obnovu on-chain prostředků; odpovědnost za každý typ obnovy se popisuje zvlášť.
Smlouva o půjčce a stav na řetězci
Uživatelská smlouva a smart kontrakt musí popisovat stejné ekonomické události, i když používají jiný jazyk. V obou je nutné určit jistinu, splatnost, úrok, zástavu, podmínku likvidace a důsledky výpadku orákula. Rozpor se nesmí řešit až při sporu. Produktový tým vytvoří mapu každé smluvní klauzule na on-chain stav, off-chain důkaz a odpovědnou osobu. U klauzule, kterou nelze automatizovat, se výslovně uvede ruční proces.
Před podpisem transakce by dlužník měl vidět parametry, které kontrakt skutečně uloží, nikoli jen marketingový souhrn. Podpis neznamená vždy okamžité čerpání a zástava nemusí být ihned bezpečně uzamčena. Uživatelské rozhraní ukazuje stav každého kroku a případnou možnost zrušení. Právní závaznost a informování spotřebitele posuzuje tým klienta; technický tým dodá přesné údaje a auditní vazbu.
Financování a likvidita věřitele
Kontrakt musí rozlišit nabídnutou likviditu od prostředků skutečně dostupných k vyplacení. Pokud věřitel může prostředky odvolat, nabídka se nesmí zneužít po stažení. U poolu je nutné vymezit podíl, rezervu, priority výběru a účtování ztráty. Nelze slíbit instantní čerpání, jestliže kapitál čeká na převod nebo na potvrzení jiné transakce.
Testy obsahují současný požadavek dvou dlužníků na poslední dostupné prostředky, neúspěšný transfer tokenu a výběr věřitele během likvidace. Zůstatek kontraktu, evidovaná závazková pozice a skutečná dostupnost se musí průběžně rovnat podle definovaného invariantu. Nesoulad je bezpečnostní událost, ne pouze chyba dashboardu.
Úroková matematika a čas
Úrok lze počítat lineárně, složeně nebo podle jiné smluvní formule. Každá volba musí mít jednotku času, přesnost, zaokrouhlení a pravidlo pro přestupný rok či kratší období. Solidity pracuje s celými čísly, takže pořadí násobení a dělení mění výsledek. Referenční výpočet mimo kontrakt se používá v testech, ale nesmí být jediným zdrojem výsledku.
Zkoušky pokrývají okamžik před splatností, přesně na hranici a po ní, dlouhé trvání i opakované částečné platby. Při změně sazby se přesně určí, zda se přepočítává starý dluh nebo jen nové období. Pokud sazbu nastavuje administrátor, smlouva musí uvést jeho pravomoc a uživatel musí mít možnost změnu zjistit před dalším čerpáním.
Příjem tokenů a nestandardní chování
Přijetí tokenu není jen volání transferFrom. Některé ERC-20 tokeny nevracejí očekávanou hodnotu, mají poplatek při převodu, blacklist nebo mění zůstatek bez převodu. Kontrakt porovnává stav před a po operaci tam, kde je to relevantní, a allowlist omezuje aktiva na schválené implementace. Token s jinou přesností může zásadně změnit výpočet zástavy.
Schválení allowance samo nepřesouvá peníze, ale může nechat aplikaci oprávnění k budoucímu výběru. Rozhraní by proto mělo žádat přiměřený limit, vysvětlit uživateli, komu jej dává, a podporovat zrušení. Při přidání nové verze tokenu se testují všechny kritické funkce: vklad, čerpání, splátka, refund přebytku i likvidace.
Rizikové parametry a scénáře tržního stresu
Bezpečný poměr zástavy není jedno číslo použitelné pro každý token. Závisí na hloubce trhu, koncentraci držitelů, volatilitě, dostupnosti orákula a rychlosti likvidace. Parametry se schvalují s uvedenou hypotézou a simulací. Když se likvidita trhu zhorší, samotná předchozí historie ceny nestačí k odhadu výnosu z prodeje.
Scénáře zahrnují cenový gap přes noc, hromadnou likvidaci, depeg stablecoinu, výrazně vyšší gas a selhání hlavní burzy. Výsledkem není jeden reklamní poměr bezpečnosti, ale distribuce možných ztrát a seznam podmínek, za nichž systém nové půjčky zastaví. U otevřených pozic musí být předem dané, zda se mění prahy retroaktivně.
Likvidační incentivy a aukce
Likvidátor potřebuje ekonomickou motivaci zaplatit gas a převzít riziko trhu. Příliš vysoký bonus zbytečně poškozuje dlužníka; nízký může vést k tomu, že při stresu nikdo nezareaguje. Kontrakt počítá limit prodeje, cenu, bonus a zbylou zástavu podle explicitní formule. U částečné likvidace se ověřuje, že pozice po zásahu není horší než před ním.
Aukce může pomoci s objevováním ceny, ale přidává čas, manipulaci a režii. Pokud se použije, určí se start, konec, pravidlo nabídky, zrušení a situace bez kupce. Test zahrnuje MEV, front-running a více současných likvidátorů. Pouhé spuštění likvidační transakce neznamená, že věřitel skutečně obdržel požadovanou hodnotu.
Orákulum, fallback a emergency režim
Primární feed se kontroluje podle round ID, timestampu, kladné ceny a jednotky. Příliš starý údaj zastaví čerpání i rizikovou likvidaci podle pravidla stanoveného předem. Fallback feed může mít jiný trh a přesnost; přepnutí proto vyžaduje kontrolu odchylky a správu oprávnění. Jediný administrátorský klíč, který může bez prodlevy změnit feed i práh likvidace, je závažné koncentrované riziko.
Emergency režim omezuje nové půjčky a další nárůst rizika, ale musí zachovat bezpečné možnosti splacení. Před nasazením se simuluje výpadek cenového zdroje během splatnosti a během propadu trhu. Tým musí umět vysvětlit, kdo režim zapne, za jakých důkazů ho vypne a jak budou informováni účastníci. Případná ruční cena je vysoce privilegovaná výjimka.
Upgrade a ochrana otevřených půjček
Upgrade může opravit chybu, ale také změnit pravidla již uzavřených půjček. To je produktové, bezpečnostní i právní rozhodnutí. Návrh stanoví, zda nový kód spravuje jen nové pozice, nebo musí zachovat staré parametry u otevřených. Storage layout, role a migrační transakce se kontrolují v testech s reálnými historickými stavy.
Před upgradem existuje review, schválení, čas na upozornění a plán při neúspěchu. Rollback není vždy možný, zejména po transakcích, které změnily ekonomický stav. Proto se simulují nejen bytecode a storage, ale i splátky a likvidace otevřených pozic přes hranici verzí. Transparentní postup zmenšuje důvěru, kterou účastníci musí vložit do správce.
Podpisy, peněženky a ochrana uživatele
Uživatel musí rozumět tomu, co podepisuje: schválení tokenu, vložení zástavy, přijetí půjčky a splátka jsou rozdílné akce. Rozhraní ověřuje chain ID a adresu kontraktu, aby nevznikla záměna s podvrženou sítí. Podepisovaná data zahrnují nonce a dobu platnosti, pokud se používají off-chain nabídky. Starý podpis nesmí být znovu použit po změně ceny nebo podmínek.
Ztráta peněženky, kompromitace klíče a změna adresy jsou provozní scénáře. Nelze automaticky slíbit obnovu zástavy, pokud kontrakt neobsahuje bezpečnou a právně schválenou cestu. Podpora nesmí získat obecné oprávnění převést cizí prostředky jen kvůli jednoduchosti recovery. Kritické informace se zobrazují před podpisem a jsou dohledatelné po něm.
On-chain události a off-chain index
Kontrakt emituje události pro otevření, čerpání, změnu zástavy, splátku, likvidaci a uzavření. Události poskytují historii, ale ne vždy kompletní aktuální stav; indexer je kombinuje s čtením kontraktu. Blok, hash transakce a pořadí logu tvoří stabilní klíč. Při reorganizaci se index vrátí a znovu přehraje, jinak může zobrazovat půjčku jako splacenou, přestože transakce zmizela.
Provozní pohled uvádí poslední potvrzený blok a rozdíl od hlavy sítě. Pokud indexer zaostává, UI označí data jako starší a zastaví rizikové akce závislé na jeho projekci. Samotný kontrakt zůstává finančním zdrojem pravdy. Indexační databáze se dá obnovit z řetězce a checkpointů, ale tato obnova musí být skutečně nacvičena.
Auditní důkazy a reprodukovatelné sestavení
Veřejný bytecode, ověřený zdrojový kód, verze kompilátoru, nastavení optimizeru, knihovny a adresy závislostí tvoří reprodukovatelný artefakt. Bez něj nelze z publikovaného repozitáře spolehlivě dokázat, že odpovídá nasazenému kontraktu. Release postup eviduje hash, schválení a parametry nasazení. Změna implementace či proxy se zapisuje jako nová auditní událost.
Auditní dokumentace popisuje ekonomické invarianty, hranice důvěry, známé výjimky, verzi testů a zbytkové riziko. Veřejné tvrzení o externím auditu vyžaduje skutečnou zprávu a souhlas ji uvést; zde to kvůli anonymitě netvrdíme. Pro interní provoz je ale důležité, aby z jednoho incidentu šlo reprodukovat verzi kontraktu, cenu, roli správce a stav pozice v daném bloku.
Zátěž sítě a transakční náklady
Cena gasu může zlikvidovat ekonomiku drobné půjčky nebo zabránit uživateli včas doplnit zástavu. Návrh proto měří náklady na vklad, čerpání, splátku a likvidaci v realistických podmínkách. Batch operace mohou ušetřit náklady, ale zvyšují složitost a riziko hromadného selhání. Před volbou sítě či L2 se posuzuje dostupnost aktiv, orákul, uživatelů i proces výběru zpět.
Při vysokém gasu se může pozice stát likvidovatelnou dřív, než dlužník stihne zaslat doplnění. Protokol nesmí slibovat pevnou dobu potvrzení, kterou síť neumí garantovat. Monitoring sleduje nevyřízené transakce a cenu provedení; provozní tým má postup pro bezpečné přecenění nebo zrušení vlastní transakce, ale nikdy nepodepisuje ekonomickou akci za uživatele bez jasného mandátu.
Ekonomický útok a chybná motivace
Útočník nemusí hledat chybu v Solidity. Může manipulovat tenký trh, využít krátkodobý cenový výkyv, vytvořit mnoho malých pozic nebo zneužít likvidační bonus. Threat model proto zahrnuje ekonomické chování, MEV a koordinované transakce. Simulace porovnává zisk útočníka s jeho náklady a hledá parametry, při nichž se škodlivá strategie vyplatí.
Úvěrový produkt má také riziko špatně nastavených pobídek legitimních účastníků. Pokud se věřiteli vyplatí čekat na default nebo likvidátorovi zhoršit cenu, technicky správný kód může vytvářet špatné výsledky. Produktový a bezpečnostní tým proto hodnotí mechanismus jako celek, včetně pravidel poplatků a zbytkové zástavy.
Předání a dlouhodobá odpovědnost
Předání obsahuje adresy a ABI, ověřený zdroj, verzi kompilátoru, testy invariantů, parametry, držitele rolí, runbooky a postup pro incident. Nový tým musí umět bezpečně pozastavit rizikovou funkci a ověřit, zda otevřené pozice stále splňují invarianty. Správa kontraktu po spuštění je samostatná práce: sledovat feedy, síť, tokeny a oprávnění.
Každé rozšíření pro další aktivum nebo typ půjčky prochází novou ekonomickou a bezpečnostní revizí. Provozní metriky se soustředí na stáří cen, rizikové pozice, neúspěšné splátky a nevyřízené likvidace, nikoli pouze na počet transakcí. Anonymní reference nepublikuje tyto klientské hodnoty; poskytuje však konkrétní otázky, které musí podobný systém umět zodpovědět.
Právní rámec a další rozvoj
Poskytování půjček, úschova aktiv, směna a provoz platformy mohou mít odlišnou právní kvalifikaci podle země a konkrétních rolí. MiCA a další pravidla nelze vyřešit jednou větou v marketingové studii. Odpovědný právní tým musí posoudit produkt, smluvní dokumentaci, identifikaci uživatelů, ochranu spotřebitele, daně a řešení sporů. Technická implementace sama neuděluje licenci ani nevytváří právní vymahatelnost.
Další verze mohou přidat nové zástavy, typy úroku nebo věřitele, ale každá změna znovu otevírá ekonomický model, orákulum, likviditu a bezpečnost. Stabilní kontrakt není překážka růstu, pokud je dobře popsána hranice pro nové moduly. Přínos technické studie spočívá ve schopnosti vysvětlit každou ekonomickou událost, její on-chain důkaz a odpovědnost za výjimku, ne v nedoloženém tvrzení o velikosti provozu.
Obecné technické podklady
Tyto odkazy vysvětlují obecné principy. Nedokládají konkrétní neveřejnou implementaci klienta.