MiCA
The register, in the vocabulary of MiCA.
A white paper is published on your own website, and it stays there for as long as the crypto-asset is held by the public. It is modified rather than replaced, and each modification is a publication with a date and a predecessor. That is a register, and a website is not one.
- Article 9
The white paper, and any marketing communications, are published on a publicly accessible website before the offer begins — and remain available there for as long as the crypto-assets are held by the public.
- Article 12
A significant new factor, material mistake or material inaccuracy means the published white paper is modified, notified to your competent authority ahead of publication, and published in the same manner as the original.
- Article 66
A service provider links to the white papers of the assets it provides services in, and publishes the adverse environmental impacts of each asset's consensus mechanism.
- Article 109
ESMA's own register holds white papers and their modified versions, and keeps out-of-date versions in a separate archive, clearly marked as out of date.
We do not read any of this for you, and we take no view on whether you have met it. What we note is narrower: the obligations are written in the language of a record — a date, a predecessor, a period, a version that is no longer current but still exists — and a folder on a website has nowhere to put any of it.
What hangs where
Your own assets, the ones you service, and the firm.
A document is attached to a crypto-asset or to the firm itself. The attachment decides where the document is shown and how it is grouped. It does not decide the address: every document has its own, unchanged by anything that happens to the structure around it.
Each language version is a document in its own right, with its own address and its own publication date — which matters more here than in most places, because the language a client is served in is the language the information has to exist in.
An asset you offer. The white paper you notified, its modifications, and what is published alongside it.
/d/example-token-white-paper-en- Crypto-asset white paperone per language
- Modified white papera publication of its own
- Marketing communicationspublished with the paper
- Adverse environmental impactsper consensus mechanism
- Reserve figures for an asset-referenced tokenmonthly series
An asset you service. Somebody else issued it, and your obligations still attach to it. Both of these are yours to keep current.
/d/example-listed-asset-environmental-en- Link to the issuer's white paperthe address is theirs
- Adverse environmental impactsyours to publish
The firm. Published in your own name, and expected to be current rather than merely present.
/d/example-digital-assets-complaints-en- Complaints handling procedurewith its form
- Terms and conditionsper service
- Conflicts of interest policy
- Custody policy
- Operating rules of a trading platform
- Client information and risk statementsper language
A modification is a publication
The modified white paper goes to the address the previous one had, and the previous one keeps its own dated address. The register records when the modification took effect, what it superseded and the hash of both files — so the question which paper was published when we notified the authority has an answer that is not somebody's recollection.
Scheduled, not hurried
A modification is notified before it is published. You upload it when it is ready and set the date it takes effect; it stays invisible outside your own organisation until that day, and then goes live without anyone being at a keyboard that morning.
Where the address ends up
Written down once, and quoted for years.
The address of a white paper does not stay on your website. It is notified, registered, linked to and quoted — and each of those copies keeps pointing wherever it pointed on the day it was written down.
- The notification to your competent authority
The white paper is notified before it is published, and the address travels with it.
- ESMA's register
It holds white papers and their modified versions, and keeps out-of-date versions in a separate archive, clearly marked as such.
- Other service providers' websites
A provider that offers services in an asset links to that asset's white paper. If you issued it, that link is to your address.
- Your marketing communications
They state where the white paper is published, and they are published themselves.
- Your own app, website and support material
The places nobody updates, because nobody remembers that they carry a link at all.
None of them are ours, and we do not submit anything to any of them. What a permanent address does is make the copies harmless: they were written once and they stay correct, because the address answers with whatever version is current rather than with whatever file was uploaded last.
Documents are served from your own domain by CNAME, as standard rather than as an upgrade, so the address you notify sits on your own host name. Rename a document and the previous address keeps answering — permanently, and without a redirect, because a redirect is what makes a collector record the wrong address.
The same holds inside the firm. An address that has been printed in a client notification, quoted in a support article or embedded in an app release is not one you can change; a version of the document behind it is something you change every time the paper is modified.
Format and identifiers
We store the file you notified. We never look inside it.
White papers are prepared to a template and in a machine-readable format, tagged against ESMA's taxonomy. We neither produce that file nor validate it: it arrives from you, is stored byte for byte, and its hash is recorded on arrival. If the file we hold differs from the one you notified, the hash says so.
What the register does hold is the metadata around the file — the identifiers, the type, the language, the dates — and it holds more than one identifier per publisher and per product, because a firm has an LEI whilst an asset is identified by a digital token identifier and its functionally fungible group. Neither is the address, and neither is reused as one: an identifier that changes hands would otherwise take the address with it.
- LEI
the firm, in the register of its own name
- DTI
the crypto-asset, per ISO 24165
- FFG DTI
the functionally fungible group it belongs to
- Language
one document per language, each with its own address
- Valid from · valid to
the period this version was the one in force
Slugs are proposed on upload from the identifier, the document type and the language, and you approve them before anything is public. The address reads as what it is, and it carries no ownership: a transfer, a rebranding or a new corporate name leaves it exactly as it is.
Getting started
One asset, with the documents you have already published.
A good first step is a single crypto-asset: the white paper as it stands, the modifications it has been through, and the firm-level information published alongside it. It is small enough to set up in an afternoon and complete enough to judge — the addresses, the version history and the answer to a date, on your own domain, with your own files. How the setup runs, what the register records and where our responsibility ends is written out on the front page.
The demonstration portal we can show you today is set up for a fictional fund manager rather than a crypto-asset firm, because that is the vertical we started in. The register behind it is the same one, and the documents in it are held the same way.