Multisig 2026: når signaturen overlever øyeblikket

1. april 2026 forsvant verdier for rundt 2,7 milliarder kroner fra Drift Protocol på omtrent tolv minutter. Ingen privat nøkkel ble stjålet, ingen kryptografi ble knekt, og ingen smartkontrakt hadde en skjult feil som revisorene hadde oversett. To av fem medlemmer i protokollens Security Council hadde godkjent noen transaksjoner de trodde var rutine. Signaturene var helt ekte. Problemet var at de hadde ventet.

Angriperne, som CoinDesk beskrev i detalj og som TRM Labs senere knyttet til nordkoreanske aktører, hadde brukt uker på å bygge tillit og manipulere signatarene. De fikk dem til å forhåndssignere transaksjoner ved hjelp av en lovlig Solana-funksjon kalt durable nonces, som lar en signatur være gyldig på ubestemt tid. De signerte godkjenningene lå hvilende til angriperen valgte å sende dem inn, omtrent ett minutt etter at Drift selv hadde kjørt et legitimt testuttak fra forsikringsfondet. To transaksjoner, fire slots fra hverandre, var nok til å overføre administratorrettighetene og tømme hvelvene.

De fleste veiledninger om multisig-sikkerhet behandler signaturen som et øyeblikk: du leser transaksjonen, du godkjenner, den utføres, ferdig. Drift viste hvorfor den forestillingen er farlig. En signatur er ikke et øyeblikk. Den er en gjenstand som kan fanges opp, lagres og utføres lenge etterpå, under forhold signataren aldri så. Der søsterartikkelen vår om hvordan selve tillatelsen blir angrepet handlet om hva en signatur gir bort, handler denne om noe like undervurdert: når signaturen faktisk virker. Dette er tidsdimensjonen i multisig-sikkerhet, og beste praksis i 2026 handler i stor grad om å lukke den.

Signaturen som ventet: anatomien til Drift-tapet

Drift Protocol er en av de største derivatbørsene på Solana. Administrasjonen lå hos et Security Council, en multisig som i dagene før angrepet var migrert til en 2-av-5-løsning bygget på Squads, ifølge Chainalysis med null timelock, og samtidig hadde byttet ut et medlem. To av fem signaturer kunne altså endre protokollen med umiddelbar virkning. Det hørtes smidig ut. Det ble katastrofalt. Tapet er anslått til mellom 270 og 286 millioner dollar, rundt 2,7 milliarder kroner.

Angrepet begynte ikke på kjeden, men i innboksen. I ukene fra slutten av mars utga angriperne seg etter alt å dømme for å være et legitimt handelsfirma, bygget en relasjon til rådsmedlemmene og fikk dem til å godkjenne det Drift senere beskrev som uautoriserte eller feilfremstilte transaksjonsgodkjenninger. Med andre ord: klassisk blindsignering, der signataren ikke forsto hva godkjenningen faktisk gjorde. Da Drift byttet ut et rådsmedlem like før angrepet, tilpasset angriperne seg og skaffet en godkjenning fra det nye medlemmet i stedet.

Det tekniske grepet som gjorde godkjenningene dødelige, var durable nonces. Sikkerhetsselskapet BlockSec dokumenterte sekvensen: 1. april klokka 16:05 UTC sendte angriperen inn to forhåndssignerte transaksjoner fire slots fra hverandre. Den første opprettet og godkjente et ondsinnet forslag om å overføre administratorrollen; den andre godkjente og utførte det via instruksjonen UpdateAdmin. Deretter opprettet angriperen et falskt kollateralmarked kalt CarbonVote Token (CVT), blåste opp prisen på det gjennom wash trading, svekket uttaksbegrensningene og tømte USDC, JLP, SOL, cbBTC og andre eiendeler gjennom 31 uttak på rundt tolv minutter.

Poenget er verdt å gjenta: hvert eneste skritt var teknisk gyldig. Multisigen gjorde nøyaktig det den var bedt om. At revisjon alene ikke fanger denne typen operasjonell kompromittering, er et tema vi har tatt opp i omtalen av Halborn og angrepene som omgår revisjonen. Her er lærdommen enda snevrere: kontrollene sviktet fordi ingen hadde tenkt på tiden mellom signering og utførelse.

Hvorfor signaturen ikke er et øyeblikk

Den mentale modellen de fleste signatarer bærer med seg, ser slik ut: jeg inspiserer transaksjonen, jeg signerer, den havner på kjeden med en gang, og så er den ute av mine hender. I den modellen er sikkerhet ensbetydende med å se riktig på signeringstidspunktet. Hvis skjermen viser det riktige, er jobben gjort.

Virkeligheten er at signering og utførelse er to adskilte hendelser, og at avstanden mellom dem er en angrepsflate i seg selv. En signatur er bare et kryptografisk bevis på at en gitt nøkkel godkjente en gitt melding. Beviset bryr seg ikke om når det brukes. Normalt holdes avstanden kort av tekniske grunner: på Solana utløper en vanlig transaksjon etter omtrent 150 slots, og på Ethereum binder en nonce rekkefølgen. Disse mekanismene fungerer som et usynlig sikkerhetsnett, fordi en godkjenning som ikke utføres raskt, dør av seg selv.

Durable nonces, forhåndssignerte transaksjoner, offline-signaturer og sesjonsnøkler fjerner alle dette nettet, hver på sin måte. De lar en godkjenning overleve øyeblikket den ble gitt i. Og i det øyeblikket signaturen kan vente, endres hele trusselbildet: det er ikke lenger nok å verifisere hva du signerer. Du må også kontrollere når og under hvilke betingelser signaturen kan virke, og hva som kan ha endret seg i mellomtiden. Resten av denne artikkelen er en gjennomgang av nettopp det, bygget rundt beste praksis som faktisk tar høyde for tiden.

Durable nonces, forhåndssignering og forsinket utførelse

For å bygge gode rutiner må man forstå hvordan en signatur kan overleve øyeblikket. Det finnes minst fire mekanismer, og de dukker opp på tvers av kjeder og lommeboktyper.

Den første er durable nonces på Solana. Solanas egen dokumentasjon forklarer at en durable nonce erstatter den kortlivde blockhash-en med en verdi lagret i en egen konto, slik at transaksjonen forblir gyldig til noen uttrykkelig advancer noncen. Funksjonen er laget for legitime formål, som offline-signering og planlagte utbetalinger, men den er også nøyaktig det som gjorde de forhåndssignerte Drift-godkjenningene uutløpelige.

Den andre er offline-signaturer på Ethereum, særlig EIP-712-meldinger og token-godkjenninger (permit). En signatur som ikke er en transaksjon i seg selv, men en melding en kontrakt godtar senere, kan ligge ubrukt til den innløses. Drainere har i årevis utnyttet nettopp dette mot vanlige brukere. Den tredje er sesjonsnøkler og delegert signering, som blir stadig vanligere i account abstraction; de er praktiske, men i realiteten forhåndsgodkjenninger med et tidsrom der de kan misbrukes, noe vi har sett nærmere på i artikkelen om hvem som driver maskineriet bak account abstraction. Den fjerde er køede, timelock-forsinkede transaksjoner, der godkjenningen per definisjon utføres på et senere tidspunkt.

Felles for alle fire er at de bryter antakelsen om at signert betyr snart utført. Når den antakelsen faller, må rutinene dekke hele levetiden til en signatur, ikke bare sekundet den ble laget.

Et årskull av multisig-tap, sortert etter tid

Drift er ikke et unntak, men det tydeligste eksemplet i en lengre rekke. TRM Labs talte 207 angrep i første halvår 2026, med tap på rundt 9,3 milliarder kroner. Smartkontraktfeil sto for flertallet av hendelsene (125 av 207), men bare en liten del av verdiene. Kompromittering av infrastruktur, nøkler og rutiner sto for rundt 15 prosent av hendelsene, men rundt 76 prosent av verdiene. Pengene forsvinner altså nesten aldri der koden brytes; de forsvinner der noen godkjenner noe. (Bitcoin lå rundt 821 000 kroner og Ether rundt 25 900 kroner da dette ble skrevet, ifølge CoinGecko.)

September 2026 ble årets verste måned med tap på over 7 milliarder kroner, ifølge Shattered, drevet av det store Bitget-tyveriet og Liquid Network. Tabellen under sorterer de store multisig-relaterte tapene etter det som er denne artikkelens poeng: avstanden mellom da den avgjørende signaturen ble gitt, og da pengene forsvant.

Mønsteret er tydelig. De fleste tapene skjer på sekunder, fordi signaturen autoriserer noe annet enn det signataren trodde. Men de vanskeligste å oppdage er de der signaturen bevisst er satt til å vente, som Drift, eller der en tidligere godkjenning har etterlatt en stående fullmakt, som Aave Loop-modulen og Base-hvelvet. Det er disse to kategoriene beste praksis i 2026 må ta mer på alvor.

Beste praksis 1: aldri forhåndssigner, og la hver fullmakt utløpe

Den mest direkte lærdommen fra Drift er også den enkleste å formulere: administrative operasjoner skal aldri forhåndssigneres. En godkjenning som ikke utføres der og da, er en fullmakt du har gitt fra deg uten å vite når den brukes. BlockSec anbefaler eksplisitt sterkere vern rundt mekanismer for forsinket utførelse, blant annet høyere signaturterskler og tidsbegrensede eller tilbakekallbare godkjenninger.

I praksis betyr det tre ting. For det første: behandle hver signatur som ferskvare. Der protokollen tillater det, settes en utløpstid på godkjenningen, slik at den dør hvis den ikke utføres innen et kort vindu. For det andre: hold orden på nonce-hygienen. På Solana bør dedikerte nonce-kontoer overvåkes, og en nonce bør advanceres så snart en legitim transaksjon er utført, slik at gamle forhåndssignerte transaksjoner blir ugyldige. For det tredje: gjør godkjenninger tilbakekallbare. En token-approval på Ethereum som ikke lenger er i bruk, bør trekkes tilbake, og en sesjonsnøkkel som ikke lenger trengs, bør deaktiveres umiddelbart.

Fristelsen til å forhåndssignere er reell, særlig i team spredt over mange tidssoner der det er tungvint å samle nok signatarer på kort varsel. Men nettopp denne bekvemmeligheten var inngangen i Drift. Hvis en prosess krever at noen signerer på forhånd slik at andre kan utføre senere, er prosessen selv sårbarheten.

Beste praksis 2: timelock er deteksjonsvinduet Drift fjernet

Hvis man bare skulle trekke fram én teknisk kontroll fra Drift-saken, ville det vært timelock. Chainalysis er utvetydig: migreringen til en 2-av-5-multisig med null timelock fjernet forsinkelsesvinduet som ellers ville gjort det mulig å oppdage og gripe inn før angrepet ble utført. Uten det vinduet var de forhåndssignerte transaksjonene umulige å stanse i det øyeblikket de ble sendt inn.

En timelock legger en obligatorisk forsinkelse mellom godkjenning og utførelse, typisk fra noen timer til flere døgn for de mest følsomme operasjonene. Forsinkelsen gjør ingenting for å hindre at en ondsinnet transaksjon blir godkjent; den gir derimot teamet, overvåkingsverktøyene og i verste fall hele fellesskapet tid til å se hva som er på vei, og til å avbryte. Timelock er med andre ord ikke en lås, men et varsel.

Beste praksis i 2026 kobler timelocken til et eget veto-kvorum: en mindre gruppe med rett til å kansellere et ventende forslag i forsinkelsesvinduet, uavhengig av signatarene som godkjente det. Det er også verdt å merke seg hva Drift-saken sier om endringer i selve oppsettet. Teamet fjernet timelocken dager før angrepet, antakelig for å gjøre driften smidigere. Enhver endring som forkorter eller fjerner et deteksjonsvindu, bør behandles som en høyrisikooperasjon i seg selv, med minst like streng seremoni som en utbetaling på ni sifre.

Beste praksis 3: signatarene, sosial manipulering og verifisering utenfor båndet

Durable nonces var våpenet, men inngangen var menneskene. Angriperne brukte uker på å posere som et legitimt handelsfirma før de ba om en eneste signatur. Det peker på den eldste og mest oversette delen av multisig-sikkerhet: hvem signatarene er, og hvordan de snakker sammen.

Ethereum-grunnlegger Vitalik Buterin har formulert det som to spørsmål: «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?» Sitatet rammer inn poenget: en multisig er ikke sterkere enn dømmekraften og rutinene til personene som holder nøklene.

Rammeverket fra Security Alliance (SEAL) er konkret her. Nøklene bør holdes av ulike, uavhengige og geografisk spredte personer, med minst én ekstern signatar utenfor kjerneteamet, slik at ingen enkelt arbeidsgiver, lokasjon eller kompromittert kommunikasjonskanal rammer et helt kvorum. Like viktig er en dokumentert kommunikasjonsprotokoll: en forespørsel om signering bør aldri komme bare via en chat eller e-post, men bekreftes utenfor båndet, for eksempel med en videosamtale og en signert melding. Det samme menneskelige angrepet står sentralt i vår gjennomgang av fysisk tvang mot kryptoeiere: presset på personen, ikke på koden, er ofte den korteste veien inn.

Et avgjørende poeng for tidsdimensjonen: verifisering utenfor båndet må skje ved utførelse, ikke bare ved signering. Hvis en godkjenning kan ligge og vente, holder det ikke at alle var enige da de signerte. Noen må bekrefte, på et uavhengig grunnlag, at transaksjonen fortsatt skal utføres i det øyeblikket den faktisk sendes inn.

Beste praksis 4: verifiser det du signerer, og clear signing sin grense

Både Bybit, WazirX og Radiant kokte ned til blindsignering: signatarene godkjente noe annet enn det skjermen deres viste. Svaret bransjen har samlet seg om i 2026, er clear signing. 12. mai 2026 lanserte Ethereum Foundation sin Clear Signing-standard under Trillion Dollar Security-initiativet, med en klar tese: «What You See Is What You Sign (WYSIWYS) must be our goal, and Clear Signing must be the default.»

Kjernen er ERC-7730, et JSON-format som lar en lommebok vise en transaksjon i lesbar form på en sikker skjerm, i stedet for en ugjennomtrengelig streng med calldata. Rundt det ligger et offentlig register av beskrivelser og et attesteringssystem som lar uavhengige revisorer gå god for at en beskrivelse stemmer. For en multisig betyr beste praksis at hver signatar uavhengig verifiserer rådataene, altså måladresse, funksjon og parametere, helst ved å regne ut transaksjonshashen på nytt på en separat, ren enhet og sammenligne.

Men clear signing har en grense som er direkte relevant her, og som ofte overses. Clear signing forteller deg hva en transaksjon gjør. Den forteller deg ikke når den utføres. En perfekt lesbar, korrekt forstått durable-nonce-transaksjon er fortsatt en forhåndssignert fullmakt som kan virke uker senere. Clear signing løser blindsigneringsproblemet; det løser ikke tidsproblemet. Derfor er den nødvendig, men ikke tilstrekkelig, og må kombineres med utløpstid, timelock og overvåking.

Beste praksis 5: maskinvaren, isolasjonen og entropien

En multisig er ikke sterkere enn hver enkelt signeringsenhet. SEAL anbefaler at hver signatar bruker en dedikert maskinvarelommebok, at modellene og produsentene er forskjellige, slik at én sårbarhet ikke rammer alle, og at signering skjer på en dedikert, helst luftgappet enhet.

Sommeren 2026 ga en brutal påminnelse om hvorfor diversitet i maskinvare betyr noe. En feil i Coldcards fastvare gjorde at enkelte enheter falt tilbake på en svak programvarebasert tilfeldighetsgenerator i stedet for den maskinvarebaserte, slik at nøklene ble langt lettere å gjette enn de 128 bitene de skulle hatt. Angripere tømte etter hvert verdier for over en milliard kroner fra tusenvis av adresser. Lærdommen er ubehagelig: selv en luftgappet maskinvarelommebok av høy kvalitet kan stille og rolig produsere nøkler som kan gjettes. Hvis alle signatarene i en multisig bruker samme modell, arver hele kvorumet samme feil.

Enheten signataren bruker til daglig, teller også. En kompromittert telefon eller laptop kan endre det som vises, eller stjele det som signeres, noe vi har sett nærmere på i artikkelen om Trail of Bits og mobiltrusselen. Beste praksis er å skille signeringsenheten fra enheten som brukes til e-post, chat og nettlesing, og å behandle selve signeringen som en seremoni på en ren maskin, ikke som noe man gjør i forbifarten.

Beste praksis 6: overvåk det som ligger og venter

Når en signatur kan overleve øyeblikket, må overvåkingen gjøre det samme. Det holder ikke å følge med på utførte transaksjoner; man må følge med på det som er godkjent, køet eller forhåndssignert, men ennå ikke utført.

Chainalysis understreker at hvert skritt i Drift-angrepet var teknisk gyldig, og anbefaler overvåking som vurderer hva en transaksjon faktisk gjør før den utføres, og som flagger unormal hensikt, som plutselige ekstreme parameterendringer eller et mistenkelig nytt kollateralmarked. Konkret betyr beste praksis i 2026 varsling på enhver administrativ aktivitet, ikke bare på uttak, overvåking av nonce-kontoer og ventende forslag, og simulering av hver transaksjon før utførelse, med forbehold om at simulering på en allerede kompromittert maskin kan lyve, slik den gjorde i Radiant-saken.

Oktober 2026 ga to ferske eksempler på stående fullmakter som overvåking burde fanget. I Base-hvelvet ble en kontrakt fjernet fra en tillatelsesliste klokka 08:52 UTC og gjeninnsatt ett minutt senere, begge ganger med gyldige signaturer, før den lånte mot hvelvets Aave-posisjon rundt 70 sekunder etterpå; hvelvet hadde ligget i dvale i 25 dager. I Aave Loop Safe-modulen lot en forhåndsaktivert tredjepartsmodul en angriper flytte midler helt uten en ny godkjenning fra kvorumet. Aave-grunnlegger Stani Kulechov presiserte at feilen ikke lå i Aave selv: «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.» Uttalelsen er en nyttig påminnelse: når en modul først er aktivert, blir modulens egen tilgangskontroll, og forfatteren bak den, din grense.

Beste praksis 7: terskel, diversitet og rotasjon

Tidsdimensjonen kommer i tillegg til, ikke i stedet for, de klassiske terskelrådene. SEAL anbefaler minst tre signatarer og en terskel på minst 50 prosent, og minst sju signatarer for multisiger som forvalter verdier over rundt 10 millioner kroner. N-av-N bør unngås, fordi tap av én nøkkel da låser alt. Men Drift, der 2-av-5 var nok, viser at en lav terskel kan være like farlig i den andre retningen: jo lavere terskel, jo færre personer må manipuleres.

Rotasjon hører med. Signatarer slutter, bytter enhet eller blir kompromittert, og en multisig som aldri roterer nøkler eller gjennomgår tilgang, samler opp risiko. SEAL anbefaler jevnlige tilgangsgjennomganger og en rask, dokumentert prosess for å fjerne en signatar. Men rotasjon er selv en følsom operasjon, som Drift-migreringen viste: hver endring i oppsettet er et øyeblikk der noe kan gå galt, eller der en ny, manipulert signatar slippes inn.

Tabellen er et utgangspunkt, ikke en fasit. Poenget er at kontrollene skal skaleres med verdiene, og at timelock og forbud mot forhåndssignering flyttes fra kjekt å ha til obligatorisk lenge før man er oppe i de summene Drift mistet.

Multisig, MPC og hvor den utsatte risikoen bor

Mange institusjoner spør om MPC (multi-party computation) løser problemet. Svaret er at MPC flytter det, ikke fjerner det. I en multisig ligger logikken på kjeden, synlig og etterprøvbar; Safe formulerer det som at «multisig externalizes trust into verifiable code», mens MPC internaliserer tilliten i systemer og infrastruktur som ikke fullt ut kan etterprøves på kjeden.

For tidsdimensjonen betyr det følgende. I en multisig er en forhåndssignert transaksjon synlig på kjeden som en durable-nonce-konto eller et ventende forslag, i prinsippet mulig å overvåke. I en MPC- eller terskelsignatur-løsning skjer koordineringen utenfor kjeden, og en forhåndsautorisering kan ligge i leverandørens backend der du ikke kan se den. Bitget-tyveriet i september 2026, der et backend-system ble matet med forfalskede transaksjonsdata og den automatiske godkjenningsprosessen frigjorde midlene uten at en nøkkel var stjålet, er mønstereksemplet på hvordan en uverifiserbar backend svikter. Ledgers teknologidirektør Charles Guillemet har advart mot refleksen om at mer maskineri alltid er tryggere: «Multisig is not automatically the right answer.» Poenget hans er at hvert ekstra lag med enheter, sikkerhetskopier og koordinering skaper nye feilpunkter. De fleste profesjonelle oppsett i 2026 kombinerer derfor begge: multisig på kjeden, der hver nøkkel i sin tur er beskyttet av MPC.

Finanstilsynet, MiCA og hullet for forhåndssignerte angrep

Hvem bærer risikoen når en multisig tømmes? Det avhenger av hvem som holdt nøklene. Forvarer en registrert kryptoeiendelstjenesteyter (CASP) midlene dine, er den underlagt Finanstilsynet og MiCA-regelverket, som er innlemmet i norsk rett gjennom kryptoeiendelsloven via EØS-avtalen. MiCA artikkel 75 pålegger tjenesteyteren ansvar for forvaringen, og DORA stiller krav til den operasjonelle og IKT-messige motstandsdyktigheten, altså nettopp de rutinene rundt signering som sviktet i sakene over. Da har du en motpart å gå til.

Bruker du derimot en desentralisert multisig selv, enten som enkeltperson eller som et DAO, faller den utenfor MiCA. Ingen CASP, intet tilsyn, ingen erstatning. Da er dine egne rutiner det eneste vernet, og grensen mellom selvforvaring og tjeneste blir avgjørende, noe vi har gått grundig inn i under smartkontoens juss. Base-hvelvet, som ble styrt av sju anonyme signatarer uten noen kjent operatør, er den rene versjonen av dette hullet: da pengene forsvant, fantes det ingen å klage til.

Sjekklisten for signaturer som ikke overlever deg

Oppsummert, som en praktisk liste å gå gjennom før og etter hver signering:

• Forhåndssigner aldri administrative operasjoner; behandle hver godkjenning som ferskvare med utløpstid.
• Advancer nonce-kontoer så snart en legitim transaksjon er utført, og trekk tilbake ubrukte approvals og sesjonsnøkler.
• Krev obligatorisk timelock på følsomme operasjoner, med et eget veto-kvorum som kan kansellere i vinduet.
• Behandle enhver endring i selve oppsettet, særlig fjerning av timelock eller bytte av signatar, som en høyrisikooperasjon.
• Velg uavhengige, geografisk spredte signatarer med minst én ekstern, og bekreft hver forespørsel utenfor båndet.
• Verifiser utenfor båndet ved utførelse, ikke bare ved signering.
• Bruk clear signing og regn ut transaksjonshashen på nytt på en ren enhet, men husk at det viser hva, ikke når.
• Bruk dedikerte, luftgappede maskinvarelommebøker av ulike modeller og produsenter.
• Overvåk alt som er godkjent, køet eller forhåndssignert, ikke bare det som allerede er utført.
• Skaler terskel og kontroller med verdiene, og unngå både for lav terskel og N-av-N.

Ingen enkelt av disse punktene ville alene stoppet Drift. Til sammen ville de ha gjort angrepet langt vanskeligere: utløpstid ville drept de hvilende signaturene, en timelock ville gitt et vindu, og overvåking av ventende forslag ville reist alarm før de tolv minuttene begynte.

Ofte stilte spørsmål

Hva er en durable nonce, og hvorfor er den farlig for multisig?

En durable nonce er en Solana-funksjon som erstatter den kortlivde blockhash-en med en lagret verdi, slik at en signert transaksjon forblir gyldig på ubestemt tid i stedet for å utløpe. Den er nyttig for offline-signering, men farlig for multisig fordi en angriper kan få signatarene til å forhåndssignere en transaksjon som ligger hvilende og utføres uker senere, slik det skjedde med Drift i april 2026.

Er det trygt å forhåndssignere en multisig-transaksjon?

Nei, ikke uten utløpstid og streng kontroll. En forhåndssignert transaksjon er en fullmakt som kan utføres senere uten en ny godkjenning, så den bør alltid være tidsbegrenset, tilbakekallbar og overvåket. Beste praksis er å unngå forhåndssignering helt for administrative operasjoner.

Hvorfor er timelock så viktig i en multisig?

En timelock legger en obligatorisk forsinkelse mellom godkjenning og utførelse, og skaper dermed et vindu der et uønsket eller ondsinnet forslag kan oppdages og stoppes. Drift hadde fjernet timelocken dager før angrepet, og uten det vinduet var det ingenting som kunne avbryte de forhåndssignerte transaksjonene.

Beskytter en maskinvarelommebok mot denne typen angrep?

Delvis. En maskinvarelommebok beskytter den private nøkkelen, men den hindrer ikke at du signerer feil innhold eller en transaksjon som utføres senere. Clear signing, uavhengig verifisering av rådata og en seremoni utenfor båndet er nødvendig i tillegg til selve enheten.

Gir Finanstilsynet meg erstatning hvis en multisig jeg bruker blir tømt?

Det kommer an på. Hvis en registrert kryptoeiendelstjenesteyter forvarer midlene dine, er den underlagt Finanstilsynet og MiCA-reglene, og du kan ha et krav. Bruker du en desentralisert multisig selv, faller den utenfor MiCA, og da er dine egne rutiner det eneste vernet.

Av Anneke de Vries, sikkerhetsredaktør i HOGE Wire.