Safe Multisig: DAO-Treasury i 14 Steg, 50 Min [2026]

Sommeren 2026 kostet bro-hack og kompromitterte signeringsnøkler kryptomiljøet over 97 millioner dollar, og de fleste tapene sporet tilbake til dårlig nøkkelhåndtering, ikke feil i selve smartkontraktene. Et team eller en DAO som styrer en felles kasse trenger noe bedre enn én person med én privatnøkkel. Safe{Wallet}, tidligere kjent som Gnosis Safe, har blitt standardverktøyet for dette. Ifølge Safe Foundations kvartalsrapport for første kvartal 2026 sikret protokollen 35,25 milliarder dollar i eiendeler fordelt på over 61 millioner kontoer, mer enn en tredjedel av all EVM-basert DeFi-TVL. Denne guiden viser deg, steg for steg, hvordan du setter opp en Safe multisig-lommebok for en DAO-treasury eller et kryptoteam i 2026, fra terskelvalg til et komplett prosjekt med tidslås og gjenopprettingsmodul.

Nordiske kryptoteam har historisk vært flinke på selvforvaring, men mange henger etter når pengene tilhører en gruppe i stedet for én person. En hobbyist som setter opp kald lagring alene, kan lene seg på egne rutiner. Et team på fem, ti eller femten personer trenger en delt prosess som fungerer selv om noen er syke, på ferie, eller har byttet jobb. Safe multisig løser nettopp det problemet, og resten av denne guiden går gjennom hele veien fra første klikk til et driftsklart oppsett dere faktisk stoler på. Du finner mer bakgrunnsstoff om trender i kryptosikkerhet i vår løpende dekning av kryptovaluta.

Hva er Safe{Wallet}, og hvorfor trenger DAO-er multisig i 2026

Safe{Wallet} er et smartkontrakt-basert lommebokprotokoll som lar flere personer eie og godkjenne transaksjoner fra samme adresse. I stedet for at én privatnøkkel kontrollerer midlene, definerer du et sett med eiere og et terskeltall, for eksempel tre av fem signaturer, før en transaksjon kan sendes ut. Kjernekontraktene kjører som en Singleton, og hver enkelt Safe er en minimal proxy som peker til den delte logikken. Produksjonsstandarden i 2026 er versjon 1.4.1 av Singleton-kontrakten, dokumentert i Safe sitt offisielle GitHub-repo.

Grunnen til at DAO-er og team velger nettopp Safe multisig, handler om skala og sporbarhet. Protokollen behandlet 4 779 000 ETH i transaksjonsvolum i første kvartal 2026, en økning på 25 prosent fra forrige kvartal, til tross for et svakere marked totalt sett. Rundt 2 prosent av hele det globale stablecoin-markedet, verdt 340 milliarder dollar, ligger i Safe-kontoer. Det gjør Safe til den mest brukte kassestrukturen for protokoller, foundations og team som ikke vil stole på én ansatt eller ett hardware-produkt. Samtidig er ikke en multisig-lommebok automatisk trygg. Angriperen trenger ikke bryte selve kontrakten hvis signererne kan lures til å godkjenne noe de ikke forstår.

Det finnes flere måter å bruke Safe multisig på enn en ren treasury for en DAO. Utviklerteam bruker det til å styre oppgraderingsnøkler for egne smartkontrakter. Foundations bruker det til å forvalte grants-programmer der flere personer må godkjenne hver utbetaling. Selskaper som holder krypto på balansen, bruker det som et alternativ til å legge alt hos en enkelt børs eller en enkelt ansatt. Fellesnevneren er alltid den samme: ingen enkeltperson skal kunne flytte midlene alene.

Det tydeligste eksempelet er Bybit-hacket 21. februar 2025, der Lazarus Group stjal rundt 1,46 milliarder dollar fra en Safe-basert kald lommebok. Angriperne kompromitterte en utviklermaskin knyttet til Safe sin infrastruktur, injiserte skadelig kode i grensesnittet, og fikk signererne til å godkjenne en transaksjon som byttet ut implementasjonskontrakten uten at de så det på skjermen. Kontraktslogikken fungerte som den skulle, men brukerne signerte blindt på noe helt annet enn det de trodde de godkjente. BleepingComputer sin gjennomgang av hendelsen er fortsatt den mest siterte tekniske kilden. Denne guiden bygger inn rutiner som direkte adresserer akkurat den svakheten.

Veksten fortsetter gjennom hele 2026. Safe Foundation rapporterte 2,21 millioner netto nye kontoer bare i første kvartal, en økning som førte totalen forbi 61,11 millioner. Mye av denne veksten kommer fra protokoller og foundations som flytter styringsmidler og infrastrukturbudsjetter over fra enklere løsninger. Navnet Safe stammer for øvrig fra Gnosis Safe, produktet som senere ble skilt ut som eget selskap. Historien om hvordan søsterprosjektet Gnosis Chain gikk over til å bli en Ethereum-lag 2 er verdt å kjenne til hvis du vil forstå hele økosystemet Safe kommer fra, selv om selve multisig-produktet i dag driftes uavhengig av kjeden.

For norske og nordiske team gir en slik multisig-struktur også en praktisk fordel utover ren sikkerhet. Når regulatorer eller revisorer ber om dokumentasjon på hvordan en organisasjon forvalter kryptomidler, er en Safe med tydelig eierliste, terskel og transaksjonshistorikk langt enklere å forklare enn en enkelt privat nøkkel kontrollert av én ansatt. Hele historikken ligger åpent på kjeden, og kan hentes ut av hvem som helst med adressen, uten at teamet må stole på interne regneark.

Forutsetninger: verktøy, nettverk og versjoner du trenger

Før du starter oppsettet, sørg for at alt er klart. Dette sparer deg for feilsøking senere, og reduserer sjansen for at du gjør et forhastet valg midt i prosessen. Sett gjerne av en fast tidsluke der hele teamet er samlet, i stedet for å strekke oppsettet over flere separate dager, siden kontinuitet gjør det lettere å oppdage feil før de blir permanente.

En nettleser med tilgang til app.safe.global, den offisielle web-klienten for Safe multisig.
Minst tre hardware-lommebøker (Ledger eller Trezor), én per foreslått signerer, med oppdatert fastvare.
Node.js versjon 20 eller nyere hvis du vil bruke Safe CLI og skripte oppgaver.
Python 3.11 eller nyere for safe-cli-pakken, som brukes til avansert verifisering senere i guiden.
En finansiert testkonto på et testnett, for eksempel Sepolia, til å øve på hele flyten før dere flytter ekte midler.
Tilgang til en blokkjede-utforsker for nettverket dere velger, slik at dere kan verifisere kontraktsadresser manuelt.

Safe støtter i dag 28 eller flere nettverk, ifølge Safe sin dokumentasjon om støttede nettverk. De mest brukte for team-treasuries er Ethereum mainnet, Arbitrum One, Optimism, Base, Polygon og Gnosis Chain. Velg nettverk ut fra hvor teamet allerede opererer, ikke ut fra hvor gassavgiftene er lavest der og da. Å flytte en etablert Safe til et annet nettverk i etterkant er mulig, men krever ny deployering og full re-signering fra alle eiere, så det er langt billigere å bruke litt tid på valget først.

Hardware-lommeboken er det svakeste leddet hvis den settes opp feil, uavhengig av hvor godt Safe-kontraktene er testet. Hvis noen i teamet ikke har gjort dette før, bør de lese en egen gjennomgang av sikker oppsett av hardware-lommebok før de kobler enheten til Safe. Det tar under en time, og det er tiden best brukt før dere håndterer felles midler i det hele tatt. Sett også av tid til å teste selve nettleser-utvidelsen eller mobilappen på forhånd, slik at ingen står fast midt i et produksjonsoppsett fordi en driver mangler.

Slik velger du riktig terskel og antall signerere

Terskelen, altså hvor mange av eierne som må signere før en transaksjon utføres, er det viktigste sikkerhetsvalget i hele oppsettet. For lav terskel gjør kassen sårbar for ett kompromittert medlem. For høy terskel gjør daglig drift tregere enn nødvendig, og øker risikoen for at treasuryen fryser hvis noen mister tilgangen sin.

Tenk på terskelen som et kompromiss mellom to typer risiko, ikke som et enkelt sikkerhetstall du bare skal maksimere. Den ene risikoen er at en angriper klarer å kompromittere nok signerere til å tømme kassen. Den andre risikoen er at dere selv mister tilgangen fordi for mange nøkler samtidig blir utilgjengelige, for eksempel ved dødsfall, sykdom eller en kompromittert enhet dere må erstatte raskt. Et godt terskelvalg balanserer begge, og bør revurderes hvert år etter hvert som treasuryens verdi og teamets størrelse endrer seg.

Små team på tre til fem personer

For et lite team holder det med tre til fem eiere og en terskel på 2-av-3 eller 3-av-5. Dette gir rom for at én person er utilgjengelig, samtidig som ingen enkeltperson kan tappe kassen alene. Bruk denne modellen for operasjonelle midler, altså penger som brukes til løpende drift og ikke er hele organisasjonens sparepenger.

Et vanlig mønster i norske og nordiske oppstartsselskaper er at gründerteamet også er signererne, ofte tre stiftere som allerede kjenner hverandre godt. Dette fungerer fint operasjonelt, men gjør Safen sårbar hvis alle tre bruker samme kontor, samme nettverk og samme leverandør av hardware. Spre i det minste geografien der det er praktisk mulig, selv i et lite team.

Mellomstore DAO-er med fem til ni signerere

Når flere interessenter skal representeres, for eksempel kjerneteam pluss eksterne rådgivere, gir 3-av-5 eller 4-av-7 en god balanse. Fordel signererne geografisk og organisatorisk, slik at ikke alle sitter i samme selskap eller samme tidssone. Det reduserer risikoen for at én lokal hendelse, som en husransakelse eller en juridisk beslagleggelse, setter hele kassen ut av spill.

Mange DAO-er velger også å inkludere minst én signerer som ikke er ansatt eller kjerneteam, for eksempel et rådsmedlem valgt av tokenholderne. Dette bygger tillit til at treasuryen ikke kontrolleres ensidig av grunnleggerne, samtidig som det introduserer et koordineringsbehov som må planlegges eksplisitt, ikke overlates til tilfeldighetene når en stor utbetaling haster.

Store protokoll-treasuries og foundations

For beløp i millionklassen bør dere gå for syv til tretten eiere med terskel 5-av-9 eller 7-av-11. Kombiner dette med moduler som setter tidslås på store uttak, slik at et kompromittert flertall likevel gir teamet tid til å reagere før pengene faktisk forlater kontoen.

På dette nivået bør signeringsseremonien være formalisert, ikke basert på tillit alene. Store protokoller og foundations som er med på Safe Standard List, dokumenterer typisk hele signeringsprosessen skriftlig, inkludert hvem som verifiserer hva før en signatur avgis. Dette tar lengre tid per transaksjon, men det er nettopp poenget når beløpene er store nok til å tiltrekke seg målrettede angrep.

Type organisasjon	Antall eiere	Anbefalt terskel	Typisk bruksområde	Nøkkelkrav for signerere
Lite team / startup	3-5	2-av-3	Driftskostnader, lønn	Hardware-lommebok anbefalt
Voksende team	4-6	3-av-5	Produktbudsjett, reserver	Hardware-lommebok påkrevd
Mellomstor DAO	5-9	4-av-7	Governance-utbetalinger	Geografisk spredning
Stor protokoll-treasury	7-13	5-av-9	Reserver, investeringer	Tidslås på store uttak
Foundation / kjerneprotokoll	9-15	7-av-11	Kritisk infrastruktur	Formell signeringsseremoni

Steg 1-4: Opprett din første Safe-konto

Nå starter selve oppsettet. Gjør de fire første stegene sammen med minst én annen fra teamet, gjerne på skjermdeling, slik at dere kan verifisere hverandres skjermbilder underveis.

Sett av god tid til hele prosessen første gang. Tabellen under gir et realistisk anslag per fase, basert på et team som følger stegene i denne guiden uten å hoppe over verifiseringspunktene.

Fase	Steg	Anslått tidsbruk	Krever alle signerere	Kan gjøres på forhånd
Forberedelse	Forutsetninger og terskelvalg	15-20 min	Nei	Ja
Opprettelse	Steg 1-4	10-15 min	Nei, kun én oppretter	Nei
Signeroppsett	Steg 5-8	15-20 min per signerer	Ja, hver for seg	Delvis
Modulkonfigurasjon	Steg 9-11	10 min	Nei	Nei
Testtransaksjon	Steg 12-14	5-10 min	Ja, ved terskel	Nei

Gå til app.safe.global og koble til lommeboken din. Bruk en hardware-lommebok, ikke en ren nettleserutvidelse, for kontoen som skal opprette Safen.
Velg “Create new Safe Account” og bekreft riktig nettverk øverst i grensesnittet. En feilklikket nettverksvelger er den vanligste nybegynnerfeilen i hele prosessen.
Legg inn et beskrivende navn på Safen, for eksempel “Teamnavn-Treasury-Prod”, slik at dere ikke forveksler den med en testkonto senere.
Legg til eier-adressene én etter én. Be hver signerer selv lime inn sin adresse fra hardware-lommeboken, ikke fra en melding sendt via chat, for å unngå at en kompromittert kanal bytter ut en adresse underveis.

Etter at eierlisten er komplett, setter du terskelen basert på tabellen over. Grensesnittet viser et sammendrag før du deployerer, og dette er stedet der dere bør stoppe opp og lese hver eneste adresse høyt for hverandre. Det høres unødvendig ut helt til noen oppdager at én bokstav i en adresse er feil.

Deployeringen krever en liten mengde native token på nettverket dere har valgt, siden dette er en vanlig kontraktstransaksjon som betaler gassavgift. Beløpet varierer mye avhengig av nettverk. På Ethereum mainnet kan kostnaden svinge fra noen få dollar til et tosifret beløp i perioder med høy trafikk, mens Arbitrum, Optimism og Base normalt koster en brøkdel av dette. Vent gjerne til dere ser en rolig periode på gassprisen før dere deployerer, spesielt hvis det er en foundation-treasury med mange eiere som skal signere selve opprettelsen.

Når Safen er deployert, kopier adressen og sjekk den mot en offentlig blokkjede-utforsker før dere sender noe til den. Bekreft at eierlisten og terskelen på utforskeren matcher det dere avtalte, ikke bare det Safe-grensesnittet viser. Dette gir et andre, uavhengig sted å verifisere konfigurasjonen, og tar under to minutter.

# Installer safe-cli for å verifisere Safe-konfigurasjonen fra terminalen
pip install safe-cli==6.5.0

# Sjekk versjon og bekreft at installasjonen fungerer
safe-cli --version

Med safe-cli installert kan dere dobbeltsjekke den ferdige konfigurasjonen uavhengig av nettleseren, noe som er nyttig hvis dere mistenker at en maskin i teamet er kompromittert.

Steg 5-8: Legg til signerere og koble til hardware-lommebok

Signererne er selve svakheten angripere jakter på, ikke smartkontraktene. Disse fire stegene handler om å gjøre hver enkelt nøkkel så vanskelig å kompromittere som mulig.

Koble hardware-lommeboken direkte til maskinen med kabel, ikke via en tredjeparts bro-app. Bekreft at fastvaren er den nyeste tilgjengelige for enheten før du fortsetter.
I Safe-grensesnittet, under “Settings” og “Owners”, legg til den nye signereren og skriv inn en kort merkelapp, som “Ledger-Anna” eller “Trezor-Finans”, slik at eierlisten er lesbar for alle senere.
Fjern eventuelle midlertidige eller test-adresser fra listen før produksjonen settes i drift. En glemt test-nøkkel er en unødvendig angrepsflate.
Test at hver signerer faktisk klarer å logge inn og se transaksjonskøen før dere flytter ekte midler til Safen. En signerer som ikke får logget inn under en krise, er verdiløs.

Verifiser alltid transaksjonsdetaljene på selve hardware-enhetens skjerm, ikke bare i nettleseren. Bybit-hacket lyktes nettopp fordi signererne stolte på det nettleseren viste, mens den faktiske transaksjonen var noe helt annet. En hardware-lommebok som viser mottakeradresse og beløp direkte på egen skjerm, gir deg et uavhengig andre synspunkt som skadelig JavaScript ikke kan manipulere.

Kjøp hardware-enhetene direkte fra produsenten eller en autorisert forhandler, aldri fra en bruktmarked-annonse eller en tredjepart dere ikke kjenner. En enhet som er tuklet med før den når signereren, kan se helt normal ut og likevel lekke nøkkeldata ved første oppsett. Sett også en enkel regel for teamet: ingen signerer legger inn gjenopprettingsfrasen sin i noe annet enn selve hardware-enheten, uansett hvor overbevisende en support-forespørsel eller en “verifiseringsapp” ser ut.

# Hent full eierliste og terskel direkte fra kontrakten via safe-cli
safe-cli safe-info 0xDinSafeAdresseHer --network ethereum

# Forventet utdrag av utdata:
# Threshold: 3
# Owners: [
#   '0xA1b2...9f3C',
#   '0xB4c5...1a2D',
#   '0xC7d8...4e5F',
#   '0xD9e0...7f6A',
#   '0xE1f2...9c8B'
# ]

Steg 9-11: Konfigurer moduler og forbruksgrenser

Safe-moduler lar dere gi begrenset, automatisert tilgang uten å svekke selve multisig-terskelen. Dette er forskjellen mellom en treasury som fungerer i praksis og en som blir for treg til å bruke.

Uten moduler ender mange team opp med to dårlige alternativer. Enten krever de full signering for absolutt alt, noe som gjør selv en abonnementsfaktura til en tretimers prosess, eller de gir én person for mye frihet utenfor Safen for å unngå friksjonen. Moduler løser dette ved å la dere definere presist hva som kan gjøres uten full godkjenning, og hva som fortsatt krever terskelen.

Gå til “Apps” i Safe-grensesnittet og finn “Spending Limits”-modulen under de offisielle Safe-appene.
Sett en daglig eller månedlig grense for lavrisiko-utbetalinger, for eksempel lønn eller abonnementer, slik at disse ikke krever full signering hver gang.
Definer en egen delegat-adresse for rutinemessige betalinger, adskilt fra eiernøklene, og gi denne adressen kun tilgang til forbruksgrense-modulen, ikke til selve eierlisten.

Moduler kan også brukes til recovery, altså gjenoppretting hvis dere mister tilgang til nok signerere. En “guard”-kontrakt kan i tillegg blokkere spesifikke transaksjonstyper helt, uavhengig av hvor mange som signerer. Denne kombinasjonen, forbruksgrense pluss guard, er det som skiller en moden treasury-oppsett fra en som bare har kopiert standardinnstillingene.

Hvis teamet skal skrive en egen modul eller guard fra bunnen av, ikke bare bruke Safe sine ferdige apper, gjelder de samme reglene som for annen smartkontraktkode. Kontrakten bør testes grundig og helst revideres før den kobles til en produksjons-Safe med reelle midler. Vår egen gjennomgang av hvordan du skriver en sikker smart kontrakt i Solidity dekker mønstrene som gjelder også for Safe-moduler, siden en feil i en modul kan omgå hele multisig-beskyttelsen selv om selve Singleton-kontrakten er urørt.

// Minimal Solidity-grensesnitt for en Safe Guard som blokkerer
// utbetalinger over en fast grense uten tidslås
interface ITransactionGuard {
    function checkTransaction(
        address to,
        uint256 value,
        bytes calldata data,
        uint8 operation,
        uint256 safeTxGas,
        uint256 baseGas,
        uint256 gasPrice,
        address gasToken,
        address payable refundReceiver,
        bytes calldata signatures,
        address msgSender
    ) external;

    function checkAfterExecution(bytes32 txHash, bool success) external;
}

Steg 12-14: Foreslå, signer og utfør din første transaksjon

Med kontoen og modulene på plass er det på tide å teste hele flyten med et lite beløp, gjerne under 50 dollar i verdi, før dere flytter noe større.

I Safe-grensesnittet, velg “New Transaction” og “Send tokens”. Skriv inn en mottakeradresse dere selv kontrollerer, og et lite beløp.
Send transaksjonsforslaget til de andre signererne, gjerne via en fast intern kanal dere har avtalt på forhånd, aldri via en lenke sendt fra en ukjent avsender.
Hver signerer logger inn separat, sjekker mottakeradresse og beløp mot det som ble avtalt muntlig eller i en dokumentert kanal, og signerer først når begge stemmer overens.

Når terskelen er nådd, kan hvem som helst av eierne utføre transaksjonen på kjeden. Bruk transaction service-APIet til å bekrefte status programmatisk hvis dere automatiserer varsling internt.

Mange team kobler dette API-et opp mot en varslingskanal, slik at hele teamet får beskjed så snart et transaksjonsforslag dukker opp, og igjen når det faktisk utføres. Dette lukker et gap som ellers er lett å overse: en signerer kan godkjenne noe uten at resten av teamet vet at det skjer før pengene allerede har forlatt kontoen. Et enkelt varslingsoppsett koster lite å bygge og gir hele teamet samme oversikt i sanntid.

# Hent status for en spesifikk Safe-transaksjon fra Transaction Service
curl -s "https://safe-transaction-mainnet.safe.global/api/v1/multisig-transactions/0xTxHashHer/"

# Forventet utdrag av JSON-svar:
# {
#   "safe": "0xDinSafeAdresseHer",
#   "confirmationsRequired": 3,
#   "confirmations": [ ... ],
#   "isExecuted": true,
#   "isSuccessful": true
# }

Det komplette prosjektet: bygg en tidslåst DAO-treasury med gjenopprettingsmodul

Nå setter vi sammen alt til ett fungerende oppsett dere kan bruke i produksjon. Målet er en treasury som tåler både et kompromittert flertall og et tapt flertall, uten å bli tregere enn nødvendig i det daglige.

Tenk på dette prosjektet som malen dere justerer etter egen størrelse, ikke en fasit dere må følge til punkt og prikke. Et team på fem personer kan bruke lavere terskeltall gjennom hele oppsettet, mens en foundation med femten interessenter kan trenge et tredje lag med enda strengere terskel for de aller mest kritiske transaksjonene, som å bytte ut selve Singleton-implementasjonen.

Deployer en hoved-Safe med 5-av-9 terskel på nettverket dere har valgt, som beskrevet i stegene over.
Legg til en tidslås-modul som krever 48 timers ventetid på alle uttak over en fastsatt grense, for eksempel 100 000 dollar i verdi.
Deployer en separat “operasjons-Safe” med 2-av-3 terskel og forbruksgrense-modul, finansiert med et fast månedlig beløp fra hoved-Safen, til rutinemessige utgifter.
Konfigurer en gjenopprettingsmodul som lar et flertall av en forhåndsdefinert “guardian”-liste bytte ut en tapt signerer etter en fastsatt ventetid, uten å måtte tømme og gjenopprette hele Safen.
Sett opp overvåkning som varsler teamet ved ethvert forslag til transaksjon over en gitt terskel, uavhengig av om den er signert ferdig eller ikke.
Gjennomfør en full øvelse hvor dere later som om to signerere er utilgjengelige samtidig, og bekreft at gjenopprettingsmodulen faktisk lar resten av teamet erstatte dem innenfor rimelig tid.

Resultatet er en to-lags struktur. Hoved-Safen holder mesteparten av verdiene bak en høy terskel og tidslås, mens operasjons-Safen håndterer daglige utgifter uten å kreve fem signaturer for hver kaffe-abonnement organisasjonen betaler. Denne modellen speiler hvordan flere protokoller på Safe Standard List strukturerer egne foundation-treasuries, ifølge Safe sitt eget blogginnlegg om standarden publisert 10. februar 2026.

#!/bin/bash
# Enkel verifiseringsscript som sjekker at bytekoden til Safen
# matcher den offisielle Singleton v1.4.1-implementasjonen
SAFE_ADDRESS="0xDinSafeAdresseHer"
EXPECTED_HASH="offisiell_bytekode_hash_fra_github_releases"

ACTUAL_HASH=$(cast code $SAFE_ADDRESS --rpc-url https://ethereum-rpc.publicnode.com | sha256sum | cut -d' ' -f1)

if [ "$ACTUAL_HASH" == "$EXPECTED_HASH" ]; then
  echo "Bytekode bekreftet mot offisiell Singleton v1.4.1"
else
  echo "ADVARSEL: bytekoden matcher ikke forventet versjon"
fi

Sikkerhetsherding: Safe Shield og Trusted Safe List i praksis

Safe lanserte 12. februar 2026 en oppdatering av Safe Shield som inkluderer en Trusted Safe List, en strukturell endring i hvordan Safe-kontoer vises og verifiseres i grensesnittet. Samme oppdatering la til “Positions” i mobilappen, slik at porteføljeverdier nå stemmer overens mellom mobil og web. Dette er relevant fordi det gir teamet et ekstra lag med verifisering før store transaksjoner godkjennes.

Aktiver Trusted Safe List-varsler for alle produksjons-Safer, slik at teamet ser umiddelbart hvis en ukjent kontrakt prøver å etterligne en kjent Safe.
Bruk kun offisielle apper fra Safe App Store. Safe fjernet 84 apper fra butikken 21. august 2026 nettopp for å redusere eksponeringen mot lite vedlikeholdte integrasjoner.
Roter signerere hver 6. til 12. måned, og oppdater eierlisten i Safe umiddelbart når noen forlater teamet.
Krev at alle signerere bekrefter transaksjonsdetaljer på selve hardware-enhetens skjerm, aldri kun i nettleservinduet.
Hold en oppdatert liste over hvilke apper i Safe App Store teamet faktisk bruker, og fjern tilgang til apper dere ikke lenger trenger. Færre integrasjoner betyr færre potensielle angrepsflater.

Ingen av kildene som er gjennomgått for denne artikkelen, viser til noe nytt sårbarhetsfunn i selve Safe-kontraktene i 2026. Risikoen ligger fortsatt i signeringsflyten og i menneskene som opererer den, ikke i Singleton-kontrakten. Det er nettopp derfor rutinene over teller mer enn selve kontraktsversjonen.

Det samme prinsippet gjelder for enhver konto knyttet til treasuryen, ikke bare selve Safen. Hvis teamet også har en aktiv konto hos en sentralisert børs for av- og pårampe av midler, bør den sikres med like strenge rutiner. Vår guide til sikring av en kryptobørs-konto går gjennom to-faktor, whitelisting av uttaksadresser og andre tiltak som utfyller multisig-oppsettet dere nå har bygget.

Fem vanlige fallgruver ved multisig-oppsett

Disse feilene dukker opp igjen og igjen hos team som setter opp Safe multisig for første gang. De fleste er enkle å unngå hvis dere kjenner dem på forhånd, men de koster dyrt hvis de først slår ut i produksjon.

For lav terskel i forhold til beløpet. En 1-av-3-oppsett gir ingen reell beskyttelse mot en kompromittert signerer, selv om det ser ut som multisig på papiret.
Alle signerere bruker samme type lommebok fra samme leverandør. Én produktsårbarhet kan da ramme hele eierlisten samtidig. Coldcard-hacket som drenerte 116 millioner dollar fra kald lagring tidligere i 2026 viser hvorfor et enkelt svakt punkt i leverandørkjeden kan bli katastrofalt dyrt, selv utenfor multisig-sammenheng.
Signering uten å lese transaksjonsdetaljene på hardware-skjermen. Dette var nøyaktig svakheten som gjorde Bybit-hacket mulig.
Manglende dokumentasjon av hvem som eier hvilken nøkkel. Når en signerer slutter uten at rutinene er skrevet ned, blir gjenoppretting kaotisk.
Å teste med store beløp i stedet for små. Første transaksjon fra en ny Safe bør alltid være liten, uansett hvor sikre dere føler dere på oppsettet.

Felles for alle fem er at de sjelden oppdages før det er for sent. En terskel som ser fornuftig ut på papiret, en eierliste som virker godt dokumentert, og et team som stoler på hverandre, skjuler lett disse svakhetene i hverdagen. Sett av tid til en årlig gjennomgang der noen utenfor den daglige driften stiller spørsmål ved hele oppsettet, gjerne en teknisk person som ikke selv er signerer. En slik gjennomgang tar sjelden mer enn en arbeidsdag, og den avdekker ofte at eierlisten inneholder adresser ingen lenger husker hvem tilhører.

Feilsøking: åtte vanlige problemer og hvordan du løser dem

Selv et korrekt oppsett kan støte på praktiske problemer. Her er de vanligste, med konkrete løsninger, samlet fra faktiske supporthenvendelser og fellesskapsforum knyttet til Safe.

Transaksjonen vises ikke hos alle signerere. Sjekk at alle bruker samme nettverk øverst i grensesnittet, ikke bare samme Safe-adresse.
Hardware-lommeboken kobler ikke til nettleseren. Bytt USB-kabel og deaktiver andre lommebok-utvidelser som kan kollidere med tilkoblingen.
Transaksjonen henger som “pending” lenge etter nok signaturer. Noen må fortsatt trykke “Execute” manuelt. Signaturer alene utfører ikke transaksjonen automatisk.
Feil gassestimat gjør at utførelsen feiler. Øk gassgrensen manuelt i grensesnittet før du prøver på nytt.
En signerer har mistet hardware-enheten. Bruk gjenopprettingsmodulen fra prosjektet over, eller foreslå en eierbytte-transaksjon signert av resten av terskelen.
Safe-appen viser feil saldo. Dette er ofte en indekseringsforsinkelse hos transaction service, ikke et faktisk problem med midlene. Sjekk saldoen direkte i en blokkjede-utforsker.
To signerere signerer identiske transaksjoner med ulik nonce. Avtal alltid hvem som foreslår transaksjonen først, slik at dere unngår konkurrerende forslag.
En modul nekter en transaksjon uten tydelig feilmelding. Sjekk guard- og modul-loggen i utforskeren. Modulene kan blokkere transaksjoner tause hvis en betingelse ikke er oppfylt.

Hvis ingen av punktene over løser problemet, skriv ned nøyaktig hva som skjedde, hvilken transaksjonshash det gjelder, og hvilket nettverk dere bruker, før dere spør om hjelp i offisielle kanaler. En presis feilbeskrivelse sparer ofte flere timer sammenlignet med en generell melding om at “noe er galt med Safen”.

Avanserte tips for team- og protokoll-treasuries

Når grunnoppsettet er stabilt, kan dere legge til lag som gjør driften enda tryggere uten å gå på bekostning av tempo. Disse tipsene retter seg mot team som allerede har kjørt oppsettet over noen måneder og kjenner grensesnittet godt.

Bruk separate Safer per formål, ikke én enkelt kasse for alt. Skill mellom driftsmidler, langsiktige reserver og eventuelle grants-programmer.
Sett opp en signeringsseremoni med skriftlig sjekkliste for beløp over en fastsatt terskel, slik at store utbetalinger alltid følger samme prosess uansett hvem som er involvert.
Vurder et modulbasert tak på gass-utgifter for automatiserte transaksjoner, slik at en feilkonfigurert bot ikke kan tømme operasjons-Safen over tid.
Dokumenter et “break glass”-scenario: hva gjør dere hvis flertallet av signererne er utilgjengelige samtidig, for eksempel etter en naturkatastrofe eller en koordinert overvåkningsaksjon.
Følg Safe sin egen changelog jevnlig. Mobilappen fikk oppdateringer 12. juni 2026 med forbedret håndtering av sertifikatfornyelse, noe som direkte påvirker hvor stabilt teamet kan signere fra telefon.
Skriv en enkel driftshåndbok som beskriver hele prosessen fra forslag til utført transaksjon, med skjermbilder. Nye signerere skal kunne følge den uten å spørre noen andre om hvordan grensesnittet fungerer.
Vurder å knytte en tidsforsinket varsling til svært store uttak, i tillegg til selve tidslås-modulen, slik at ledelsen får en siste sjanse til å stoppe en transaksjon som ser uvanlig ut.

Ingen av disse tipsene erstatter grunnarbeidet fra de første stegene i guiden. De bygger videre på et oppsett som allerede har riktig terskel, verifiserte signerere og en dokumentert prosess. Legger dere på avansert tooling før grunnmuren er på plass, øker dere kompleksiteten uten å faktisk redusere risikoen.

Safe mot alternativene: Ledger Multisig og Palmera

Safe er ikke det eneste alternativet, selv om det er det mest brukte. To andre verktøy er verdt å kjenne til, spesielt hvis teamet allerede er tungt investert i ett bestemt økosystem. Ingen av dem er bedre i absolutt forstand, men de passer ulike behov.

Ledger Multisig er bygget direkte oppå Safe-kontraktene, men med et eget grensesnitt tilpasset Ledger sine hardware-enheter. Løsningen støtter Ethereum, Base, Arbitrum, Polygon, Optimism og Sepolia-testnettet, og legger jevnlig til nye EVM-nettverk. For team som allerede har standardisert på Ledger som eneste hardware-leverandør, gir dette en mer sammenhengende opplevelse, men det introducerer samtidig den svakheten som er nevnt i fallgruve-listen over: alle signerere på samme produkt.

Palmera tilbyr white-label Safe-grensesnitt og Safe-kompatible utrullinger på tvers av flere EVM-nettverk, med egen indeksering og merkevarebygget UI. Dette passer bedre for protokoller som vil tilby en skreddersydd treasury-opplevelse til egne brukere, fremfor et internt team som bare trenger et standard oppsett.

Uansett hvilket verktøy dere lander på, sjekk at det bygger på samme reviderte kontraktstandard som Safe selv, eller på en variant som er offentlig dokumentert og verifiserbar på en blokkjede-utforsker. Et grensesnitt kan se profesjonelt ut uten at kontraktene bak er like grundig testet, og det er kontraktene, ikke fargevalget i UI-et, som faktisk beskytter pengene deres.

Skifter dere verktøy senere, for eksempel fra standard Safe til en Ledger-drevet variant, gjennomfør migreringen som en fullverdig produksjonsendring. Behandle den med samme sjekkliste dere brukte ved førstegangsoppsettet, inkludert en liten testtransaksjon før dere flytter hovedbeholdningen over til den nye konfigurasjonen.

Verktøy	Bygget på	Nettverksdekning	Best egnet for	Merk
Safe{Wallet}	Egen Singleton v1.4.1	28+ nettverk	De fleste team og DAO-er	Størst adopsjon, 35,25 mrd. dollar sikret
Ledger Multisig	Safe-kontrakter	6 nettverk, flere kommer	Team med kun Ledger-enheter	Egen UI, samme sikkerhetsmodell som Safe
Palmera	Safe-kompatible kontrakter	Flere EVM-nettverk	Protokoller med egen merkevare	White-label grensesnitt og indeksering

For de fleste DAO-er og kryptoteam er standard Safe{Wallet} fortsatt riktig valg. Det har lengst driftshistorikk, bredest nettverksstøtte, og en aktiv oppdateringstakt gjennom hele 2026.

Ofte stilte spørsmål om Safe{Wallet} multisig

Er Safe{Wallet} gratis å bruke?
Ja, det koster ikke noe å opprette eller bruke en Safe utover vanlige nettverksavgifter for transaksjoner på kjeden.

Hvor mange signerere bør en liten DAO ha?
Tre til fem eiere med en terskel på 2-av-3 eller 3-av-5 dekker de fleste små DAO-er, som beskrevet i tabellen tidligere i artikkelen.

Kan jeg flytte en eksisterende Safe til et annet nettverk?
Nei, en Safe er knyttet til nettverket den ble deployert på. Dere må deployere en ny Safe og signere en fullstendig migreringsprosess for å flytte midlene, inkludert å informere alle motparter om den nye adressen.

Hva skjer hvis vi mister nok signerere til å nå terskelen?
Uten en forhåndskonfigurert gjenopprettingsmodul kan midlene bli varig utilgjengelige. Sett opp gjenopprettingsmodulen beskrevet i prosjektdelen før dere flytter store beløp.

Er Safe tryggere enn en enkelt hardware-lommebok?
For felles midler, ja. En enkelt hardware-lommebok er fortsatt ett enkelt feilpunkt, mens en riktig konfigurert multisig krever kompromittering av flere uavhengige nøkler samtidig. For en enkeltperson som forvalter egne midler alene, er en godt sikret hardware-lommebok fortsatt et fullgodt valg.

Hvorfor skjedde Bybit-hacket når Safe-kontraktene ikke var direkte kompromittert?
Fordi angriperne manipulerte det signererne så i grensesnittet, ikke selve kontraktslogikken. Dette er grunnen til at hardware-verifisering av transaksjonsdetaljer er et eget steg i denne guiden.

Trenger vi Safe CLI, eller holder det med nettleseren?
Nettleseren er nok for daglig bruk. Safe CLI er nyttig som et uavhengig verifiseringslag, spesielt hvis dere mistenker at en maskin i teamet kan være kompromittert.

Hvor ofte bør vi rotere signerere?
Hver 6. til 12. måned som standard, og umiddelbart hvis noen forlater teamet eller mister en hardware-enhet. Skriv rotasjonsdatoen inn i driftshåndboken, slik at den ikke blir glemt når hverdagen tar over.