Smart kontrakty bez programování

Proč se vyplatí číst smart kontrakt přes UI, i když neprogramujete

Ne každý, kdo používá DeFi, NFT nebo Web3 nástroje, musí umět číst Solidity. Klíčová rizika dokážete odhalit i bez znalosti kódu – přímo v uživatelském rozhraní (UI) průzkumníků bloků, peněženek a analytických nástrojů. Tento článek je návodem, na co si dávat pozor, kde kliknout, jaké signály jsou pozitivní a které varují před možným rizikem.

Kde začít: základní UI místa pro „čtení“ kontraktu

• Průzkumník sítě (Etherscan, Basescan, Arbiscan…): záložky Contract (Read/Write), Transactions, Internal Txns, Events, Holders, Analytics.
• Peněženka: detail schválení/approvals, simulace transakce, varování na podezřelé volání.
• Protokolové UI: panel nastavení, sekce rizik, informace o adminovi, odkaz na governance, dokumentaci a audit.
• Agregátory schválení: přehled on-chain oprávnění (možnost rychlého „revoke“).

Ověření kontraktu: verifikace zdrojového kódu a licence

Na záložce Contract hledejte:

• „Contract Source Code Verified“: verifikovaný = kompilace proběhla se stejnými nastaveními; zvyšuje důvěru, že zobrazené rozhraní odpovídá bytecode na síti.
• Licence (MIT, GPL, BUSL…): komerční a omezující licence mohou naznačovat záměry projektu s forkováním.
• Více souborové složení a komentáře: obsáhlé komentáře a oddělené moduly (Ownable, AccessControl, Pausable) usnadňují pochopení i laikovi díky názvům funkcí.

Proxy a upgradeovatelnost: nenechte se zmást jednou adresou

Řada protokolů používá upgradeovatelné proxy. V UI průzkumníka věnujte pozornost:

• Detekci proxy: štítek „Proxy“ nebo „Implementation“ s odkazem na Implementation Contract.
• Admin vs. Implementation: kdo drží práva na změnu implementace (admin), zda je to multisig, timelock nebo EOA (privátní peněženka fyzické osoby).
• Vzor UUPS/Transparent: v událostech (Events) hledejte logy jako Upgraded nebo AdminChanged.
• Timelock: UI by mělo odkazovat na časový zámek (např. 48–72 hodin) pro změny – pozitivní signál řízení rizika.

Vlastnická a přístupová práva: Ownable, AccessControl, Guardian

Na záložce Read Contract vyhledejte funkce a proměnné:

• owner() nebo getRoleAdmin(): kdo je vlastník a kdo může nastavovat role.
• hasRole() a seznam rolí (DEFAULT_ADMIN_ROLE, PAUSER_ROLE, MINTER_ROLE): ověřte, zda jsou vázány na multisig nebo DAO.
• renounceOwnership(): rezignace může snížit riziko svévolných zásahů, ale brání rychlým opravám; v UI by to mělo být vysvětleno.
• Guardian/Pauser: existuje „nouzová brzda“? Je omezena timelockem a pravidly governance?

Tokenová ekonomika v UI: supply, mint/burn, poplatky, blacklisty

U tokenů si všímejte:

• totalSupply() a maxSupply (pokud existuje): je supply pevná nebo inflační?
• mint(), burn(), setFee(), setTaxWallet(): kdo to může volat? Jsou změny omezené?
• Blacklist/Whitelist funkce: legitimní v regulovaných modelech, ale riziko cenzury; UI by mělo explicitně dokumentovat podmínky.
• Převodní omezení (anti-bot, anti-whale): sledujte prahové limity a dočasné režimy po spuštění.

Schválení (approvals) a povolení (permit): čtěte, co podepisujete

• allowance(owner, spender) v Read: podívejte se, kdo má právo utrácet vaše tokeny a kolik.
• approve(spender, amount) v Write: UI protokolů často nabízí „infinite approval“. Preferujte přesná nebo limitovaná schválení.
• permit (EIP-2612): „gasless approval“ přes podpis; UI by mělo zobrazit přesného spendera, value a deadline.
• Revokace: dobré UI odkazuje na rychlé revoke a po akci připomíná zkontrolovat zbývající schválení.

Události (Events) jako náhrada logiky kódu

Pokud kód nečtete, sledujte historii událostí:

• OwnershipTransferred, RoleGranted, RoleRevoked: kdo získává strážné role a práva?
• ParametersUpdated (poplatky, limity): změny parametrů a frekvence úprav.
• Upgraded u proxy: časová osa upgradeů, odpovídá governance procesu?

Transakce a interní volání: pohled na „chování“ kontraktu

• Transactions: kdo volá administrativní funkce, jak často, v jakých dávkách?
• Internal Txns: přesuny do jiných kontraktů (treasury, fee recipient, rewarder); ověřte, zda adresy odpovídají dokumentaci.
• Contract Creator: původní instalace, mintování tokenů, seed pro treasury, vesting kontrakty.

DEX a pool UI: parametry, které vypovídají o riziku

• Rezervy a likvidita: nízká likvidita = vysoký skluz; UI by mělo zobrazovat rezervy a historický objem.
• Poplatky poolu a admin fee: kdo může měnit poplatky? Je stanoven strop nebo governance proces?
• Vlastník poolu a práva: upgradeovatelnost poolu, feeTo adresa, práva na skim/sync.
• Ekonomika LP tokenů: kam směřují odměny, existuje emission schedule a možnost jednostranného stažení stimulů?

Bridgy a cross-chain UI: smluvní páry a závislosti

• Adresy na obou sítích: UI by mělo propojit „kanonické“ adresy a ověřit messenger / oracle kontrakty.
• Finalita / Challenge parametry: čas zdržení, challengové periody, bonding mechanismy.
• Admin práva: kdo může pozastavit most, měnit „routery“ nebo měnit limit toků?

Bezpečnostní moduly v UI: timelock, pauzy, rate-limity

• Pausable: jasná signalizace, kdo může pauzovat a za jakých podmínek; zneužitelný pauser bez timelocku je riziko.
• Rate-limiter: limity na výběry a přebalancování v jednotlivých epochách; UI by mělo ukázat aktuální využití.
• Emergency Withdraw: mechanismy „bez odměn“, které chrání hlavní kapitál.

Simulace a náhled transakce: co musí UI ukázat před podpisem

• Funkční selektor a parametry: uživatelsky čitelné názvy funkcí s parametry (příjemce, množství, deadline, minOut).
• Odhad spotřeby gasu a celkové ceny; varování, pokud je odhad netypicky vysoký.
• Externí volání: pokud transakce spouští další kontrakty (router, vault), UI to má zobrazit.
• Výsledek simulace: očekávaný zůstatek před/po, očekávaný skluz, výše poplatků a příjemců adres.

Audit, bug bounty, verzování: meta-informace v rozhraní

• Odkazy na audity s verzemi commitů; UI by mělo spárovat auditovanou verzi s implementací.
• Bug bounty – rozsah a kritéria; kontakt a responsible disclosure.
• Changelog implementací; historie změn s hashy a daty.

Varovné signály v UI: když něco „nesedí“

• Neverifikovaný kód nebo chybějící odkazy na proxy/implementation.
• EOA jako admin bez multisigu a timelocku.
• Neomezené parametry (libovolná změna poplatků, blacklist kdykoli, mint bez stropu) bez governance kontroly.
• „Infinite approval“ defaultně bez možnosti zvolit přesnou částku.
• Nejasné destinace odměn/poplatků; chybí audit trail na feeTo a treasury adresy.

Tabulka: mapa rychlé kontroly v průzkumníku

Čtení „Read/Write“ bez kódu: tipy na interpretaci

• Názvy funkcí často mluví samy za sebe (deposit, withdraw, setFee, pause, upgradeTo).
• Konstanty a parametry v Read prozradí limity (fee cap, maxMint, cooldown).
• Write ukáže, co je vůbec možné udělat – pokud UI protokolu nepodporuje tlačítko, ale Write je dostupné, je to signál k dalším otázkám.

UX prvky, které zvyšují důvěru

• Funkce „Copy-to-clipboard“ a přepojení všech adres na průzkumník.
• Badgy a štítky: Verified Code, Audited, Proxy Detected, Time-locked Admin.
• Tooltipy „Explain like I’m 5“: jednoduché popisy funkcí a rizik.
• Výchozí bezpečné volby: přesná schválení, přísné sklzové limity, varování před rizikovými akcemi.

Kontekst sítě: L2 specifika v UI

• Poplatky a „blob“ náklady jsou jinde než na L1; UI by mělo ukazovat skutečnou konečnou cenu.
• Sequencer a výpadky: zobrazení stavu sítě a zpoždění publikace na L1.
• Stav bridge: čekací doby, challenge periody a limity výběrů.

Nejčastější omyly při „čtení“ bez kódu

• Záměna verifikace s auditem: verifikovaný kód ≠ auditovaný.
• Ignorování proxy: čtete proxy místo implementation, ze kterého plyne logika.
• Přehlédnutí rolí: změna poplatků či pauza systému může být v rukách jedné adresy.
• „Infinite approval“ z pohodlnosti: usnadňuje UX, ale zvyšuje riziko odčerpání.

Checklist: 10minutový rituál před interakcí s novým protokolem

1. Verifikace kódu a propojení proxy na implementation.
2. Admin/Owner: multisig + timelock nebo EOA?
3. Role a práva: kdo může měnit poplatky, pauzovat, upgradovat?
4. Události: historie Upgraded/Role/Param změn.
5. Parametry tokenu: minty, fee stropy, blacklist funkce.
6. Holders: koncentrace, vesting, treasury adresy.
7. Schválení: stávající schválení, možnost přísných limitů.
8. DEX/Pool: likvidita, fee parametry, vlastník poolu.
9. Bridge: kanonické adresy na obou stranách, limity a pauzy.
10. UI simulace: jasné parametry volání, očekávaný výsledek a náklady.

Shrnutí: UI jako lupa na chování kontraktů