Wanneer een rollup offline gaat: uitleg over de stopzetting van Polygon zkEVM

3 juli 2026

10 min lezen

Samenvatten met AI

Polygon zkEVM is officieel in de uitfaseringsfase gekomen. Op 1 juli 2026, Polygon Labs heeft de sequencer van de Polygon zkEVM Mainnet Beta uitgeschakeld, waarbij de saldi van de wallets via een claimprocedure naar Ethereum L1 zijn overgezet. Eerlijk gezegd is de uitschakeling netjes afgehandeld: gebruikers hadden een heel jaar de tijd om zich voor te bereiden, de bridge bleef tot de laatste dag open en claims kunnen nog tot eind 2027 worden ingediend.

Het probleem is dat blockchains niet alleen munten in wallets bewaren. Tegen de tijd dat een netwerk wordt afgebouwd, zit een deel van de liquiditeit al meerdere lagen diep begraven: in pools, kluizen, kredietmarkten, onderpandposities en andere contracten waarover Polygon geen zeggenschap heeft. Dat weer terugbrengen naar L1 is niet langer een simpele brugoperatie.

Daarom hebben we onze expert, Andrew Nalichaev, de vragen gesteld die velen in de sector zich op dit moment waarschijnlijk stellen: Wie is verantwoordelijk voor vastzittende liquiditeit, wat gebeurt er met stablecoins op een netwerk dat ten onder gaat, en waar moeten andere rollups lering uit trekken voordat ze met hetzelfde probleem worden geconfronteerd?

Andrew Nalichaev

Blockchain expert & DeFi analist

Andrew vertaalt gedecentraliseerde concepten in veilige, functionele financiële tools. Hij navigeert door het vluchtige DeFi-landschap om schaalbare blockchain-infrastructuren te bouwen die het echte nut aanspreken, en gaat voorbij aan de modewoorden om technische waarde te leveren.

Bekijk profiel

- Als we Polygon zkEVM beschouwen als een casestudy over het stilleggen van een L2-netwerk, wat is er dan goed aangepakt en waar had vanaf het begin rekening mee moeten worden gehouden bij het ontwerp?

Het beste wat Polygon hier heeft gedaan, was mensen de tijd geven en een duidelijk proces bieden. De stopzetting van zkEVM werd ongeveer een jaar van tevoren aangekondigd, de bridge bleef tot de laatste dag open, er werd een momentopname van de saldi gemaakt en gebruikers kregen de mogelijkheid om hun tegoeden op Ethereum L1 op te eisen. Voor zover het stopzettingen betreft, is dat een behoorlijk nette manier om dit aan te pakken.

Het onderdeel dat vanaf dag één had moeten zijn ingebouwd, is het DeFi-noodplan. Het overboeken van wallet-saldi is één ding, omdat die saldi netjes overeenkomen met activa die in de bridge-escrow staan. DeFi is een heel ander verhaal. LP-tokens, vault-aandelen, onderpandposities en schuldvorderingen hebben allemaal hun eigen nooduitgangen nodig op protocolniveau. Zonder dat kan het, zodra de sequencer stopt, erg moeilijk of soms zelfs onmogelijk worden om de liquiditeit in contracten van derden te bereiken.

- Hoe realistisch is het om een L2-netwerk “netjes” af te sluiten als er al DeFi-protocollen, LP-posities, vaults, onderpand en derivatentokens op draaien?

Een soepele afwikkeling is mogelijk, maar slechts tot op zekere hoogte. Als het gaat om eenvoudige wallet-saldi of activa die rechtstreeks gekoppeld zijn aan een bridge-escrow, dan kun je het proces inderdaad vrij soepel laten verlopen. Zodra de composabiliteit van DeFi in het spel komt, wordt het een stuk lastiger.

Neem een standaard AMM-pool. In theorie zou je kunnen kijken wie de LP-tokens in bezit heeft, hun aandeel in de pool berekenen en de onderliggende activa verdelen. Het moet de huidige houder zijn, niet degene die het oorspronkelijk heeft gestort, anders loop je het risico dezelfde persoon twee keer te betalen. Maar in de praktijk verloopt DeFi zelden zo overzichtelijk. LP-tokens kunnen in vaults worden geplaatst, worden gestaked, als onderpand worden gebruikt of in een ander product worden verwerkt. Plotseling heb je niet meer te maken met één enkele vordering, maar met een hele keten ervan, en er is geen universele manier om te achterhalen wie de “echte” eigenaar is in alle mogelijke contracten.

Het eerlijke antwoord is dus: een L2 kan alleen op een ordelijke manier worden afgesloten als de protocollen die daarop draaien vanaf het begin rekening hebben gehouden met dat scenario. Anders ziet het afsluiten op netwerkniveau er misschien wel georganiseerd uit, maar kan de DeFi-laag nog steeds een puinhoop zijn.

- Hoe zou u het risico op dubbele uitgaven inschatten wanneer u na een netwerkstoring handmatig DeFi-posities probeert af te wikkelen? Is dit vooral een technisch, juridisch of economisch probleem?

Het is een combinatie van alle drie, maar in wezen gaat het hier om een economisch probleem.

De escrow-rekening op L1 bevat alleen de daadwerkelijke activa die in het systeem zijn ingebracht. DeFi bouwt daar vervolgens extra lagen bovenop: LP-tokens, vault-aandelen, kredietposities, schuldtokens en andere vorderingen. Op een kredietmarkt kun je bijvoorbeeld al snel meer vorderingen hebben dan er activa in de escrow staan, tenminste als je probeert iedereen tegelijkertijd volledig schadeloos te stellen.

Daar doet zich het probleem van dubbele besteding voor. Je kunt de deposant, de kredietnemer en alle houders van derivaten niet uit dezelfde pool van onderliggende activa uitbetalen als die pool niet groot genoeg is om al die vorderingen te dekken.

Er is ook een valkuil wat betreft de timing. Sommige posities hebben op het moment dat je ze bevriest nog niet eens een vaststaande waarde: een lening met een negatieve waarde moet worden geliquideerd, er moet rente worden opgebouwd, een orakel moet worden bijgewerkt. Als je de keten halverwege stilzet, wordt het “eerlijke” aandeel van die posities onbepaald, en niet alleen maar moeilijk te berekenen.

Technisch gezien kun je proberen uit te zoeken wie wat bezit. Juridisch gezien moet je wellicht bepalen wiens aanspraak voorrang heeft. Maar economisch gezien is de beperking heel eenvoudig: je kunt niet meer activa verdelen dan er daadwerkelijk zijn.

- Moeten L2-teams protocollen verplichten om een ‘achterdeurtje’ in te bouwen voordat ze toestemming krijgen om liquiditeit op het netwerk in te zetten?

Ja, vooral als een protocol het geld van mensen gaat beheren. Je kunt niet eerst stortingen accepteren en liquiditeit opbouwen, om vervolgens pas te gaan vragen “hoe krijgen we iedereen eruit?” wanneer het netwerk al wordt uitgeschakeld.

De L2 zelf kan alleen helpen met het overzichtelijke, eenvoudige deel: saldi die overeenkomen met wat er in de bridge-escrow staat. Het is realistisch gezien onmogelijk om elk DeFi-protocol te doorgronden en de boekhouding te ontwarren. Op dat moment zou het L2-team moeten beslissen wie wat bezit, hoe posities moeten worden gewaardeerd en wie als eerste wordt uitbetaald. Dat is een enorme verantwoordelijkheid, en het is eigenlijk niet hun taak.

Dus ja, DeFi-protocollen moeten beschikken over eigen noodopnamemogelijkheden, afwikkelingsprocedures of noodplannen voordat gebruikers er serieus geld in gaan steken.

- Hoe beïnvloedt het uitschakelen van een sequencer het vertrouwensmodel voor L2’s? Moeten gebruikers nu niet alleen het brugrisico, maar ook het uitschakelingsrisico in kaart brengen?

Dit is waar het hele idee van “gewoon overzetten” op zijn grondvesten begint te wankelen. Het werkt als je geld gewoon in een wallet staat. Het verloopt niet zo soepel als het vastzit in een kredietmarkt, een LP-positie, een kluis of een contract waarvoor nog één transactie nodig is om eruit te kunnen stappen.

Zodra de sequencer stopt, ontvangt de keten geen instructies meer. Misschien heb je ergens nog wel een geldige claim, maar is er geen werkend pad meer om daarop in te spelen. Dat is het lastige ervan: het activum is misschien niet verdwenen, maar de route ernaartoe kan wel verdwijnen.

Gebruikers moeten verder kijken dan alleen de stabiliteit van de bridge. Voor kleinere L2’s, met name die met beperkte liquiditeit of experimentele ecosystemen, moet de vraag ook zijn: wat gebeurt er als dit netwerk wordt stopgezet, en kan ik er daadwerkelijk uitstappen voordat dat gebeurt?

- Wat gebeurt er met de reserves van stablecoins op een netwerk dat op het punt staat te verdwijnen, met name wanneer men overgebrugde USDC.e vergelijkt met native uitgifte via een CCTP-achtig model?

Bij “bridged” stablecoins zoals USDC.e staat de echte USDC in escrow op Ethereum L1. Als je USDC.e gewoon in je wallet staat, kan deze worden gemigreerd of opgeëist. Als het vastzit in een contract waarmee niemand meer kan communiceren, is de onderliggende USDC er nog steeds, maar heeft de gebruiker geen praktische manier om erbij te komen. De uitgever verdient hier geen „extra“ geld aan. De dekking is er nog steeds, maar de waarde zit in feite vast.

Native stablecoins werken anders. In een CCTP-achtige opzet wordt het token rechtstreeks op de L2 geslagen en bevindt de fiatreserve zich bij de uitgever. Om op een nette manier uit te stappen, moet je het token vóór de sluiting op de L2 vernietigen en het ergens anders opnieuw slaan. Als het token vastzit in een ‘dood’ contract, kun je het niet meer on-chain vernietigen. Daardoor blijft de uitgever zitten met echte reserves voor tokens die nog steeds bestaan, maar op een netwerk dat niet meer functioneert.

Op dat moment moet de uitgever beslissen wat hij vervolgens gaat doen: de reserves behouden, off-chain-claims met bewijs accepteren, of die tokens uiteindelijk als achtergelaten beschouwen.

Laat infrastructuurrisico’s geen productrisico’s worden

Innowise helpt bij het ontwerpen van Web3-infrastructuur met minder blinde vlekken

- Welke lessen kunnen teams die nieuwe rollup-ecosystemen opzetten, trekken uit de stopzetting van Polygon zkEVM?

Polygon zkEVM laat zien dat elke rollup twee roadmaps nodig heeft: één voor groei en één voor een veilige afbouw. Het aantrekken van liquiditeit is slechts de helft van het werk. Teams moeten ook een duidelijke manier hebben om die liquiditeit weer terug te halen als het netwerk ooit wordt afgebouwd.

Dat betekent dat gebruikers tijdig moeten worden gewaarschuwd, dat de bridge zo lang mogelijk open moet blijven, dat er een duidelijk claimproces moet zijn voor de saldi in wallets, en dat er ruim voor de sluitingsdatum met DeFi-protocollen moet worden overlegd. Het betekent ook dat duidelijk moet worden uitgelegd wat er gebeurt met overgebrugde activa, native activa en stablecoins.

Bovenal moeten teams ophouden TVL te beschouwen als iets dat je zomaar kunt inpakken en later verplaatsen. Zodra de sequencer stilvalt, luidt de echte vraag: hoeveel liquiditeit moet er nog worden verwerkt voordat een transactie kan worden voltooid?

Hierachter schuilt ook een les op het gebied van ontwerp. Als het afbouwen van een systeem zo moeizaam verloopt, is het de moeite waard om je vóór de lancering eerlijk af te vragen of de workload echt een eigen keten nodig had. Veel use cases waarbij “sabotagebeveiliging” nodig is, zijn beter gediend met een verifieerbare database of een transparant logboek met een externe koppeling. Daar is geen sequencer die je kunt uitschakelen.

- Wat moet het minimale draaiboek voor het afsluiten van een L2-netwerk vóór de lancering van het mainnet bevatten: communicatie, claims via de bridge, DeFi-coördinatie, beleid inzake stablecoins, of iets anders?

Een goed draaiboek voor het afsluiten van L2 moet het hele proces in kaart brengen, vanaf de eerste waarschuwing tot en met de uiterste termijn voor het indienen van claims. Teams moeten in een vroeg stadium beslissen wanneer gebruikers op de hoogte worden gesteld, hoe lang de overbrugging open blijft, wanneer de laatste momentopname plaatsvindt, hoe L1-claims zullen verlopen en wat er gebeurt met fondsen die niet worden opgeëist.

DeFi verdient een apart plan. Protocollen moeten aangeven of gebruikers in geval van nood geld kunnen opnemen, hoe posities kunnen worden afgewikkeld en wat er gebeurt met LP-tokens, vault-aandelen, onderpand en schulden als het netwerk geen transacties meer verwerkt.

Ook voor stablecoins is diezelfde duidelijkheid nodig. Overgebrugde activa en in het netwerk zelf uitgegeven activa gedragen zich heel verschillend wanneer een netwerk wordt stilgelegd; gebruikers moeten dus precies weten welke regels voor welk token gelden.

- Wat is in dit soort situaties meestal het moeilijkste: het netwerk technisch stilleggen, de aansprakelijkheid juridisch vaststellen of de bevroren liquiditeit economisch oplossen?

Het uitschakelen van het netwerk is waarschijnlijk het meest overzichtelijke deel van het hele proces. De echte problemen beginnen pas als je gaat kijken wie er nog geld vastzit, waar dat geld zich bevindt en wie het recht heeft om daarover beslissingen te nemen.

Op juridisch vlak worden de verantwoordelijkheden al snel onduidelijk. Het L2-team beheert de infrastructuur, maar is niet de eigenaar van elk DeFi-protocol dat daarop is gebouwd. Op economisch vlak wordt het nog ingewikkelder, omdat DeFi meerdere lagen van vorderingen op dezelfde onderliggende liquiditeit kan creëren. Als die liquiditeit beperkt is, vastzit of al in verschillende vormen is toegezegd, kunnen sommige vorderingen simpelweg niet volledig worden voldaan.

De grootste uitdaging is dus om een eerlijke manier te vinden om met bevroren liquiditeit om te gaan, zonder dat we twee keer voor hetzelfde onderliggende activum hoeven te betalen, zonder nieuwe verplichtingen te creëren en zonder het infrastructuurteam te dwingen om voor elk protocol in het ecosysteem als een rechter op te treden.

- Hoe denk je dat deze zaak het vertrouwen in kleinere L2’s en zk-rollup-ecosystemen met een lage TVL zal beïnvloeden?

Door deze zaak zullen kleinere L2-netwerken een stuk minder “standaard veilig” aanvoelen. Een lage TVL roept nu al vragen op. Nu moeten gebruikers zich nog een andere vraag stellen: als dit netwerk wordt stopgezet, kan ik er dan daadwerkelijk uitstappen?

Voor zk-rollups zal vertrouwen niet alleen afhangen van technologie, kosten en snelheid. Afhankelijkheid van sequencers, claims via bridges, uitwegmogelijkheden voor DeFi en de omgang met stablecoins komen allemaal op de checklist te staan. Een rollup moet nu aantonen dat gebruikers net zo soepel kunnen vertrekken als ze zijn binnengekomen.

Andrews expertise aan het werk

Meer over dit onderwerp

Blog

Hoe USDT te verplaatsen van Tron naar EVM zonder gevangen te raken door liquiditeit

Blog

Toplaag 2 blockchains: vind de juiste pasvorm voor uw project

Blog

Wat is een DID? Een gids over digitale identiteit

Contacteer ons

Boek een gesprek of vul het onderstaande formulier in en we nemen contact met je op zodra we je aanvraag hebben verwerkt.

Naam

Bedrijf

E-mail

Telefoon

Bericht

Stuur ons een spraakbericht

Documenten bijvoegen

Bestand uploaden

Je kunt 1 bestand van maximaal 2 MB bijvoegen. Geldige bestandsformaten: pdf, jpg, jpeg, png.

Door op Verzenden te klikken, stemt u ermee in dat Innowise uw persoonsgegevens verwerkt volgens onze Privacybeleid om u van relevante informatie te voorzien. Door je telefoonnummer op te geven, ga je ermee akkoord dat we contact met je opnemen via telefoongesprekken, sms en messaging-apps. Bellen, berichten en datatarieven kunnen van toepassing zijn.

U kunt ons ook uw verzoek sturen
naar contact@innowise.com

Wat gebeurt er nu?

Zodra we je aanvraag hebben ontvangen en verwerkt, nemen we contact met je op om de details van je projectbehoeften en tekenen we een NDA om vertrouwelijkheid te garanderen.

Na het bestuderen van uw wensen, behoeften en verwachtingen zal ons team een projectvoorstel opstellen met de omvang van het werk, de teamgrootte, de tijd en de geschatte kosten voorstel met de omvang van het werk, de grootte van het team, de tijd en de geschatte kosten.

We zullen een afspraak met je maken om het aanbod te bespreken en de details vast te leggen.

Tot slot tekenen we een contract en gaan we meteen aan de slag met je project.