I oktober 2026 ble et Base-hvelv tømt ved at angriperne endret en tillatelsesliste, ikke ved at de stjal en nøkkel. Her er beste praksis for å styre tillatelsesflaten i en multisig.
By Anneke de Vries· Oct 6, 2026· 1d ago~25 min read
Base-hvelvet: da en hake i en liste tømte hvelvet
Søndag 4. oktober 2026, klokken 08:52 UTC, fjernet et anonymt hvelv på Base en adresse fra en tillatelsesliste. Ett minutt senere, 08:53 UTC, la den samme multisigen adressen tilbake. Begge transaksjonene bar tre gyldige ECDSA-signaturer fra de samme signatærene, og ingenting ved dem så unormalt ut for kjeden. Rundt 70 sekunder etter at kontrakten var tilbake på lista, lånte den 1 783,067 aBaswstETH mot hvelvets Aave v3-posisjon og løste tokenene inn til omtrent 1 783 wstETH, verdt rundt 6 millioner dollar (cirka 58 millioner kroner), som forsvant til en angriperadresse. Cryptotimes og sikkerhetsselskapet Blockaid dokumenterte at tapet vokste fra et første anslag på 2,02 millioner dollar til rundt 6 millioner i løpet av 40 minutter.Ingen nøkkel ble stjålet. Ingen smartkontrakt i Aave eller på Base ble brutt. Angrepet var en helt vanlig, gyldig endring av hvem som fikk lov til å låne fra hvelvet, utført gjennom multisigens egne rutiner. Etterpå sto fortsatt rundt 31,7 millioner dollar (cirka 300 millioner kroner) igjen i hvelvet, ifølge mpost, og ingen prosjekt har meldt seg som eier. Hvelvet ble kontrollert av en 3-av-7 Safe der alle sju signatæradressene er ukjente, og multisigen hadde ikke utført en eneste transaksjon på 25 dager før de to endringene kom på rekke og rad under angrepet. News.Bitcoin.com kalte det treffende et hvelv styrt av sju mysteriesignatærer.To dager tidligere, 2. oktober, hadde noe beslektet skjedd. Angripere tappet rundt 114,09 ETH (cirka 3 millioner kroner) fra to Safe-multisiger, ikke ved å lure noen til å signere en overføring, men ved å utnytte en tredjeparts modul koblet til lommebøkene. Begge sakene peker på det samme, og det er temaet for denne artikkelen: i 2026 er det ikke uttaket angriperne er ute etter først. Det er tillatelsen.
Multisigen brøt ikke sammen, den adlød
En multisig er en lommebok der flere av et sett nøkler må godkjenne før noe skjer, for eksempel tre av fem. Logikken er enkel: én kompromittert nøkkel skal ikke være nok. Mot rent nøkkeltyveri virker modellen godt. Problemet er at en multisig ikke bare godkjenner overføringer. Den godkjenner også endringer i sine egne regler: hvem som er eier, hvilke moduler som er aktive, hvilke kontrakter som står på en lånetillatelse, og hvilken implementasjon en proxy-kontrakt peker på. Alle disse er like gyldige multisig-handlinger som et uttak, men de har en helt annen rekkevidde.Forskjellen er lett å overse og dyr å lære. En overføring tømmer hvelvet én gang. En tillatelsesendring gir angriperen en stående nøkkel. Når en ondsinnet kontrakt først står på lånetillatelsen, slik i Base-hvelvet, kan den komme tilbake og låne igjen. Når en modul først er aktivert, kan den flytte midler uten å gå gjennom m-av-n på nytt. Når eierskapet først er overført, slik i flere av fjorårets saker, eier angriperen multisigen. Signatærene i Base-hvelvet gjorde ingen feil i kryptografien; de autoriserte nøyaktig det angrepet trengte, og trodde det var rutine.Derfor er den viktigste, og minst lærte, lærdommen fra 2026-sakene denne: en privilegert endring må styres like strengt som et milliarduttak. Samme seremoni, samme ventetid, samme verifisering utenfor signeringskanalen. De fleste team gjør ikke det. De behandler en modulaktivering eller en justering av en allowlist som teknisk vedlikehold, noe en eller to personer ordner raskt, mens de omgir et stort uttak med kontroller. Angriperne har lagt merke til det. Som Ledgers teknologidirektør Charles Guillemet har advart om etter årets hendelser, er «Multisig is not automatically the right answer»; flere nøkler hjelper ikke hvis det angriperen er ute etter, er en gyldig endring av reglene.Mønsteret er ikke anekdotisk. I halvårsrapporten for 2026 teller TRM Labs 207 hendelser med tap på rundt 972 millioner dollar (cirka 9,3 milliarder kroner) i første halvår, et rekordhøyt antall hendelser selv om totalbeløpet falt 57 prosent fra 2,3 milliarder dollar året før. Det interessante er fordelingen. Rene smartkontraktsfeil sto for 125 av de 207 hendelsene, altså flertallet av angrepene, men bare en liten andel av verdien. Kompromittering av infrastruktur, nøkler og drift sto for rundt 15 prosent av hendelsene, men hele 76 prosent av verdien. Medianen lå på rundt 219 000 dollar, mens gjennomsnittet var 4,7 millioner; noen få store tyverier drar snittet opp.Oversatt til vanlig språk: koden holder stort sett. Det som svikter, er lagene rundt nøklene, og stadig oftere handler det om hvem som har lov til hva. September 2026 ble årets verste måned med rundt 766 millioner dollar tapt (cirka 7,4 milliarder kroner) ifølge Shattered, drevet av Bitget-tyveriet 24. september og Liquid Network-tappingen 6. september. Oktober åpnet med Loop-modulen og Base-hvelvet. Felles for dem alle er at angriperne ikke lette etter en matematisk svakhet, men etter en fullmakt de kunne vri om.
Syv saker, og hva signatærene egentlig skrev under på
Ser man 2026-sakene, og de ferskeste fra 2024 og 2025, gjennom tillatelseslinsen i stedet for som en liste over tapte beløp, blir mønsteret tydelig. I nesten alle tilfellene autoriserte signatærene ikke et uttak, men en endring i hvem eller hva som hadde makt over hvelvet. Tabellen under sorterer sakene etter nettopp det: ikke hvor mye som forsvant, men hva signatærene faktisk skrev under på.
Sak
Dato
Tap
Hva signatærene faktisk autoriserte
Bybit
feb. 2025
~1,5 mrd. USD
Bytte av Safe-implementasjonen via delegatecall, forkledd som en rutineoverføring (blindsignert)
Radiant Capital
okt. 2024
~50 mill. USD
transferOwnership på en kjernekontrakt, mens skjermen viste en legitim handling
UXLINK
sep. 2025
~28 mill. USD
Delegatecall som fjernet admin og la angriperen til som eier, fulgt av mint av billioner token
Drift Protocol
apr. 2026
~285 mill. USD
Forhåndssignerte durable-nonce-transaksjoner som stille overførte admin-kontroll
Humanity Protocol
jun. 2026
~36 mill. USD
Eierskapsoverføring og en ubegrenset mint-funksjon på tvers av to kjeder
Aave Loop-modul
2. okt. 2026
~114 ETH
En aktivert tredjepartsmodul som kunne flytte midler uten ny m-av-n
Base-hvelvet
4. okt. 2026
~6 mill. USD
Kontrakt lagt til lånetillatelsen, så fjernet og lagt tilbake på ett minutt
Noen av disse er verdt et nærmere blikk. I Bybit-saken, det største kryptotyveriet noensinne med rundt 1,5 milliarder dollar (cirka 14,4 milliarder kroner), så signatærene en helt vanlig overføring på skjermen mens de i virkeligheten godkjente en transaksjon som byttet ut hvelvets egen logikk. I Radiant Capital kalte angriperen transferOwnership på en kjernekontrakt etter at malware på utviklernes maskiner hadde fått både simuleringer og skjermbilder til å se riktige ut. I UXLINK brukte angriperen en delegatecall til å fjerne admin og legge seg selv til som eier, og kunne deretter prege billioner nye token. I alle tre var selve tyveriet nesten en ettertanke; det avgjørende øyeblikket var da fullmakten skiftet hender.Drift Protocol, det største DeFi-tyveriet i 2026 med rundt 285 millioner dollar (cirka 2,7 milliarder kroner), er det reneste eksempelet på hvorfor dette er en governance-feil og ikke en kodefeil. Vi har gått grundig gjennom saken i gjennomgangen av Halborn og angrepene som omgår revisjonen: angriperne brukte måneder på å sosialmanipulere Drifts Security Council til å forhåndssignere såkalte durable-nonce-transaksjoner, en legitim Solana-funksjon der en transaksjon kan signeres én gang og utføres senere uten å utløpe. Da rådet kort tid før angrepet byttet til en ny terskel uten timelock, forsvant deteksjonsvinduet, og de forhåndssignerte fullmaktene kunne løses ut på kommando. Ingen revisjon fanger det, for koden var aldri problemet.
Loop-modulen: når en tredjeparts modul blir en stående nøkkel
Safe lar deg utvide en multisig med moduler, små kontrakter som får lov til å utføre bestemte handlinger uten å gå gjennom hele m-av-n hver gang. Det er praktisk for automatisering, men det flytter grensen for tilliten din: når en modul først er aktivert, er modulens egen tilgangskontroll din tilgangskontroll. Det var akkurat her det gikk galt 2. oktober 2026.Ifølge sikkerhetsselskapet SlowMist, gjengitt av mpost, ble rundt 114,09 ETH tappet fra to Safe-lommebøker via Loop Safe Module, en tredjeparts adapter (FlashLoopAdapter) bygget oppå Aave v3. Feilen lå i tilgangskontrollen: modulens funksjoner sjekket bare om den som kalte, hadde modulen aktivert, ikke hvem kalleren egentlig var. Angriperen satte opp en falsk Safe som var hardkodet til å svare at modulen var aktivert, forfalsket på den måten Safe-autentiseringen, og styrte deretter modulen med sin egen calldata til å trekke ut pantet. Kjernen i Aave ble aldri rørt.Aave-grunnlegger Stani Kulechov var rask til å trekke den grensen tydelig. Til ChainCatcher sa han at «The contract with the vulnerability is not the Aave v3 contract, but rather a third-party external adapter built on top of Aave, which does not affect Aave v3 itself». Det er en viktig presisering, men også selve poenget for en multisig-eier: Aave var trygt, og likevel forsvant pengene, fordi lommeboken hadde delegert makt til en modul hvis forfatter og kode nå var den reelle grensen. En modul du aktiverer, er en nøkkel du gir bort, helt til du aktivt fjerner den.
Kjenn signatærene dine, og hva du ber dem om
Ethereum-grunnlegger Vitalik Buterin har pekt på det som egentlig er det første spørsmålet for enhver multisig. Han har skrevet at «Two key questions in using multi-sig wallets and social recovery wallets securely are: (i) whom do you choose as guardians, and (ii) what instructions do you give them?». Begge delene handler om tillatelser før de handler om teknikk: hvem du gir en nøkkel, og hva de har fått beskjed om å gjøre med den.Base-hvelvet er motsatsen til begge svarene. Sju signatærer, ingen kjent identitet, ingen forvalter, ingen regulator å gå til. Da tre av dem signerte endringen i lånetillatelsen, fantes det ingen uavhengig part som kunne stanse den, og i etterkant ingen å stille til ansvar. Anonyme signatærer kan være akseptabelt for et lite, gjennomsiktig eksperiment, men for et hvelv som holder verdier i millionklassen, fjerner det den siste bremsen: muligheten til å ringe et menneske og spørre «autoriserte du virkelig dette?».Praksisen her er todelt. For det første: velg signatærer du kan nå, med minst én ekstern part som ikke sitter i samme organisasjon eller samme rom, slik at en intern kompromittering eller et internt komplott ikke rekker hele terskelen. For det andre: gi dem en instruks som gjelder tillatelser spesifikt, ikke bare uttak. En signatær som vet at en ny modul eller en endring i allowlisten alltid skal bekreftes i en videosamtale og aldri hastes gjennom, er en langt bedre forsvarslinje enn en som bare teller nuller i et beløp. Det menneskelige laget er uansett det siste; som vi har sett i dekningen av fysisk tvang mot kryptoeiere, er en signatær også et menneske som kan presses, så instruksen må tåle at noen prøver å omgå den.
En tillatelsesendring er et uttak
Den enkeltpraksisen som ville ha stanset flest av sakene over, er også den billigste: behandle enhver privilegert operasjon som om den var et uttak på størrelse med hele hvelvet, for i praksis er det ofte nettopp det den er. SEAL, sikkerhetskollektivet bak de åpne retningslinjene for multisig, lister opp en egen kontroll de kaller «Out-of-Band Verification for Admin Changes»: endringer i eierskap, moduler, terskel eller tillatelser skal bekreftes utenfor signeringskanalen, for eksempel i en videosamtale kombinert med en signert melding, før de utføres.Poenget med å verifisere utenfor kanalen er at angriperen ofte kontrollerer selve kanalen. Var skjermen manipulert (Bybit), var utviklermaskinen infisert (Radiant), eller var en signatær sosialmanipulert (Drift), så er den eneste påliteligheten en uavhengig bekreftelse gjennom et helt annet medium. Tabellen under kobler de vanligste privilegerte operasjonene til rekkevidden deres og til kontrollen som bør være obligatorisk før de utføres.
Privilegert operasjon
Rekkevidde om misbrukt
Obligatorisk kontroll
Vanlig overføring
Tømmer ett beløp én gang
Terskel, simulering, beløpsgrense
Legge til eller bytte eier
Angriperen overtar multisigen
Timelock, veto-quorum, bekreftelse utenfor kanalen
Aktivere en modul
Stående makt til å flytte midler uten m-av-n
Kodegjennomgang av modulen, timelock, overvåking
Endre allowlist eller whitelist
Ny låntaker eller mottaker kan komme tilbake
Bekreftelse utenfor kanalen, timelock, varsling
Oppgradere proxy eller implementasjon
Bytter ut hele lommebokens logikk
Timelock, uavhengig verifisering av ny kode
Fjerne eller senke en timelock
Fjerner deteksjonsvinduet for alt annet
Behandles som den mest kritiske endringen av alle
Den siste raden er verdt å dvele ved. I Drift fjernet rådet timelocken selv, kort før angrepet, og åpnet dermed døren for de forhåndssignerte fullmaktene. En endring som svekker et forsvar, bør alltid regnes som farligere enn endringen den skal muliggjøre, ikke mindre farlig fordi den bare rører ved innstillinger.
Revider modulene, vaktene og fullmaktene dine
Hvis en tillatelse er en nøkkel, må du vite nøyaktig hvor mange nøkler som finnes. De fleste team kan liste opp signatærene sine, men langt færre kan på stående fot svare på hvilke moduler som er aktive på Safe-en, hvilke kontrakter som står på allowlisten, hvem som er satt opp som guard, og hvilken implementasjon proxy-en peker på. Hver av dem er en inngang. En tillatelsesflate du ikke har oversikt over, kan du heller ikke forsvare.Praksisen er en jevnlig revisjon av tillatelsesflaten, ikke bare av koden. Før hvert kvartal, og etter enhver endring: list opp alle aktive moduler og hvem som skrev dem, alle adresser på enhver allowlist, alle eiere og terskelen, alle guards, og tidspunktet for siste endring i hver. Fjern det som ikke lenger brukes. En modul som ble stående igjen fra et pilotprosjekt i fjor, er en åpen dør ingen lenger vokter. Dette er den samme disiplinen vi etterlyste i omtalen av Bitget og revisjonsparadokset: en ren revisjon av koden sier ingenting om hvem som har fått stående fullmakter utenfor den.Base-hvelvet gir en siste, konkret ledetråd: multisigen hadde ligget stille i 25 dager før de to tillatelsesendringene plutselig kom. En Safe som er dvask i ukevis og så gjør to raske administrative grep på rad, er i seg selv et varsel. Det bør utløse en alarm, ikke bare en loggføring, og det bringer oss til neste spørsmål: hvem som skal varsles, og hvor høy terskelen egentlig bør være.
Terskel og signatærmangfold: flere er ikke tryggere
Det er en utbredt misforståelse at flere signatærer alltid betyr mer sikkerhet. SEAL-retningslinjene setter noen gulv som er verdt å følge: minst tre signatærer, en terskel på minst 50 prosent, og sju eller flere signatærer for multisiger som holder verdier over én million dollar (rundt ti millioner kroner). Men de advarer også mot N-av-N, der alle må signere, fordi en eneste utilgjengelig eller kompromittert nøkkel da enten låser hvelvet eller stanser all drift. Poenget er balanse, ikke maksimal spredning.Mangfold betyr mer enn antall. SEAL anbefaler ulike maskinvarelommebøker fra ulike produsenter (så en enkelt firmware-feil ikke rammer alle), geografisk spredning av signatærene, minst én ekstern signatær, og en dedikert signeringsadresse per multisig i stedet for å gjenbruke den samme nøkkelen flere steder. Humanity Protocol er motsatsen: terskler på to kjeder så nominelt uavhengige ut, men flere av nøklene var sikkerhetskopiert til den samme bærbare datamaskinen, så én enkelt enhet brøt begge tersklene samtidig.
Verdi i hvelvet
Foreslått oppsett
Merknad
Lite team eller hobby
2 av 3
Tåler tap av én nøkkel uten å låse hvelvet
Betydelig eller i drift
3 av 5
Terskel minst 50 prosent, unngå N-av-N
Høy verdi
4 av 7
Rom for geografisk og organisatorisk spredning
Over ~1 mill. USD
7+ signatærer
SEAL-gulv, med minst én ekstern signatær
Alle nivåer
Ulike HW-modeller og produsenter
Hindrer at én firmware-feil rammer alle
Men merk hva tabellen ikke løser. Alle sakene i denne artikkelen skjedde i multisiger som i praksis fulgte tersklene over. En 3-av-7 stanser ikke et angrep der tre gyldige signaturer er akkurat det angriperen har skaffet seg, enten gjennom kompromitterte enheter, sosial manipulasjon eller en manipulert skjerm. Terskel og mangfold er nødvendige gulv, men de beskytter mot tapte og stjålne nøkler, ikke mot en signatær som blir lurt til å godkjenne feil ting. For det trengs det neste laget: å faktisk lese det du signerer.
Les det du signerer, og grensen for clear signing
Blindsignering, altså å godkjenne en transaksjon lommeboken bare viser som en uleselig streng med hex, er den røde tråden gjennom de dyreste sakene. Svaret bransjen samlet seg om i 2026, er clear signing. 12. mai 2026 lanserte Ethereum Foundation en felles Clear Signing-standard under initiativet Trillion Dollar Security, med ERC-7730 (et JSON-format som lar en lommebok vise en transaksjon i lesbar tekst), et offentlig register og et attestasjonssystem. Begrunnelsen formulerte stiftelsen slik: «Approving a transaction is meant to be the last line of defense … When it is done blindly, that defense does not hold», og målet er at «What You See Is What You Sign (WYSIWYS) must be our goal, and Clear Signing must be the default».ERC-7730 er fortsatt på utkaststadiet, men aktivt i bruk, og er ifølge EIP-registeret opprinnelig foreslått av Ledger med bidrag fra blant andre MetaMask og Trezor. For en multisig betyr det at en signatær kan se at en transaksjon kaller addOwnerWithThreshold eller enableModule, og mot hvilken adresse, i stedet for en ugjennomtrengelig datablokk. Det er et stort steg, og det ville ha hjulpet mot Bybit-typen angrep der skjermen løy.Men clear signing har en grense som er direkte relevant for tillatelsesangrep. Standarden kan vise deg sant at du er i ferd med å aktivere en modul eller legge en kontrakt til en allowlist. Den kan ikke fortelle deg om den modulen eller den kontrakten er trygg. I Base-hvelvet var transaksjonen som la kontrakten til lista, antakelig helt lesbar; problemet var ikke at signatærene ikke så hva de godkjente, men at det de godkjente, var farlig. Clear signing løser blindsignering. Det løser ikke spørsmålet om du burde ha signert i det hele tatt, og derfor er menneskelig instruks og verifisering utenfor kanalen fortsatt uunnværlig.
Timelocks, simulering og overvåking
Hvis en tillatelsesendring er det farligste en multisig gjør, trenger du tid til å oppdage den før den får virke. En timelock, en obligatorisk forsinkelse mellom at en transaksjon er godkjent og at den kan utføres, er det enkleste verktøyet for nettopp det. SEAL anbefaler obligatoriske timelocks, og gjerne et eget veto-quorum som kan kansellere en mistenkelig transaksjon i ventetiden. Forsinkelsen er ikke til bry; den er deteksjonsvinduet. Drift viste hva som skjer når det vinduet lukkes: uten timelock var det ingenting mellom den forhåndssignerte fullmakten og uttaket.Simulering hører med, men med et forbehold. Å simulere en transaksjon før den utføres, for eksempel gjennom verktøy som Tenderly, viser hva den faktisk vil gjøre mot kjeden. Det fanger mange feil. Men i Radiant var nettopp utviklermaskinene kompromittert, så simuleringen viste et rent resultat mens den virkelige transaksjonen var en annen. Lærdommen er at simulering må skje på en ren, uavhengig enhet for å bety noe, og at den utfyller, ikke erstatter, en uavhengig rekompilering av transaksjonens hash på en separat maskin.Overvåking er det siste leddet, og det er her tillatelsesflaten fortjener spesiell oppmerksomhet. De fleste team varsler på store overføringer. Langt færre varsler automatisk på en ny eier, en aktivert modul, en endret allowlist eller en senket timelock. Det bør snus: enhver endring i hvem som har makt, bør utløse et varsel til alle signatærer umiddelbart, uavhengig av beløp. Hadde Base-hvelvet hatt et slikt varsel, ville de to endringene klokken 08:52 og 08:53 vært en alarm, ikke en oppdagelse 28 minutter senere.
Isoler nøklene, roter signatærene, øv på krisen
Selve signeringen bør skje på en dedikert, helst luftgappet enhet som ikke brukes til noe annet. Jo mer en maskin gjør, desto større er angrepsflaten; en bærbar PC full av nettlesere, utvidelser og nedlastede PDF-er er ikke et signeringsmiljø. Radiant og Humanity er begge påminnelser om at når signeringsmaskinen eller nøkkelkopien deler plass med resten av arbeidslivet, flytter angriperen inn der. En nøkkel som bare lever på en isolert enhet, og en sikkerhetskopi som ikke ligger i samme sky som alt annet, fjerner de vanligste inngangene.Signatærlisten er ikke statisk. Folk slutter, bytter rolle, mister en enhet eller blir kompromittert. SEAL anbefaler jevnlige gjennomganger av tilgang og rask offboarding når noen går, med en langt strammere frist for signatærer i kritiske roller. Hver gang listen endres, er det i seg selv en privilegert operasjon, så den hører hjemme under de samme kontrollene som resten: timelock, bekreftelse utenfor kanalen og varsling. Rotasjon er bra, men selve rotasjonen er også en tillatelsesendring.Til slutt: en katastrofeplan som er øvd på, ikke bare skrevet. Hva gjør dere hvis en nøkkel mistes midt i en transaksjon, hvis en signatær ikke er å få tak i, eller hvis dere mistenker at en terskel er kompromittert akkurat nå? SEAL legger vekt på dokumenterte kommunikasjonskanaler og regelmessige øvelser nettopp fordi flere av de virkelige sakene startet med en forvekslet eller forfalsket kanal, ikke i selve signeringen. Avgrenset tilgang og tidsbegrensede fullmakter, som vi beskrev i regnskapet for EIP-7702 halvannet år etter Pectra, peker samme vei: makt bør være så snevert avgrenset og så lett å trekke tilbake som mulig.
Multisig eller MPC, og Bitget-speilet
Et naturlig spørsmål er om en annen arkitektur hadde hjulpet. Alternativet til multisig er ofte MPC (multi-party computation), der én nøkkel deles i hemmelige andeler som aldri settes sammen, og signeringen koordineres utenfor kjeden. Safe oppsummerer forskjellen presist: «Multisig externalizes trust into verifiable code. MPC internalizes trust into systems and infrastructure that cannot be fully verified on-chain». Multisigens styrke er at hver godkjenning er synlig og etterprøvbar på kjeden; svakheten er at feilen flytter til godkjenningsskjermen. MPC gir færre synlige ledd og raskere drift, men du må stole på en infrastruktur du ikke kan revidere fullt ut. Fireblocks beskriver sin egen modell som at den fulle nøkkelen «never created, never stored, and never assembled at any point».Bitget-tyveriet 24. september 2026 er speilet som viser at ingen av modellene er magi. Her forsvant rundt 387,5 millioner dollar (cirka 3,7 milliarder kroner), årets største kryptotyveri, ifølge Fortune. Administrerende direktør Gracy Chen opplyste at ingen privat nøkkel ble stjålet og ingen kundeuttak forfalsket; angriperne kompromitterte i stedet et backend-system i Bitgets infrastruktur, matet det med forfalskede transaksjonsdata, og lot børsens egen automatiske autorisasjon frigi midlene. Det er i bunn og grunn den samme feilen som i en multisig, bare flyttet til et sted ingen signatær kunne se: autorisasjonen var gyldig, men det som ble autorisert, var angriperens.I praksis konvergerer bransjen mot en kombinasjon: MPC for den daglige driften, multisig for governance og de store beslutningene, slik at ingen enkelt lag er både raskt og uetterprøvbart. Men uansett modell er konklusjonen den samme som resten av denne artikkelen. Det avgjørende er ikke om nøkkelen er delt i kontrakter eller i kryptografiske andeler, men hvor godt du styrer hvem og hva som får lov til å bruke den.
Det norske bildet: Finanstilsynet, MiCA og de anonyme signatærene
For norske lesere avhenger svaret på «hvem kan jeg gå til?» helt av hvem som holder nøklene. Siden 1. juli 2025 gjelder kryptoeiendelsloven, som innfører MiCA i norsk rett gjennom EØS-avtalen, og Finanstilsynet fører tilsyn med tilbydere av kryptoeiendelstjenester (CASP-er). En CASP som oppbevarer kundenes midler, er underlagt MiCA artikkel 75: klientmidler skal holdes rettslig atskilt fra tilbyderens eget bo, kreditorer har ikke tilgang ved konkurs, og tilbyderen er ansvarlig for tap av kundenes eiendeler eller tilgangsmidler, begrenset til markedsverdien på tapstidspunktet. I tillegg stiller DORA krav til operasjonell IKT-robusthet, inkludert tredjepartsrisiko, noe som er høyst relevant når feilen ligger i en modul eller et backend-system.Base-hvelvet faller på utsiden av alt dette. En anonym DeFi-multisig uten en identifiserbar tilbyder er ikke en CASP; det finnes ingen regulator å klage til, ingen segregeringsregel, ingen ansvarsgrense. De sju ukjente signatærene er bokstavelig talt det eneste forsvaret, og når noe går galt, er det ingen å stille til ansvar. Det er grensen vi har beskrevet i gjennomgangen av smartkontoens juss: i det øyeblikket en tjeneste tar kontroll over tilgangsmidlene dine, flytter du inn under MiCA og Finanstilsynets paraply, mens ekte selvforvaring og anonyme hvelv blir liggende utenfor, med alt ansvaret på deg selv.Praktisk betyr det to ting for en norsk bruker eller et norsk selskap. Velger du en regulert CASP, har du et rettslig sikkerhetsnett, men du gir fra deg teknisk kontroll. Styrer du en egen multisig, beholder du kontrollen, men da er beste praksis i denne artikkelen hele forsvaret ditt. Tap på selvforvarte midler er din risiko alene; ved tyveri går veien til politiet og eventuelt Økokrim, og et eventuelt tap må uansett håndteres i skattemeldingen til Skatteetaten. Ingen regulator henter tilbake en fullmakt du selv signerte bort.
Sjekkliste: slik styrer du tillatelsesflaten
Oppsummert, som en liste du kan gå gjennom før neste administrative transaksjon:
Behandle enhver tillatelsesendring (eier, modul, allowlist, terskel, proxy) som et uttak på størrelse med hele hvelvet.
Krev bekreftelse utenfor signeringskanalen, for eksempel en videosamtale og en signert melding, for alle administrative endringer.
Legg en obligatorisk timelock på privilegerte operasjoner, og et veto-quorum som kan kansellere i ventetiden.
Før et oppdatert register over alle aktive moduler, guards, eiere og allowlist-adresser, og fjern det som ikke lenger brukes.
Varsle automatisk på enhver endring i hvem som har makt, uavhengig av beløp, ikke bare på store overføringer.
Velg minst tre signatærer, terskel på minst 50 prosent, sju eller flere for verdier over rundt ti millioner kroner, og unngå N-av-N.
Spre signatærene på ulike maskinvaremodeller, ulike produsenter og ulike steder, med minst én ekstern part.
Signer på en dedikert, luftgappet enhet, og verifiser transaksjonens hash uavhengig på en ren maskin.
Bruk clear signing der det finnes, men husk at det viser hva du signerer, ikke om kontrakten eller modulen er trygg.
Gjennomgå tilgang jevnlig, offboard raskt, og øv på en skriftlig katastrofeplan minst én gang i året.
Ofte stilte spørsmål
Hva er en multisig-lommebok?
En multisig er en lommebok der flere av et sett nøkler må godkjenne en transaksjon før den utføres, for eksempel tre av fem. Hensikten er at én enkelt kompromittert nøkkel ikke skal være nok til å flytte midler. Modellen beskytter godt mot rent nøkkeltyveri, men ikke mot at nok signatærer blir lurt til å godkjenne feil ting.
Hvorfor er en tillatelsesendring farligere enn en vanlig overføring?
En overføring tømmer hvelvet én gang, mens en tillatelsesendring, som en ny eier, en aktivert modul eller en endret allowlist, gir angriperen en stående mulighet til å komme tilbake. I Base-hvelvet i oktober 2026 holdt tre gyldige signaturer til å legge en ondsinnet kontrakt på lånelista, som deretter kunne låne mot hvelvets posisjon. Derfor bør enhver privilegert endring styres like strengt som et stort uttak.
Stopper flere signatærer et multisig-angrep?
Ikke nødvendigvis. Alle de store sakene i 2026 skjedde i multisiger som fulgte anbefalte terskler, fordi angriperen hadde skaffet seg akkurat de signaturene som trengtes gjennom kompromitterte enheter, sosial manipulasjon eller en manipulert skjerm. Terskel og mangfold beskytter mot tapte og stjålne nøkler, ikke mot en signatær som godkjenner feil ting.
Hva er clear signing, og løser det blindsignering?
Clear signing, standardisert gjennom ERC-7730 og Ethereum Foundations Clear Signing-initiativ fra mai 2026, lar lommeboken vise en transaksjon i lesbar tekst i stedet for en uleselig datablokk. Det løser blindsignering, der signatæren ikke ser hva som faktisk godkjennes. Men det kan ikke fortelle deg om kontrakten eller modulen du godkjenner, er trygg, så menneskelig verifisering er fortsatt nødvendig.
Er en DeFi-multisig beskyttet av Finanstilsynet og MiCA?
Nei, ikke hvis den er et rent selvforvart eller anonymt hvelv uten en identifiserbar tilbyder. Finanstilsynet fører tilsyn med registrerte CASP-er, som er underlagt MiCA artikkel 75 om segregering og ansvar, men en anonym DeFi-multisig er ingen CASP og faller utenfor. Da er dine egne rutiner hele forsvaret, og tap må håndteres i skattemeldingen til Skatteetaten.Anneke de Vries er sikkerhetsredaktør i HOGE Wire og dekker multisig, forvaring og europeisk kryptoregulering.