Føring av migrering

Med jevne mellomrom hender det at kryptovaluta ender navn. Enten som en ren rebranding uten teknologiske endringer (RNDR til RENDER), samtidig med endring av underliggende teknologi (MATIC til POL), eller det kan være ulike varianter der flere prosjekter slår seg sammen til en felles valuta (OCEAN og AGIX til FET).

I denne sammenheng betyr teknologisk endring enten bytte av kontraktsadresse (ERC20 til ERC20) på eksisterende blokkjede, eller bytte til en annen blokkjede (ERC20 til SPL).

Dette krever ofte at det gjøres endring på importerte transaksjoner eller at det må legges til manuelle transaksjoner for at skatteberegningen skal bli riktig. Nøyaktig fremgangsmåte kan variere avhengig av hva slags migrering det er snakk om, men også hvilken børs du har brukt. Noen børser rapporterer dette på en ryddig måte, mens andre har en delvis eller ingen rapportering.

Det er en realisasjon

Skattemessig vil en migrering i de fleste tilfeller være å anse som realisasjon av den gamle valutaen. Det betyr at den selges, eventuell oppgang eller nedgang i kurs fra da du kjøpt vil gi skattemessig gevinst eller tap. Rent praktisk er dette også den enkleste måten å føre det på.

I tilfeller der det er en ren rebranding kan det argumenteres for at det ikke er en realisasjon. Dette skriver vi om litt avslutningsvis.

Automatisk håndtering i Kryptosekken ved import

Som utgangspunkt, men avhengig av hva/hvordan børsene rapporterer, vil Kryptosekken forsøke å føre alle navneendringer som en Handel fra den gamle til den nye valutaen. Dette gjelder uavhengig om det er rebranding eller en teknologisk endring. Dersom rapportering ikke gjør det mulig å føre som handel, vil vi forsøke å føre den nye valutaen som Inntekt primært og Erverv sekundært. Den gamle valutaen vil føres som Tap. I noen tilfeller kan det være vi kun fører enten Inntekt/Erverv eller Tap, eller ingen av delene.

Er det kun en endring av teknologi uten endring av navn/valuta kode vil det som hovedregel ikke legges til transaksjoner automatisk ved import.

Eksempler på føring

2024 har vært et godt år og gitt oss flere gode eksempler på flere ulike varianter av migrering. Under går vi igjennom flere eksempler på føring fra flere forskjellige børser. Vi anbefaler at du leser igjennom alle eksemplene da detaljer ikke vil bli gjentatt på sammenfallende eksempler.

Binance: fra RNDR til RENDER

For å si det forsiktig og unødvendig diplomatisk; Binance har generelt langt fra en optimal transaksjonshistorikk. Dette ser vi et tydelig resultat av når det gjelder migrering. Med API-import vil du få den nye kryptoen som Erverv. Tapet av den gamle får du ved import av API-hjelp (CSV-import).

I tilfellet med Render vil det etter import vil det i transaksjonslisten se slik ut:

Dette er skattemessig feil. Som minimum må Erverv endres til Inntekt. Den mest riktige løsningen er å endre dette til å være en handel som vist under

I tilfellet med Render er antallet av RNDR du gir fra deg likt antallet RENDER du mottar, det er en 1:1 swap/migrering. Den enkleste måten å gjøre endringen på er først å slette Taps-transaksjonen. Ervervs-transakasjonen må redigeres og endres til Handel. Feltet for kjøp vil da være riktig utfylt med det antall RENDER du kjøper og du trenger kun legge til RNDR i feltet for slag. Antallet kopierer du fra kjøps-feltet siden dette er en 1:1 migrering.

Binance: fra AGIX til FET

Som med Render er det ikke ikke optimalt skattemessig og må gjøres om til en Handel.

Her er det viktig å merke seg at migreringen ikke er 1:1, men at det er en avvikende vekting. 1384 AGIX gir 599 FET. Her bør du ikke slette Taps-transaksjonen før du har kopiert det nøyaktige antallet av AGIX du gir fra deg - med alle desimaler. Når du kopierer antallet må du gjøre det fra redigeringsvisning av transaksjonen. I selve transaksjonslisten kan det være desimaler som er skjult, avhengig av hvilke innstillinger du har satt.

Binance: fra MATIC til POL

Dette er en ren repetisjon av RNDR til RENDER. Migreringen er 1:1.

Transaksjonene over må endres til en Handel som vist under:

Firi: fra MATIC til POL

Datakvaliteten hos Firi er heldigvis bedre enn hos Binance. Det gjør at vi via API-import kan legge til transaksjonen for konvertering fra MATIC til POL helt automatisk. Dersom du bruker CSV-import fra Firi må dette føres helt manuelt. Om du kun hadde Polygon på Firi trenger du ikke gjøre manuelle endringer.

Bitpanda: fra MATIC til POL (og andre krypto)

Bitpanda er et av mange eksempler på børser som ikke loggfører migrering i det hele tatt. Her må du selv finne ut hvor mange MATIC du hadde på tidspunktet for migrering. Det må du føre som en Handel tilsvarende eksemplene over.

Føring uten realisasjon

I tilfellet med Render og AGIX er det ingen tvil om at det er en skattemessig realisasjon (i følge skatteetaten). Kontraktsadressen eller blokkjeden endres, og du får en helt ny token på en annen teknologisk plattform.

For Polygon er dermed situasjonen noe mer kompleks. Polygon finnes både native på en egen blokkjede og som en token på Ethereum. Ved migrering var det en endring av kontrakt på Ethereum - mens det på native blokkjede kun var en ren rebranding med endring av valutakode. Avhengig av hvor du har hatt midler vil det derfor enten være en soleklar realisasjon eller ingen realisasjon. Om du har midlene på børs er det mer uklart. Svaret på om det var en realisasjon vil kanskje ikke være klart før (og om) du overfører kryptoen ut fra børsen. Sender du til Ethereum vil det være en realisasjon, sender du til native vil det ikke være realisasjon.

Hva fasiten er, om den i det hele tatt finnes, skal ikke vi spekulere i. Dersom du ønsker å føre en ren navneendring uten skattemessig konsekvens har vi en oppskrift på det i FAQ under overskriften Hvordan gjør jeg VEN/VET-konverteringen. Overskriften Tap uten fradrag og Kjøp til gammel inngangsverdi beskriver fremgangsmåten for å føre swappen uten verken gevinst eller tap.