När en rollup slutar fungera: en förklaring till nedstängningen av Polygon zkEVM

3 juli 2026

10 min läsning

Sammanfatta med AI

Polygon zkEVM har officiellt gått in i sin avvecklingsfas. Den 1 juli 2026, Polygon Labs stängde av sekvenseraren för Polygon zkEVM Mainnet Beta, och plånbokssaldona överfördes till Ethereum L1 genom en utbetalningsprocess. För att vara rättvis har avstängningen skötts på ett smidigt sätt: användarna hade ett helt år på sig att förbereda sig, bryggan förblev öppen fram till sista dagen och utbetalningarna kan fortfarande göras fram till slutet av 2027.

Haken är att blockkedjor inte bara förvarar mynt i plånböcker. När ett nätverk avvecklas finns en del likviditet redan begravd flera lager djupt: i pooler, valv, utlåningsmarknader, säkerhetspositioner och andra kontrakt som Polygon inte kontrollerar. Att flytta tillbaka det till L1 är inte längre en enkel uppgift för en brygga.

Därför ställde vi frågorna – som många inom branschen förmodligen ställer sig just nu – till vår expert, Andrew Nalichaev: Vem bär ansvaret för den fastlåsta likviditeten, vad händer med stablecoins i ett nätverk som håller på att dö ut, och vad bör andra rollups lära sig innan de ställs inför samma problem?

Andrew Nalichaev

Blockchain-expert och DeFi-analytiker

Andrew översätter decentraliserade koncept till säkra, funktionella finansiella verktyg. Han navigerar i det flyktiga DeFi-landskapet för att bygga skalbara blockchain-infrastrukturer som adresserar verklig nytta, och går förbi buzzwords för att leverera tekniskt värde.

Visa profil

— Om vi betraktar Polygon zkEVM som ett fallstudieexempel på nedläggningen av ett L2-nätverk, vad hanterades då på ett bra sätt, och vad borde man ha planerat in redan från början?

Det bästa Polygon gjorde i det här fallet var att ge användarna tid och en tydlig process. Nedläggningen av zkEVM tillkännagavs ungefär ett år i förväg, bryggan förblev öppen ända fram till den sista dagen, det gjordes en översikt över saldon och användarna fick möjlighet att hämta ut sina medel på Ethereum L1. När det gäller nedläggningar är det ett ganska smidigt sätt att hantera det på.

Den del som borde ha varit inbyggd redan från början är utträdesstrategin för DeFi. Att flytta saldon i plånböcker är en sak, eftersom dessa saldon tydligt motsvarar tillgångar som finns i en bridge-deposition. DeFi är en helt annan sak. LP-tokens, andelar i valv, säkerhetspositioner och skuldförpliktelser behöver alla sina egna nödutgångar på protokollnivå. Utan detta kan likviditeten som finns i tredjepartskontrakt bli mycket svår, eller ibland omöjlig, att nå så snart sekvenseraren stannar.

— Hur realistiskt är det att stänga ner ett L2-nätverk “på ett ordnat sätt” när det redan innehåller DeFi-protokoll, LP-positioner, valv, säkerheter och derivat-tokens?

En smidig avveckling är möjlig, men bara till en viss gräns. Om vi talar om enkla plånbokssaldon eller tillgångar som direkt kopplas till en bridge-deposition, ja, då kan man göra processen ganska smidig. Så fort DeFi:s komposibilitet kommer in i bilden blir det betydligt svårare.

Ta en vanlig AMM-pool som exempel. I teorin skulle man kunna se vem som innehar LP-tokens, beräkna deras andel av poolen och fördela de underliggande tillgångarna. Det måste vara den nuvarande innehavaren, inte den som ursprungligen satte in medlen, annars riskerar man att betala samma person två gånger. Men i verkligheten är DeFi sällan så överskådligt. LP-tokens kan placeras i valv, stakas, användas som säkerhet eller förpackas i ännu en produkt. Plötsligt har man inte att göra med en enda fordran utan en hel kedja av dem, och det finns inget universellt sätt att se vem den “verkliga” ägaren är i alla möjliga kontrakt.

Det ärliga svaret är alltså: ett L2-nätverk kan endast stängas ner på ett ordnat sätt om protokollen ovanpå det har planerat för det scenariot redan från början. Annars kan nedstängningen på nätverksnivå visserligen se organiserad ut, men DeFi-lagret kan ändå vara ett enda kaos.

— Hur skulle du bedöma risken för dubbelbetalning när man försöker avveckla DeFi-positioner manuellt efter ett nätverksavbrott? Är det främst ett tekniskt, juridiskt eller ekonomiskt problem?

Det är en blandning av alla tre, men i grund och botten handlar det om ett ekonomiskt problem.

Escrow-kontot på L1 innehåller endast de faktiska tillgångar som har förts in i systemet. DeFi bygger sedan ytterligare lager ovanpå detta: LP-tokens, andelar i valv, utlåningspositioner, skuldtokens och andra fordringar. På en utlåningsmarknad kan man till exempel snabbt hamna i en situation där det finns fler fordringar än vad det finns tillgångar i depån, åtminstone om man försöker tillgodose alla samtidigt.

Det är där problemet med dubbelutgifter uppstår. Man kan inte betala insättaren, låntagaren och alla innehavare av derivat från samma pool av underliggande tillgångar om den poolen inte är tillräckligt stor för att täcka alla dessa fordringar.

Det finns också en tidsrelaterad fallgrop. Vissa positioner har inte ens ett fastställt värde i det ögonblick då man fryser dem: ett lån med negativt värde måste likvideras, räntan måste löpa vidare och ett orakel måste uppdateras. Om man stoppar kedjan mitt i processen blir den “rättvisa” andelen av dessa positioner odefinierad – inte bara svår att beräkna.

Tekniskt sett kan man försöka reda ut vem som äger vad. Juridiskt sett kan man behöva avgöra vems anspråk som har företräde. Men ekonomiskt sett är gränsen mycket enkel: man kan inte fördela fler tillgångar än vad som faktiskt finns.

— Bör L2-team kräva att protokollen har en utväg innan de tillåts tillföra likviditet till nätverket?

Ja, särskilt om ett protokoll ska förvalta människors pengar. Man kan inte ta emot insättningar, bygga upp likviditet och sedan först börja fråga sig “hur ska vi få ut alla?” när nätverket redan håller på att stängas ner.

L2-nätverket i sig kan bara hjälpa till med den tydliga och enkla delen: att se till att saldon stämmer överens med vad som finns i bryggans depå. Det är inte realistiskt att det ska gå in i varje DeFi-protokoll och reda ut bokföringen. I det läget skulle L2-teamet behöva avgöra vem som äger vad, hur positionerna ska värderas och vem som ska få betalt först. Det är ett stort ansvar, och det är egentligen inte deras uppgift.

Så ja, DeFi-protokoll behöver ha egna nöduttagsvägar, avvecklingslogik eller avstängningsplaner innan användarna börjar placera betydande likviditet i dem.

— Hur påverkar en sekvenserares avstängning förtroendemodellen för L2-nätverk? Bör användarna nu inte bara bedöma brorisk, utan även avstängningsrisk?

Det är här som hela idén om att “bara brygga över” börjar fallera. Det fungerar om dina medel ligger fritt tillgängliga i en plånbok. Det fungerar inte lika smidigt om de är bundna på en utlåningsmarknad, i en LP-position, i ett valv eller i ett kontrakt som fortfarande kräver ytterligare en transaktion för att du ska kunna ta ut dem.

När sekvenseraren stannar slutar kedjan att ta emot instruktioner. Du kan fortfarande ha en giltig fordran någonstans, men du kanske inte längre har någon fungerande väg att agera på den. Det är det besvärliga: tillgången kanske inte är borta, men vägen dit kan försvinna.

Användarna måste se bortom nätverkets säkerhet. När det gäller mindre L2-nätverk, särskilt sådana med begränsad likviditet eller experimentella ekosystem, bör man också ställa sig frågan: vad händer om detta nätverk avvecklas, och kan jag verkligen ta mig ur det innan det sker?

— Vad händer med stablecoin-reserverna i ett nätverk som håller på att upplösas, särskilt när man jämför USDC.e som överförts via en brygga med inhemsk emission genom en CCTP-liknande modell?

När det gäller överbryggade stablecoins som USDC.e finns den verkliga USDC:n i ett deponeringskonto på Ethereum L1. Om din USDC.e bara ligger i din plånbok kan den migreras eller hämtas ut. Om de sitter fast i ett kontrakt som ingen längre kan interagera med finns den underliggande USDC:n fortfarande kvar, men användaren har inget praktiskt sätt att komma åt den. Emittenten tjänar inga “extra” pengar på detta. Täckningen finns fortfarande där, men värdet är i princip låst.

Inhemska stablecoins fungerar på ett annat sätt. I en CCTP-liknande modell skapas token direkt på L2, och fiatreserven förvaras hos utgivaren. För att kunna avsluta verksamheten på ett korrekt sätt måste man bränna token på L2 innan nedstängningen och sedan skapa den någon annanstans. Om tokenen sitter fast i ett inaktivt kontrakt kan man inte längre bränna den på kedjan. Därför sitter emittenten kvar med verkliga reserver för token som fortfarande existerar, men på ett nätverk som inte längre fungerar.

Vid det läget måste utgivaren besluta hur man ska gå vidare: behålla reserverna, godta fordringar utanför blockkedjan mot uppvisande av bevis, eller i slutändan betrakta dessa tokens som övergivna.

Låt inte infrastrukturrisker bli produktrisker

Innowise bidrar till att utforma Web3-infrastruktur med färre blinda fläckar

— Vilka lärdomar bör team som bygger nya rollup-ekosystem dra av nedläggningen av Polygon zkEVM?

Polygon zkEVM är ett exempel på att varje rollup behöver två strategier: en för tillväxt och en för en säker avveckling. Att tillföra likviditet är bara halva jobbet. Teamen behöver också en tydlig plan för hur de ska få ut den likviditeten om nätverket någonsin avvecklas.

Det innebär att man i god tid varnar användarna, håller bryggan öppen så länge som möjligt, erbjuder användarna en smidig process för att göra anspråk på sina plånbokssaldon och för en dialog med DeFi-protokollen långt före stängningsdatumet. Det innebär också att man tydligt redogör för vad som händer med tillgångar som överförts via bryggan, inhemska tillgångar och stablecoins.

Framför allt bör teamen sluta betrakta TVL som något som helt enkelt kan packas ihop och flyttas senare. När sekvenseraren tystnar blir den verkliga frågan: hur mycket likviditet återstår som måste omvandlas till transaktioner för att kunna tas ut?

Det finns också en lärdom att dra när det gäller systemdesign i allt detta. Om det är så besvärligt att avveckla ett system är det värt att, innan lanseringen, ärligt fråga sig om arbetsbelastningen verkligen behövde en egen kedja. Många användningsfall där man vill förhindra obehörig ändring hanteras bättre med en verifierbar databas eller en transparenslogg med en extern förankring. Där finns ingen sekvenserare att stänga av.

— Vad bör en minimiplan för nedstängning av en L2-nätverk innehålla inför lanseringen av mainnet: kommunikation, anspråk på bryggor, DeFi-samordning, policy för stablecoins eller något annat?

En väl utarbetad plan för nedstängning av L2 bör beskriva hela processen, från den första varningen till den sista tidsfristen för anspråk. Teamen måste i ett tidigt skede besluta när användarna ska underrättas, hur länge övergångsperioden ska pågå, när den sista ögonblicksbilden ska tas, hur anspråk på L1 ska hanteras och vad som ska hända med medel som inte hämtas ut.

DeFi förtjänar en egen plan. Protokollen bör redogöra för om användarna kan göra uttag i en nödsituation, hur positioner kan avvecklas och vad som händer med LP-tokens, andelar i valv, säkerheter och skulder om nätverket slutar bearbeta transaktioner.

Stablecoins kräver samma tydlighet. Tillgångar som överförts via en brygga och tillgångar som utfärdats direkt av nätverket beter sig på helt olika sätt när ett nätverk stängs ner, så användarna bör veta exakt vilka regler som gäller för respektive token.

— Vad är vanligtvis det svåraste i sådana situationer: att tekniskt sett stänga ner nätverket, att rättsligt fastställa ansvaret eller att ekonomiskt lösa problemet med den frysta likviditeten?

Att stänga av nätverket är förmodligen den enklaste delen av hela processen. De verkliga problemen börjar först när man börjar undersöka vem som fortfarande har pengar bundna, var dessa pengar finns och vem som har rätt att fatta beslut om dem.

Ur juridisk synvinkel blir ansvarsförhållandena snabbt otydliga. L2-teamet sköter infrastrukturen, men äger inte alla DeFi-protokoll som byggts ovanpå den. Ur ekonomisk synvinkel blir det ännu svårare, eftersom DeFi kan skapa flera lager av fordringar på samma underliggande likviditet. Om den likviditeten är begränsad, låst eller redan utlovad i olika former kan vissa fordringar helt enkelt inte tillgodoses fullt ut.

Det svåraste är alltså att hitta ett rättvist sätt att hantera fryst likviditet utan att betala två gånger för samma underliggande tillgång, skapa nya skulder eller tvinga infrastrukturteamet att agera som domare för varje protokoll i ekosystemet.

— Hur tror du att det här fallet kommer att påverka förtroendet för mindre L2-lösningar och zk-rollup-ekosystem med låg TVL?

Det här fallet kommer att få mindre L2-nätverk att kännas betydligt mindre “säkra som standard”. En låg TVL väcker redan nu frågor. Nu har användarna ytterligare en fråga att ställa sig: om det här nätverket läggs ned, kan jag verkligen ta ut mina tillgångar?

När det gäller zk-rollups kommer förtroendet att handla om mer än bara teknik, avgifter och hastighet. Beroendet av sekvenserare, anspråk via bryggor, utvägar ur DeFi och hanteringen av stablecoins hamnar alla på checklistan. En rollup måste numera bevisa att användarna kan lämna systemet lika smidigt som de kom in.

Andrews expertis i arbete

Mer om detta ämne

Blogg

Hur man flyttar USDT från Tron till EVM utan att bli fångad av likviditet

Blogg

Top Layer 2 blockkedjor: hitta rätt passform för ditt projekt

Blogg

Vad är en DID? En guide till digital identitet

Kontakta oss

Boka ett samtal eller fyll i formuläret nedan så återkommer vi till dig när vi har behandlat din förfrågan.

Namn

Företag

E-post

Telefon

Meddelande

Skicka ett röstmeddelande till oss

Bifoga dokument

Ladda upp filen

Du kan bifoga 1 fil på upp till 2 MB. Giltiga filformat: pdf, jpg, jpeg, png.

Genom att klicka på Skicka samtycker du till att Innowise behandlar dina personuppgifter enligt våra Integritetspolicy för att förse dig med relevant information. Genom att lämna ditt telefonnummer samtycker du till att vi kan kontakta dig via röstsamtal, SMS och meddelandeappar. Samtals-, meddelande- och datataxor kan gälla.

Du kan också skicka oss din förfrågan

till contact@innowise.com

Vad händer härnäst?

När vi har tagit emot och behandlat din förfrågan återkommer vi till dig för att beskriva dina projektbehov och undertecknar en NDA för att säkerställa sekretess.

Efter att ha undersökt dina önskemål, behov och förväntningar kommer vårt team att ta fram ett projektförslag förslag med arbetsomfattning, teamstorlek, tids- och kostnadsberäkningar.

Vi ordnar ett möte med dig för att diskutera erbjudandet och fastställa detaljerna.

Slutligen undertecknar vi ett kontrakt och börjar arbeta med ditt projekt direkt.