{"id":644,"date":"2026-11-06T13:06:59","date_gmt":"2026-11-06T13:06:59","guid":{"rendered":"https:\/\/hoge.gg\/no\/feltet-uten-angrefrist-adresse-ux-lommebok-2026\/"},"modified":"2026-11-06T13:06:59","modified_gmt":"2026-11-06T13:06:59","slug":"feltet-uten-angrefrist-adresse-ux-lommebok-2026","status":"publish","type":"post","link":"https:\/\/hoge.gg\/no\/feltet-uten-angrefrist-adresse-ux-lommebok-2026\/","title":{"rendered":"Feltet uten angrefrist: adresse-UX i lommeboken 2026"},"content":{"rendered":"

I 2026 ble kryptolommeboken usynlig nesten overalt. Passn\u00f8kler (passkeys) og innebygde lommeb\u00f8ker fjernet seed-frasen ved inngangsd\u00f8ren, gassfrie transaksjoner skjulte nettverksavgiften, og sosial innlogging gjorde at mange aldri s\u00e5 en privat n\u00f8kkel i det hele tatt. P\u00e5 signeringsskjermen erstattet simulering og clear signing den uleselige nyttelasten med en setning du faktisk kan forst\u00e5. Ett felt motsto likevel hver eneste runde med forenkling: mottakeradressen.<\/p>

Det er feltet merket \u00abTil\u00bb. For en Ethereum-konto er det 42 tegn: \u00ab0x\u00bb etterfulgt av 40 heksadesimale tegn som ser ut som ren st\u00f8y. Du limer dem inn, trykker send, og pengene er borte. Det finnes ingen angrefrist. Angrerettloven gir deg fjorten dager p\u00e5 et nettkj\u00f8p; en overf\u00f8ring p\u00e5 blokkjeden gir deg null sekunder. Finaliteten er b\u00e5de funksjonen og fellen.<\/p>

Poenget ble ubehagelig tydelig denne uken. Torsdag 6. november 2026 falt kryptomarkedet rundt seks prosent p\u00e5 et d\u00f8gn; 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<\/a>). Men tapene som ikke kom tilbake da st\u00f8vet la seg, stammet sjelden fra selve kursfallet. De stammet fra folk som sendte til feil 42 tegn.<\/p>

Feltet uten angrefrist: hvorfor mottakeradressen er annerledes<\/h2>

Nesten alt annet du taster inn i en lommebok er tilgivende. Skriver du feil bel\u00f8p i et bytte, ser du resultatet f\u00f8r 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\u00f8kkel i skyen eller en sosial gjenoppretting. Mottakeradressen har ingen av delene. Den er den ene inntastingen der et enkelt feiltrykk er endelig.<\/p>

Grunnen er at blokkjeden ikke kjenner forskjell p\u00e5 \u00abfeil adresse\u00bb og \u00abtiltenkt gave\u00bb. En gyldig adresse er en gyldig adresse. Sender du til en skrivefeil som tilfeldigvis ogs\u00e5 har gyldig format, utf\u00f8rer 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\u00f8ring. Dette er den samme asymmetrien vi har skrevet om tidligere: 2026 brukte hele friksjonsbudsjettet ved d\u00f8ren, men de st\u00f8rste tapene landet ved hvelvet, og mottakerfeltet er et hvelv\u00f8yeblikk forkledd som et tekstfelt (Friksjon er funksjon<\/a>).<\/p>

Innsatsen skaleres med bel\u00f8pet. 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.<\/p>

Tre akter i lommebok-UX, og adressen er den ul\u00f8ste<\/h2>

Lommebokens brukeropplevelse kan leses som et skuespill i tre akter. F\u00f8rste akt handlet om tilgang: hvordan komme inn uten \u00e5 miste en tolv ords frase skrevet p\u00e5 en lapp. Den akten er langt p\u00e5 vei vunnet, med passn\u00f8kler, n\u00f8kler i sikre enklaver og innloggingsflyter som ligner fintech. Andre akt handler om forst\u00e5else: \u00e5 gj\u00f8re signeringen leselig, slik at du ser hva du godkjenner i stedet for en heksadesimal nyttelast. Den akten p\u00e5g\u00e5r, drevet av simulering og standarder for clear signing.<\/p>

Tredje akt er destinasjonen, og den er fortsatt ul\u00f8st. Det hjelper lite at inngangen er s\u00f8ml\u00f8s og signaturen er leselig hvis selve m\u00e5let for pengene er en streng du umulig kan verifisere med egne \u00f8yne. Oktoberb\u00f8lgen i 2026 viste at ingen trengte \u00e5 knekke en n\u00f8kkel for \u00e5 t\u00f8mme en lommebok; det holdt \u00e5 angripe tilliten rundt skjermen (Ingen knakk n\u00f8kkelen<\/a>). Adressefeltet er den samme historien i miniatyr: angrepet retter seg ikke mot kryptografien, men mot det ene stedet der mennesket fortsatt m\u00e5 lese og kopiere for h\u00e5nd.<\/p>

Det er verdt \u00e5 merke seg hvorfor rekkef\u00f8lgen ble slik. Tilgang og forst\u00e5else er problemer som kan l\u00f8ses med bedre grensesnitt alene, fordi all n\u00f8dvendig informasjon finnes p\u00e5 enheten din. Destinasjonen er annerledes, for den riktige adressen finnes ikke i lommeboken; den finnes hos mottakeren og m\u00e5 krysse en kanal, en melding, en nettside eller en QR-kode, f\u00f8r den n\u00e5r deg. Hvert slikt mellomledd er et sted et angrep kan settes inn, og det er derfor adressen er den vanskeligste av de tre aktene \u00e5 designe bort.<\/p>

Anatomi av en adresse: Ethereum, Bitcoin og Solana<\/h2>

En kryptoadresse ser ut som st\u00f8y fordi den er laget for maskiner, ikke for \u00f8yne. Under overflaten er den en innpakning av en offentlig n\u00f8kkel eller en hash av den, kodet slik at datamaskiner kan validere den raskt. At den er vanskelig \u00e5 lese for mennesker, var aldri et designm\u00e5l; det var en bivirkning. Problemet er at nettopp denne strengen er det eneste du m\u00e5 kontrollere manuelt f\u00f8r du gir slipp p\u00e5 pengene.<\/p>

Formatene er heller ikke like. En Ethereum-adresse er \u00ab0x\u00bb pluss 40 heksadesimale tegn, til sammen 42 tegn, og den samme adressen er gyldig p\u00e5 alle EVM-kjeder: Base, Arbitrum, Polygon, BNB Chain og resten. Standarden EIP-55<\/a> legger en valgfri store\/sm\u00e5-bokstav-sjekksum opp\u00e5 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 \u00e5 sende til.<\/p>

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\u00e5 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\u00f8rste er en skrivefeil; det andre er en forveksling, og det er forveksling nesten alle de store tapene handler om. Derfor gir det falsk trygghet \u00e5 stole blindt p\u00e5 at lommeboken sier fra: den sier bare fra n\u00e5r strengen er ugyldig, ikke n\u00e5r den er feil.<\/p>

Bitcoin har flere formater samtidig: eldre adresser som begynner med 1 eller 3, moderne SegWit-adresser som begynner med \u00abbc1q\u00bb, og Taproot-adresser som begynner med \u00abbc1p\u00bb. 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\u00e5r sin egen vei med Base58-kodede n\u00f8kler p\u00e5 32 til 44 tegn, uten \u00ab0x\u00bb og uten et eget sjekksum-lag av samme type. Resultatet er en verden der lengden, tegnsettet og feilkontrollen avhenger av hvilken kjede du st\u00e5r p\u00e5.<\/p>

Kjede<\/th>Typisk format<\/th>Lengde<\/th>Innebygd feilkontroll<\/th><\/tr><\/thead>
Ethereum og EVM-kjeder<\/td>0x + 40 heksadesimale tegn<\/td>42 tegn<\/td>EIP-55 valgfri store\/sm\u00e5-bokstav-sjekksum<\/td><\/tr>
Bitcoin (eldre)<\/td>Begynner med 1 eller 3 (Base58Check)<\/td>26 til 35 tegn<\/td>Base58Check-sjekksum<\/td><\/tr>
Bitcoin (SegWit\/Taproot)<\/td>bc1q (SegWit) eller bc1p (Taproot)<\/td>42 til 62 tegn<\/td>Bech32\/Bech32m, sterk feildeteksjon<\/td><\/tr>
Solana<\/td>Base58, ingen prefiks<\/td>32 til 44 tegn<\/td>Ingen separat sjekksum<\/td><\/tr><\/tbody><\/table>
Adresseformater varierer mellom kjeder i lengde, tegnsett og om de i det hele tatt fanger skrivefeil.<\/figcaption><\/figure>

Adresseforgiftning: angrepet som utnytter at du ikke leser<\/h2>

Fordi ingen leser 42 tegn n\u00f8ye, har tyvene bygget et helt angrep rundt antagelsen om at du ikke gj\u00f8r det. Adresseforgiftning (address poisoning) planter en adresse som ligner p\u00e5 en du bruker, i din egen transaksjonshistorikk. Neste gang du skal sende til \u00abden samme\u00bb mottakeren, kopierer du fra historikken, ser at de f\u00f8rste og siste tegnene stemmer, og limer inn tyvens adresse i stedet.<\/p>

Teknikken finnes i to hovedvarianter. Den ene er null-overf\u00f8ringer: mange token-kontrakter tillater at hvem som helst utl\u00f8ser en overf\u00f8ring p\u00e5 null tokens med en vilk\u00e5rlig avsender, slik at historikken din viser en utg\u00e5ende \u00abbetaling\u00bb du aldri gjorde, til en adresse som ligner p\u00e5 mottakerens. Den andre er forfalskede hendelser: en ondsinnet kontrakt sender ut Transfer-hendelser slik at utforskere og lommeb\u00f8ker viser en lookalike-adresse i loggen din. I begge tilfeller utnytter angriperen vanen med \u00e5 bekrefte bare de f\u00f8rste og siste tegnene, og lager en vanity-adresse som matcher nettopp dem (Chainalysis<\/a>).<\/p>

Omfanget er ikke marginalt. Sikkerhetsselskapet Blockaid har flagget over 65,4 millioner forgiftningstransaksjoner siden januar 2025, og fors\u00f8kene \u00f8kte fra 628 000 i november 2025 til 3,4 millioner i januar 2026, en femdobling p\u00e5 to m\u00e5neder. Av de 65,4 millionene var rundt 316 000 bekreftede angrep der offeret faktisk sendte penger, alts\u00e5 om lag ett av to hundre fors\u00f8k som lykkes (Blockaid<\/a>). Hvert vellykket fors\u00f8k kan v\u00e6re stort: i mai 2024 mistet en handler 1 155 wrapped bitcoin verdt rundt 68 millioner dollar til en forgiftet adresse, f\u00f8r angriperen uvanlig nok returnerte mesteparten (CoinDesk<\/a>). I en annen sak forsvant nesten 50 millioner dollar i USDT p\u00e5 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.<\/p>

Lommeb\u00f8ker og blokkutforskere har svart med \u00e5 endre standardvisningen: mange skjuler n\u00e5 null-overf\u00f8ringer, filtrerer bort \u00e5penbar spam og merker ukjente tokens som mistenkelige. Det hjelper, men det er et kappl\u00f8p. Angriperne tilpasser seg ved \u00e5 bruke bel\u00f8p som er sm\u00e5 nok til \u00e5 se ekte ut, men store nok til \u00e5 vises, og ved \u00e5 etterligne nettopp de tokenene offeret faktisk bruker. S\u00e5 lenge historikken er en offentlig, skrivbar logg som hvem som helst kan legge oppf\u00f8ringer i, er filtrering en demping, ikke en kur.<\/p>

Copy-paste-vanen og utklippstavle-kapring<\/h2>

Ingen holder 42 tilfeldige tegn i hodet, s\u00e5 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\u00e5ker det du kopierer og bytter ut en kryptoadresse med angriperens i det korte \u00f8yeblikket mellom kopier og lim inn. Du kopierer riktig adresse; du limer inn en annen.<\/p>

Dette er grunnen til at den utbredte vanen med \u00e5 sjekke \u00abde fire f\u00f8rste og fire siste tegnene\u00bb er svakere enn den f\u00f8les. En vanity-adresse som matcher akkurat de tegnene, er billig \u00e5 generere, og mellomtegnene er nettopp dem ingen leser. Resultatet er at verifisering i praksis ofte betyr \u00e5 bekrefte at angriperen gjorde jobben sin. Og n\u00e5r overf\u00f8ringen f\u00f8rst er sendt, er gjenvinning en forhandling, ikke en rettighet: akkurat som ved annet kryptotyveri finnes det ingen angreknapp, bare h\u00e5pet om at motparten frivillig sender tilbake (Nummeret ditt er n\u00f8kkelen<\/a>).<\/p>

Den eneste robuste l\u00f8sningen p\u00e5 dette niv\u00e5et er \u00e5 ikke stole p\u00e5 manuell lesing i det hele tatt: verifiser hele strengen maskinelt, eller unng\u00e5 \u00e5 taste og lime inn ved \u00e5 bruke navn, QR-koder eller lagrede kontakter. Alt dette finnes i 2026, men det er ujevnt fordelt og ofte skjult bak innstillinger folk aldri \u00e5pner.<\/p>

Lesbare navn: ENS, Basenames og .sol<\/h2>

Den mest intuitive l\u00f8sningen er \u00e5 erstatte strengen med et navn. Navnetjenester kobler et kort, lesbart navn til en adresse: Ethereum Name Service (\u00abalice.eth\u00bb), Basenames p\u00e5 Base (\u00abalice.base.eth\u00bb) og Solana Name Service (\u00abalice.sol\u00bb). Du sender til et navn du kan uttale og huske, og lommeboken sl\u00e5r det opp til den fulle adressen. For et menneske er \u00abalice.eth\u00bb uendelig mye lettere \u00e5 verifisere enn 42 tegn, og det er den retningen hele bransjen peker.<\/p>

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\u00e5 Ethereums hovedkjede. Begrunnelsen var en reduksjon i registreringskostnadene p\u00e5 rundt 99 prosent det siste \u00e5ret, kombinert med at Ethereum selv skalerer raskere enn ventet. If\u00f8lge grunnlegger og hovedutvikler Nick Johnson er kostnadsfordelen ved en egen L2 n\u00e5 \u00ablangt mindre overbevisende enn den pleide \u00e5 v\u00e6re\u00bb (CoinDesk<\/a>, Cointelegraph<\/a>). For brukere betyr det at identitetslaget blir billigere og mindre fragmentert, nettopp p\u00e5 et tidspunkt da navn trengs mest.<\/p>

Men navn fjerner ikke tilliten, de flytter den. Et navn kan forfalskes med homoglyfer, alts\u00e5 tegn som ser like ut (en \u00abl\u00bb mot en stor \u00abI\u00bb, eller bokstaver fra andre alfabeter), slik at \u00ab\u0430lice.eth\u00bb ser riktig ut, men peker et annet sted. Navn kan utl\u00f8pe og registreres p\u00e5 nytt av en fremmed. Og til slutt l\u00f8ser navnet uansett opp til en adresse du m\u00e5 stole p\u00e5 at oppslaget gir riktig. Navn gj\u00f8r verifisering menneskelig mulig, men de er et lag over problemet, ikke en oppheving av det.<\/p>

Det st\u00f8rste hinderet for navn er likevel at de enn\u00e5 ikke er standardveien. I de fleste send-skjermer m\u00e5 du fortsatt lime inn en r\u00e5 adresse med mindre du aktivt har satt opp et navn, og et navn koster penger \u00e5 registrere og m\u00e5 fornyes f\u00f8r det utl\u00f8per. 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\u00f8re adresser trygge, arver dermed sine egne frister og fallgruver.<\/p>

N\u00e5r lommeboken skjuler adressen helt<\/h2>

Den mest radikale tiln\u00e6rmingen er \u00e5 fjerne adressen fra synsfeltet helt. Innebygde og \u00abusynlige\u00bb lommeb\u00f8ker, b\u00f8lgen som akselererte da Stripe kj\u00f8pte Privy i 2025 og store akt\u00f8rer 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<\/a>). For en nykommer som aldri vil se \u00ab0x\u00bb, er dette en \u00e5penbar forbedring.<\/p>

Prisen er at verifiseringen flytter seg til et sted du ikke kan se. N\u00e5r du aldri m\u00f8ter adressen, stoler du implisitt p\u00e5 appens adressebok og oppslag. Viser appen feil kobling, enten ved feil eller fordi den er kompromittert, finnes det ingen r\u00e5 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\u00e5 bel\u00f8p og dagligdagse betalinger, og en d\u00e5rlig en for en overf\u00f8ring som utgj\u00f8r sparepengene dine.<\/p>

Dette er den samme spenningen som l\u00f8per gjennom hele lommebok-UX i 2026: hver forenkling som fjerner en skummel detalj, flytter ogs\u00e5 et ansvar brukeren pleide \u00e5 ha, over til en tjeneste brukeren m\u00e5 stole p\u00e5. Adressefeltet er bare det stedet der avveiningen er mest uforsonlig, fordi feilen er endelig.<\/p>

Bitcoin tar en annen vei: BIP-353 og Lightning-adresser<\/h2>

Bitcoin-milj\u00f8et har angrepet det samme problemet, men med en annen filosofi. Her er m\u00e5let \u00e5 unng\u00e5 gjenbruk av adresser (av personvernhensyn) samtidig som betalingsm\u00e5let gj\u00f8res lesbart. Lightning-adresser ser ut som en e-post, \u00abbruker@domene\u00bb, og l\u00f8ses opp via protokollen til en faktisk faktura; de har gjort Lightning-betalinger nesten like enkle som \u00e5 sende penger i en bankapp.<\/p>

Et skritt videre st\u00e5r BIP-353<\/a>, som legger betalingsinstruksjoner i DNS. En adresse p\u00e5 formen \u00ab\u20bfbruker@domene\u00bb sl\u00e5s 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 \u00e9n statisk, delbar adresse generere en fersk on-chain-adresse per betaling uten at partene m\u00e5 snakke sammen, peker Bitcoin mot en verden der du deler et navn, ikke en streng, og likevel f\u00e5r en ny adresse hver gang. Ogs\u00e5 dette hviler til slutt p\u00e5 tillit til et domene og en DNS-kjede, men det er en tillit som er lettere \u00e5 resonnere om enn 62 tilfeldige tegn.<\/p>

Feil kjede: n\u00e5r adressen finnes p\u00e5 ti nettverk<\/h2>

Det finnes en feil som er s\u00e6regen for EVM-verdenen, og som rammer selv folk som verifiserer adressen helt riktig. Fordi den samme 0x-adressen er gyldig p\u00e5 Ethereum, Base, Arbitrum, Polygon, BNB Chain og alle de andre, kan du sende til helt riktig adresse p\u00e5 feil kjede. Da havner midlene p\u00e5 en adresse du kontrollerer, men p\u00e5 et nettverk der mottakeren, ofte en b\u00f8rs, ikke krediterer dem, eller der du mangler n\u00f8kkeloppsettet for \u00e5 hente dem ut. Teknisk sett er pengene ikke borte; i praksis kan de v\u00e6re like utilgjengelige.<\/p>

Standardforslaget EIP-3770<\/a> pr\u00f8ver \u00e5 b\u00f8te p\u00e5 dette ved \u00e5 sette et lesbart kjede-prefiks foran adressen, for eksempel \u00abbase:0x…\u00bb eller \u00abeth:0x…\u00bb, slik at det blir umulig \u00e5 forveksle hvilket nettverk som gjelder. Parallelt jobber bransjen med chain abstraction, der lommeboken selv velger kjede slik at brukeren slipper, p\u00e5 samme m\u00e5te som en nettleser ikke sp\u00f8r hvilken server et domene bor p\u00e5. Fordelen er \u00e5penbar; ulempen er den samme som med usynlige adresser, at ansvaret for et valg med endelige konsekvenser flyttes inn i programvare du m\u00e5 stole p\u00e5. Kryssing mellom kjeder er dessuten der mye verdi strandet og ble angrepet i 2026, noe vi har dokumentert i egen broanalyse (N\u00e5r de nyeste broene brister<\/a>).<\/p>

Et vanlig eksempel er innskudd til en b\u00f8rs. Du har en adresse b\u00f8rsen ga deg for USDC p\u00e5 Ethereum, men sender USDC p\u00e5 Arbitrum til den samme strengen. Pengene lander p\u00e5 en adresse b\u00f8rsen eier, men systemet krediterer deg ikke automatisk, fordi det ventet midler p\u00e5 en annen kjede. I beste fall finnes en manuell gjenvinningsprosess mot et gebyr; i verste fall er midlene utenfor rekkevidde. Nettopp fordi adressen s\u00e5 helt riktig ut, f\u00f8les feilen urettferdig: alt du gjorde galt, var \u00e5 velge feil nettverk i en nedtrekksmeny.<\/p>

QR-koder og betalingsforesp\u00f8rsler<\/h2>

En QR-kode er i praksis en tryggere lim-inn. Du skanner i stedet for \u00e5 taste, og fjerner dermed b\u00e5de manuelle skrivefeil og det meste av risikoen for utklippstavle-kapring. Under overflaten koder QR-koden ofte en betalingsforesp\u00f8rsel etter standarden EIP-681<\/a> for Ethereum, som kan inneholde b\u00e5de adresse, bel\u00f8p og kjede i \u00e9n streng; Bitcoin har sin egen \u00abbitcoin:\u00bb-URI med samme id\u00e9. N\u00e5r mottakeren genererer foresp\u00f8rselen, flyttes byrden bort fra avsenderens tastatur.<\/p>

QR-koder har likevel sine egne angrep. En fysisk klistrelapp kan byttes ut p\u00e5 et utsalgssted, en kode delt som bilde kan v\u00e6re manipulert, og en skjerm du skanner kan vise en annen adresse enn du tror. Skanning l\u00f8ser transkripsjonsproblemet, ikke intensjonsproblemet: koden overf\u00f8rer tegnene korrekt, men den garanterer ikke at tegnene tilh\u00f8rer den du vil betale. QR er et stort steg opp fra manuell inntasting, men det er fortsatt bare s\u00e5 trygt som kilden til koden.<\/p>

Stealth-adresser: personvern mot adressebok<\/h2>

Mens navn og kontakter trekker i retning av stabile, gjenkjennelige m\u00e5l, trekker personvern i stikk motsatt retning. Stealth-adresser, standardisert som ERC-5564<\/a>, lar avsenderen utlede en fersk engangsadresse for mottakeren ut fra en publisert \u00abmeta-adresse\u00bb, slik at betalingene ikke kan knyttes til \u00e9n offentlig adresse. Mottakeren finner pengene ved \u00e5 skanne kjeden med en egen visningsn\u00f8kkel. Vitalik Buterin, som var med p\u00e5 \u00e5 utforme standarden, har beskrevet stealth-adresser som en sentral personvernprimitiv for Ethereum, men har samtidig v\u00e6rt tydelig p\u00e5 at de b\u00e6rer en reell brukskostnad: mottakeren m\u00e5 skanne etter innbetalinger, og en helt fersk adresse kommer uten ETH til \u00e5 betale gass med (vitalik.eth.limo<\/a>).<\/p>

Her ligger en motsetning 2026 ikke har l\u00f8st. Personvern vil ha adresser som er ferske, uforutsigbare og umulige \u00e5 knytte sammen; adressebok-UX vil ha m\u00e5l som er stabile, lesbare og lette \u00e5 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\u00e5lene er ikke uforenlige for alltid, men ingen har forel\u00f8pig levert en opplevelse som gir begge deler p\u00e5 samme tid for vanlige brukere.<\/p>

\u00c5 signere mottakeren: clear signing og simulering<\/h2>

Siste skanse f\u00f8r pengene flytter seg er signeringsskjermen, og her har 2026 gjort reelle fremskritt, men ikke n\u00f8dvendigvis mot adresseproblemet. Transaksjonssimulering viser nettoeffekten av det du er i ferd med \u00e5 godkjenne (\u00abdu sender 1 ETH, du mottar 0\u00bb), og fanger mange svindelfors\u00f8k. Men en simulering viser virkningen, ikke om mottakeradressen er den du mente. En simulert overf\u00f8ring til en forgiftet adresse ser helt normal ut, fordi den faktisk er en helt vanlig overf\u00f8ring, bare til feil sted.<\/p>

Clear signing, formalisert i standarden ERC-7730 som Ledger startet og Ethereum Foundation overtok forvalterskapet for i mai 2026, gj\u00f8r nyttelasten lesbar: i stedet for en r\u00e5 streng ser du \u00abdu sender X til Y\u00bb, gjerne med en kjent etikett p\u00e5 mottakerkontrakten. Ledgers teknologidirekt\u00f8r Charles Guillemet har v\u00e6rt en av de skarpeste kritikerne av alternativet, blindsignering, der du godkjenner noe som \u00abikke er forst\u00e5elig i seg selv. Det er en digital nyttelast\u00bb (Investing.com<\/a>). Poenget er sterkt, men det l\u00f8ser forst\u00e5elsen av nyttelasten, ikke riktigheten av m\u00e5let. Clear signing viser deg trofast adressen du selv matet inn; ble du forgiftet lenger oppstr\u00f8ms, viser den deg trofast feil adresse.<\/p>

Clear signing har dessuten en forutsetning: lommeboken m\u00e5 vite hva kontrakten gj\u00f8r. ERC-7730 fungerer ved at prosjekter leverer beskrivelsesfiler som oversetter r\u00e5 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\u00f8rste m\u00f8tet med noe upr\u00f8vd. Lesbarhet er alts\u00e5 ikke en egenskap ved kjeden, men noe som m\u00e5 vedlikeholdes kontrakt for kontrakt.<\/p>

Metode for \u00e5 oppgi mottaker<\/th>Hva det beskytter mot<\/th>Gjenst\u00e5ende risiko<\/th><\/tr><\/thead>
Manuell inntasting av hele strengen<\/td>Utklippstavle-kapring<\/td>Skrivefeil; umulig \u00e5 kontrollere for mennesker<\/td><\/tr>
Lim inn fra utklippstavle<\/td>Skrivefeil ved tasting<\/td>Utklippstavle-kapring; forgiftet historikk<\/td><\/tr>
Sjekk av fire f\u00f8rste og fire siste tegn<\/td>Grove feilkopieringer<\/td>Vanity-adresser som matcher nettopp de tegnene<\/td><\/tr>
QR-skanning<\/td>Skrivefeil og utklippstavle-kapring<\/td>Byttet eller manipulert kode<\/td><\/tr>
Navn (ENS, Basenames, .sol)<\/td>Uleselige strenger<\/td>Homoglyfer; tillit til oppslaget<\/td><\/tr>
Lagret kontakt eller hviteliste<\/td>Gjentatt bruk av samme mottaker<\/td>F\u00f8rstegangs-oppf\u00f8ringen m\u00e5 v\u00e6re riktig<\/td><\/tr>
B\u00f8rs-hviteliste med tidsforsinkelse<\/td>Store, forhastede uttak<\/td>Intern kompromittering av kontoen<\/td><\/tr><\/tbody><\/table>
Metodene rangert fra minst til mest robust; ingen fjerner behovet for \u00e5 verifisere f\u00f8rstegangsmottakeren.<\/figcaption><\/figure>

B\u00f8rsen, hvitelister og reiseregelen<\/h2>

B\u00f8rsene har l\u00f8st en del av adresseproblemet med hvitelisting av uttaksadresser. Du registrerer gyldige mottakeradresser p\u00e5 forh\u00e5nd, ofte med en tidsforsinkelse f\u00f8r en nyregistrert adresse kan brukes, slik at en angriper som kommer seg inn p\u00e5 kontoen, ikke umiddelbart kan sende til en fersk adresse. Det er en treghet som er bevisst lagt inn akkurat der innsatsen er h\u00f8yest, og den fungerer, som forvaringsakt\u00f8rer har bygget hele forretningsmodeller rundt (Forvareren som ble bank<\/a>).<\/p>

Det regulatoriske laget som ber\u00f8rer adressen mest direkte, er reiseregelen. I EU og E\u00d8S er dette TFR II, forordning (EU) 2023\/1113, som gjelder sammen med MiCA. Den p\u00e5legger tilbydere av kryptoaktivatjenester (CASP-er) \u00e5 la informasjon om b\u00e5de avsender og mottaker f\u00f8lge en overf\u00f8ring, inkludert DLT-adressen og navn, adresse og identifikasjon. For overf\u00f8ringer til og fra selvforvarte (unhosted) lommeb\u00f8ker over terskelverdier m\u00e5 CASP-en samle inn og kontrollere hvem som st\u00e5r bak adressen (CryptoSlate<\/a>).<\/p>

For brukeren merkes reiseregelen som nye sp\u00f8rsm\u00e5l i uttaksflyten: b\u00f8rsen kan be deg oppgi hvem mottakeren er, om adressen tilh\u00f8rer deg selv eller en tredjepart, og i noen tilfeller be om en bekreftelse p\u00e5 at du kontrollerer en selvforvart adresse. Det f\u00f8les som friksjon, og det er det, men det er friksjon plassert nettopp der en overf\u00f8ring forlater det regulerte systemet. For personvernet betyr det at pseudonymiteten til en adresse kollapser i det \u00f8yeblikket den knyttes til en identifisert konto.<\/p>

For Norge tas disse pliktene inn via E\u00d8S-avtalen; regjeringen har sendt p\u00e5 h\u00f8ring de forventede E\u00d8S-forpliktelsene som svarer til b\u00e5de MiCA og TFR II (regjeringen.no<\/a>). Finanstilsynet f\u00f8rer 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 \u00f8yeblikket den m\u00f8ter en b\u00f8rs, kobles en identitet til den.<\/p>

Skattemessig er adressen i ferd med \u00e5 bli et rapporteringsh\u00e5ndtak. Rapporteringsregelverket CARF tr\u00e5dte i kraft i Norge 1. januar 2026, og tjenestetilbydere skal rapportere kryptoeiendeler til Skatteetaten fra 2027 (Skatteetaten<\/a>). Hver realisasjon er skattepliktig med 22 prosent p\u00e5 gevinst, og beholdningen f\u00f8res 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 \u00e5 ha sendt dem til en fremmed. Det understreker poenget: mottakerfeltet er det ene stedet der verken kode, b\u00f8rs eller stat kommer deg til unnsetning.<\/p>

Hva som faktisk fikser det<\/h2>

Det finnes ingen enkeltknapp som l\u00f8ser adresseproblemet, men det finnes et lagvis forsvar som fjerner de fleste m\u00e5tene det g\u00e5r galt p\u00e5. De store lommeb\u00f8kene har begynt \u00e5 bygge deler av det inn: MetaMask og andre varsler n\u00e5 aktivt om adresseforgiftning i det du limer inn (MetaMask<\/a>). Resten er vaner.<\/p>