Smarta konton för kassan: Safe, multisig och miljardförvaret 2026

Den största stölden i kryptovärldens historia gick rakt genom ett smart konto. Den 21 februari 2025 tömdes en av kryptobörsen Bybits kalla plånböcker på tillgångar värda omkring 1,5 miljarder dollar (runt 14 miljarder kronor), och pengarna lämnade börsen via precis samma sorts multisig-konto som i dag vaktar hundratals miljarder kronor åt kryptobolag, stiftelser och DAO:er. Att angreppet över huvud taget var möjligt säger något viktigt: smarta konton har blivit ryggraden i hur organisationer förvarar pengar på kedjan, men de tekniska garantierna är aldrig starkare än rutinerna runt omkring dem.

Den här artikeln handlar inte om plånboken i din telefon. Den handlar om kassan: hur en decentraliserad organisation, en spelstudio eller en fond faktiskt håller reda på sina medel med Safe, multisig och programmerbara regler, varför Bybit-stölden blev en läxa för hela branschen, och vad en svensk styrelse behöver tänka igenom innan den lägger bolagets tillgångar i ett självförvarat smart konto. Vi har tidigare gått igenom grunderna för account abstraction och plånböcker för enskilda användare; nu tar vi steget upp till organisationsnivå, där insatserna räknas i miljarder och där ett enda felaktigt klick kan kosta ett helt bolag.

Från personlig plånbok till organisationens kassa

För en privatperson löser ett smart konto framför allt bekvämlighet: passkeys i stället för seed-fraser, gaslösa transaktioner och sessionsnycklar som gör att ett spel slipper be om signatur vid varje drag. För en organisation är problemet ett annat, och allvarligare. Ingen enskild person bör kunna flytta kassan på egen hand. Så fort mer än en handfull personer delar ansvaret för gemensamma pengar uppstår frågan hur man fördelar kontrollen utan att göra förvaringen långsam, ogenomskinlig eller beroende av en enda betrodd part.

En vanlig kryptoadress, i branschen kallad en externt ägd adress eller EOA (externally owned account), styrs av en enda privat nyckel. Den som har nyckeln har pengarna, punkt. För en enskild sparare är det en hanterbar risk. För en kassa på tiotals eller hundratals miljoner kronor är det oacceptabelt: nyckeln kan läcka, undertecknaren kan bli sjuk, försvinna eller vända sig mot organisationen, och det finns ingen andra spärr. Ett smart konto vänder på logiken. I stället för att en nyckel styr pengarna är det kod, ett smart kontrakt, som avgör vad som får hända och under vilka villkor.

Den koden kan kräva att flera undertecknare godkänner varje utbetalning, sätta tak för hur mycket som får flyttas per dygn, lägga in fördröjningar före stora ändringar och begränsa vilka mottagare eller protokoll pengarna får röra. Det är den här programmerbarheten, inte bekvämligheten, som gör smarta konton oumbärliga för den som förvaltar andras eller gemensamma pengar.

Vad ett multisig-konto faktiskt är

Kärnan i ett organisationskonto är multisignatur, oftast förkortat multisig. Principen är enkel: i stället för en nyckel krävs flera, och ett förutbestämt antal av dem måste skriva under samma transaktion för att den ska gå igenom. En vanlig uppställning skrivs som M-av-N, till exempel 3-av-5: det finns fem behöriga undertecknare, och minst tre av dem måste godkänna varje utbetalning. Talet på vänster sida kallas tröskeln, och att sätta den rätt är en av de viktigaste besluten en organisation fattar.

Rent tekniskt är kontot ett smart kontrakt som ligger på kedjan. Kontraktet känner till listan över ägaradresser och tröskeln. När någon vill flytta pengar samlas de nödvändiga signaturerna in, ofta i ett gränssnitt som Safe{Wallet}, och kontraktet verifierar på kedjan att tillräckligt många giltiga signaturer finns innan det utför transaktionen. Ägarna kan i sin tur vara hårdvaruplånböcker, andra smarta konton eller vanliga adresser, vilket gör det möjligt att bygga hierarkier: en dotterkassa vars ägare i sig är moderorganisationens multisig.

Två begrepp är värda att hålla isär redan nu, eftersom de blir avgörande längre fram. En modul är en utökning som ger kontot nya förmågor, till exempel att automatiskt betala ut lön eller låta en röstning styra en transaktion. En guard (vakt) är tvärtom en spärr som granskar varje transaktion innan den släpps igenom och kan stoppa den om den bryter mot en regel. Moduler adderar makt; guards adderar begränsningar. Tabellen nedan sammanfattar de delar som tillsammans utgör ett Safe-konto.

Safe, jätten bakom miljardförvaren

När branschen pratar om organisationskonton menar den nästan alltid Safe, tidigare Gnosis Safe. Projektet började som Gnosis Multisig 2017, blev Gnosis Safe 2018 och knoppades av som ett självständigt varumärke, Safe, 2022. I dag är det den dominerande infrastrukturen för självförvarade kassor på Ethereum och de flesta EVM-kedjor.

Siffrorna från andra kvartalet 2026 ger en känsla för skalan. Enligt Safe Ecosystem Foundations kvartalsrapport behandlade Safe-konton nästan 130 miljoner transaktioner under kvartalet, med april som rekordmånad på 55,4 miljoner. Vid kvartalets slut förvarade kontona självförvarade tillgångar värda drygt 27 miljarder dollar (omkring 260 miljarder kronor), varav 6,48 miljarder dollar (runt 61 miljarder kronor) i stablecoins, och den totala överföringsvolymen nådde 39,35 miljarder dollar (omkring 370 miljarder kronor), en ökning med åtta procent på ett år. Antalet skapade Safe-konton passerade 63 miljoner, en uppgång med tjugo procent, rapporterar The Block.

Det handlar inte bara om volym. Under kvartalet genomförde Ethereum Foundation sina uppmärksammade försäljningar ur den egna kassan via ett Safe-konto, och en koalition ledd av Aave, kallad DeFi United, koordinerade omkring 300 miljoner dollar (runt 2,8 miljarder kronor) genom ett enda Safe för att återställa säkerheterna bakom en insatt token (rsETH), med över 142 000 deltagande plånböcker. Safe har med andra ord blivit det ställe där stora, komplicerade och offentligt granskade pengaflöden faktiskt äger rum. Till perspektivet hör också att ether i skrivande stund handlas kring 1 900 dollar (drygt 18 000 kronor) enligt CoinGecko, en bit under tidigare toppnivåer, vilket påverkar hur stora kassorna ser ut mätt i kronor.

Lukas Schor, medgrundare av Safe och ordförande för Safe Ecosystem Foundation, beskriver riktningen så här i kvartalsrapporten: ”Safe utvecklas från en infrastruktur som skyddar värde till ett nätverk som också kan hjälpa till att verifiera hur värde rör sig.” Det sista ledet, att verifiera hur värde rör sig, är ingen tillfällighet. Det är svaret på den läxa som Bybit-stölden gav hela branschen, och som vi återkommer till.

Multisig, MPC eller depå: tre vägar att förvara en kassa

Multisig är inte det enda sättet att förvara en organisations krypto, och det är värt att förstå alternativen innan man väljer. I praktiken står valet mellan några få modeller, med olika avvägningar mellan transparens, kontroll och regelverk.

Den första är enkelsignatur, alltså en vanlig adress med en nyckel, gärna i en hårdvaruplånbok. Det är billigt och enkelt, men för en kassa är det som sagt en enda felkälla, och de flesta seriösa organisationer har lämnat den modellen bakom sig. Den andra är multisig via ett smart konto som Safe: kontrollen är utspridd, allt är synligt och verifierbart på kedjan, och ingen tredje part behöver litas på. Priset är ett större fotavtryck på kedjan, transaktionsavgifter och att signeringsrutinerna måste skötas noggrant.

Den tredje modellen är MPC (multi-party computation), där en privat nyckel aldrig existerar i sin helhet utan delas upp i fragment mellan flera parter som tillsammans räknar fram signaturer utan att någonsin sätta ihop nyckeln. MPC fungerar på alla kedjor, syns inte som ett särskilt kontrakt på kedjan och används ofta av börser och förvaringsföretag. Nackdelen är att logiken sker utanför kedjan och därför är svårare att granska offentligt. Ett fjärde alternativ, att lämna bort pengarna till en reglerad förvaringspart, tar bort det operativa krånglet men återinför exakt den motpartsrisk som självförvaring var tänkt att lösa. Tabellen jämför de vanligaste vägarna.

Så styr en DAO sin kassa på kedjan

Ett multisig-konto löser vem som får skriva under. Men en decentraliserad organisation vill ofta gå längre: besluten ska fattas av medlemmarna, inte av en liten grupp undertecknare, och ändå ska utbetalningen ske automatiskt och verifierbart när ett beslut väl är taget. Här kommer ett lager av moduler in, och den mest använda verktygslådan heter Zodiac och kommer från utvecklarkollektivet Gnosis Guild.

Grundmönstret ser ut så här. Medlemmarna röstar avgiftsfritt och utanför kedjan i verktyg som Snapshot. När en omröstning gått igenom behöver resultatet omvandlas till en faktisk transaktion från kassan. Zodiacs Reality-modul, som ligger bakom det som brukar kallas SafeSnap, gör just det: den låter ett utfall som rapporterats och kontrollerats via oraklet Reality.eth exekvera en förberedd Safe-transaktion, med ett tvistefönster där felaktiga påståenden kan bestridas innan pengarna rör sig. UMA:s variant oSnap bygger på samma optimistiska princip. Verktygen beskrivs i Gnosis Guilds egen genomgång av Zodiac.

Två andra Zodiac-moduler är särskilt användbara för en kassa. Roles-modifieraren låter organisationen ge en adress eller bot mycket avgränsade rättigheter, till exempel att bara byta en viss token på en viss börs upp till ett visst belopp, utan att någonsin få tillgång till hela kassan. Delay-modifieraren lägger in en obligatorisk fördröjning mellan att en transaktion föreslås och att den kan utföras, vilket ger tid att upptäcka och stoppa något som ser fel ut. Tillsammans gör de att en DAO kan minska sitt beroende av en liten uppsättning undertecknare, men de byter i gengäld in en del av säkerheten mot antaganden om orakel och tvistelösning, vilket är en avvägning värd att ta på allvar. Bakom varje välskött DAO-kassa står ofta en liten grupp bidragsgivare med djup teknisk kunskap, en roll som fått nästan kultstatus i branschen; vi har skrivit om hur ‘byggare’ blev kryptos finaste ord.

Bybit: när miljardförvaret brast

Den 21 februari 2025 höll Bybit på med något helt rutinmässigt: att flytta ether från en kall plånbok till en varm. Kontot var ett Safe-multisig, och flera behöriga undertecknare skulle godkänna överföringen. När de gjorde det tömdes kontot i stället på 401 347 ETH plus stETH, cmETH och mETH, tillsammans värt omkring 1,5 miljarder dollar (runt 14 miljarder kronor). Det blev den största stölden i kryptovärldens historia.

Det viktiga, och obehagliga, är hur det gick till. Safe-kontraktet var inte trasigt. Enligt NCC Groups tekniska genomgång och analyser sammanfattade av The Block hade angriparna komprometterat en dator hos en av Safes utvecklare och smugit in skadlig JavaScript i webbgränssnittet Safe{Wallet}. Koden var riktad specifikt mot Bybits undertecknare: den visade dem en helt normal överföring på skärmen, samtidigt som den transaktion de faktiskt signerade i bakgrunden bytte ut Safe-kontraktets logik via ett lågnivåanrop, delegatecall, till ett kontrakt som angriparna kontrollerade. Undertecknarna godkände på sina hårdvaruplånböcker, men hårdvaruplånboken visar bara en hash, inte den avkodade handlingen. De signerade alltså blint.

Attributionen blev snabbt tydlig. FBI kopplade stölden till den Nordkorea-länkade gruppen Lazarus, i det kluster som brukar kallas TraderTraitor. Bybit själva rapporterade några dagar senare att cirka 42,9 miljoner dollar (drygt 400 miljoner kronor) av bytet redan hade frysts genom samordning mellan flera aktörer i branschen, men huvuddelen var borta.

Säkerhetsexperterna som obducerade fallet pekade alla på samma svaga punkt. Odysseus, grundare av säkerhetsföretaget Phylax, framhöll för The Block att en hårdvaruplånbok inte visar vilken handling som signeras utan bara signaturens hash, och att skyddet därför blir verkningslöst i det ögonblick transaktionen förbereds på en internetansluten dator. Taylor Monahan, ledande säkerhetsforskare på MetaMask, beskrev angreppskoden som skräddarsydd för exakt den här stölden och exakt de här undertecknarna. Och Ido Ben Natan, grundare av säkerhetsbolaget Blockaid, har kallat kombinationen av blind signering och riktad skadekod för en av de snabbast växande hotbilderna i kryptovärlden.

Slutsatsen är obekväm men lärorik: kontraktet höll, tröskeln höll, hårdvaran höll. Det som brast var det mänskliga verifieringssteget, förmågan att se vad man faktiskt godkände. För en organisation är det den verkliga läxan, och den handlar mindre om kryptografi än om rutiner. Den som vill förstå hur den här sortens obduktioner går till kan läsa vår genomgång av forensikbranschen bakom kryptohacken.

Blind signering och myten om den säkra hårdvaruplånboken

Blind signering, blind signing, betyder att man godkänner en transaktion utan att kunna läsa vad den gör i klartext. Man ser en lång hexadecimal sträng eller en hash, klickar godkänn på hårdvaruplånboken och litar på att gränssnittet visade sanningen. Bybit visar varför det antagandet är farligt: en hårdvaruplånbok skyddar nyckeln, inte innebörden. Den ser till att den privata nyckeln aldrig lämnar enheten, men den kan inte garantera att den handling du tror att du godkänner är den handling du faktiskt godkänner.

Motmedlet kallas clear signing, klartextsignering, och bygger på att plånboken kan avkoda och visa exakt vad en transaktion gör: vem som tar emot, hur mycket, vilket kontrakt som anropas och med vilka parametrar. Standarden ERC-7730 försöker göra det här möjligt i stor skala genom att beskriva hur transaktioner ska översättas till läsbar text. För en kassa räcker det ändå inte att lita på ett enda gränssnitt. Den robusta rutinen är att varje undertecknare oberoende verifierar både den avkodade transaktionen och den resulterande Safe-hashen, gärna på en andra, fristående enhet, innan någon skriver under.

Siffrorna visar att hotet är reellt men hanterbart. Enligt Scam Sniffers årssammanställning föll de sammanlagda förlusterna från nätfiske och plånboksdränerare med 83 procent under 2025, till 83,85 miljoner dollar (runt 795 miljoner kronor), samtidigt som nya angrepp som utnyttjar batchsignaturer och EIP-7702 började dyka upp. Trenden är alltså uppmuntrande på det stora hela, men de dyraste enskilda fallen handlar fortfarande om undertecknare som godkände något de inte förstod. Vi har gått djupare in på den här säkerhetsnotan i vår text om passkeys, paymasters och säkerheten kring smarta konton.

Vad Safe och branschen ändrade efteråt

Bybit-stölden tvingade fram förändringar långt bortom den enskilda börsen. Safe satte enligt crypto.news först sitt gränssnitt i ett slags karantän och rullade sedan ut infrastrukturen på nytt i etapper, med ett tiotal förändringar i användargränssnittet. Rekommendationerna och åtgärderna kretsade kring samma tema: integritetskontroller av frontend-koden, oberoende validering av transaktionshashar, hårdare övervakning av förändringar och en medveten minskning av blind signering till förmån för flöden som visar transaktionerna i klartext.

Kanske viktigast var framväxten av verktyg som låter vem som helst verifiera en Safe-transaktion oberoende av gränssnittet, genom att tolka anropsdatan, räkna om hashen och kontrollera signaturerna direkt mot kedjan. Poängen är principiell: det som beräknas på kedjan går inte att manipulera via en komprometterad webbsida. Den bredare läxan för hela branschen blev att aldrig lita på en enda kanal. Om frontend, hårdvaruplånbok och en fristående verifierare alla måste stämma överens innan pengar rör sig, räcker det inte längre att smitta en enda utvecklardator för att komma åt en kassa.

För en enskild organisation är den praktiska slutsatsen att verifieringen måste ske på flera oberoende ställen. Det kan betyda att en utsedd granskare räknar om Safe-hashen i ett separat verktyg, att en andra undertecknare jämför mottagaradressen tecken för tecken mot en känd lista, och att stora ändringar aldrig godkänns samma dag som de föreslås. Inget av detta kräver ny teknik, bara att någon bestämmer att det ska vara obligatoriskt.

Nyckelhantering och de mänskliga rutinerna

Om Bybit lärde branschen något är det att den svagaste länken sällan är kontraktet, utan människorna och deras rutiner. En organisationskassa lever i åratal, och under den tiden byter medarbetare jobb, tappar bort enheter och gör misstag. Därför är nyckelhantering minst lika viktig som själva tröskeln. Vem lägger till och tar bort undertecknare, och hur snabbt stängs en avgången medarbetare ute? En vanlig men farlig genväg är att låta samma person kontrollera flera av nycklarna i ett multisig, vilket i praktiken sänker tröskeln utan att någon märker det.

Återställning är den andra halvan av problemet. Vad händer om en undertecknare blir långvarigt sjuk, avlider eller helt enkelt försvinner? För en privatperson finns numera social återställning, där betrodda kontakter eller enheter kan hjälpa till att återfå åtkomst. För en organisation är motsvarigheten att bygga in redundans: sätt tröskeln så att kassan överlever att en eller två nycklar går förlorade, håll en dokumenterad process för att rotera in nya undertecknare, och testa den processen på ett tomt testkonto innan den behövs på riktigt. Ett multisig som är 5-av-5 ser säkert ut på pappret men förvandlas till ett lås utan nyckel så fort en enda enhet går sönder.

Slutligen handlar det om att göra rätt sak till den enkla vägen. De organisationer som klarar sig bäst har en fast rutin för hur en transaktion förbereds, granskas och signeras, med en tydlig ansvarsfördelning och en andra person som alltid kontrollerar mottagare och belopp oberoende. Rutinen ska vara så inövad att den fungerar även en stressig fredagseftermiddag, för det är precis då angriparna slår till. Tekniken ger verktygen; disciplinen avgör om de används rätt.

Gaslös drift: betalmästare och sessionsnycklar för organisationer

En organisationskassa är inte bara ett valv, den är också ett nav för löpande drift: löner, återkommande utbetalningar, ombalansering av positioner och samspel med DeFi-protokoll. Här kommer den andra halvan av account abstraction in, den som handlar om vem som betalar avgifterna och hur automatisering kan ske utan att exponera huvudnycklarna.

En paymaster, på svenska ungefär betalmästare, är ett kontrakt som betalar transaktionsavgiften åt någon annan. Det låter ett driftskonto slippa hålla ether i varje adress bara för att kunna betala gas. Circles betalmästare, till exempel, låter ett ERC-4337-konto betala avgiften i stablecoinen USDC i stället för i ether, mot ett påslag på omkring tio procent sedan den 1 juli 2025, och fungerar på kedjor som Arbitrum och Base. För en kassa innebär det enklare bokföring och mindre kringflytt av ether, men påslaget gör att modellen passar bättre för driftskonton än för själva huvudkassan.

Automatisering löses i sin tur med sessionsnycklar: tillfälliga, avgränsade nycklar som får utföra vissa handlingar under en begränsad tid utan att röra den underliggande uppsättningen undertecknare. På DAO-nivå är det Roles-modifieraren som fyller samma funktion, genom att låsa en bot till en snäv uppsättning tillåtna anrop. Tekniken är densamma som gör moderna kryptospel spelbara, något vi utforskat i vår genomgång av session keys och osynliga plånböcker. Under huven vilar allt på ERC-4337-räls: särskilda transaktioner kallade UserOperations samlas ihop av så kallade bundlers och skickas via ett gemensamt EntryPoint-kontrakt. Enligt mätsajten BundleBear har standarden hunnit behandla över 1,2 miljarder sådana operationer fördelade på tiotals miljoner konton.

Standarderna som formar nästa generation

Smarta konton vilar på en handfull standarder som är värda att känna igen, eftersom de avgör vad ett organisationskonto kan göra i morgon. ERC-4337, som blev klar 2023, införde account abstraction utan att ändra Ethereums grundprotokoll, genom det separata systemet med UserOperations, bundlers och ett EntryPoint-kontrakt. Den senaste versionen av EntryPoint-kontraktet stödjer numera även nästa byggsten.

Den byggstenen är EIP-7702, som infördes i uppgraderingen Pectra i maj 2025. Den låter en vanlig adress tillfälligt uppträda som ett smart konto, vilket för en organisation betyder att ett befintligt drifts- eller börskonto kan få batchning och betald gas utan att flytta till en ny adress. Möjligheten kommer med brasklappar: kort efter lanseringen fann forskare att en stor majoritet av de tidiga delegationerna var återanvänd dräneringskod, dock riktad mot redan tömda plånböcker snarare än mot vanliga användare. En annan pusselbit är RIP-7212, en förbetald funktion för kurvan P-256 som gör passkeys och Secure Enclave-signaturer billiga nog att använda på kedjan. Och på modulsidan pågår en tyst standardstrid mellan det minimalistiska ERC-7579, som Safe och flera andra lutar åt, och det tyngre ERC-6900.

Nästa stora steg kan bli att bygga in account abstraction direkt i protokollet. I augusti 2026 lade Ethereums grundare Vitalik Buterin fram EIP-8141, som han beskriver som ett samlingsförslag som löser i princip alla kvarvarande problem som account abstraction var tänkt att lösa, med sikte på den uppgradering han kallar Hegota och en tidshorisont på ungefär ett år. Buterin har påpekat att diskussionen om account abstraction pågått ända sedan 2016; att den nu närmar sig protokollnivå skulle göra smarta konton till standard snarare än tillval. För en kassa som byggs i dag är det ett argument för att välja infrastruktur som är förberedd för de här standarderna, inte låst till en enskild leverantör.

Den svenska vinkeln: FI, MiCA och den självförvarade kassan

Var hamnar då ett självförvarat smart konto i det svenska regelverket? Utgångspunkten är att MiCA, EU:s regelverk för kryptotillgångar, och Finansinspektionens tillståndsplikt riktar sig mot den som tillhandahåller tjänster åt andra, inte mot den som förvarar sina egna pengar. Ett bolag eller en DAO som håller sin egen kassa i ett Safe-konto driver ingen kryptotillgångstjänst i lagens mening och behöver därför inget tillstånd från FI för själva förvaringen.

Gränsen går vid att göra det åt andra. Den som erbjuder förvaring, växling eller handel med kryptotillgångar till kunder behöver tillstånd. Enligt Finansinspektionen måste företag som bedrev sådan verksamhet före den 30 december 2024 ha ansökt om tillstånd senast den 30 september 2025, och bolag utan tillstånd ska avveckla sin verksamhet. MiCA reglerar alltså tjänsteleverantörer och emittenter, inte det underliggande Safe-protokollet; ESMA har dessutom klargjort var gränsen går mot rena nytto- och speltokens.

Kvar finns ändå frågor som en svensk styrelse måste äga. Innehav av kryptotillgångar ska redovisas och beskattas, och ansvaret för att det finns fungerande kontroller kring kassan vilar ytterst på ledningen, inte på tekniken. Det är här Bybit-läxan blir konkret även för ett litet svenskt bolag: separera arbetsuppgifter, dokumentera vem som får skriva under vad, kräv klartextverifiering och öva incidentrutiner. Ett smart konto flyttar risken från att tappa bort en nyckel till att fatta fel beslut under tidspress, och den risken hanteras med rutiner, inte med kod. Detta är en beskrivning av hur regelverket ser ut, inte juridisk eller skattemässig rådgivning.

Checklista för organisationens smarta konto

Sammanfattningsvis, för den som ska sätta upp eller granska en organisationskassa på kedjan, är det här de punkter som skiljer en robust uppställning från en bräcklig.

• Sätt tröskeln medvetet: undvik både 1-av-N, som återinför en enda felkälla, och N-av-N, som gör kassan obrukbar om en enda undertecknare försvinner.
• Sprid undertecknarna geografiskt och organisatoriskt, så att ingen enskild dator, person eller plats kan avgöra ett utfall.
• Ge varje undertecknare en hårdvaruplånbok, men lita aldrig på den ensam: verifiera alltid den avkodade transaktionen och Safe-hashen på en fristående kanal.
• Kräv klartextsignering och behandla varje uppmaning att signera blint som en varningssignal.
• Lägg in en fördröjnings- eller timelock-modul före stora ändringar, som byte av ägare eller tröskel.
• Begränsa moduler och rättigheter med Roles-modifieraren; ge bottar och driftskonton minsta möjliga behörighet.
• Använd betalmästare och sessionsnycklar för löpande drift, inte för huvudkassan.
• Testa återställningsscenarier innan de behövs, inte efteråt.
• Anta att frontend kan manipuleras, håll enheter uppdaterade och verifiera mot kedjan.
• Dokumentera och öva incidentrutiner, så att beslut inte fattas för första gången mitt i en kris.

Vanliga frågor

Vad är skillnaden mellan ett multisig-konto och en vanlig kryptoplånbok?

En vanlig plånbok styrs av en enda privat nyckel, medan ett multisig-konto är ett smart kontrakt som kräver att flera förutbestämda undertecknare godkänner varje transaktion, till exempel tre av fem. Det sprider kontrollen och tar bort den enskilda felkälla som en ensam nyckel utgör, vilket är avgörande för en organisation som förvaltar gemensamma pengar.

Är Safe säkert att använda efter Bybit-stölden?

Bybit-stölden berodde inte på ett fel i Safe-kontraktet utan på att angriparna manipulerade webbgränssnittet och lurade undertecknarna att signera blint. Safe har sedan dess infört integritetskontroller, oberoende hashvalidering och flöden som minskar blind signering. Kärntekniken anses fortsatt robust, men säkerheten avgörs i praktiken av signeringsrutinerna, inte bara av koden.

Behöver ett svenskt bolag tillstånd från Finansinspektionen för att förvara krypto i ett smart konto?

Nej, inte för att förvara sin egen kassa. Tillståndsplikten under MiCA och Finansinspektionen gäller den som tillhandahåller kryptotillgångstjänster åt andra, som förvaring, växling eller handel. Ett bolag som håller sina egna medel i ett Safe-konto driver ingen sådan tjänst, men innehavet ska ändå redovisas och beskattas, och ansvaret för kontrollerna ligger hos ledningen.

Vad betyder blind signering och hur undviker man den?

Blind signering innebär att man godkänner en transaktion utan att kunna läsa i klartext vad den gör, ofta bara en hash på en hårdvaruplånbok. Man undviker den genom klartextsignering, där plånboken visar mottagare, belopp och anropat kontrakt, och genom att varje undertecknare verifierar den avkodade transaktionen och hashen på en fristående enhet innan de skriver under.

Kan en DAO styra sin kassa utan att lita på ett fåtal undertecknare?

Ja, delvis. Med moduler som Zodiacs Reality-modul kan en omröstning i Snapshot automatiskt utlösa en Safe-transaktion när resultatet bekräftats via ett orakel, och med Roles- och Delay-modifierare kan rättigheter avgränsas och fördröjas. Beroendet flyttas då från undertecknarna till orakel och tvistelösning, vilket är en annan sorts avvägning snarare än en gratis lösning.

Av Yuki Tanaka, senior redaktör på HOGE Wire med fokus på plånböcker, självförvaring och infrastruktur på kedjan.