MiCA avkodet: Kryptohvitboken din kan ikke bare være en Gitbook eller PDF

MiCA Decoded er en ukentlig serie på 12 artikler for Bitcoin.com News, medforfattet av LegalBisons medgründere og administrerende direktører: Aaron Glauberman, Viktor Juskin og Sabir Alijev. LegalBison rådgir krypto- og FinTech-selskaper om MiCA-lisensiering, CASP- og VASP-søknader, samt regulatorisk strukturering i Europa og utover.

Under MiCA er et white paper et obligatorisk juridisk opplysningsinstrument. Den nærmeste analogien i tradisjonell finans er et verdipapirprospekt, ikke et markedsføringsdokument. Forordningen angir hvem som må utarbeide et, i hvilket format, med hvilke identifikatorer, underlagt hvilken automatisert validering, og med ansvar knyttet til en bestemt navngitt person.

Å få noen av disse elementene feil betyr at dokumentet ikke eksisterer i europeiske regulatorers øyne, uansett hvor godt skrevet det er.

Denne sjette delen av MiCA Decoded pakker ut hva det faktisk betyr, bit for bit.

Myten: Et MiCA-white paper er bare en GitBook eller en PDF

Et MiCA-white paper har tyngden av en formell regulatorisk innlevering.

Kommisjonens gjennomføringsforordning (EU) 2024/2984, som regulerer skjemaer, formater og maler for white papers for kryptoaktiva, krever at dokumentet utarbeides i et strukturert digitalt format utformet slik at ESMA og nasjonale kompetente myndigheter i alle EU-medlemsstater kan kjøre identisk automatisert analyse på hver innsendelse, uavhengig av hvem som har levert den eller hvor.

Det juridiske formålet med dette designvalget betyr mer enn de tekniske detaljene. MiCA er en regulering for det indre markedet, og sammenlignbarhet på tvers av innleveringer er et sentralt håndhevingsverktøy.

Et white paper som ikke kan leses av den samme maskinen som alle andre white papers som leveres i Europa, er ikke i samsvar, uansett hva innholdet sier. ESMA publiserte den påkrevede taksonomien (det strukturerte rammeverket som definerer hva et white paper i samsvar må inneholde) 5. august 2025. Reglene gjelder fra 23. desember 2025.

Opplysningspliktene varierer avhengig av typen kryptoaktivum som er involvert. MiCA trekker opp tre ulike kategorier, hver med sin egen white paper-mal og feltkrav:

Kategorien avgjør ikke bare innholdet i white paper, men hele den juridiske veien til å levere et. Et prosjekt kan ikke velge hvilken kategori som gjelder basert på preferanse. Aktivets kjennetegn avgjør det, og utarbeidelsespliktene følger derfra.

Hvem bærer den juridiske forpliktelsen – og ansvaret

For det store flertallet av tokens i markedet (kategorisert som «Other» kryptoaktiva, eller OTHR), faller forpliktelsen ikke automatisk på enheten som skapte tokenet. For disse aktivene legger MiCA forpliktelsen på tilbyderen eller personen som søker opptak til handel, som er definerte roller som kan sammenfalle – eller ikke – med den opprinnelige utstederen.

Dette skillet har reelle konsekvenser. Et prosjekt som faller inn under OTHR-kategorien, lansert fra De britiske Jomfruøyene, Caymanøyene eller en annen offshore-jurisdiksjon, kan være tilbyderen under MiCA og bære white paper-forpliktelsen direkte, uten krav om å flytte sitt juridiske sete til Europa.

(Merk: Denne strukturelle fleksibiliteten gjelder strengt for OTHR-tokens. For Asset-Referenced Tokens og E-Money Tokens ligger den juridiske forpliktelsen og det strenge sivilrettslige ansvaret for white paper utelukkende hos den autoriserte EU-utstederen og kan ikke delegeres).

Som vi undersøkte i den andre delen av denne serien, bekrefter ESMA-registrene at dette allerede er standard praksis: flertallet av uavhengige token-innleveringer kommer fra enheter med hovedkontor utenfor EU.

En CASP som driver en handelsplattform kan også påta seg white paper-forpliktelsen, enten på eget initiativ eller gjennom skriftlig avtale med prosjektteamet. Det er ikke et smutthull eller en administrativ bekvemmelighet.

Når en CASP leverer, påtar den seg juridisk ansvar for nøyaktigheten og fullstendigheten i opplysningene. Hvis white paper inneholder villedende informasjon eller ikke oppfyller regulatoriske standarder, tilhører ansvaret den som leverte det.

Personen som signerer white paper kan ikke delegere denne eksponeringen til en programvareleverandør, en teknisk integrator eller et advokatfirma. Juridisk gjennomgang av innhold og teknisk gyldighet er to separate etterlevelsesforpliktelser, og begge hviler på tilbyderen. Dette er punktet de fleste prosjekter undervurderer.

To koder som må eksistere før innlevering begynner

To obligatoriske identifikatorer er forutsetninger for ethvert white paper i samsvar. Begge er hentet fra internasjonale standarder som er eldre enn MiCA. Forordningen skapte dem ikke; den gjorde dem obligatoriske.

Den første er Legal Entity Identifier (LEI), en ISO 17442-kode tildelt juridiske enheter og vedlikeholdt i den globale LEI-databasen administrert av GLEIF. Mandatet for bruken spenner over flere regulatoriske standarder: mens artikkel 14 i RTS for journalføring (Kommisjonens delegerte forordning (EU) 2025/1140) håndhever LEI-krav på CASP-er for deres kunder, pålegger artikkel 3 i RTS for klassifisering av white paper (Kommisjonens delegerte forordning (EU) 2025/421) strengt at alle som utarbeider white paper må identifisere sin egen juridiske enhet med en gyldig LEI-kode. For enhver enhet som ikke allerede har en, må LEI-søknadsprosessen fullføres før utarbeidelsen av white paper begynner.

Den andre er Digital Token Identifier (DTI), en ISO 24165-kode som identifiserer selve kryptoaktivaet, vedlikeholdt i DTIF-registeret. Artikkel 15 i RTS for journalføring og artikkel 3 i RTS for klassifisering av white paper (Kommisjonens delegerte forordning (EU) 2025/421) krever bruken. Det avgjørende poenget for ethvert prosjekt som lanserer et nytt token: hvis DTI ennå ikke finnes i registeret, må noen be om at det opprettes før white paper kan leveres. Der en CASP leverer for et aktivum uten sentralisert utsteder og uten eksisterende white paper, er plattformen ansvarlig for å hente eller be om DTI direkte fra DTIF.

Kilde: DTIF-registeret for kryptoaktiva

Et white paper som ikke inneholder en gyldig LEI og DTI, feiler automatisert validering før noen menneskelig saksbehandler ser det. Prosjekter som når innleveringsstadiet uten begge kodene på plass, møter en full omstart.

Den automatiserte porten og hva den betyr juridisk

Ingen person hos en nasjonal kompetent myndighet vurderer et white paper som feiler sine automatiserte kontroller. ESMA-taksonomien definerer 257 eksistenskontroller (verifiserer at påkrevde felter er til stede) og 223 verdikontroller (verifiserer at feltinnholdet er gyldig). En innlevering som feiler en kontroll med alvorlighetsgrad «Error», er teknisk ugyldig. Dokumentet går ikke videre.

Den juridiske implikasjonen av denne arkitekturen er direkte: teknisk gyldighet og innholdsmessig nøyaktighet er like mye tilbyderens ansvar. En perfekt utformet juridisk opplysning i feil struktur feiler. En strukturelt gyldig fil med villedende innhold feiler også; den feiler bare på et annet stadium og med andre konsekvenser.

Prosjekter som tilbyr tokens i flere EU-medlemsstater, møter et ekstra lag. Hver språkversjon av white paper krever sin egen separat strukturerte fil. Alle språkversjoner må være internt konsistente og ikke bare oversatt, men identisk organisert på feltnivå. En oversettelse som ikke speiler strukturen i originalen, er teknisk ikke i samsvar, uansett språklig korrekthet.

Bærekraftsopplysninger legger til en ytterligere begrensning. Taksonomien pålegger spesifikke måleenheter for energiforbruk og CO2-utslipp: henholdsvis kWh og tCO2. Dette er juridiske opplysningskrav, ikke valgfri miljørapportering. Innlevering med andre enheter eller utelatelse av feltene utløser valideringsfeil.

Mønsteret på tvers av alle disse kravene er det samme: white paper er en juridisk innlevering med maskinhåndhevede standarder. Prosjekter som behandler det som en dokument-skriveøvelse, snarere enn en etterlevelsesprosess med strukturerte forutsetninger og automatisert portvokting, vil møte håndhevelsen før de når en menneskelig regulator.

Hva dette betyr i praksis

Den populære forståelsen av et krypto-white paper som en narrativ pitch (noe skrevet for å overbevise snarere enn å opplyse) beskriver en dokumenttype som MiCA har erstattet med noe kategorisk annerledes.

MiCA-white paper er et juridisk instrument med foreskrevet innhold, obligatoriske identifikatorer, et strukturert format designet for automatisert grensekryssende sammenlignbarhet, og navngitt personlig ansvar knyttet til den som godkjenner det med sin signatur. Inngangsporten til det europeiske kryptomarkedet går gjennom det. Prosjekter som forstår innleveringen for hva den juridisk er, snarere enn hva begrepet historisk har antydet, er de som ikke blir sendt tilbake ved den automatiserte kontrollen.

Viktige punkter:

• White paper er ikke et markedsføringsdokument. MiCA omdefinerte begrepet. Den nærmeste ekvivalenten i tradisjonell finans er et verdipapirprospekt, og det bør behandles med samme juridiske tyngde.
• Tre aktivakategorier, tre ulike løp. OTHR, ART og EMT har hver sine særskilte white paper-krav og ulike autorisasjonsforutsetninger. Aktivets kjennetegn avgjør hvilken kategori som gjelder; prosjektet velger ikke.
• Ansvar følger den som leverer, men reglene avhenger av aktivet. For det store flertallet av tokens (OTHR-er) tilhører den juridiske forpliktelsen tilbyderen eller personen som søker opptak til handel, ikke nødvendigvis tokenets opprinnelige skaper. Når en CASP (som en operatør av en handelsplattform) går med på å utarbeide og publisere et white paper på vegne av et OTHR-prosjekt, påtar den seg betydelige regulatoriske plikter, men den overtar ikke ansvaret fullt ut. Etter MiCA artikkel 14(3) forblir den opprinnelige personen som søker opptak til handel juridisk ansvarlig dersom de gir ufullstendig, urimelig, uklar eller villedende informasjon til CASP-en. Du kan sette bort papirarbeidet, men du kan ikke fullt ut sette bort ansvaret.
• For Asset-Referenced Tokens (ART-er) og E-Money Tokens (EMT-er) hviler ikke strengt sivilrettslig ansvar for white paper utelukkende på den autoriserte utstederen som juridisk enhet; det utvides uttrykkelig til medlemmene av dens administrative, ledelses- eller tilsynsorgan. Ethvert kontraktsforsøk på å begrense eller utelukke dette ansvaret er juridisk ugyldig.
• LEI og DTI er forutsetninger. Begge identifikatorene må være på plass før utarbeidelsen av white paper begynner. Hvis en DTI ikke eksisterer for aktivet, må den forespørres fra DTIF-registeret før noe annet går videre.
• Automatisert validering er den første portvokteren. 257 eksistenskontroller og 223 verdikontroller kjøres før noen person vurderer filen. Et dokument som feiler en påstand på Error-nivå, når ikke en regulator.
• Flerspråklige innleveringer har en skjult teknisk forpliktelse. Hver språkversjon krever sin egen separat strukturerte fil, organisert identisk med originalen. En oversettelse som ikke samsvarer med kildestrukturen på feltnivå, er ikke i samsvar.
• Innholdsnøyaktighet og teknisk gyldighet er to separate forpliktelser. Juridisk gjennomgang dekker den første. Teknisk strukturering dekker den andre. Begge hviler på tilbyderen, og ingen av dem erstatter den andre.

Denne artikkelen er basert på en studie gjennomført av LegalBison i april 2026. Innholdet er kun til informasjonsformål og utgjør ikke juridisk rådgivning.