On-chain approvals: proč existují, kde se ukládají a co přesně povolují
On-chain approvals jsou oprávnění, která majitel adresy udělí jinému účtu nebo smart kontraktu ke správě jeho aktiv bez nutnosti dalšího podpisu při každém převodu. V praxi se jedná především o: (1) ERC-20 allowance prostřednictvím funkce approve(spender, amount), která umožňuje „spenderovi“ převádět vaše tokeny přes transferFrom; (2) ERC-721/1155 operator práva pomocí setApprovalForAll(operator, true), která zmocňují operátora nakládat s NFT (prodávat, přesouvat, zalistovat na marketplace); a (3) permit mechanismy (např. EIP-2612 a Permit2), které udělují oprávnění pomocí podepsané zprávy bez on-chain transakce při schválení. Povolení se ukládají do storage příslušného tokenového kontraktu (respektive frameworku na oprávnění) a jsou čitelná na block explorerech i specializovaných nástrojích.
Typy povolení a jejich rozdíly (ERC-20, ERC-721/1155, Permit, Permit2)
ERC-20 allowance je kvantitativně omezené – zadáváte částku, často „neomezenou“ (maximální hodnotu), abyste nemuseli schvalovat každou výměnu zvlášť. ERC-721/1155 obvykle pracují s binárním schválením „pro všechny tokeny“ vůči operátorovi (např. marketplace), přičemž některé implementace podporují také per-token schválení přes approve(tokenId). EIP-2612 Permit umožňuje udělit nebo aktualizovat allowance podpisem (off-chain), který kontrakt ověří až při prvním použití; podpis obsahuje nonce a deadline. Permit2 (Uniswap) abstrahuje schválení pro více tokenů a dAppky s jednotným formátem a jemnějšími limity (per-spender, časová okna), čímž snižuje potřebu „infinite approvals“.
Hlavní rizika: neomezená schválení, zranitelné dApp, ztracená kontrola nad NFT
Nejčastějším rizikem je neomezené (infinite) ERC-20 schválení pro kontrakt, který se později ukáže být škodlivý, kompromitovaný nebo upgradovaný s neférovou logikou. U NFT hrozí riziko globálního operátora s právy na všechny vaše NFT kolekce; při kompromitaci operátora může dojít k rychlému vyprázdnění aktiv. U permit schém platí, že ukradený podpis v rámci platnosti a s nepoužitým nonce může být zneužit.
Kde a jak kontrolovat existující approvals
Kontrolu lze provádět třemi způsoby: (1) přímo na block explorerech v sekcích tokenu (Allowance/Approved Operators), (2) přes specializované „revoke“ nástroje, které zobrazují seznam oprávnění napříč tokeny a dAppkami na dané síti, a (3) pro pokročilé čtením storage nebo voláním allowance(owner, spender) či isApprovedForAll(owner, operator) přes „read contract“. Dbejte na to, že každá síť (Ethereum, L2, sidechainy) udržuje vlastní stav – ověřujte povolení na všech sítích, které používáte.
Postup: audit vašich approvals krok za krokem
1) Zvolte síť (např. Ethereum mainnet) a přihlaste peněženku v nástroji pro kontrolu oprávnění. 2) Zobrazte seznam „spenderů“ a „operátorů“ setříděný podle rizika (neznámé kontrakty, velké nebo neomezené částky, staré a nepoužívané dApp). 3) Ověřte identitu kontraktů (oficiální adresy, verifikovaný kód, reputace). 4) Označte si, která oprávnění opravdu potřebujete (např. aktivně používaný DEX) a která jsou „legacy“. 5) Přistupte k odvolání (revoke), začínaje nejrizikovějšími položkami. 6) Opakujte pro L2 (Arbitrum, Optimism), sidechainy (Polygon) a další EVM sítě, které používáte.
Jak technicky odvolat (revoke) ERC-20 allowance
Odvolání znamená provést transakci, která nastaví allowance na 0 pro konkrétní pár (owner, spender). Buď použijete UI nástroje „Revoke“, nebo přímo volání approve(spender, 0) v sekci „Write Contract“ na block explorere. Některé tokeny vyžadují dvoustupňové nastavení: nejprve na 0, následně na novou hodnotu (historické vzory ochrany proti race conditions). Poplatek za gas platí ten, kdo odvolává (vy), a transakce probíhá v síti, kde bylo původní schválení uděleno.
Jak odvolat operátorská práva pro ERC-721/1155
U NFT kontraktů voláte setApprovalForAll(operator, false). Učiníte tak přes UI nástroje pro správu oprávnění nebo přímo na block explorere přes „Write Contract“. Ověřte, že jde o správnou kolekci (adresu NFT kontraktu) a správného operátora (adresu marketplace/agent kontraktu). Pokud používáte více marketplace účtů, zkontrolujte všechny.
Permit a Permit2: expirace, nonce a revokace
EIP-2612 Permit pracuje s deadline a nonce. Pokud je podpis nepoužitý a deadline vyprší, stává se neplatným. Pokud byl podpis již jednou použit (nonce spotřebována), nelze jej znovu použít. Při odvolání oprávnění uděleného přes permit můžete buď: (1) nastavit allowance na 0 klasickým approve, čímž efektivně zneplatníte budoucí pokusy o transferFrom daného spendera, nebo (2) pokud framework podporuje funkce „invalidate“/„lockdown“, použít je. Permit2 umožňuje revoke pro konkrétní páry token/spender a také pracuje s časově omezenými povoleními; revokaci provedete přes kompatibilní UI nebo přímým voláním metod smlouvy Permit2.
Specifika L2 a multireťazcové správy oprávnění
Každá síť je samostatný stav. Schválení na Ethereum mainnetu neznamená schválení na Arbitrum či Optimism a naopak. Odvolání musíte spustit na téže síti a zohlednit tamní poplatky a mempool. U rollupů sledujte také odlišné časy finality a možné rozdíly v block explorerech.
Bezpečnostní zásady při udělování nových approvals
Minimalizujte rozsah a délku trvání: (1) pokud možno neudělujte „infinite approval“; nastavte pouze částku potřebnou pro operaci; (2) preferujte časově omezená a per-spender schválení (Permit2 a podobné); (3) využívejte ověřené dApp, kontrakty s verifikovaným kódem a audity; (4) u NFT zvažte použití dedikované „trading“ peněženky oddělené od „trezorové“; (5) aktivujte notifikace z peněženky a sledujte Approval/ApprovalForAll události; (6) pro týmy využívejte multisig a role-based přístupy (např. treasury má jiné pravomoci než trading bot).
Incident response: co dělat při podezření na kompromitaci
1) Okamžitě odpojte peněženku od podezřelé dApp (odvolání web3 „connection“ neruší on-chain approvals, ale zabrání dalšímu podepisování). 2) Revokujte kritická oprávnění (ERC-20 infinite allowances, NFT operátory). 3) Přesuňte zbývající aktiva na novou adresu, pokud máte indikace kompromitace seed frází nebo zařízení. 4) Zkontrolujte všechny sítě, kde jste aktivní. 5) Vyhodnoťte původ incidentu (phishing, škodlivé rozšíření, falešná dApp) a poučte se pro budoucnost.
Specifika peněženek: EOA vs. smart contract/AA účty
U klasických EOA účtů (Externally Owned Account) vše probíhá přes podpisy klíčem. U smart-contract účtů (Account Abstraction, např. ERC-4337) může peněženka poskytovat jemnější politiky – limity, session keys, časová okna, whitelist dApp – což prakticky redukuje potřebu „globálních“ approvals nebo riziko jejich zneužití. Ověřte, jaké guard mechanismy a modulární politiky vaše AA peněženka podporuje.
Ověřování legitimity spenderů a operátorů
Před revokací nebo novým schválením si ověřte: (1) adresu kontraktu (oficiální zdroje projektu), (2) zda je zdrojový kód verifikovaný a zda odpovídá očekávaným standardům (ERC-20/721/1155), (3) historii transakcí kontraktu a reputaci (nevyskytuje-li se jako nově vytvořená, „podezřele prázdná“ adresa), (4) případné proxy/upgradovatelné vzory (Transparent/Beacon proxy), kde se logika může měnit bez změny adresy.
Účtování poplatků a optimalizace gasu při revokaci
Revokace jsou standardní on-chain transakce a stojí gas. Úsporu lze dosáhnout: (1) seskupením revokací do období s nižším base-fee, (2) využitím batch funkcí, pokud je nástroj/peněženka podporuje, (3) preferencí revokací pouze tam, kde je skutečné riziko (nepoužívané a neznámé kontrakty, infinite approvals), (4) výběrem L2 sítě, pokud bylo schválení prováděno tam (poplatky jsou řádově nižší než na mainnetu).
Co dělat po revokaci: test a „least privilege“ režim
Po odvolání si ověřte, že daná dApp již nemůže čerpat vaše tokeny: zkuste provést malou operaci, která by vyžadovala transferFrom – měla by selhat a dApp by měla opět vyžádat schválení. Při dalším používání dodržujte zásadu least privilege – schvalovat jen to, co je nezbytné, pouze na nezbytnou dobu a vůči důvěryhodnému spenderovi.
Checklist: měsíční audit approvals
• Sepište sítě, které používáte (Ethereum, L2, sidechainy) a k nim adresy peněženek.
• Pro každou síť vygenerujte seznam „spender“ a „operátor“ oprávnění.
• Vyhodnoťte riziko: neznámé kontrakty, velké/infinite částky, staré dApp bez aktivity, upgradovatelné proxy bez důvěry.
• Revokujte vysoce riziková oprávnění, snižte z „infinite“ na konkrétní limity.
• Ověřte funkčnost důležitých dApp po zpřísnění.
• Zaznamenejte změny a připomeňte si další audit za 30 dní.
Nejčastější chyby a mýty
Chyba: „Odpojení peněženky od webu ruší on-chain approvals.“ – Neruší; jde pouze o zrušení webové relace. Chyba: „Když jsem udělil permit, už to nejde zvrátit.“ – v praxi lze zrušit účinnost přes approve(spender, 0) nebo expirací/spotřebováním nonce. Mýtus: „Operátor u NFT vidí jen konkrétní tokeny.“ – při setApprovalForAll má operátor zpravidla práva na všechny NFT daného kontraktu.
Shrnutí
On-chain approvals jsou nezbytným mazivem DeFi a NFT ekosystému, avšak představují trvalá a často rozsáhlá oprávnění nad vašimi aktivy. Klíčem je pravidelná kontrola, cílené odvolávání a minimalistická, časově omezená schválení vůči důvěryhodným kontraktům. Takto významně snížíte povrch útoku bez obětování použitelnosti.
