On-chain approvals: proč existují, kde se ukládají a co přesně povolují
On-chain approvals jsou oprávnění, která vlastník adresy uděluje jinému účtu nebo smart kontraktu k provádění operací s jeho aktivy bez nutnosti dalšího podpisu při každém převodu. V praxi jde zejména 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 k manipulaci s NFT (prodej, přesuny, zalistování na marketplace); a (3) permit mechanismy (např. EIP-2612 a Permit2), které udělují povolení podepsanou zprávou bez on-chain transakce při schvalování. Oprávnění se ukládají do storage příslušného tokenového kontraktu (resp. frameworku na oprávnění) a jsou čitelná na block explorerech i specializovaných nástrojích.
Typy oprávnění 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í i per-token schválení přes approve(tokenId). EIP-2612 Permit umožňuje udělit nebo aktualizovat allowance podpisem (off-chain), který kontrakt verifikuje až při prvním použití; podpis obsahuje nonce a deadline. Permit2 (Uniswap) abstrahuje schvalování pro více tokenů a dAppky 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ý se záměrně nepoctivou 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 bleskovému odčerpání aktiv. U permit schém platí, že ukradený podpis během platnosti a s nepoužitým nonce může být zneužit.
Kde a jak kontrolovat existující approvals
Kontrolu můžete provádět třemi způsoby: (1) přímo na block explorere v sekcích tokenu (Allowance/Approved Operators), (2) pomocí specializovaných „revoke“ nástrojů, 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“. Mějte na paměti, že každá síť (Ethereum, L2, sidechainy) udržuje vlastní stav – ověřujte oprávnění 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ů“ seřazený 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) počí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í dvoukrokové nastavení: nejprve na 0, a až potom na novou hodnotu (historické vzory ochrany proti race conditions). Poplatek za gas platí ten, kdo odvolává (vy), a transakce proběhne 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). Uděláte to přes UI nástroje pro správu oprávnění nebo přímo na block explorere v sekci „Write Contract“. Ověřte, zda se jedná o správnou kolekci (adresu NFT kontraktu) a správného operátora (adresu marketplace/agenturálního 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 uplyne, stává se neplatným. Pokud byl podpis již použit (nonce spotřebováno), 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í transferFrom pokusy daného spendera, nebo (2) pokud framework podporuje „invalidate“ / „lockdown“ funkce, použít je. Permit2 umožňuje revoke pro konkrétní páry token/spender a také pracuje s časově omezenými oprávněními; revokaci provedete přes kompatibilní UI nebo přímým voláním metod kontraktu 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 Optimismu a naopak. Odvolání musíte spouštět na téže síti a zohlednit tamní poplatky a mempool. U rollupů sledujte také odlišné časy finality a případné rozdíly v block explorerech.
Bezpečnostní zásady při udělování nových approvals
Minimalizujte rozsah a dobu trvání: (1) pokud je to možné, neuVOLUJTE „infinite approval“; nastavte pouze částku potřebnou pro operaci; (2) preferujte časově omezená a per-spender schválení (Permit2 a podobné); (3) používejte ověřené dApp, kontrakty s verifikovaným kódem a audity; (4) u NFT zvažte používání dedikované „trading“ peněženky oddělené od „trezorové“; (5) aktivujte notifikace z peněženky a sledujte Approval/ApprovalForAll eventy; (6) pro týmy využívejte multisig a role-based přístupy (např. treasury má jiná práva 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, operátoři NFT). 3) Přesuňte zbývající aktiva na novou adresu, pokud máte podezření na kompromitaci 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) jde vše 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é ochranné mechanizmy a modulární politiky vaše AA peněženka podporuje.
Ověřování legitimity spenderů a operátorů
Před revokací či novým schválením si ověřte: (1) adresu kontraktu (oficiální zdroje projektu), (2) zda je kód verifikován a odpovídá očekávaným rozhraním (ERC-20/721/1155), (3) historii transakcí kontraktu a reputaci (jestli nejde o nově vytvořenou, „podezřele prázdnou“ adresu), (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 běžné on-chain transakce a stojí gas. Úsporu můžete dosáhnout: (1) seskupením revokací do období s nižším base-fee, (2) využitím batch funkcí, pokud to nástroj/peněženka umožňuje, (3) preferencí revokace jen tam, kde je skutečné riziko (nepoužívané a neznámé kontrakty, infinite approvals), (4) výběrem L2 sítě, pokud se schválení nachází právě 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 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 znovu vyžádat schválení. Při dalším používání dodržujte strategii least privilege – schvalovat pouze to, co je nezbytné, na nezbytnou dobu, 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 „infinite“ na konkrétní limity.
• Ověřte fungování důležitých dApp po zpřísnění.
• Zaznamenejte si změny a naplánujte další audit za 30 dní.
Nejčastější chyby a mýty
Chyba: „Odpojení peněženky od webu ruší on-chain approvals.“ – Neplatí; jde jen o ukončení webové relace. Chyba: „Když jsem udělil permit, už to nelze vzít zpět.“ – v praxi můžete 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 obvykle práva na všechny NFT daného kontraktu.
Shrnutí
On-chain approvals jsou nepostradatelným mazivem DeFi a NFT ekosystému, avšak představují trvalá a často rozsáhlá práva nad vašimi aktivy. Klíčem je pravidelná kontrola, cílené odvolávání a minimalistická, časově omezená schválení s důvěryhodnými kontrakty. Tím zásadně snížíte povrch útoku, aniž byste obětovali použitelnost.
