EIP-8477 stelt 256-blokkengrens voor ongebruikte 7702-autorisaties voor

EIP-8477 richt zich op een specifiek gat in EIP-7702: autorisatiehandtekeningen die ongebruikt worden opgeslagen en later alsnog worden afgespeeld. Het voorstel is gedocumenteerd op Ethereum Magicians, en de genoemde motivatie hangt direct samen met recente EIP-7702-sweeps op Binance 16.

Alleen ongebruikte autorisaties worden geraakt. Elke autorisatie zou een recent uitvoeringsblocknummer en de headerhash van dat blok moeten ondertekenen, naast de bestaande chain-ID, het delegatieadres en de nonce. Voor opname in uitvoeringsblok N moet het ondertekende blok binnen de voorafgaande 256 ancestors vallen.

De grens is exact. Een anker 256 blokken terug komt door de controle heen. Een anker 257 blokken terug wordt afgewezen. Het huidige blok en eventuele toekomstige blokken zijn eveneens uitgesloten, zodat het geldige venster precies die 256 voorgaande ancestors beslaat.

Die verenging is de kern van de beveiligingswijziging: een opgeslagen EIP-7702-autorisatie kan maar zo lang blijven liggen voordat hij te verouderd is om nog te gebruiken. Het concept stelt dat de bestaande EIP-7702-functionaliteit geen antwoord bood op langdurige opslag en latere herafspeling van ongebruikte handtekeningen, en de sweeps op Binance 16 worden expliciet als motiverende gebeurtenis genoemd.

De versheid wordt gecontroleerd tijdens de native autorisatieverwerking — vóór herstel van de handtekening of enige toegang tot autoriteitsspecifieke state. Als het blokanker is verlopen of de hash niet overeenkomt, wordt die autorisatie overgeslagen onder het bestaande “skip-on-failure”-gedrag van EIP-7702. Een structureel misvormde autorisatie volgt een ander pad: die maakt de hele transactie ongeldig.

Dezelfde versheidsregel geldt voor alle drie de bewerkingen. Het installeren van een delegatie, het vervangen ervan en het intrekken ervan met een nuladres zouden allemaal door dezelfde controle gaan. Dat geldt zowel voor eerste autorisaties als voor latere wijzigingen zodra de upgrade actief wordt, wat relevant is voor iedereen die protocol- of wallet-workflows bouwt bovenop 7702.

Eén punt maakt het concept expliciet: een geïnstalleerde delegatie blijft van kracht nadat het bijbehorende autorisatieanker is verlopen. EIP-8477 beperkt vertraagd gebruik van een ongebruikte handtekening. Het doet niets met een delegatie die al on-chain staat.

Activering zou een gecoördineerde netwerkupgrade vereisen, waarna oudere autorisaties met zes velden regelrecht worden afgewezen en het uitgebreide formaat met acht velden verplicht wordt. Het concept behoudt transactietype0x04 en ondertekeningsprefix0x05, al blijven beide onderwerp van beoordeling.

Dat is een harde migratiedrempel. Daarna bestaat het formaat met zes velden niet meer. Het voorstel noemt geen activeringsdatum.

Het concept benoemt ook eerlijk de openstaande vragen — of 256 blokken in de praktijk daadwerkelijk genoeg ruimte biedt voor workflows rond wallets, relayers, vervanging en herstel over verschillende chains heen, en wat de extra kosten van bijkomende autorisatiebytes, ancestor-opzoekingen en verwerking in de praktijk betekenen.

Op 30 oktober 2026 liet het forumdossier van het voorstel geen externe technische reviews zien, en zowel de implementatiekosten als de operationele speelruimte blijven onopgelost.