EIP-7702-stacken: sessionsnycklar, gassponsring och börsen

Ett drygt år efter att Ethereums Pectra-uppgradering gick live den 7 maj 2025 har EIP-7702 slutat vara en rubrik och blivit infrastruktur. Förslaget som lät ett vanligt plånbokskonto, en så kallad externally owned account (EOA), peka på smart kontraktslogik utan att byta adress ligger nu tyst under miljontals konton. Den intressanta frågan är inte längre om din plånbok kan bli ett smart konto, utan vad som byggs ovanpå: sessionsnycklar, gassponsring och batchade signaturer, och hur börser, förvarare och svenska regler förhåller sig till konton som är både nyckel och kod på samma gång.

Den här genomgången tar hela stacken. Vi går igenom mekaniken i korthet, standarderna som gör funktionerna användbara (EIP-5792, ERC-7677 och sessionsnycklar), plånbokskrigets ställning, adoptionskurvan, samt baksidan som sweeper-kontrakten och en batch-phishing på över 1,5 miljoner dollar blottlade. Priser anges i kronor med en dollarkurs kring 9,50; ETH låg i slutet av augusti 2026 kring 2 460 dollar, omkring 23 000 kronor, enligt CoinDesk. Ingenting av detta är finansiell eller juridisk rådgivning.

Vad EIP-7702 egentligen gör med ditt konto

I Ethereum har det länge funnits två sorters konton. Ett EOA-konto styrs av en privat nyckel men kan inte köra egen kod. Ett kontraktskonto kör kod men saknar nyckel. Den uppdelningen har kostat användarvänlighet i åratal, eftersom allt smart, som spärrar, återställning och batchning, krävde att man flyttade pengar till ett separat kontrakt. EIP-7702 river den skarpa gränsen genom att låta en EOA bära kod tillfälligt. Rent tekniskt införs en ny transaktionstyp, 0x04 (SET_CODE_TX_TYPE), enligt specifikationen för EIP-7702. Kontots kodfält sätts till en 23 byte lång delegeringsmarkör: prefixet 0xef0100 följt av en 20 byte lång måladress. När någon anropar kontot laddar EVM:en kontraktets kod och kör den i EOA:ns eget sammanhang, med dess lagring, saldo och adress.

Poängen är att ingenting av det viktiga flyttar. Adressen är densamma, den privata nyckeln styr fortfarande, och pengarna ligger kvar. Auktorisationen är en signerad tupel med fälten chain_id, address och nonce plus signaturkomponenterna, undertecknad med magivärdet 0x05 över keccak(MAGIC || rlp([chain_id, address, nonce])). Två gaskostnader är värda att känna till: PER_AUTH_BASE_COST på 12 500 gas per auktorisation och PER_EMPTY_ACCOUNT_COST på 25 000 gas för tomma konton. Vid normala gasavgifter handlar det om ören till någon krona för själva delegeringen.

EIP-7702 föreslogs av bland andra Vitalik Buterin och kärnutvecklaren Matt Garnett (lightclient), tillsammans med Sam Wilson och Ansgar Dietrichs, och ersatte den tidigare EIP-3074-ansatsen med opkoderna AUTH och AUTHCALL. Vill du se om ditt eget konto är delegerat visar Etherscan markören 0xef0100 med måladressen. För att ta bort en delegering signerar du en ny auktorisation som pekar på nolladressen, vilket rensar kodfältet och gör kontot till en helt vanlig EOA igen.

Stacken ovanpå: EIP-5792, paymasters och sessionsnycklar

EIP-7702 i sig gör bara en sak: den lägger kod på ett konto. Det som gör funktionerna användbara är en uppsättning standarder som låter appar och plånböcker prata samma språk. Först ut är EIP-5792, ibland kallad Wallet Call API. Den definierar wallet_sendCalls, som skickar en hel batch av anrop i en enda begäran, och wallet_getCapabilities, där en app frågar plånboken vad den och kedjan klarar av, till exempel atomisk batchning eller gassponsring. Utan den skulle appar behöva gissa om ett konto är en smart EOA eller inte.

Ovanpå det ligger ERC-7677, som standardiserar hur en app ber plånboken att använda en paymaster-webbtjänst för att sponsra gas, och ERC-7715, ett utkast för att bevilja en app avgränsade, tidsbegränsade behörigheter (grunden för sessionsnycklar). En delegerad EOA kan dessutom peka på en implementation från Safe, Coinbase eller MetaMask och därmed köras genom ERC-4337:s EntryPoint som vore den ett kontraktskonto, fast den behåller sin ursprungliga adress. Tabellen nedan sorterar delarna.

Det är den här kombinationen, inte 7702 ensamt, som förvandlar ett gammalt nyckelkonto till en plattform. En app kan upptäcka stöd, skicka en batch, be en sponsor betala avgiften och begära en sessionsnyckel, allt i ett flöde som för användaren ser ut som ett enda klick. Först när standarderna finns på plats blir de teoretiska funktionerna verklig UX.

Ett steg som ofta glöms bort är den som faktiskt skickar transaktionen. När en sponsor betalar gasen måste någon lägga transaktionen på kedjan, en relayer eller en bundler. I 4337-världen buntar en bundler ihop flera UserOperations, medan en ren 7702-delegering kan skickas av vilken relayer som helst mot ersättning. Detaljen är osynlig för användaren men avgörande för driften: en app som lovar gratis gas är beroende av att dess relayer-infrastruktur fungerar och inte blir en flaskhals eller en censurpunkt. Här kommer också en av 7702:s avvägningar in, eftersom en relayer kan luras att lägga ut gas utan att få betalt om auktorisationen ogiltigförklaras innan den bekräftas.

Gassponsring: betala nätavgiften i stablecoin, eller inte alls

En av de mest konkreta vinsterna är att någon annan kan betala nätavgiften. En paymaster är en tredje part som täcker gasen, antingen gratis som del av en tjänst eller mot att användaren betalar i en stablecoin i stället för ETH. Ethereums egna riktlinjer lyfter fram just detta, att betala gas i tokens via sponsrade transaktioner, som ett av huvudskälen till förslaget. För en nybörjare som saknar ETH betyder det att den första transaktionen faktiskt går att genomföra.

Effekten märks tydligast i onboarding. En användare som gör en insättning med USDT eller handlar för första gången behöver inte längre skaffa ETH bara för att betala avgiften. Det suddar ut skillnaden mellan att använda en app och att administrera en plånbok. För en börs eller speltjänst blir gassponsring ett sätt att ta bort friktion utan att ta emot kundens nycklar, vilket är precis den typ av osynlig infrastruktur som avgör om en tjänst känns modern eller klumpig.

Baksidan är att en sponsor ser din aktivitet och att en dåligt vald sponsor blir en central felkälla. Ethereums riktlinjer är tydliga med att man bara ska delegera till granskade, tillståndslösa implementationer och inte till centraliserade relayers som kan låsa in dig. I praktiken har plånböckerna byggt in detta: enligt MetaMasks hjälpdokumentation kan ett smart konto betala gas i andra tokens, och dokumentationen betonar att pengarna aldrig flyttar och att kontot fortfarande styrs av din nyckel.

Räkneexemplet är enkelt. Själva delegeringen lägger till 12 500 gas i baskostnad, och vid en måttlig gasavgift på några gwei landar den delen på ören till någon enstaka krona. Att betala i en stablecoin i stället för ETH kostar oftast ett litet påslag som paymastern tar för att täcka sin egen växling och risk. För en användare som annars skulle ha tvingats köpa ETH på en börs, föra över den och först därefter kunna handla, är nettot ändå en klar vinst i både tid och avgifter. Det är den sortens friktion som avgjort mer om kryptots vardagsanvändning än de flesta tekniska finesser.

Sessionsnycklar: när appen får handla åt dig, inom ramar

En sessionsnyckel är en tillfällig signeringsnyckel med inbyggda gränser. I stället för att godkänna varje enskild transaktion med din huvudnyckel ger du en app en avgränsad fullmakt, till exempel att handla för högst ett visst belopp per anrop och bara under en timme. När tiden går ut eller taket nås slutar nyckeln att fungera. ERC-7715 är utkastet som formaliserar hur sådana behörigheter beviljas och skickas vidare i 5792-flödet.

Störst nytta gör det i sammanhang med många små, snabba transaktioner. Spelekonomier är det tydligaste exemplet: i stället för en signeringsruta för varje drag kan spelaren signera en gång och sedan spela på, en modell som ligger nära det vi beskrev i genomgången av spelekonomier som Sky Mavis. Samma mönster passar handelsgränssnitt där man vill lägga order i snabb följd utan att bli avbruten av en ruta för varje steg.

Ethereums riktlinjer beskriver sessionsnycklar som ett sätt till privilegienedtrappning, att minska beroendet av en enda långlivad nyckel. Men en fullmakt är bara så säker som sina gränser. En sessionsnyckel med för brett mandat eller för lång giltighet är en tillgång som kan missbrukas, och därför är det viktigt att kunna se och återkalla aktiva nycklar. Bra plånböcker gör listan över beviljade behörigheter synlig, precis som de gör med token-godkännanden.

Batchning: en signatur i stället för fem

Klassisk DeFi tvingar användaren att först godkänna en token och sedan göra bytet, två separata signaturer och två avgifter. Med batchning via 5792 och en 7702-delegering blir det ett enda atomiskt steg: godkänn och byt, eller sätt in och satsa, i samma transaktion. Antingen lyckas allt eller ingenting, vilket både minskar antalet klick och tar bort risken att bli stående med ett halvfärdigt godkännande som en angripare senare kan utnyttja.

Men samma kraft som gör batchning bekväm gör den farlig i fel händer. En enda signatur kan nu bunta ihop en delegering, flera token-godkännanden och överföringar. Det gör att momentet då du signerar blir viktigare än någonsin, temat vi grävde i under signera-ögonblicket. Klartextsignering och transaktionssimulering, där plånboken visar exakt vad som händer innan du godkänner, är den avgörande försvarslinjen mellan bekvämlighet och katastrof.

Plånbokskriget: vem stödjer 7702 och hur

Den enskilt största adoptionsmotorn är MetaMask. Enligt MetaMasks hjälpdokumentation är smarta konton numera automatiskt aktiverade för nya användare, medan befintliga kan slå på och av funktionen i inställningarna. Adressen är densamma och nyckeln styr fortfarande; dokumentationen liknar det vid en flitig robot som jobbar för dig och som du kan sparka och återanställa när du vill. När den största befintliga EOA-basen börjar peka på smart kontraktslogik får 7702 fäste av ren tröghet.

Runt MetaMask har ett fält av plånböcker byggt stöd. Enligt Alchemy och andra integratörer var Ambire, Trust Wallet, Rabby och OKX bland de tidiga, ofta med 7702 som ett val per transaktion snarare än en permanent inställning. Implementationer från Safe och Coinbase Smart Wallet fungerar som delegeringsmål: en EOA kan peka på deras logik och sedan köras genom 4337:s EntryPoint. Hårdvaruplånböcker är mer försiktiga och lutar mot listor med betrodda delegatorer i stället för att tillåta godtycklig delegering.

Vilken plånbok som passar handlar därför allt mindre om ikoner och allt mer om hur de hanterar delegering, klartextsignering och återkallelse, något vi vägde av i jämförelsen av vilken plånbok som passar dig 2026. Skillnaden mellan en trygg och en riskabel 7702-upplevelse ligger i detaljer som få användare granskar innan de klickar.

Adoptionen: var står smarta EOA:er nu?

Att mäta 7702 är knepigare än det låter. Wintermutes Dune-panel följer typ 0x04-transaktioner och delegeringar och visar att aktiviteten inte stannat på Ethereums huvudnät utan spridit sig till kedjor som BNB Chain, Base och Arbitrum i takt med att de tagit in motsvarande uppgradering. Antalet konton som signerat minst en delegering räknas i miljoner, men själva antalet säger mindre än man tror.

Skälet är att kurvan är sned. En stor del av alla delegeringar är inte användare som slår på smarta konton, utan massutplacerade sweeper-kontrakt (mer om dem strax). Den verkliga användaradoptionen drivs framför allt av att MetaMask vänder nya konton till smarta konton, vilket lägger till 7702 under människor som aldrig aktivt bad om det men som får batchning och gasval på köpet. Adoptionen är alltså både större och mindre än siffrorna antyder, beroende på vad man räknar.

För den som vill följa utvecklingen på riktigt är det bättre att titta på vad delegeringarna pekar på än på totalsumman. Etherscan märker numera delegerade konton, och analysverktyg skiljer på legitima plånboksimplementationer och de kopierade dräneringskontrakt som utgör majoriteten av instanserna. Utan den uppdelningen ser statistiken skrämmande ut på fel sätt.

Baksidan: sweepers, CrimeEnjoyor och 97-procenten

Kort efter Pectra kom en obehaglig siffra. Wintermutes analysteam rapporterade att över 97 procent av alla EIP-7702-delegeringar på huvudnätet, inom fyra veckor, pekade på kontrakt med exakt samma kopierade kod. Kontrakten döptes till CrimeEnjoyor och är så kallade sweepers: enkel, återanvänd bytekod som automatiskt tömmer inkommande ETH från redan kapade konton.

Här är nyanserna som lätt försvinner i rubrikerna. Ett sweeper-kontrakt placeras ut efter att en privat nyckel redan har läckt. Det är alltså inte 7702 som orsakar intrånget; standarden automatiserar bara stölden när nyckeln redan är förlorad. 97-procenten är dessutom ett mått på antalet delegeringsinstanser, kraftigt uppblåst av massutplacerade sweepers, inte ett mått på hur stor andel användare eller värde som är i fara.

Wintermute var noga med att förtydliga detta efter att vissa rubriker överdrivit: EIP-7702 är inte felaktigt och är säkert att använda. Sweeper-vågen säger mer om hur billigt det är att kopiera ett kontrakt än om ett fel i själva standarden. Ändå är den en påminnelse om att en läckt nyckel numera töms snabbare och mer automatiserat än förr, vilket höjer insatsen för god nyckelhantering och för att förstå exakt vad ett kontrakt kan göra innan man delegerar till det.

Batch-phishingen som tömde en plånbok på 14 miljoner

Den dyraste enskilda läxan hittills kom i slutet av augusti 2025. En användare förlorade omkring 1,54 miljoner dollar, cirka 14,5 miljoner kronor, efter att ha signerat vad som såg ut som ett rutinmässigt byte på ett falskt DeFi-gränssnitt. Som det rapporterades auktoriserade signaturen i själva verket en delegering till angriparens implementation plus en batch av godkännanden och överföringar, som i ett svep tömde kontot på wstETH, cbBTC och NFT:er.

Det var inte första gången. Tidigare samma sommar förlorade en annan användare runt 146 000 dollar, ungefär 1,4 miljoner kronor, till en variant av Inferno Drainer som snyltade på en legitim delegatoradress. Mönstret är detsamma: 7702 gör en enda signatur mäktigare, och när ett falskt gränssnitt får dig att signera fel blir konsekvensen total i stället för partiell.

Slutsatsen är inte att undvika smarta konton, utan att behandla varje signering som det den är, ett beslut med potentiellt fullständig räckvidd. Plånböcker som visar måladressen tydligt och simulerar resultatet innan du godkänner är det bästa skyddet, och användare bör vara extra vaksamma på gränssnitt som ber om en signatur som ser ovanligt bred ut.

Vad utvecklare och revisorer granskar

På kontraktssidan har 7702 en egen risklista. Den första är lagringskrockar. Eftersom ett konto kan byta implementation över tid kan en ny logik tolka gamla lagringsplatser fel. OpenZeppelins dokumentation och specifikationens säkerhetsavsnitt rekommenderar därför namnrymdslagring enligt ERC-7201, så att varje implementation rotar sin lagring på en unik plats i stället för att trampa på föregångarens data.

Den andra är initieringen. Vid en delegering körs ingen initcode, så en angripare kan försöka fronta uppsättningen av kontot. Specifikationen kräver att uppsättningsdatan verifieras som signerad av EOA:ns nyckel med ecrecover. Ethereums riktlinjer lägger till två tumregler: delegera bara till ett oföränderligt kontrakt, aldrig till en proxy, och var försiktig med chain_id noll, som gör delegeringen giltig på alla kedjor och därmed öppnar för replay. Checklistan som revisorerna betar av ser i korthet ut så här.

• Delegera bara till oföränderliga, granskade kontrakt, aldrig till en proxy.
• Använd namnrymdslagring (ERC-7201) för att undvika krockar mellan implementationer.
• Verifiera att uppsättningsdatan är signerad av kontots nyckel för att stoppa front-running.
• Undvik chain_id noll om du inte medvetet vill ha giltighet på alla kedjor.
• Anta inte längre att en avsändare utan kod är ett vanligt konto.

Den mest underskattade konsekvensen är kanske att ett vanligt säkerhetsantagande inte längre håller. Säkerhetsföretaget CertiK beskriver hur 7702 omdefinierar förtroendeantagandena för EOA-konton: kontroller som bygger på att tx.origin är lika med msg.sender, ett vanligt sätt att kräva att anroparen är ett vanligt konto och inte ett kontrakt, kan nu kringgås eftersom en delegerad EOA både är avsändare och kör kod. Kod som förlitar sig på att EOA:er inte kan köra logik måste ses över.

För hårdvaruplånböcker har diskussionen landat i en pragmatisk kompromiss. Att låta en enhet blint signera vilken delegering som helst vore farligt, eftersom användaren på en liten skärm knappast kan granska en måladress. Branschen lutar därför åt listor med betrodda delegatorer, alltså granskade implementationer som enheten känner igen och kan visa med ett begripligt namn, medan okända mål varnas för eller blockeras. Det är samma logik som redan gäller för kontraktsinteraktioner, och den blir viktigare när en enda signatur kan förvandla hela kontot. Revisorernas roll växer i takt med detta, eftersom varje betrodd implementation blir en del av angreppsytan för alla konton som pekar på den.

Börsen och förvararen möter smarta EOA:er

För börser och förvarare är 7702 inte bara en plånboksfråga. De tar numera emot insättningar från konton som bär en delegeringsmarkör, alltså smarta EOA:er. Att upptäcka dem är enkelt i teorin: ett insättningskonto vars kod börjar med 0xef0100 är delegerat, och flödesövervakning kan flagga det. Frågan är vad man gör med informationen.

Två saker sticker ut. Dels kan ett kompromissat konto vara sweeper-styrt, så att medel som skickas dit riskerar att sopas vidare direkt, vilket gör screening av insättningsadresser mer relevant. Dels går gamla antaganden sönder: system som byggt på att en avsändare är en enkel EOA, som vissa airdrop-krav, bot-skydd eller de tx.origin-kontroller CertiK varnar för, måste anpassas. Här är EIP-5792:s wallet_getCapabilities det rena verktyget, eftersom en integratör kan fråga vad ett konto faktiskt stödjer i stället för att gissa.

Samtidigt är det värt att slå fast vad 7702 inte ändrar. Adressen är densamma, nyckeln är kvar hos användaren och pengarna flyttar inte. En smart EOA är fortfarande självförvar, inte en förvaringsrelation. Det gör att gränsen mellan börs och plånbok blir suddigare på UX-nivå men inte nödvändigtvis på den juridiska, ett tema vi vägde av i texten om hur gränsen mellan börs och plånbok löses upp.

På uttagssidan öppnar 7702 för att börser kan erbjuda plånbokslik UX utan att lämna ifrån sig kontrollen på fel sätt. En tjänst kan låta kunden ta ut till en adress som redan är ett smart konto och där batcha ett uttag med en direkt insättning i ett protokoll, eller sponsra gasen så att kunden slipper hålla ETH för avgifter. Samtidigt tvingar det compliance-team att tänka nytt: en delegerad adress kan byta beteende efter att den har godkänts, eftersom implementationen den pekar på kan bytas. Det gör löpande övervakning viktigare än en engångskontroll vid registrering, och det är en av anledningarna till att infrastrukturleverantörer nu bygger 7702-medvetenhet direkt in i sina verktyg.

Regler, Finansinspektionen och självförvarets gräns

Regelmässigt landar 7702 i en intressant gråzon. MiCA reglerar leverantörer av kryptotillgångstjänster (CASP), däribland förvaring, och Finansinspektionen är behörig myndighet i Sverige. Ett smart konto enligt 7702 håller användaren kvar i självförvar, eftersom nyckeln aldrig lämnar användaren, och faller därför utanför den förvaringsdefinition som utlöser tillståndsplikt. Att slå på funktionen flyttar dig alltså inte in i en reglerad förvaringsrelation.

Gränsdragningen blir knivigare i kanterna. En gassponsor eller en tjänst för social återställning med vårdnadshavare kan börja likna en tjänst. Men en tillståndslös, icke-förvarande paymaster tar inte emot kundmedel och tar inte hand om några nycklar, och skiljer sig därmed från en förvarare. Någon specifik åtgärd från Finansinspektionen riktad mot just 7702 har inte rapporterats, och det vore fel att låtsas annat; det här är en teknik som rör sig snabbare än regelverken.

För en svensk användare ändrar 7702 lite av det praktiska runt skatt och konsumentskydd. Ett byte är fortfarande ett byte oavsett om det sker i en batch, och självförvar innebär fortfarande att ansvaret för nyckeln är ditt. Det här är ingen juridisk rådgivning, men grundregeln håller: förstå vad du delegerar till och behåll kontrollen över din nyckel. Frågan om vem som bär ansvaret när en fullmakt missbrukas är dessutom fortfarande i stor utsträckning obesvarad, och den lär prövas i domstol och tillsyn i takt med att smarta konton blir standard.

Vägen framåt: Fusaka, Glamsterdam och native account abstraction

Sedan Pectra har Ethereum gått vidare. Fusaka-uppgraderingen aktiverades den 3 december 2025 och, som Ethereum Foundation beskrev, handlade den främst om PeerDAS och skalning av blob-kapacitet för lager 2. Den rörde inte 7702:s mekanik, som ligger kvar oförändrad.

Nästa steg är Glamsterdam, som planeras till andra halvan av 2026. Enligt ethereum.org är huvudförslagen EIP-7732 (enshrined proposer-builder separation) och EIP-7928 (block-level access lists), alltså förändringar i hur block byggs och verifieras, inte account abstraction. Smarta konton står inte på tur för någon protokollförändring i den uppgraderingen.

Den riktigt inbyggda kontoabstraktionen, EIP-7701, är ännu inte inplanerad i någon hard fork. Så länge det dröjer är 7702 den bro som gäller, och i praktiken den standard som definierar vad ett smart konto är på Ethereum idag. Med andra ord: det som byggs på 7702-stacken nu kommer att bära ett bra tag till, och den som förstår stacken förstår var plånboks- och börsupplevelsen är på väg.

Sammantaget är EIP-7702 ett ovanligt exempel på en uppgradering vars effekter blivit tydligast långt efter att rubrikerna tystnat. Den gjorde inte plånboken smart över en natt, men den gav hela ekosystemet en gemensam grund att bygga sessionsnycklar, gassponsring och batchning på, och den tvingade börser, förvarare och revisorer att ompröva antaganden som stått sig i åratal. Vinsten i användarvänlighet är verklig, och det är också risken när en enda signatur kan göra så mycket. Den som förstår båda sidorna, och håller fast vid att granska vad man delegerar till, får det bästa av en plånbok som äntligen kan programmeras.

Vanliga frågor om EIP-7702

Vad är EIP-7702 med enkla ord?

EIP-7702 är en Ethereum-standard från Pectra-uppgraderingen som låter ett vanligt plånbokskonto (en EOA) tillfälligt låna kod från ett smart kontrakt. Kontot behåller samma adress och samma privata nyckel, men kan få funktioner som batchade transaktioner, gassponsring och sessionsnycklar.

Blir min plånbok mindre säker av EIP-7702?

Standarden i sig ändrar inte vem som kontrollerar nyckeln, och Wintermutes analysteam beskrev den som säker att använda. Riskerna handlar om vad du delegerar till och vad du signerar; delegera bara till granskade, oföränderliga kontrakt och läs varje signering noga.

Hur ser jag om mitt konto har en delegering, och hur tar jag bort den?

På Etherscan visas ett delegerat konto med markören 0xef0100 följt av måladressen. Du tar bort delegeringen genom att signera en ny auktorisation som pekar på nolladressen, vilket rensar kodfältet och gör kontot till en vanlig EOA igen.

Vad är skillnaden mellan EIP-7702 och ERC-4337?

ERC-4337 bygger smarta konton som separata kontrakt med egna adresser, medan EIP-7702 ger ett befintligt EOA-konto kontraktslogik utan att byta adress. De två kombineras ofta: en 7702-delegerad EOA kan köras genom 4337:s EntryPoint.

Kan jag betala gas i stablecoin med EIP-7702?

Ja, om plånboken och appen stödjer en paymaster via ERC-7677 kan nätavgiften betalas av en tredje part eller dras i en stablecoin i stället för ETH. MetaMask och flera andra plånböcker erbjuder någon form av gasflexibilitet.

Av Yuki Tanaka, redaktör för plånböcker och infrastruktur på HOGE Wire.