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 k provádění operací s jeho aktivy bez potřeby 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žní „spenderovi“ převádět vaše tokeny přes transferFrom; (2) ERC-721/1155 operator práva prostřednictvím 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 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žní 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 schvalování 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 nepoctivou logikou. U NFT je rizikem globální operátor s právy na všechny vaše NFT kolekce; při kompromitaci operátora může dojít k bleskovému vyčerpá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 můžete provádět třemi způsoby: (1) přímo na block explorerech přes sekce tokenu (Allowance/Approved Operators), (2) přes specializované „revoke“ nástroje zobrazující 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“. Dávejte pozor, ž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 na 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) 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, až poté 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 operator práva pro ERC-721/1155
U NFT kontraktů voláte setApprovalForAll(operator, false). Uděláte to přes UI nástroje na správu oprávnění nebo přímo na block explorere přes „Write Contract“. Ověřte, zda 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 vyčerpá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í 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 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 Arbitru či Optimismu 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 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é, neudělujte „infinite approval“; nastavte pouze částku potřebnou na operaci; (2) preferujte časově omezená a per-spender oprávnění (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 indicii kompromitace seed phrase 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 do budoucna.
Specifika peněženek: EOA vs. smart contract/AA účty
Při klasických EOA účtech (Externally Owned Account) jde vše přes podpisy klíčem. Při smart-contract účtech (Account Abstraction, např. ERC-4337) může peněženka poskytovat jemnější politiky – limity, session keys, časová okna, whitelist dApp – což prakticky snižuje 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 kód verifikovaný a odpovídá očekávaným rozhraním (ERC-20/721/1155), (3) historii transakcí kontraktu a reputaci (zda nejde o nově vytvořenou, „podezřele prázdnou“ adresu), (4) případné proxy/upgradovatelné vzory (Transparent/Beacon proxy), kdy 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 dosáhnete: (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í revokace pouze tam, kde je reálné 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ž nedokáž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 z „infinite“ na konkrétní limity.
• Ověřte fungování důležitých dApp po zpřísnění.
• Zapište 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 můžete zrušit účinnost přes approve(spender, 0) nebo expiráci/spotřebování 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á 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ímto způsobem zásadně snížíte povrch útoku, aniž byste obětovali použitelnost.
