Skip to main content

Goldsky

MiCA stablecoin reporting data

Talk to our team

What is MiCA stablecoin reporting data?

MiCA stablecoin reporting data is the onchain part of the quarterly report that the EU’s Markets in Crypto-Assets Regulation (MiCA) asks of some stablecoin issuers under Article 22: how many holders the token has, how much is in issue and how much it’s used for transactions.

It applies to asset-referenced tokens above €100 million in issue and, through Article 58(3), to e-money tokens in currencies outside the EU, such as the dollar; euro tokens are not covered.

The issuer’s compliance team files it with its national regulator, so the counts have to come from a record the team can rebuild and explain.

Goldsky publishes every mint, burn and transfer to your Kafka topic as it happens; your team counts holders and volume, adds the reserve figures from your custodian and files the report.

Who needs MiCA stablecoin reporting data?

Issuers of asset-referenced tokens and of dollar or other non-EU-currency stablecoins in the EU, and the issuance platforms that run tokens for them.

How MiCA stablecoin reporting data is gathered

The diagram follows a quarter of token use from transfers on the chain to the report your team submits, and shows who does each step. Your setup may differ.

Goldsky, steps 2–3: TurboPublish every transferMints, burns and payments on your queue
Blockchains, step 1: Token in useHolders transact every day
Your business, steps 4–5: Count holders and volumeHolders, issuance and daily transactions
Your business, step 6: CustodianReport the reservesYour custodian states the reserve’s size
Your business, step 7: Submit the reportTo your regulator each quarter
  • Goldsky
  • Your provider

How to gather MiCA stablecoin reporting data

A pipeline publishes every mint, burn and transfer of your token to a Kafka topic as it happens, and your systems count holders, issuance and transaction volume from it for each quarter.

What you’ll need

  • Goldsky Turbo
  • Your token’s contract addresses on each chain
  • A Kafka cluster, and a consumer that stores the events
  • Reserve figures from your custodian
  • Your reporting tools

  1. Let the token be used

    Holders mint, redeem and pay with the token every day, and the report measures that use.

    Every mint, burn and transfer on every chain the token runs on counts toward the quarter. Missing a chain understates both holders and volume.

  2. Decode every mint, burn and transfer

    Handled by Goldsky Turbo

    Holder counts and volume are built from each event, so each one has to be read into plain fields.

    Events are decoded from the token’s logs with their chain, block and time, starting early enough to cover every holder’s history. Starting at the quarter’s first day misses holders who bought earlier.

    A Turbo Pipelines transform filters your token’s logs and decodes them with _gs_log_decode, from past blocks through to new ones.

    See the decode functions (opens in a new tab)

  3. Publish every event to your queue

    Handled by Goldsky Turbo

    Your reporting systems need each event as it happens, in a feed they already consume.

    Each event goes out with a stable key so your consumer can drop repeats. A consumer that counts every message it receives counts retried messages twice.

    With Goldsky, a Turbo Pipelines Kafka sink publishes each decoded event to your topic as Avro or JSON, keyed on its primary_key.

    Set up a Kafka sink (opens in a new tab)

  4. Apply corrections after a reorg

    If the chain replaces recent blocks, some published transfers no longer happened.

    Corrections arrive as messages of their own, and your consumer deletes or updates the events they name. Skipping them leaves transfers in your counts that the chain no longer has.

  5. Count holders, issuance and volume

    The report asks how many holders the token has, how much is in issue and how much it’s used, for the quarter.

    Your team totals mints minus burns for issuance, counts wallets with a balance, and sums transactions by day, using your regulator’s definitions and keeping them the same from quarter to quarter. Customers who hold the token at an exchange show onchain only as the exchange’s wallets, so Article 22(3) has crypto-asset service providers (CASPs) give the issuer the information it needs, including transactions made off the chain, and some issuers have each CASP holding the token send a daily holdings report (template S 08.00).

  6. Report the reserves

    The report also covers the reserve behind the token, which comes from your custodian, not the chain.

    Your custodian states the size and makeup of the reserve as of the same date as your token figures. Figures from different dates can’t be compared.

  7. Submit the report

    The report is filed with your national regulator each quarter.

    Your compliance team checks the figures against the chain and your records before filing. The data behind the report doesn’t make it complete or correct; that check and your firm’s sign-off do.

What you control

Your team
  • Apply corrections after a reorg
  • Count holders, issuance and volume
  • Submit the report
Your providers
  • Custodian

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

More use cases that report to regulators

Gather MiCA stablecoin reporting data with Goldsky

We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.

Talk to our team

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status