EIP-7702 w praktyce: co oznacza dla Twojego portfela?

80% użytkowników portfeli nie musi zmieniać adresu, aby ich konto zyskało funkcje smart kontraktu. To efekt nowego podejścia do transakcji, które pozwala EOA delegować wykonanie do logiki kontraktu bez utraty oryginalnego adresu.

EIP-7702 w praktyce daje użytkownikom możliwość podpisania authorization (np. w viem z executor: 'self’ i contractAddress) i wykonania zadań jak batching czy sponsorowane opłaty, przy zachowaniu tego samego msg.sender w kontekście EOA.

W eksploratorze bloków pojawia się wtedy sekcja Authorizations (Authority = EOA, Contract = adres logiki). To otwiera drogę do programowalnych reguł działania portfela i lepszego UX bez migracji konta.

W dalszych częściach artykułu pokazane zostanie, jak przygotować authorizationList, jak działa chainId: 0 i jakie są różnice między self-execution a sponsored execution. Czytelnik dowie się też, jak bezpiecznie podpisywać autoryzacje i czego unikać.

Najważniejsze wnioski

Nowy proposal umożliwia EOA działanie jak smart account bez zmiany adresu.
Pojedynczy podpis authorization otwiera batching i sponsorowane opłaty.
W eksploratorze widać Authorizations: Authority = EOA, Contract = adres logiki.
chainId: 0 ułatwia multichain, ale wymaga zsynchronizowanych nonce.
Warto poznać przykłady implementacji (np. viem) i sprawdzić bezpieczeństwo przed podpisem.
Aby zrozumieć różne portfele, przeczytaj także przewodnik o rodzajach portfeli: rodzaje portfeli kryptograficznych.

Dlaczego EIP-7702 powstało i co rozwiązuje w UX portfeli

Główną motywacją projektu była poprawa doświadczeń użytkowników podczas typowych operacji w portfelach. Dziś wiele prostych akcji wymaga kilku podpisów i oddzielnych opłat, co zniechęca nowych użytkowników.

Użytkownicy często muszą mieć ETH na gas, nawet gdy operują wyłącznie stablecoinami. To blokuje płynne wejście do ekosystemu.

Ryzyko związane z pojedynczą frazą seed lub prywatnym kluczem też jest duże. Błędy są trudne do naprawienia, co podnosi wymagania dotyczące security.

Most między EOAs a smart accounts

Rozwiązanie pozwala eoas delegować wykonanie do logiki kontraktu, zachowując swój adres. Dzięki temu users nie muszą migrować środków ani tracić historii i reputacji.

Portfele przejmą kontrolę nad autoryzacjami, a dAppy będą korzystać ze standardów takich jak ERC-5792 i ERC-7710/7715. To wspiera kierunek abstraction i upraszcza flow dla accounts.

Mniej kliknięć i mniej podpisów przy pojedynczym transaction.
Niższe tarcie onboardingowe, bo nie trzeba trzymać ETH wyłącznie na gas.
Lepsza kontrola bezpieczeństwa: logika ogranicza zakres operacji zamiast polegać tylko na surowym kluczu.

eip-7702 wyjaśnienie: jak EOA “zyskuje” kod smart contract

Ten rozdział pokazuje, jak new transaction type przenosi kod kontraktu do payloadu i pozwala EOA tymczasowo zyskać zachowania smart account.

Nowy transaction type rozszerza standardowy payload o pole authorizations. To tam trafia contract_code oraz podpis EOA. Dzięki temu klient może ustawić code dla wskazanego account tylko na czas wykonania transakcji.

W praktyce RLP zawiera dodatkową listę autorizacji, np. rlp([chain_id, nonce, …, [[contract_code, y_parity, r, s], …], signature_y_parity, signature_r, signature_s]).

Sieć widzi, że przy wywołaniu użyto specjalnego znacznika 0xef0100 || address. To informuje węzeł, do jakiego contract delegowana jest egzekucja.

Różnice wobec EIP-3074 i zgodność z AA

Brak invokerów i AUTH/AUTHCALL — prostszy model nonce i tenant.
Zgodność z smart contract accounts w roadmapie ERC-4337; UserOps są mniej złożone.
Kluczowa korzyść UX: nie trzeba migrować konta ani wdrażać oddzielnego kontraktu dla każdego adresu.

contract_code authorization

Jak to działa pod maską: delegacja, msg.sender i znacznik 0xef0100

Pod maską mechanizm działa jak lekka warstwa delegation, która przekierowuje execution do logiki contract, nie zmieniając tożsamości nadawcy. W trakcie call msg.sender pozostaje EOA, co utrzymuje kompatybilność z istniejącymi dAppami.

Deweloper widzi w kodzie konta postać 0xef0100 || address. Prefiks 0xef0100 jest stały, a kolejne 20 bajtów wskazuje docelowy contract. Wywołanie getCode zwróci ten zapis i pozwoli szybko wykryć aktywną delegację.

delegation contract

SetCode i „delegation designation”

Klient tymczasowo ustawia code konta (SetCode), aby EVM odczytał, do jakiego contract kierować wykonanie. To nie zmienia eoa address — podpisy i uprawnienia pozostają ważne.

Delegation nie zmienia tożsamości — msg.sender to EOA.
getCode ujawnia 0xef0100 || address — proste narzędzie do inspekcji.
Call odbywa się w kontekście EOA, więc integracje dAppów działają bez zmian.

Element	Co pokazuje	Dlaczego to ważne
0xef0100 \|\| address	Prefiks + adres kontraktu	Umożliwia szybkie wykrycie delegacji przez getCode
SetCode (tymczasowy)	Ustawia wskazanie wykonawcze	Pozwala delegować execution bez migracji konta
msg.sender = EOA	Tożsamość nadawcy zachowana	Kompatybilność z whitelistami i podpisami

Przygotowanie portfela i środowiska: krok po kroku

Przed wysłaniem pierwszej transakcji trzeba skonfigurować klienta portfela i przygotować listę autoryzacji. W Viem zaczyna się od createWalletClient, potem wywołuje się signAuthorization z parametrami takimi jak executor: 'self’ i wskazanym contractAddress.

Po podpisaniu authorization można użyć sendTransaction kierowanego do własnego account i dołączyć authorizationList. W jednym kroku następuje broadcast i wykonanie logiki kontraktu, a msg.sender pozostaje EOA.

Najważniejsze praktyczne uwagi

W obiekcie authorization widoczne są pola: address, chainId, nonce, r, s, v/yParity — to ułatwia audyt i debug.
chainId: 0 tworzy signature ważny na wielu chains, ale działa tylko gdy nonce są zsynchronizowane na tych łańcuchach.
Dla trybu self-execution Viem automatycznie dopasowuje authorization.nonce, bo EOA zwiększa nonce przed wykonaniem logiki.
Gdy transakcję nadaje relayer, authorization.nonce musi dokładnie odpowiadać bieżącemu nonce konta — to częsta przyczyna nieudanych walidacji.
Developers powinni tworzyć testy e2e i monitorować implementacje, bo różne wallets i implementations mogą inaczej obsługiwać injection authorizationList.

„Dobra konfiguracja środowiska minimalizuje ryzyko błędów związanych z nonce i poprawia przewidywalność wdrożeń.”

Na koniec warto dodać monitoring węzłów i mapowanie wersji kontraktów. To daje kontrolę nad tym, do jakiej logiki deleguje się wykonanie i ułatwia szybką diagnostykę.

Self-execution: użytkownik ma ETH na gas i wykonuje batch

Self-execution pozwala użytkownikowi uruchomić wiele akcji za jednym podpisem, gdy ma ETH na opłaty. To wygodny sposób na konsolidację kilku calls w jednej transakcji.

batch calls

Plan działania jest prosty. Najpierw użytkownik podpisuje authorization z parametrem executor: 'self’.

Plan działania

Następnie przygotowuje tablicę calls — wywołań do różnych kontraktów, np. transferów ERC‑20. Koduje function execute(calls) kontraktu BatchCallAndSponsor za pomocą ABI.

Potem broadcastuje transaction do własnego account, dołączając authorizationList. W rezultacie kontrakt agreguje calls i uruchamia wszystkie operations atomowo.

Efekty i koszty

Jeden atomowy transfer wielu tokenów zamiast kilku oddzielnych transakcji.
AuthorizationList zwiększa zużycie gas, ale suma opłat zwykle bywa niższa niż suma oddzielnych transaction.
msg.sender pozostaje EOA, więc allowances i polityki dostępu działają bez zmian.
Przy dużych batchach warto szacować limit gas i rozmiar danych ABI, aby uniknąć przekroczeń.
Emitowanie eventów w kontrakcie ułatwia późniejszą analizę, które calls zostały wykonane.

Jedna transakcja z poprawnie skomponowanym batch eliminuje ryzyko niekompletnych przepływów przy awarii i poprawia UX.

Aby dezaktywować delegację, klient może ustawić SetCode na 0x000…000 lub podmienić docelowy contract na inny address. To prosty mechanizm, ale wymaga procedury operacyjnej i testów przed wdrożeniem.

Authorization nonce: różnice praktyczne

W trybie, gdy executor to użytkownik (EOA), platforma inkrementuje nonce przed wykonaniem autoryzacji. W takim wypadku warto ustawić authorization.nonce zgodnie z wartością po inkrementacji.

Gdy transakcję nadaje relayer, authorization.nonce powinien odpowiadać bieżącemu nonce EOA. Brak tej zgodności zwykle prowadzi do odrzucenia operacji.

„Miej przygotowany plan 'odcięcia’ (SetCode=0) na wypadek błędu w logice lub incydentu; to kluczowy element security.”

Po wdrożeniu account działa jak smartne konto do czasu zmiany code.
Zarządzanie zmianami kontraktu wymaga kontroli wersji i testów (canary release).
Monitoring eventów i adresów docelowych zmniejsza ryzyko pomyłek.
Dokumentacja polityk nonce redukuje błędy operacyjne.

Problem	Objaw	Rozwiązanie
Trwała delegacja	Account wykonuje delegowane wywołania	SetCode=0x0 lub podmiana contract
Niezgodny nonce (EOA)	Authorization odrzucona przy self-execution	Użyć nonce po inkrementacji
Niezgodny nonce (relayer)	Relayer nie może zrealizować tx	Authorization.nonce = bieżący nonce EOA
Security incydent	Błąd w logice contract	Natychmiastowe SetCode=0 i audyt

W praktyce zespoły powinny też zaplanować kontrolowane migracje i testy oraz śledzić zdarzenia na łańcuchu. Dobre procedury operacyjne poprawiają bezpieczeństwo i ułatwiają zarządzanie delegacjami. Dodatkowe informacje o mechanizmach płatności i delegacji można znaleźć w przewodniku o mikropłatnościach w blockchainie.

Co możesz robić dzięki EIP-7702 i czego nie zrobisz

Dzięki nowemu mechanizmowi można łączyć kilka działań w jeden bez migracji środków. eip 7702 otwiera praktyczne use‑case’y: batching, sponsorowanie opłat i programowalne uprawnienia, przy zachowaniu tego samego address.

Use-cases:

Batch: approve + swap w jednej transakcji zmniejsza liczbę potwierdzeń i koszty.
Gas sponsorship: relayer pokrywa opłatę, co upraszcza onboarding w aplikacjach masowych.
Programowalne uprawnienia: sesyjne klucze i ograniczone prawa bez zmiany account.

Ograniczenia:

Klucz EOA wciąż jest nadrzędny — nie da się zrealizować twardego multi‑sig ani time‑locka tylko przez tę warstwę.
chainId: 0 i multichain działają tylko przy zsynchronizowanych nonce na różnych chains.
Kontrolę nad autoryzacjami mają głównie wallets — aplikacje muszą współpracować z portfelem.

W praktyce to most między tradycyjnym account a smart accounts — dużo zyskujesz, ale nie wszystkie funkcje full smart account są dostępne.

Dla deweloperów: wzorce integracji i narzędzia

Ten rozdział koncentruje się na gotowych wzorcach integracyjnych i narzędziach dla zespołów developerskich. Opis pokazuje, jak aplikacja może delegować budowę sekwencji wywołań do portfela i jak zabezpieczyć operacje.

ERC-5792: wallet_sendCalls i prosty batching

wallet_sendCalls pozwala aplikacji przekazać zestaw calls do portfela, który sam zbuduje sekwencję i wykona batch. To najprostsza ścieżka dla developers, gdy chcą uniknąć złożonych implementacji po stronie serwera.

ERC-7710/7715: delegowanie uprawnień

Standardy te wprowadzają formalne żądanie i przyznawanie uprawnień (wallet_grantPermissions). Dzięki nim contracts mogą egzekwować ograniczone function i tworzyć warstwy uprawnień.

Companion accounts i Fusion Execution

Companion accounts dają aplikacji pełną kontrolę nad execution i operations, bez polegania na implementacjach portfeli. Fusion Execution (np. Biconomy) kompresuje instrukcje, by działać z portfelami bez wsparcia 7710/7715.

Tanie wdrożenia i narzędzia

EIP-7702 sprzyja tanim wdrożeniom — proxy kosztuje ~12 500 gas. AbstractJS (Biconomy) upraszcza wykrywanie możliwości portfela, wybiera ścieżkę (5792 vs 7710/7715 vs companion) i enkoduje calls oraz function.

„Dobre wzorce integracji redukują fragmentację i przyspieszają produkcyjne wdrożenia.”

Wzorzec	Zaleta	Kiedy stosować
wallet_sendCalls (ERC-5792)	Prosty batching sterowany przez portfel	Gdy developers chcą minimalnej integracji
wallet_grantPermissions (ERC-7715)	Formalne żądanie i delegacja uprawnień	Gdy potrzebne są ograniczone permissions między contracts
Companion accounts	Pełna kontrola nad execution	Gdy aplikacja wymaga spójnych operations niezależnie od implementations
Fusion Execution	Kompatybilność z nieobsługującymi portfelami	Gdy fragmentacja portfeli blokuje wdrożenie

Rekomendacja: developers powinni dokumentować contracts, audytować smart contracts i planować migracje. Integracja z account abstraction obniża vendor lock‑in i poprawia UX.

Wniosek

To ewolucyjny krok: użytkownicy otrzymują funkcje smart accounts bez przenoszenia środków.

Proposal łączy wygodę EOA z możliwościami smart contract — batching, sponsorowanie opłat i programowalne uprawnienia przy zachowaniu tego samego address i msg.sender.

W praktyce wdrożenia pokazują znacznik 0xef0100 || address, dwa tryby execution (self i sponsored) oraz rolę walletów w kontroli authorization i podpisów.

Deweloperzy powinni sięgać po standardy (ERC‑5792, ERC‑7710/7715), używać tanich proxy (~12 500 gas) i narzędzi jak AbstractJS, a użytkownicy muszą pamiętać o security, nonce i synchronizacji across chains.

Podsumowując: eip 7702 to most między tradycyjnymi accounts a account abstraction — mniej kliknięć, mniej transaction i większa kontrola w portfelu, przy zachowaniu tożsamości EOA.

FAQ

Czym jest EIP-7702 i co zmienia dla portfela?

To propozycja pozwalająca przypisać kod kontraktu do istniejącego adresu EOA, dzięki czemu konto zewnętrzne może działać jak smart account. Użytkownik zyskuje możliwość wykonywania złożonych operacji (batch, delegacja, sponsorship) bez migracji adresu i bez tworzenia nowego konta.

Dlaczego powstało to rozwiązanie i jakie problemy UX usuwa?

Rozwiązanie powstało, by zmniejszyć friction w dAppach: eliminować konieczność wielu podpisów, umożliwić płacenie przez sponsora oraz zredukować ryzyko związane z przechowywaniem klucza prywatnego. Mostuje EOAs i smart accounts bez zmiany adresu użytkownika.

Jak EOA „zyskuje” kod smart contract technicznie?

Mechanizm wprowadza nowy typ transakcji z polem authorizations/contract_code, które pozwala na trwałe przypisanie logiki kontraktowej do adresu EOA poprzez operacje setCode lub delegację wykonania.

Czym różni się to od EIP-3074 i jak wpisuje się w account abstraction?

Główna różnica to model autoryzacji i sposób przypisywania kodu. EIP-7702 koncentruje się na trwałej integracji kodu z EOA, a jego koncepcje są komplementarne względem roadmapy account abstraction, w tym ERC-4337.

Jak działa delegacja i jak zachowuje się msg.sender?

Wykonanie może zostać delegowane do kontraktu przy zachowaniu adresu EOA jako msg.sender. Mechanizm oznaczony jest specyficznym znacznikiem 0xef0100, co ułatwia rozpoznanie delegacji i routing wywołań.

Co oznacza „delegation designation” i jak używa się 0xef0100 || address?

To format wskazujący, że delegacja ma kierować wywołania do określonego kontraktu. Prefix 0xef0100 połączony z adresem kontraktu sygnalizuje on-chain, która logika ma obsłużyć żądanie.

Jak przygotować portfel i środowisko deweloperskie krok po kroku?

Trzeba skonfigurować narzędzia (np. Viem) z opcjami signAuthorization, executor: 'self’ i wskazać contractAddress. Uwzględnia się też chainId dla bezpieczeństwa i ważności podpisów przy multi-chain.

Dlaczego warto zwrócić uwagę na chainId i co oznacza chainId: 0?

chainId określa ważność podpisu na konkretnym łańcuchu. chainId: 0 może oznaczać brak ograniczenia łańcucha, co zwiększa ryzyko replay attacków na innych sieciach, dlatego trzeba to stosować świadomie.

Co to jest self-execution i jak wygląda proces wykonania batchu?

Self-execution to scenariusz, w którym użytkownik posiada ETH na gas i sam wykonuje atomowy batch: podpisuje autoryzację, koduje batch i broadcastuje transakcję z authorizationList, co pozwala na wielooktowe transfery jednym wywołaniem.

Jak authorizationList wpływa na koszty gas?

AuthorizationList wpływa na rozmiar i koszt transakcji — większe listy zwiększają koszty, ale umożliwiają jednoatomowe wykonanie wielu operacji, co bywa tańsze niż wiele pojedynczych transakcji.

Co oznacza sponsored execution i kiedy jest przydatne?

Sponsored execution to model, gdzie relayer lub sponsor pokrywa opłatę za gas, a użytkownik jedynie podpisuje off‑chain digest. Przydatne dla UX, bo pozwala użytkownikom bez ETH wykonać operacje.

Jak weryfikowany jest off-chain podpis w modelu sponsored execution?

Podpis dotyczy zdigestowanej struktury zawierającej nonce i encodePacked danych. Relayer przesyła podpis on-chain, gdzie jest weryfikowany przed wykonaniem żądań transmit.

Jakie są zagrożenia związane z relayerem i bezpieczeństwem podpisu?

Relayer musi prawidłowo obsługiwać podpisy i nie powinien modyfikować treści bez zgody. Należy chronić nonce i stosować mechanizmy replay protection oraz weryfikację chainId, by uniknąć nadużyć.

Co dzieje się ze stanem konta po transakcji — czy delegacja jest trwała?

Delegacja może być trwała lub odwracalna. Zmiana logiki odbywa się poprzez setCode (podmiana), ustawienie na zero lub wskazanie innego kontraktu. Trzeba uważać na pułapki związane z nonce i autoryzacjami.

Jak działa authorization nonce i jakie są różnice, gdy executor: 'self’?

Authorization nonce to licznik zapobiegający replayom. Gdy executor: 'self’, to EOA bezpośrednio nadaje autoryzacje i kontroluje nonce; przy relayerze mechanika może różnić się w zależności od implementacji.

Jakie zastosowania udostępnia ten mechanizm, a czego nie osiągnie?

Umożliwia batch transactions, gas sponsorship i programowalne uprawnienia. Nie zastąpi jednak w pełni multisigów czy time-locków — klucz EOA wciąż pozostaje nadrzędny, więc nie zapewni „prawdziwej” wielopodpisowości bez dodatkowej logiki.

Jakie ograniczenia pojawiają się w środowisku multichain?

Podpisy mogą być ważne na wielu łańcuchach, ale niesynchronizowane nonce między sieciami prowadzą do replayów i konfliktów. Trzeba projektować mechanizmy cross‑chain z uwzględnieniem tych różnic.

Kto praktycznie kontroluje wdrożenia i adopcję tej propozycji?

Główną rolę odgrywają portfele i dostawcy usług walletowych, którzy implementują obsługę nowych transakcji. To wpływa na dAppy, bo kontrola nad UX i autoryzacjami przesuwa się w stronę portfeli.

Jak deweloper może integrować funkcje podobne do EIP-7702?

Deweloperzy mogą wykorzystać wzorce i standardy jak ERC-5792 do wallet_sendCalls, ERC-7710/7715 do grantPermissions oraz biblioteki i narzędzia (np. AbstractJS) do prostego batchingu i delegacji.

Co to są companion accounts i Fusion Execution jako obejścia?

Companion accounts to dodatkowe konta wspierające funkcjonalność głównego EOA, a Fusion Execution łączy kilka mechanizmów wykonania, by obejść fragmentację funkcji między różnymi implementacjami portfeli.

Jakie są koszty wdrożenia smart accounts przy tym podejściu?

W praktyce można osiągnąć relatywnie tanie wdrożenia — przykładowe proxy wykonanie może kosztować około 12 500 gas, w zależności od łańcucha i optymalizacji kodu.

Jakie narzędzia i implementacje warto znać przy pracy z tymi rozwiązaniami?

Warto używać narzędzi takich jak Viem do podpisywania autoryzacji, biblioteki AbstractJS, oraz śledzić implementacje portfeli i standardów ERC-5792, ERC-7710/7715 dla integracji permissions i batching.