ERC-20
Standardowy interfejs dla wymienialnych tokenów na Ethereum. Definiuje wspólny zestaw funkcji, dzięki czemu portfele, giełdy i protokoły DeFi mogą obsługiwać dowolny zgodny token bez pisania dedykowanego kodu dla każdego z nich.
Interfejs ERC-20
Kontrakt zgodny z ERC-20 musi implementować 6 funkcji i emitować 2 zdarzenia.
Funkcje: totalSupply() zwraca łączną liczbę tokenów w obiegu; balanceOf(address) pokazuje saldo wybranego adresu; transfer(to, amount) przenosi tokeny z konta wywołującego na to; approve(spender, amount) daje spender prawo do wydania do amount tokenów w Twoim imieniu; allowance(owner, spender) pokazuje pozostały limit allowance; transferFrom(from, to, amount) przenosi tokeny po wcześniejszym approve i jest często używane przez protokoły DeFi.
Zdarzenia: Transfer jest emitowane przy każdym przeniesieniu tokenów, w tym mint i burn. Approval jest emitowane przy każdej zmianie allowance.
Dzięki temu jednemu zestawowi funkcji Uniswap, Aave, portfele i agregatory mogą obsługiwać dowolny token ERC-20 bez osobnych integracji dla każdego kontraktu.
Mechanizm approve/transferFrom
Ten dwuetapowy mechanizm jest podstawą interakcji z DeFi. Przykład: deponujesz USDC do Aave.
Najpierw wysyłasz transakcję approve(aavePoolAddress, kwota) do kontraktu USDC — dajesz Aave pozwolenie na ruszenie Twoich środków.
Następnie wywołujesz supply(usdcAddress, kwota) na kontrakcie Aave. Aave wewnętrznie woła USDC.transferFrom(twójAdres, aavePool, kwota).
Dlatego przy pierwszym korzystaniu z protokołu widzisz dwie transakcje do podpisania: approve i właściwą akcję. Przy kolejnych wywołaniach, do wyczerpania limitu, approve nie jest już potrzebny.
Ryzyko allowance
Jeśli protokół, któremu dałeś approve, zostanie zhakowany lub zawiera złośliwy kod, atakujący może wydać Twoje tokeny do ustalonego limitu. Dlatego warto regularnie sprawdzać i odwoływać niepotrzebne allowances, np. przez Revoke.cash.
ERC-20 a natywny ETH
ETH nie jest tokenem ERC-20. Nie ma funkcji balanceOf ani mechanizmu approve — jest przesyłany jako pole value transakcji. Tworzy to problem dla protokołów DeFi, które chcą traktować ETH jak każdy inny token.
Rozwiązaniem jest Wrapped ETH (WETH) — kontrakt ERC-20, w którym deponujesz ETH i otrzymujesz równoważną ilość WETH zachowującego się jak standardowy token.
Uniswap, Aave i większość protokołów DeFi używa WETH wewnętrznie. Wiele frontendów automatycznie opakowuje ETH w WETH przed interakcją.
Niestandardowe zachowania tokenów ERC-20
Nie każdy token ERC-20 zachowuje się identycznie. Standard określa interfejs, ale nie gwarantuje prostego modelu ekonomicznego.
Tokeny z opłatą od transferu (fee-on-transfer) pobierają procent od każdego przesunięcia. Odbiorca dostaje mniej niż zadeklarowana kwota. Łamie to założenie wielu protokołów DeFi, że jeśli kontrakt transferuje 100 tokenów, odbiorca dostaje dokładnie 100.
Tokeny rebase automatycznie zmieniają saldo każdego posiadacza w regularnych odstępach. Saldo w portfelu może zmienić się bez zwykłego transferu, co komplikuje integracje z protokołami, które zakładają stałe saldo między operacjami.
Przed interakcją z nieznanym tokenem warto sprawdzić, czy nie ma opłaty od transferu, mechanizmu rebase albo innych niestandardowych zachowań.
ERC-2612: Permit
ERC-2612 to rozszerzenie ERC-20 pozwalające na udzielenie allowance za pomocą podpisu off-chain, zwykle w standardzie EIP-712, zamiast pełnej transakcji on-chain.
W praktyce permit może oszczędzić jeden krok i jedną opłatę gas. Użytkownik podpisuje zgodę, a aplikacja używa tego podpisu przy właściwej transakcji.
To funkcja opt-in na bazie ERC-20 — nie każdy token ją obsługuje i nie zmienia ona podstawowego standardu ERC-20.