Standard ERC-20 to kręgosłup większości zamiennych tokenów na Ethereum. Dzięki niemu portfele, giełdy i aplikacje DeFi rozumieją ten sam zestaw reguł, zamiast integrować każdy projekt osobno. W praktyce oznacza to prostsze transfery, łatwiejszą integrację i mniej niespodzianek przy obsłudze aktywów cyfrowych.
Najważniejsze rzeczy, które warto wiedzieć o ERC-20
- ERC-20 opisuje zasady działania tokenu zamiennego, a nie samą sieć Ethereum ani ethera.
- Najważniejsze elementy kontraktu to m.in.
balanceOf,transfer,approveitransferFrom. - Standard świetnie sprawdza się przy stablecoinach, tokenach governance, punktach lojalnościowych i wrapped assetach.
- Najczęstsze ryzyka to fałszywe tokeny, zła sieć, nadmiarowe uprawnienia i wysyłka środków na nieobsługujący kontrakt.
- Nie każdy token musi mieć te same parametry, bo część pól, jak
name,symbolczydecimals, jest opcjonalna.
Czym są tokeny ERC-20 i dlaczego ten standard w ogóle powstał
Ja patrzę na ERC-20 jak na wspólny język dla aktywów zamiennych na Ethereum. Zamienny oznacza tu coś bardzo konkretnego: jedna jednostka jest ekonomicznie taka sama jak każda inna jednostka tego samego tokenu. Jeśli masz 1 USDC albo 10 USDC, znaczenie ma wyłącznie ilość, a nie to, który konkretnie egzemplarz trzymasz w portfelu.
Ten standard powstał po to, żeby tokeny mogły działać w aplikacjach bez ręcznego dopisywania osobnej logiki dla każdego projektu. Zamiast tworzyć własne reguły transferu, salda i zatwierdzania wydatków, twórca tokena korzysta z ustalonego interfejsu. Właśnie dlatego portfel, giełda albo protokół DeFi może rozpoznać nowy token i obsłużyć go podobnie jak inne aktywa zgodne z tym samym wzorcem.
W praktyce ERC-20 to nie „kolejna kryptowaluta”, tylko standard techniczny dla smart kontraktów. W dokumentacji Ethereum podkreśla się, że chodzi o interoperacyjność z portfelami, aplikacjami i giełdami, a to jest dla użytkownika ważniejsze niż sama nazwa tokena. Jeśli projekt ma być łatwo przenoszalny i czytelny dla ekosystemu, taki standard daje mu solidny punkt startu.
To dobry punkt wyjścia, ale sama definicja nie wystarcza. Żeby naprawdę rozumieć ERC-20, trzeba zobaczyć, jakie funkcje musi oferować kontrakt i jak to przekłada się na codzienne użycie.
Jakie funkcje musi mieć kontrakt ERC-20
Najprościej mówiąc, kontrakt ERC-20 ma przechowywać informację o saldach i umożliwiać transfer oraz zatwierdzanie wydatków przez inne adresy. Część pól jest obowiązkowa, część opcjonalna, a właśnie te detale najczęściej umykają osobom, które patrzą tylko na nazwę tokena w portfelu.
| Element | Do czego służy | Status | Co warto zapamiętać |
|---|---|---|---|
name |
Nazwa tokena | Opcjonalny | Pomaga w identyfikacji w interfejsach, ale nie każdy kontrakt go zwraca. |
symbol |
Skrót tokena | Opcjonalny | Przykład: USDC, DAI, UNI. |
decimals |
Liczba miejsc dziesiętnych | Opcjonalny | Najczęściej spotyka się 18, ale to konwencja, nie nakaz. |
totalSupply |
Całkowita podaż tokena | Wymagany | Pokazuje, ile jednostek istnieje w obiegu według kontraktu. |
balanceOf |
Saldo wskazanego adresu | Wymagany | To podstawowa metoda do sprawdzania stanu portfela. |
transfer |
Przesłanie tokenów do innego adresu | Wymagany | Powinien emitować zdarzenie Transfer. |
approve |
Nadanie uprawnienia do wydania określonej ilości tokenów | Wymagany | To nie jest zwykły przelew, tylko zgoda na późniejsze użycie środków. |
transferFrom |
Transfer z adresu, który wcześniej przyznał allowance | Wymagany | Używany przez kontrakty, które działają w modelu zatwierdzeń. |
allowance |
Sprawdzenie pozostałego limitu wydatków | Wymagany | Pokazuje, ile dany kontrakt albo adres może jeszcze wydać. |
Transfer |
Zdarzenie informujące o transferze | Wymagany | Ułatwia śledzenie ruchu tokenów przez aplikacje i eksploratory. |
Approval |
Zdarzenie informujące o zatwierdzeniu allowance | Wymagany | Kluczowe dla integracji z DeFi i innymi kontraktami. |
Ważny detal: standard dopuszcza też transfer zerowej ilości tokenów i taki transfer nadal powinien być obsłużony jak normalna operacja. To drobiazg, ale właśnie takie niuanse odróżniają poprawną implementację od kontraktu, który działa tylko „na papierze”.
W praktyce to te funkcje sprawiają, że token da się pokazać w portfelu, zliczyć w aplikacji i użyć w protokole bez osobnych reguł dla każdego projektu. A skoro już wiemy, jak działa techniczny szkielet, przejdźmy do tego, gdzie ten standard daje najwięcej wartości.
Gdzie ERC-20 sprawdza się najlepiej
Największą siłą ERC-20 jest przewidywalność. Jeśli projekt ma reprezentować coś zamiennego, łatwego do przesyłania i rozpoznawalnego przez różne aplikacje, ten standard zwykle jest pierwszym sensownym wyborem. Właśnie dlatego tak dużo ekosystemu Ethereum opiera się na tokenach zgodnych z tym wzorcem.
- Stablecoiny - tu standard działa wyjątkowo dobrze, bo liczy się prosty transfer wartości i kompatybilność z portfelami, giełdami oraz DeFi.
- Tokeny governance - służą do głosowania i udziału w decyzjach protokołu, więc zamienność jednostek jest naturalna.
- Wrapped assets - przykład WETH pokazuje, jak można „opakować” aktywo tak, by działało w aplikacjach oczekujących interfejsu ERC-20.
- Tokeny użytkowe - punkty, kredyty, jednostki dostępu albo wewnętrzna waluta aplikacji web3.
- Tokeny w DeFi - płynność, staking, lending i rewardy zazwyczaj opierają się na tokenach zamiennych.
Ważne jest jednak coś jeszcze: sam standard nie mówi, czy token ma wartość inwestycyjną, jak jest emitowany ani kto kontroluje podaż. To już zależy od konkretnego projektu, tokenomiki i tego, czy zespół naprawdę panuje nad emisją. Dla użytkownika oznacza to jedno - dwa tokeny zgodne z ERC-20 mogą wyglądać podobnie w portfelu, ale ekonomicznie być zupełnie inną historią.
Skoro zastosowania są tak szerokie, łatwo pomylić ERC-20 z innymi standardami. Żeby nie mieszać pojęć, porównajmy go z tym, co spotyka się najczęściej w Ethereum.
Czym ERC-20 różni się od ETH, NFT i ERC-1155
To porównanie porządkuje najwięcej nieporozumień. ERC-20 dotyczy tokenów zamiennych, ale Ethereum jako sieć, NFT i standard wielotokenowy ERC-1155 rozwiązują inne problemy. Jeśli rozumiesz tę różnicę, dużo łatwiej ocenisz, czy dany projekt jest dobrze zaprojektowany.
| Standard | Co reprezentuje | Zamienność | Typowe zastosowanie | Najważniejsza różnica |
|---|---|---|---|---|
| ETH | Nattywny asset sieci Ethereum | Tak | Opłaty, płynność, rozliczenia | To nie token na smart kontrakcie, tylko bazowe aktywo sieci. |
| ERC-20 | Token zamienny zarządzany przez kontrakt | Tak | Stablecoiny, governance, utility, wrapped assets | Najbardziej uniwersalny standard dla aktywów wymiennych. |
| ERC-721 | Unikalny NFT | Nie | Kolekcje, bilety, aktywa indywidualne | Każdy egzemplarz ma własny identyfikator i może mieć inną wartość. |
| ERC-1155 | Standard wielotokenowy | Tak i nie, zależnie od typu | Gry, zasoby mieszane, batch transfery | Jeden kontrakt może obsługiwać wiele klas aktywów jednocześnie. |
Jeśli projekt potrzebuje tylko prostych jednostek wymiennych, ERC-20 zwykle wygrywa prostotą. Jeśli w grę wchodzą rzeczy unikalne, kolekcjonerskie albo mieszane zasoby, sens zaczyna mieć ERC-721 lub ERC-1155. Ja patrzę na to bardzo praktycznie: nie wybiera się standardu „bo popularny”, tylko dlatego, że pasuje do modelu aktywa i do tego, jak będą z nim pracować aplikacje.
To prowadzi do kolejnego ważnego pytania: jak taki token powstaje od strony technicznej i co w praktyce robi zespół, który go wdraża.
Jak powstaje token ERC-20 w praktyce
W większości projektów nikt nie pisze tokenu od zera, jeśli nie ma ku temu bardzo dobrego powodu. Najczęściej korzysta się z gotowej, sprawdzonej implementacji i dopina własną logikę wokół podaży, uprawnień, mintowania, spalania albo blokad czasowych. To rozsądne podejście, bo sam standard jest prosty, ale błędy w logice biznesowej potrafią być kosztowne.
- Definiuję tokenomikę - ustalam, czy podaż ma być stała, kontrolowana przez mint, częściowo spalana, czy rozdzielana etapami.
- Wybieram bazową implementację - w praktyce często używa się sprawdzonych bibliotek, bo redukują ryzyko błędów w podstawowych funkcjach.
- Określam parametry techniczne - nazwa, symbol i liczba miejsc po przecinku muszą pasować do użycia w portfelach i integracjach.
- Projektuję role i uprawnienia - decyduję, kto może emitować nowe jednostki, zmieniać parametry albo zatrzymywać określone operacje.
- Testuję transfery i allowance - sprawdzam zwykłe przelewy, zatwierdzenia i scenariusze graniczne, bo tu najłatwiej o błąd.
- Weryfikuję kontrakt po wdrożeniu - dzięki temu użytkownicy i narzędzia mogą łatwiej przejrzeć kod oraz potwierdzić, że token robi to, co deklaruje.
Koszt wdrożenia nie jest stały, bo zależy od rozmiaru kontraktu, liczby zapisów w pamięci, złożoności logiki oraz aktualnego obciążenia sieci. Im bardziej rozbudowany projekt, tym większa szansa na dodatkowe testy, audyt i ostrożniejsze wdrażanie. I właśnie dlatego prosty token użytkowy da się zbudować szybko, ale token z kontrolą emisji, vestingiem i dodatkowymi regułami wymaga już dużo więcej dyscypliny.
Sam kontrakt to jednak tylko połowa historii. Druga połowa zaczyna się wtedy, gdy użytkownik faktycznie wysyła tokeny, daje zgodę aplikacji albo próbuje przenieść je między kontraktami. Wtedy pojawiają się realne ryzyka.
Jak używać tokenów bezpiecznie i nie wpaść w typowe pułapki
Najwięcej strat nie wynika z samego standardu, tylko z pośpiechu. Ja zawsze sprawdzam trzy rzeczy: adres kontraktu, właściwą sieć i uprawnienia, które dana aplikacja chce uzyskać. To jest prosty nawyk, ale w praktyce oszczędza mnóstwo problemów.
| Błąd | Co może się stać | Jak się zabezpieczyć |
|---|---|---|
| Ocena tokena po samym symbolu | Fałszywy token może wyglądać identycznie jak prawdziwy | Sprawdzaj adres kontraktu, a nie tylko nazwę i skrót. |
| Wysyłka na złą sieć | Środki trafiają tam, gdzie ich nie widać lub nie da się ich łatwo użyć | Upewnij się, że portfel i token są na tej samej sieci. |
| Bezrefleksyjne approve | Aplikacja dostaje szerokie prawo do wydawania środków | Dawaj tylko potrzebny limit i odwołuj zgodę po użyciu. |
| Wysyłka do kontraktu, który nie obsługuje ERC-20 | Token może zostać bezpowrotnie utracony na adresie kontraktu | Sprawdzaj, czy odbiorca wspiera taki transfer albo czy używa modelu depozytu. |
| Założenie, że każdy token ma 18 decimals | Możesz pomylić wartość transakcji o kilka rzędów wielkości | Zawsze weryfikuj liczby przed potwierdzeniem transakcji. |
Dokumentacja Ethereum zwraca uwagę na jeszcze jeden ważny problem: zwykły transfer do kontraktu, który nie został zaprojektowany do odbioru tokenów, może je zablokować. W wielu integracjach lepszy jest model approve + transferFrom, ale i on wymaga ostrożności, bo daje kontraktowi uprawnienie do wydawania środków w określonym limicie. Jeśli dApp prosi o duże allowance bez jasnego powodu, ja traktuję to jak sygnał ostrzegawczy, a nie detal techniczny.
Warto też pamiętać, że symbol tokena nie gwarantuje autentyczności. Oszukańcze projekty potrafią kopiować nazwę, wygląd interfejsu i opisy, a później próbować skłonić użytkownika do podpisania niebezpiecznej transakcji. Dlatego w praktyce liczy się nie marketingowa etykieta, tylko adres kontraktu, historia aktywności i to, czy dana operacja rzeczywiście ma sens.
To wszystko prowadzi do ostatniej ważnej rzeczy: ERC-20 jest użyteczny, ale nie jest uniwersalnym rozwiązaniem na każdy scenariusz. I dobrze wiedzieć, gdzie jego granice zaczynają być widoczne.
Gdzie ERC-20 ma granice i kiedy lepszy będzie inny standard
ERC-20 świetnie sprawdza się przy aktywach zamiennych, ale ma kilka ograniczeń, które w bardziej złożonych projektach szybko zaczynają mieć znaczenie. Najważniejsze jest to, że standard nie daje natywnego mechanizmu powiadamiania odbiorcy o przychodzących tokenach, więc kontrakty bez odpowiedniej logiki mogą źle obsłużyć transfer. To nie jest wada pojedynczej implementacji, tylko cecha samego wzorca.
- Brak natywnego odbioru tokenów przez kontrakt - jeśli odbiorca nie został przygotowany na ERC-20, środki mogą utknąć.
- Ograniczone metadane - część pól jest opcjonalna, więc interfejsy muszą być odporne na brak niektórych informacji.
- Brak unikalności - jeśli potrzebujesz pojedynczych, niepowtarzalnych aktywów, lepszy będzie NFT.
- Brak natywnej obsługi wielu klas aktywów w jednym kontrakcie - przy zasobach mieszanych częściej wygrywa ERC-1155.
- Ryzyko nadmiernych allowance - przy integracjach DeFi trzeba bardzo świadomie zarządzać zgodami.
Jeśli projekt ma charakter kolekcjonerski albo reprezentuje unikalne przedmioty, lepiej od razu spojrzeć na ERC-721. Jeśli ma łączyć aktywa zamienne i unikalne albo wymaga batch transferów, sensowniejszy bywa ERC-1155. Jeżeli zaś token ma reprezentować udział w vaultach lub strategiach yieldowych, warto rozważyć standardy wyspecjalizowane w takich zastosowaniach, a nie wciskać wszystko w ERC-20 na siłę.
Gdybym miał zostawić jedną praktyczną zasadę, powiedziałbym tak: ERC-20 jest dobrym wyborem wtedy, gdy potrzebujesz zamiennych jednostek, prostego interfejsu i szerokiej kompatybilności. Jeśli jednak projekt zaczyna wymagać unikalności, wielu typów aktywów albo specjalnych reguł transferu, lepiej zawczasu sprawdzić, czy inny standard nie będzie bezpieczniejszy i zwyczajnie bardziej sensowny. Właśnie to podejście oszczędza później najwięcej problemów.
