MiCA Naipaliwanag: Ang Iyong Crypto White Paper ay Hindi Puwedeng Basta Gitbook o PDF Lang

Ang MiCA Decoded ay isang 12-artikulong lingguhang serye para sa Bitcoin.com News, na sinulat kasama ng mga Co-Founding at Managing Directors ng LegalBison: Aaron Glauberman, Viktor Juskin at Sabir Alijev. Pinapayuhan ng LegalBison ang mga crypto at FinTech na kumpanya ukol sa MiCA licensing, mga aplikasyon ng CASP at VASP, at regulatory structuring sa buong Europa at higit pa.

Sa ilalim ng MiCA, ang white paper ay isang sapilitang legal na instrumento ng pagsisiwalat. Ang pinakamalapit na katumbas nito sa tradisyunal na pananalapi ay isang securities prospectus, hindi isang marketing document. Itinatakda ng regulasyon kung sino ang kailangang maghanda nito, sa anong pormat, na naglalaman ng aling mga identifier, napapailalim sa anong automated na validation, at may pananagutang nakaangkla sa isang partikular na pinangalanang tao.

Kapag nagkamali sa alinman sa mga elementong iyon, hindi umiiral ang dokumento sa paningin ng mga European regulator, gaano man ito kaganda ang pagkakasulat.

Ang ikaanim na installment ng MiCA Decoded na ito ay hinahimay kung ano talaga ang ibig sabihin nito, piraso-piraso.

Ang Mito: Ang MiCA White Paper ay Basta GitBook o PDF Lang

Ang MiCA white paper ay may bigat ng isang pormal na regulatory filing.

Ang Commission Implementing Regulation (EU) 2024/2984, na namamahala sa mga porma, pormat, at template para sa mga crypto-asset white paper, ay nangangailangan na ang dokumento ay ihanda sa isang structured digital format na idinisenyo upang ang ESMA at ang mga national competent authority sa lahat ng EU member states ay makapagpatakbo ng parehong automated na pagsusuri sa bawat isinusumiteng file, kahit sino pa ang nagsumite nito o saan man ito isinampa.

Mas mahalaga ang legal na layunin ng disenyo kaysa sa mga teknikal na detalye. Ang MiCA ay isang single-market regulation, at ang pagiging maihahambing sa mga filing ay pangunahing kasangkapan sa pagpapatupad.

Ang white paper na hindi mababasa ng kaparehong makina gaya ng bawat iba pang white paper na isinampa sa Europa ay hindi compliant, anuman ang sinasabi ng nilalaman nito. Inilathala ng ESMA ang kinakailangang taxonomy (ang structured framework na nagtatakda kung ano ang dapat lamanin ng isang compliant na white paper) noong 5 Agosto 2025. Umiiral ang mga patakaran simula 23 Disyembre 2025.

Nag-iiba-iba ang mga obligasyon sa pagsisiwalat depende sa uri ng crypto-asset na sangkot. Nagtatakda ang MiCA ng tatlong magkakaibang kategorya, at bawat isa ay may sariling template ng white paper at mga kinakailangan sa field:

Ang kategorya ang nagtatakda hindi lang ng nilalaman ng white paper, kundi ng buong legal na landas para makapaghain nito. Hindi maaaring pumili ang isang proyekto kung aling kategorya ang naaangkop batay sa kagustuhan. Ang mga katangian ng asset ang magtatakda nito, at mula roon susunod ang mga obligasyon sa paghahanda.

Sino ang may Dalang Legal na Obligasyon — at ang Pananagutan

Para sa napakaraming token sa merkado (na ikinategorya bilang “Other” crypto-assets, o OTHR), ang obligasyon ay hindi awtomatikong napupunta sa entity na lumikha ng token. Para sa mga asset na ito, inilalagay ng MiCA ang obligasyon sa offeror o sa taong naghahanap ng admission sa trading, na mga tinukoy na papel na maaaring magtugma o hindi sa orihinal na issuer.

May tunay na epekto ang pagkakaibang ito. Ang isang proyektong nasa OTHR na kategorya, na inilunsad mula sa British Virgin Islands, Caymans, o anumang iba pang offshore jurisdiction, ay maaaring maging offeror sa ilalim ng MiCA at direktang magdala ng obligasyon sa white paper, nang walang anumang kinakailangang ilipat ang legal seat nito sa Europa.

(Tandaan: Ang structural flexibility na ito ay mahigpit na naaangkop sa OTHR tokens. Para sa Asset-Referenced Tokens at E-Money Tokens, ang legal na obligasyon at mahigpit na civil liability para sa white paper ay ganap na nasa awtorisadong EU issuer at hindi maaaring i-delegate).

Gaya ng sinuri namin sa ikalawang installment ng seryeng ito, kinukumpirma ng mga ESMA register na ito na ay standard practice na: ang karamihan ng mga independent token filing ay nagmumula sa mga entity na ang punong-tanggapan ay nasa labas ng EU.

Ang isang CASP na nagpapatakbo ng trading platform ay maaari ring akuin ang obligasyon sa white paper, alinman sa sarili nitong inisyatiba o sa pamamagitan ng nakasulat na kasunduan sa project team. Hindi ito butas sa batas o kaginhawaan lang sa administrasyon.

Kapag ang isang CASP ang naghain, inaako nito ang legal na responsibilidad para sa katumpakan at pagkakumpleto ng pagsisiwalat. Kung may mapanlinlang na impormasyon ang white paper o hindi nito natutugunan ang mga pamantayan ng regulasyon, ang pananagutan ay nasa kung sino ang nagsumite nito.

Ang taong pumipirma para aprubahan ang white paper ay hindi maaaring i-delegate ang exposure na iyon sa isang software vendor, isang technical integrator, o isang law firm. Ang legal na pagsusuri ng nilalaman at ang teknikal na validity ay dalawang magkahiwalay na obligasyon sa compliance, at kapwa nakasalalay sa offeror. Ito ang puntong madalas maliitin ng karamihan ng proyekto.

Dalawang Code na Kailangang Umiiral Bago Magsimula ang Paghahain

Dalawang sapilitang identifier ang mga prerequisite para sa anumang compliant na white paper. Pareho silang hinango mula sa mga international standard na nauna pa sa MiCA. Hindi sila nilikha ng regulasyon; ginawa lamang silang obligado.

Ang una ay ang Legal Entity Identifier (LEI), isang ISO 17442 code na itinalaga sa mga legal entity at pinananatili sa Global LEI database na pinamamahalaan ng GLEIF. Malawak ang mandato para sa paggamit nito sa iba’t ibang regulatory standard: habang ang Article 14 ng record-keeping RTS (Commission Delegated Regulation EU 2025/1140) ay nagpapatupad ng LEI requirements sa mga CASP para sa kanilang mga kliyente, ang Article 3 ng white paper classification RTS (Commission Delegated Regulation EU 2025/421) ay mahigpit na nag-uutos na lahat ng naghahanda ng white paper ay dapat tukuyin ang sarili nilang legal entity gamit ang isang valid na LEI code. Para sa anumang entity na wala pa nito, dapat makumpleto ang proseso ng aplikasyon para sa LEI bago magsimula ang paghahanda ng white paper.

Ang ikalawa ay ang Digital Token Identifier (DTI), isang ISO 24165 code na tumutukoy sa mismong crypto-asset, na pinananatili sa DTIF registry. Kinakailangan ang paggamit nito sa ilalim ng Article 15 ng record-keeping RTS at Article 3 ng white paper classification RTS (Commission Delegated Regulation EU 2025/421). Ang mahalagang punto para sa anumang proyektong naglulunsad ng bagong token: kung wala pa ang DTI sa registry, may kailangang humiling ng paglikha nito bago maisumite ang white paper. Kapag ang isang CASP ang naghahain para sa isang asset na walang centralized issuer at walang umiiral na white paper, responsable ang platform na kunin o hingin ang DTI nang direkta mula sa DTIF.

Pinagmulan: ang DTIF Registry para sa mga crypto-asset

Ang white paper na walang valid na LEI at DTI ay bumabagsak sa automated validation bago pa ito makita ng sinumang human reviewer. Ang mga proyektong umaabot sa yugto ng pagsusumite nang wala ang parehong code ay haharap sa isang ganap na restart.

Ang Automated Gate at ang Ibig Sabihin Nito sa Legal

Walang tao sa isang national competent authority ang nagre-review ng white paper na bumabagsak sa automated checks nito. Tinutukoy ng ESMA taxonomy ang 257 existence check (pagbe-verify na naroroon ang mga kinakailangang field) at 223 value check (pagbe-verify na valid ang laman ng field). Ang filing na bumabagsak sa check na may “Error” severity ay teknikal na invalid. Hindi umuusad ang dokumento.

Direkta ang legal na implikasyon ng arkitekturang iyon: ang teknikal na validity at ang katumpakan ng nilalaman ay parehong responsibilidad ng offeror. Ang perpektong nakabalangkas na legal disclosure sa maling structure ay bumabagsak. Ang structurally valid na file na may mapanlinlang na nilalaman ay bumabagsak din; iba lang ang yugto ng pagbagsak at iba ang mga kahihinatnan.

Ang mga proyektong nag-aalok ng token sa maraming EU member state ay nahaharap sa karagdagang layer. Bawat bersyon ng wika ng white paper ay nangangailangan ng sarili nitong hiwalay na structured file. Kailangang magkakatugma sa loob ang lahat ng bersyon ng wika at hindi lang basta isinalin, kundi identikal din ang pagkakaayos sa antas ng field. Ang salin na hindi tumutugma sa structure ng orihinal ay teknikal na hindi compliant, anuman ang katumpakan nito sa wika.

Nagdaragdag ng isa pang constraint ang mga sustainability disclosure. Inaatasan ng taxonomy ang tiyak na yunit ng sukat para sa energy consumption at CO2 emissions: kWh at tCO2, ayon sa pagkakasunod. Mga legal na requirement sa pagsisiwalat ang mga ito, hindi opsyonal na environmental reporting. Ang paghahain na may ibang yunit o ang pag-omit ng mga field ay magti-trigger ng validation failure.

Iisa ang pattern sa lahat ng requirement na ito: ang white paper ay isang legal filing na may machine-enforced na pamantayan. Ang mga proyektong tatratuhin ito bilang isang document-writing exercise, sa halip na isang proseso ng compliance na may structured na mga prerequisite at automated gatekeeping, ay makakaharap ang pagpapatupad na iyon bago pa sila makarating sa isang human regulator.

Ano ang Ibig Sabihin Nito sa Praktika

Ang popular na pagkaunawa sa crypto white paper bilang isang narrative pitch (isang bagay na isinulat para manghikayat sa halip na magsiwalat) ay naglalarawan ng uri ng dokumentong pinalitan ng MiCA ng isang bagay na ganap na naiiba.

Ang MiCA white paper ay isang legal na instrumento na may itinakdang nilalaman, sapilitang identifier, structured na pormat na idinisenyo para sa automated na cross-border comparability, at pinangalanang personal na pananagutan na nakakabit sa sinumang pumipirma para aprubahan ito. Dito dumadaan ang entry gate papasok sa European crypto market. Ang mga proyektong nauunawaan ang filing kung ano ito sa legal, sa halip na kung ano ang historikal na ipinahihiwatig ng termino, ang mga proyektong iyon ang hindi nababalik sa automated check.

Mahahalagang Takeaway:

• Ang white paper ay hindi isang marketing document. Muling tinukoy ng MiCA ang termino. Ang pinakamalapit na katumbas sa tradisyunal na pananalapi ay isang securities prospectus, at dapat itong tratuhin na may kaparehong legal na bigat.
• Tatlong kategorya ng asset, tatlong magkaibang landas. Ang OTHR, ART at EMT ay may magkakaibang white paper requirement at magkaibang prerequisite sa authorization. Ang mga katangian ng asset ang nagtatakda kung aling kategorya ang naaangkop; hindi ito pinipili ng proyekto.
• Sumusunod ang pananagutan sa nagsumite, pero nakadepende ang mga patakaran sa asset. Para sa napakaraming token (OTHRs), ang legal na obligasyon ay nasa offeror o sa taong naghahanap ng admission sa trading, hindi kinakailangang nasa orihinal na lumikha ng token. Kapag ang isang CASP (gaya ng operator ng trading platform) ay pumayag na maghanda at maglathala ng white paper sa ngalan ng isang OTHR project, inaako nito ang mahahalagang tungkulin sa regulasyon, ngunit hindi nito inaako nang buo ang pananagutan. Sa ilalim ng MiCA Article 14(3), ang orihinal na taong naghahanap ng admission sa trading ay nananatiling legal na responsable kung magbibigay sila ng hindi kumpleto, hindi patas, hindi malinaw, o mapanlinlang na impormasyon sa CASP. Maaari mong i-outsource ang papeles, pero hindi mo ganap na ma-i-outsource ang pananagutan.
• Para sa Asset-Referenced Tokens (ARTs) at E-Money Tokens (EMTs), ang mahigpit na civil liability para sa white paper ay hindi lang nakasalalay sa awtorisadong issuer bilang isang corporate entity; malinaw itong umaabot sa mga miyembro ng administrative, management, o supervisory body nito. Anumang kontraktuwal na pagtatangkang limitahan o alisin ang pananagutang ito ay walang bisa sa batas.
• Ang LEI at DTI ay mga prerequisite. Dapat nakahanda ang parehong identifier bago magsimula ang paghahanda ng white paper. Kung walang umiiral na DTI para sa asset, dapat itong hilingin mula sa DTIF registry bago pa umusad ang anuman.
• Ang automated validation ang unang gatekeeper. Tumatakbo muna ang 257 existence check at 223 value check bago pa may taong mag-review ng file. Ang dokumentong bumabagsak sa isang Error-level assertion ay hindi umaabot sa isang regulator.
• May nakatagong teknikal na obligasyon ang mga multilingual filing. Bawat bersyon ng wika ay nangangailangan ng sarili nitong hiwalay na structured file, na nakaayos nang identikal sa orihinal. Ang salin na hindi tumutugma sa source structure sa antas ng field ay hindi compliant.
• Ang katumpakan ng nilalaman at ang teknikal na validity ay dalawang magkahiwalay na obligasyon. Sinasaklaw ng legal review ang una. Sinasaklaw ng technical structuring ang ikalawa. Kapwa nakasalalay ang mga ito sa offeror, at hindi pumapalit ang isa sa isa.

Ang artikulong ito ay batay sa isang pag-aaral na isinagawa ng LegalBison noong Abril 2026. Ang nilalaman ay para sa layuning pang-impormasyon lamang at hindi bumubuo ng legal na payo.