Feltet uten angrefrist: adresse-UX i lommeboken 2026
Lommeboken ble usynlig nesten overalt i 2026, bortsett fra ett felt: mottakeradressen. Det er inntastingen uten angrefrist, og nettopp der slår adresseforgiftning til.
I 2026 ble kryptolommeboken usynlig nesten overalt. Passnøkler (passkeys) og innebygde lommebøker fjernet seed-frasen ved inngangsdøren, gassfrie transaksjoner skjulte nettverksavgiften, og sosial innlogging gjorde at mange aldri så en privat nøkkel i det hele tatt. På signeringsskjermen erstattet simulering og clear signing den uleselige nyttelasten med en setning du faktisk kan forstå. Ett felt motsto likevel hver eneste runde med forenkling: mottakeradressen.
Det er feltet merket «Til». For en Ethereum-konto er det 42 tegn: «0x» etterfulgt av 40 heksadesimale tegn som ser ut som ren støy. Du limer dem inn, trykker send, og pengene er borte. Det finnes ingen angrefrist. Angrerettloven gir deg fjorten dager på et nettkjøp; en overføring på blokkjeden gir deg null sekunder. Finaliteten er både funksjonen og fellen.
Poenget ble ubehagelig tydelig denne uken. Torsdag 6. november 2026 falt kryptomarkedet rundt seks prosent på et døgn; Bitcoin gled til omkring 75 600 dollar (cirka 700 000 kroner) og Ethereum til rundt 2 228 dollar, mens mer enn en milliard dollar i girede posisjoner ble tvangssolgt etter et kraftig fall i amerikanske teknologiaksjer (CoinGape). Men tapene som ikke kom tilbake da støvet la seg, stammet sjelden fra selve kursfallet. De stammet fra folk som sendte til feil 42 tegn.
Feltet uten angrefrist: hvorfor mottakeradressen er annerledes
Nesten alt annet du taster inn i en lommebok er tilgivende. Skriver du feil beløp i et bytte, ser du resultatet før du bekrefter. Velger du feil nettverk for en handel, stopper lommeboken deg ofte. Mister du enheten, finnes det en gjenopprettingsvei: en seed-frase, en passnøkkel i skyen eller en sosial gjenoppretting. Mottakeradressen har ingen av delene. Den er den ene inntastingen der et enkelt feiltrykk er endelig.
Grunnen er at blokkjeden ikke kjenner forskjell på «feil adresse» og «tiltenkt gave». En gyldig adresse er en gyldig adresse. Sender du til en skrivefeil som tilfeldigvis også har gyldig format, utfører nettverket ordren like lojalt som om du hadde skrevet riktig. Det finnes ingen bank i andre enden, ingen kundeservice som kan trekke tilbake, ingen tilbakeføring. Dette er den samme asymmetrien vi har skrevet om tidligere: 2026 brukte hele friksjonsbudsjettet ved døren, men de største tapene landet ved hvelvet, og mottakerfeltet er et hvelvøyeblikk forkledd som et tekstfelt (Friksjon er funksjon).
Innsatsen skaleres med beløpet. En feilsendt bitcoin er i skrivende stund verdt rundt 700 000 kroner, uten noen knapp som henter den tilbake. For en vanlig sparer er dette den mest kontraintuitive egenskapen ved selvforvaring: du har full kontroll, og full kontroll betyr at ingen kan redde deg fra din egen utklippstavle.
Tre akter i lommebok-UX, og adressen er den uløste
Lommebokens brukeropplevelse kan leses som et skuespill i tre akter. Første akt handlet om tilgang: hvordan komme inn uten å miste en tolv ords frase skrevet på en lapp. Den akten er langt på vei vunnet, med passnøkler, nøkler i sikre enklaver og innloggingsflyter som ligner fintech. Andre akt handler om forståelse: å gjøre signeringen leselig, slik at du ser hva du godkjenner i stedet for en heksadesimal nyttelast. Den akten pågår, drevet av simulering og standarder for clear signing.
Tredje akt er destinasjonen, og den er fortsatt uløst. Det hjelper lite at inngangen er sømløs og signaturen er leselig hvis selve målet for pengene er en streng du umulig kan verifisere med egne øyne. Oktoberbølgen i 2026 viste at ingen trengte å knekke en nøkkel for å tømme en lommebok; det holdt å angripe tilliten rundt skjermen (Ingen knakk nøkkelen). Adressefeltet er den samme historien i miniatyr: angrepet retter seg ikke mot kryptografien, men mot det ene stedet der mennesket fortsatt må lese og kopiere for hånd.
Det er verdt å merke seg hvorfor rekkefølgen ble slik. Tilgang og forståelse er problemer som kan løses med bedre grensesnitt alene, fordi all nødvendig informasjon finnes på enheten din. Destinasjonen er annerledes, for den riktige adressen finnes ikke i lommeboken; den finnes hos mottakeren og må krysse en kanal, en melding, en nettside eller en QR-kode, før den når deg. Hvert slikt mellomledd er et sted et angrep kan settes inn, og det er derfor adressen er den vanskeligste av de tre aktene å designe bort.
Anatomi av en adresse: Ethereum, Bitcoin og Solana
En kryptoadresse ser ut som støy fordi den er laget for maskiner, ikke for øyne. Under overflaten er den en innpakning av en offentlig nøkkel eller en hash av den, kodet slik at datamaskiner kan validere den raskt. At den er vanskelig å lese for mennesker, var aldri et designmål; det var en bivirkning. Problemet er at nettopp denne strengen er det eneste du må kontrollere manuelt før du gir slipp på pengene.
Formatene er heller ikke like. En Ethereum-adresse er «0x» pluss 40 heksadesimale tegn, til sammen 42 tegn, og den samme adressen er gyldig på alle EVM-kjeder: Base, Arbitrum, Polygon, BNB Chain og resten. Standarden EIP-55 legger en valgfri store/små-bokstav-sjekksum oppå de heksadesimale tegnene, slik at lommeboken kan oppdage en ren skrivefeil. Men den fanger bare feil i tegnene du faktisk skrev; den sier ingenting om hvorvidt den gyldige adressen er den du mente å sende til.
Det er en viktig forskjell mellom to slags feil her. En sjekksum som EIP-55 eller bech32 fanger den typen feil der du har endret et tegn ved et uhell, altså en adresse som ikke lenger er gyldig. Den fanger ikke den langt farligere feilen der du har skrevet en helt annen, men fullt gyldig adresse. Det første er en skrivefeil; det andre er en forveksling, og det er forveksling nesten alle de store tapene handler om. Derfor gir det falsk trygghet å stole blindt på at lommeboken sier fra: den sier bare fra når strengen er ugyldig, ikke når den er feil.
Bitcoin har flere formater samtidig: eldre adresser som begynner med 1 eller 3, moderne SegWit-adresser som begynner med «bc1q», og Taproot-adresser som begynner med «bc1p». De nyere bech32-formatene har en sterk innebygd feildeteksjon som fanger de fleste skrivefeil og til og med antyder hvilket tegn som er galt. Solana går sin egen vei med Base58-kodede nøkler på 32 til 44 tegn, uten «0x» og uten et eget sjekksum-lag av samme type. Resultatet er en verden der lengden, tegnsettet og feilkontrollen avhenger av hvilken kjede du står på.
| Kjede | Typisk format | Lengde | Innebygd feilkontroll |
|---|---|---|---|
| Ethereum og EVM-kjeder | 0x + 40 heksadesimale tegn | 42 tegn | EIP-55 valgfri store/små-bokstav-sjekksum |
| Bitcoin (eldre) | Begynner med 1 eller 3 (Base58Check) | 26 til 35 tegn | Base58Check-sjekksum |
| Bitcoin (SegWit/Taproot) | bc1q (SegWit) eller bc1p (Taproot) | 42 til 62 tegn | Bech32/Bech32m, sterk feildeteksjon |
| Solana | Base58, ingen prefiks | 32 til 44 tegn | Ingen separat sjekksum |
Adresseforgiftning: angrepet som utnytter at du ikke leser
Fordi ingen leser 42 tegn nøye, har tyvene bygget et helt angrep rundt antagelsen om at du ikke gjør det. Adresseforgiftning (address poisoning) planter en adresse som ligner på en du bruker, i din egen transaksjonshistorikk. Neste gang du skal sende til «den samme» mottakeren, kopierer du fra historikken, ser at de første og siste tegnene stemmer, og limer inn tyvens adresse i stedet.
Teknikken finnes i to hovedvarianter. Den ene er null-overføringer: mange token-kontrakter tillater at hvem som helst utløser en overføring på null tokens med en vilkårlig avsender, slik at historikken din viser en utgående «betaling» du aldri gjorde, til en adresse som ligner på mottakerens. Den andre er forfalskede hendelser: en ondsinnet kontrakt sender ut Transfer-hendelser slik at utforskere og lommebøker viser en lookalike-adresse i loggen din. I begge tilfeller utnytter angriperen vanen med å bekrefte bare de første og siste tegnene, og lager en vanity-adresse som matcher nettopp dem (Chainalysis).
Omfanget er ikke marginalt. Sikkerhetsselskapet Blockaid har flagget over 65,4 millioner forgiftningstransaksjoner siden januar 2025, og forsøkene økte fra 628 000 i november 2025 til 3,4 millioner i januar 2026, en femdobling på to måneder. Av de 65,4 millionene var rundt 316 000 bekreftede angrep der offeret faktisk sendte penger, altså om lag ett av to hundre forsøk som lykkes (Blockaid). Hvert vellykket forsøk kan være stort: i mai 2024 mistet en handler 1 155 wrapped bitcoin verdt rundt 68 millioner dollar til en forgiftet adresse, før angriperen uvanlig nok returnerte mesteparten (CoinDesk). I en annen sak forsvant nesten 50 millioner dollar i USDT på en eneste feilkopiering, og 30. januar 2026 gikk 4 556 ETH, rundt 12,4 millioner dollar, til en forgiftet variant av en ellers rutinemessig OTC-innskuddsadresse.
Lommebøker og blokkutforskere har svart med å endre standardvisningen: mange skjuler nå null-overføringer, filtrerer bort åpenbar spam og merker ukjente tokens som mistenkelige. Det hjelper, men det er et kappløp. Angriperne tilpasser seg ved å bruke beløp som er små nok til å se ekte ut, men store nok til å vises, og ved å etterligne nettopp de tokenene offeret faktisk bruker. Så lenge historikken er en offentlig, skrivbar logg som hvem som helst kan legge oppføringer i, er filtrering en demping, ikke en kur.
Copy-paste-vanen og utklippstavle-kapring
Ingen holder 42 tilfeldige tegn i hodet, så alle kopierer og limer inn. Det er en rasjonell tilpasning til et umulig minnekrav, men den flytter tilliten til utklippstavlen, og utklippstavlen er ikke et trygt sted. Skadevare som kaprer utklippstavlen, overvåker det du kopierer og bytter ut en kryptoadresse med angriperens i det korte øyeblikket mellom kopier og lim inn. Du kopierer riktig adresse; du limer inn en annen.
Dette er grunnen til at den utbredte vanen med å sjekke «de fire første og fire siste tegnene» er svakere enn den føles. En vanity-adresse som matcher akkurat de tegnene, er billig å generere, og mellomtegnene er nettopp dem ingen leser. Resultatet er at verifisering i praksis ofte betyr å bekrefte at angriperen gjorde jobben sin. Og når overføringen først er sendt, er gjenvinning en forhandling, ikke en rettighet: akkurat som ved annet kryptotyveri finnes det ingen angreknapp, bare håpet om at motparten frivillig sender tilbake (Nummeret ditt er nøkkelen).
Den eneste robuste løsningen på dette nivået er å ikke stole på manuell lesing i det hele tatt: verifiser hele strengen maskinelt, eller unngå å taste og lime inn ved å bruke navn, QR-koder eller lagrede kontakter. Alt dette finnes i 2026, men det er ujevnt fordelt og ofte skjult bak innstillinger folk aldri åpner.
Lesbare navn: ENS, Basenames og .sol
Den mest intuitive løsningen er å erstatte strengen med et navn. Navnetjenester kobler et kort, lesbart navn til en adresse: Ethereum Name Service («alice.eth»), Basenames på Base («alice.base.eth») og Solana Name Service («alice.sol»). Du sender til et navn du kan uttale og huske, og lommeboken slår det opp til den fulle adressen. For et menneske er «alice.eth» uendelig mye lettere å verifisere enn 42 tegn, og det er den retningen hele bransjen peker.
Navnelaget fikk en viktig kursendring i 2026. I februar la ENS bort sin planlagte Namechain, en egen Layer 2, og bestemte at den lenge varslede ENSv2-oppgraderingen i stedet lanseres direkte på Ethereums hovedkjede. Begrunnelsen var en reduksjon i registreringskostnadene på rundt 99 prosent det siste året, kombinert med at Ethereum selv skalerer raskere enn ventet. Ifølge grunnlegger og hovedutvikler Nick Johnson er kostnadsfordelen ved en egen L2 nå «langt mindre overbevisende enn den pleide å være» (CoinDesk, Cointelegraph). For brukere betyr det at identitetslaget blir billigere og mindre fragmentert, nettopp på et tidspunkt da navn trengs mest.
Men navn fjerner ikke tilliten, de flytter den. Et navn kan forfalskes med homoglyfer, altså tegn som ser like ut (en «l» mot en stor «I», eller bokstaver fra andre alfabeter), slik at «аlice.eth» ser riktig ut, men peker et annet sted. Navn kan utløpe og registreres på nytt av en fremmed. Og til slutt løser navnet uansett opp til en adresse du må stole på at oppslaget gir riktig. Navn gjør verifisering menneskelig mulig, men de er et lag over problemet, ikke en oppheving av det.
Det største hinderet for navn er likevel at de ennå ikke er standardveien. I de fleste send-skjermer må du fortsatt lime inn en rå adresse med mindre du aktivt har satt opp et navn, og et navn koster penger å registrere og må fornyes før det utløper. Glemmer du fornyelsen, kan navnet kapres av noen andre, og betalinger som var adressert til deg, kan ende et nytt sted. Et system som skal gjøre adresser trygge, arver dermed sine egne frister og fallgruver.
Når lommeboken skjuler adressen helt
Den mest radikale tilnærmingen er å fjerne adressen fra synsfeltet helt. Innebygde og «usynlige» lommebøker, bølgen som akselererte da Stripe kjøpte Privy i 2025 og store aktører rullet ut embedded wallets uten seed-frase, lar deg sende til et brukernavn, en e-post eller en kontakt, og lar appen oversette det til en adresse i bakgrunnen (CoinDesk). For en nykommer som aldri vil se «0x», er dette en åpenbar forbedring.
Prisen er at verifiseringen flytter seg til et sted du ikke kan se. Når du aldri møter adressen, stoler du implisitt på appens adressebok og oppslag. Viser appen feil kobling, enten ved feil eller fordi den er kompromittert, finnes det ingen rå streng du kan sjekke mot. Jo mer adressen forsvinner fra skjermen, jo mer konsentreres tilliten hos den som kontrollerer koblingen mellom navn og adresse. Det er en god avveining for små beløp og dagligdagse betalinger, og en dårlig en for en overføring som utgjør sparepengene dine.
Dette er den samme spenningen som løper gjennom hele lommebok-UX i 2026: hver forenkling som fjerner en skummel detalj, flytter også et ansvar brukeren pleide å ha, over til en tjeneste brukeren må stole på. Adressefeltet er bare det stedet der avveiningen er mest uforsonlig, fordi feilen er endelig.
Bitcoin tar en annen vei: BIP-353 og Lightning-adresser
Bitcoin-miljøet har angrepet det samme problemet, men med en annen filosofi. Her er målet å unngå gjenbruk av adresser (av personvernhensyn) samtidig som betalingsmålet gjøres lesbart. Lightning-adresser ser ut som en e-post, «bruker@domene», og løses opp via protokollen til en faktisk faktura; de har gjort Lightning-betalinger nesten like enkle som å sende penger i en bankapp.
Et skritt videre står BIP-353, som legger betalingsinstruksjoner i DNS. En adresse på formen «₿bruker@domene» slås opp mot en DNSSEC-signert TXT-post, som kan peke til en on-chain-adresse, et BOLT12-tilbud eller en silent payment. DNSSEC gir kryptografisk integritet i oppslaget, slik at svaret ikke like lett kan forfalskes underveis. Kombinert med silent payments (BIP-352), som lar én statisk, delbar adresse generere en fersk on-chain-adresse per betaling uten at partene må snakke sammen, peker Bitcoin mot en verden der du deler et navn, ikke en streng, og likevel får en ny adresse hver gang. Også dette hviler til slutt på tillit til et domene og en DNS-kjede, men det er en tillit som er lettere å resonnere om enn 62 tilfeldige tegn.
Feil kjede: når adressen finnes på ti nettverk
Det finnes en feil som er særegen for EVM-verdenen, og som rammer selv folk som verifiserer adressen helt riktig. Fordi den samme 0x-adressen er gyldig på Ethereum, Base, Arbitrum, Polygon, BNB Chain og alle de andre, kan du sende til helt riktig adresse på feil kjede. Da havner midlene på en adresse du kontrollerer, men på et nettverk der mottakeren, ofte en børs, ikke krediterer dem, eller der du mangler nøkkeloppsettet for å hente dem ut. Teknisk sett er pengene ikke borte; i praksis kan de være like utilgjengelige.
Standardforslaget EIP-3770 prøver å bøte på dette ved å sette et lesbart kjede-prefiks foran adressen, for eksempel «base:0x…» eller «eth:0x…», slik at det blir umulig å forveksle hvilket nettverk som gjelder. Parallelt jobber bransjen med chain abstraction, der lommeboken selv velger kjede slik at brukeren slipper, på samme måte som en nettleser ikke spør hvilken server et domene bor på. Fordelen er åpenbar; ulempen er den samme som med usynlige adresser, at ansvaret for et valg med endelige konsekvenser flyttes inn i programvare du må stole på. Kryssing mellom kjeder er dessuten der mye verdi strandet og ble angrepet i 2026, noe vi har dokumentert i egen broanalyse (Når de nyeste broene brister).
Et vanlig eksempel er innskudd til en børs. Du har en adresse børsen ga deg for USDC på Ethereum, men sender USDC på Arbitrum til den samme strengen. Pengene lander på en adresse børsen eier, men systemet krediterer deg ikke automatisk, fordi det ventet midler på en annen kjede. I beste fall finnes en manuell gjenvinningsprosess mot et gebyr; i verste fall er midlene utenfor rekkevidde. Nettopp fordi adressen så helt riktig ut, føles feilen urettferdig: alt du gjorde galt, var å velge feil nettverk i en nedtrekksmeny.
QR-koder og betalingsforespørsler
En QR-kode er i praksis en tryggere lim-inn. Du skanner i stedet for å taste, og fjerner dermed både manuelle skrivefeil og det meste av risikoen for utklippstavle-kapring. Under overflaten koder QR-koden ofte en betalingsforespørsel etter standarden EIP-681 for Ethereum, som kan inneholde både adresse, beløp og kjede i én streng; Bitcoin har sin egen «bitcoin:»-URI med samme idé. Når mottakeren genererer forespørselen, flyttes byrden bort fra avsenderens tastatur.
QR-koder har likevel sine egne angrep. En fysisk klistrelapp kan byttes ut på et utsalgssted, en kode delt som bilde kan være manipulert, og en skjerm du skanner kan vise en annen adresse enn du tror. Skanning løser transkripsjonsproblemet, ikke intensjonsproblemet: koden overfører tegnene korrekt, men den garanterer ikke at tegnene tilhører den du vil betale. QR er et stort steg opp fra manuell inntasting, men det er fortsatt bare så trygt som kilden til koden.
Stealth-adresser: personvern mot adressebok
Mens navn og kontakter trekker i retning av stabile, gjenkjennelige mål, trekker personvern i stikk motsatt retning. Stealth-adresser, standardisert som ERC-5564, lar avsenderen utlede en fersk engangsadresse for mottakeren ut fra en publisert «meta-adresse», slik at betalingene ikke kan knyttes til én offentlig adresse. Mottakeren finner pengene ved å skanne kjeden med en egen visningsnøkkel. Vitalik Buterin, som var med på å utforme standarden, har beskrevet stealth-adresser som en sentral personvernprimitiv for Ethereum, men har samtidig vært tydelig på at de bærer en reell brukskostnad: mottakeren må skanne etter innbetalinger, og en helt fersk adresse kommer uten ETH til å betale gass med (vitalik.eth.limo).
Her ligger en motsetning 2026 ikke har løst. Personvern vil ha adresser som er ferske, uforutsigbare og umulige å knytte sammen; adressebok-UX vil ha mål som er stabile, lesbare og lette å verifisere. Jo mer privat en adresse er, desto mindre gjenkjennelig er den, og desto hardere blir nettopp det verifiseringsproblemet denne artikkelen handler om. De to målene er ikke uforenlige for alltid, men ingen har foreløpig levert en opplevelse som gir begge deler på samme tid for vanlige brukere.
Å signere mottakeren: clear signing og simulering
Siste skanse før pengene flytter seg er signeringsskjermen, og her har 2026 gjort reelle fremskritt, men ikke nødvendigvis mot adresseproblemet. Transaksjonssimulering viser nettoeffekten av det du er i ferd med å godkjenne («du sender 1 ETH, du mottar 0»), og fanger mange svindelforsøk. Men en simulering viser virkningen, ikke om mottakeradressen er den du mente. En simulert overføring til en forgiftet adresse ser helt normal ut, fordi den faktisk er en helt vanlig overføring, bare til feil sted.
Clear signing, formalisert i standarden ERC-7730 som Ledger startet og Ethereum Foundation overtok forvalterskapet for i mai 2026, gjør nyttelasten lesbar: i stedet for en rå streng ser du «du sender X til Y», gjerne med en kjent etikett på mottakerkontrakten. Ledgers teknologidirektør Charles Guillemet har vært en av de skarpeste kritikerne av alternativet, blindsignering, der du godkjenner noe som «ikke er forståelig i seg selv. Det er en digital nyttelast» (Investing.com). Poenget er sterkt, men det løser forståelsen av nyttelasten, ikke riktigheten av målet. Clear signing viser deg trofast adressen du selv matet inn; ble du forgiftet lenger oppstrøms, viser den deg trofast feil adresse.
Clear signing har dessuten en forutsetning: lommeboken må vite hva kontrakten gjør. ERC-7730 fungerer ved at prosjekter leverer beskrivelsesfiler som oversetter rå funksjonskall til lesbar tekst, og for en ukjent eller helt ny kontrakt finnes ofte ingen slik fil. Da faller lommeboken tilbake til en mer teknisk visning, akkurat i de tilfellene en bruker er mest utsatt, nemlig ved det første møtet med noe uprøvd. Lesbarhet er altså ikke en egenskap ved kjeden, men noe som må vedlikeholdes kontrakt for kontrakt.
| Metode for å oppgi mottaker | Hva det beskytter mot | Gjenstående risiko |
|---|---|---|
| Manuell inntasting av hele strengen | Utklippstavle-kapring | Skrivefeil; umulig å kontrollere for mennesker |
| Lim inn fra utklippstavle | Skrivefeil ved tasting | Utklippstavle-kapring; forgiftet historikk |
| Sjekk av fire første og fire siste tegn | Grove feilkopieringer | Vanity-adresser som matcher nettopp de tegnene |
| QR-skanning | Skrivefeil og utklippstavle-kapring | Byttet eller manipulert kode |
| Navn (ENS, Basenames, .sol) | Uleselige strenger | Homoglyfer; tillit til oppslaget |
| Lagret kontakt eller hviteliste | Gjentatt bruk av samme mottaker | Førstegangs-oppføringen må være riktig |
| Børs-hviteliste med tidsforsinkelse | Store, forhastede uttak | Intern kompromittering av kontoen |
Børsen, hvitelister og reiseregelen
Børsene har løst en del av adresseproblemet med hvitelisting av uttaksadresser. Du registrerer gyldige mottakeradresser på forhånd, ofte med en tidsforsinkelse før en nyregistrert adresse kan brukes, slik at en angriper som kommer seg inn på kontoen, ikke umiddelbart kan sende til en fersk adresse. Det er en treghet som er bevisst lagt inn akkurat der innsatsen er høyest, og den fungerer, som forvaringsaktører har bygget hele forretningsmodeller rundt (Forvareren som ble bank).
Det regulatoriske laget som berører adressen mest direkte, er reiseregelen. I EU og EØS er dette TFR II, forordning (EU) 2023/1113, som gjelder sammen med MiCA. Den pålegger tilbydere av kryptoaktivatjenester (CASP-er) å la informasjon om både avsender og mottaker følge en overføring, inkludert DLT-adressen og navn, adresse og identifikasjon. For overføringer til og fra selvforvarte (unhosted) lommebøker over terskelverdier må CASP-en samle inn og kontrollere hvem som står bak adressen (CryptoSlate).
For brukeren merkes reiseregelen som nye spørsmål i uttaksflyten: børsen kan be deg oppgi hvem mottakeren er, om adressen tilhører deg selv eller en tredjepart, og i noen tilfeller be om en bekreftelse på at du kontrollerer en selvforvart adresse. Det føles som friksjon, og det er det, men det er friksjon plassert nettopp der en overføring forlater det regulerte systemet. For personvernet betyr det at pseudonymiteten til en adresse kollapser i det øyeblikket den knyttes til en identifisert konto.
For Norge tas disse pliktene inn via EØS-avtalen; regjeringen har sendt på høring de forventede EØS-forpliktelsene som svarer til både MiCA og TFR II (regjeringen.no). Finanstilsynet fører tilsyn med CASP-ene etter kryptoeiendelsloven, mens selvforvart lommebokprogramvare i seg selv ikke er en CASP og dermed faller utenfor dette tilsynet. Praktisk betyr det en todeling: adressen du kontrollerer hjemme, er din alene, men i det øyeblikket den møter en børs, kobles en identitet til den.
Skattemessig er adressen i ferd med å bli et rapporteringshåndtak. Rapporteringsregelverket CARF trådte i kraft i Norge 1. januar 2026, og tjenestetilbydere skal rapportere kryptoeiendeler til Skatteetaten fra 2027 (Skatteetaten). Hver realisasjon er skattepliktig med 22 prosent på gevinst, og beholdningen føres til markedsverdi per 31. desember. Og sender du til feil adresse? Da sitter du med et irreversibelt tap uten en klar fradragsrett for private; staten kan se hvor myntene dine tok veien, men gir deg sjelden en skattelette for å ha sendt dem til en fremmed. Det understreker poenget: mottakerfeltet er det ene stedet der verken kode, børs eller stat kommer deg til unnsetning.
Hva som faktisk fikser det
Det finnes ingen enkeltknapp som løser adresseproblemet, men det finnes et lagvis forsvar som fjerner de fleste måtene det går galt på. De store lommebøkene har begynt å bygge deler av det inn: MetaMask og andre varsler nå aktivt om adresseforgiftning i det du limer inn (MetaMask). Resten er vaner.
- Bruk navn (ENS, Basenames, .sol) eller lagrede kontakter i stedet for å lime inn rå adresser der det er mulig.
- Verifiser hele strengen, ikke bare de fire første og fire siste tegnene, første gang en mottaker legges inn.
- Send en liten testoverføring før en stor, særlig til en ny mottaker eller en ny kjede.
- Kopier aldri en adresse fra transaksjonshistorikken; gå til kilden, altså en kontakt, et navn eller en QR fra mottakeren.
- Slå på adresseforgiftnings-varsling og transaksjonssimulering i lommeboken.
- Bruk børsens hviteliste med tidsforsinkelse for store uttak.
- Bekreft riktig kjede eksplisitt før du sender, gjerne med et EIP-3770-prefiks.
- For store beløp: bruk en maskinvarelommebok som viser mottakeren på egen skjerm med clear signing.
Det som kjennetegner et godt design, er at det gjør det vanlige tilfellet sømløst og det farlige tilfellet bevisst tregt. En kjent, navngitt mottaker du har sendt til ti ganger, bør være ett trykk. En helt fersk rå adresse, en overføring på tvers av kjeder, eller et beløp som utgjør en meningsfull del av formuen din, bør møte friksjon: en ekstra bekreftelse, en testoverføring, en forsinkelse. Det er den samme asymmetrien som gjelder ellers i lommeboken; adressefeltet er bare stedet der prisen for å ta feil er høyest, og derfor stedet som fortjener mest omtanke.
Lommebokens tre akter er tilgang, forståelse og destinasjon. 2026 vant i stor grad den første og er i ferd med å vinne den andre. Den tredje, de 42 tegnene i «Til»-feltet, er den som fremdeles ber et menneske om å gjøre noe mennesker er dårlige til. Helt til et navn, en skanning eller en lagret kontakt blir standardveien og den rå strengen blir unntaket, forblir mottakerfeltet stedet der verdens glatteste lommebok fortsatt kan miste alt på én eneste innliming.
Ofte stilte spørsmål
Kan jeg få tilbake krypto sendt til feil adresse?
Som hovedregel nei. En overføring til en gyldig adresse er endelig, og det finnes ingen angrefrist eller tilbakeføring på blokkjeden. Havner midlene på en adresse en børs kontrollerer, kan børsen i noen tilfeller hjelpe; ellers avhenger alt av at mottakeren frivillig sender tilbake.
Hva er adresseforgiftning, og hvordan unngår jeg det?
Adresseforgiftning planter en adresse som ligner på en du bruker, i transaksjonshistorikken din, slik at du kopierer tyvens adresse neste gang. Unngå det ved aldri å kopiere fra historikken, bruke navn, lagrede kontakter eller QR fra mottakeren, verifisere hele strengen, og slå på forgiftnings-varsling i lommeboken.
Er en Ethereum-adresse og en Bitcoin-adresse det samme?
Nei. En Ethereum-adresse er 0x pluss 40 heksadesimale tegn (42 tegn til sammen), Bitcoin bruker formater som begynner med 1, 3 eller bc1, og Solana bruker Base58. Du kan ikke sende én kjedes aktiva til en annen kjedes adresse, og på EVM-kjeder er samme adresse gyldig på mange nettverk, så riktig kjede må bekreftes separat.
Hva er ENS, og gjør det sending tryggere?
ENS kobler et lesbart navn som alice.eth til en adresse, slik at du kan verifisere et navn i stedet for 42 tegn. Det er tryggere, men ikke idiotsikkert, siden navn kan forfalskes med homoglyfer og du må stole på oppslaget. ENSv2 lanseres direkte på Ethereums hovedkjede etter at den planlagte Namechain ble lagt bort i 2026.
Hva er reiseregelen for krypto i Norge?
Reiseregelen (TFR II, forordning (EU) 2023/1113) pålegger børser og andre CASP-er å la informasjon om avsender og mottaker, inkludert adressen, følge en overføring. Reglene tas inn i norsk rett via EØS-avtalen, Finanstilsynet fører tilsyn med CASP-ene, mens selvforvarte lommebøker i seg selv ikke er CASP-er. Fra 2027 skal tjenestetilbydere også rapportere kryptoeiendeler til Skatteetaten etter CARF.
Yuki Tanaka dekker lommebøker, børser og selvforvaring for HOGE Wire.