Hard forks et airdrops : comptabilisation des attributions gratuites

Hard forks et airdrops : comptabilisation des attributions gratuites selon l'ANC 2026-01

1. Introduction : des événements fréquents, longtemps ignorés par la comptabilité

Les hard forks et les airdrops sont des phénomènes emblématiques de l'écosystème blockchain. Un hard fork — comme celui qui a donné naissance à Ethereum Classic (ETC) à partir d'Ethereum (ETH) en 2016, ou à Bitcoin Cash (BCH) à partir de Bitcoin (BTC) en 2017 — crée un nouvel actif numérique à partir d'un actif existant. Un airdrop est une distribution gratuite de tokens à des détenteurs existants, souvent à des fins promotionnelles ou de gouvernance.

Jusqu'au règlement ANC N°2026-01, ces événements ne bénéficiaient d'aucun traitement comptable normalisé. Les questions étaient nombreuses : à quelle valeur comptabiliser un token reçu gratuitement ? Faut-il reconnaître un produit ? Quel est le coût d'acquisition d'un actif obtenu par fork ? Le régulateur apporte désormais des réponses claires via les articles 619-17 (attributions gratuites) et 619-18 (forks), complétés par l'interprétation IR3.

2. Les attributions gratuites — Art. 619-17

L'article 619-17 du règlement ANC N°2026-01 distingue deux situations selon que l'entité est émettrice ou réceptrice de l'attribution gratuite.

2.1 Côté émetteur : l'attribution gratuite est une charge

Lorsqu'un émetteur distribue gratuitement ses propres tokens (émis ou auto-détenus) à des tiers, cette opération constitue une charge :

« L'attribution de jetons (émis ou auto-détenus) en échange d'une contribution (promotion, développement) constitue une charge. »

— Art. 619-17, Règlement ANC N°2026-01

Cette disposition couvre les cas suivants :

• Airdrops promotionnels : distribution de tokens à une communauté pour accroître la notoriété du projet.
• Récompenses contributeurs : tokens distribués à des développeurs, ambassadeurs ou partenaires en contrepartie de leur contribution.
• Programmes de fidélité : tokens offerts aux utilisateurs actifs d'une plateforme.
• Bounty programs : tokens distribués pour des tâches spécifiques (bug bounties, traductions, marketing).

Écritures comptables — Distribution de 100 000 tokens promotionnels (valeur vénale unitaire : 0,50 €) :

• Si les tokens étaient auto-détenus (compte 523) :
• Débit : 6238 « Charges de publicité et promotion » — 50 000 €
• Crédit : 523 « Crypto-actifs auto-détenus » — valeur comptable des tokens
• Ajustement du résultat pour la différence entre valeur comptable et valeur vénale.

Si les tokens sont nouvellement émis (non encore au bilan), l'émetteur débite la charge et crédite un compte de dette ou de produit selon la nature de la contrepartie attendue.

2.2 Côté récepteur : l'attribution gratuite est un produit

Pour l'entité qui reçoit des tokens gratuitement (airdrop), le traitement est symétrique : les tokens reçus sont comptabilisés à leur valeur vénale à la date de réception, en contrepartie d'un produit :

• Débit : 522 « Crypto-actifs et assimilés détenus » — valeur vénale des tokens reçus
• Crédit : 7674 ou compte de produit exceptionnel — valeur vénale

La valeur vénale est déterminée par référence au cours de marché du token à la date de l'airdrop. Si le token n'est pas encore coté (pré-listing), la valeur est estimée selon les méthodes admises par l'article 213-3 du PCG.

3. Les hard forks — Art. 619-18 et Art. 213-4

Le hard fork est un événement technique par lequel une blockchain se scinde en deux chaînes distinctes, générant un nouveau token pour les détenteurs de l'actif originel. Le règlement ANC N°2026-01 traite cette situation par analogie avec les opérations d'échange, via l'article 619-18 et la référence à l'article 213-4 (équivalence) :

« En cas de Hard Fork (Art. 213-4), l'émetteur ou le détenteur recevant un nouveau jeton distinct doit le comptabiliser à sa valeur vénale, par la contrepartie d'un produit. »

— IR3, Art. 619-18, Règlement ANC N°2026-01

3.1 Traitement côté détenteur

Lorsqu'un détenteur de crypto-actifs reçoit de nouveaux tokens à la suite d'un hard fork, le traitement comptable est le suivant :

• L'actif originel reste au bilan : les tokens de la chaîne originelle (ex. BTC) conservent leur valeur comptable. Aucune modification n'est apportée à leur évaluation du fait du fork.
• Le nouveau token est comptabilisé en produit : le token issu du fork (ex. BCH) est comptabilisé au compte 522 à sa valeur vénale, en contrepartie d'un produit.

Exemple : fork Bitcoin → Bitcoin Cash

Entreprise détenant 10 BTC (valeur comptable : 350 000 €). À la suite du fork, elle reçoit 10 BCH (valeur vénale à la date du fork : 3 000 € par BCH) :

• Les 10 BTC restent au compte 522 pour 350 000 € — pas de modification.
• Débit : 522 « Crypto-actifs détenus » (sous-compte BCH) — 30 000 €
• Crédit : 7674 « Produits sur crypto-actifs » — 30 000 €

Le coût d'acquisition des 10 BCH est donc de 30 000 € (3 000 € unitaire). Cette valeur servira de base pour le calcul du résultat de cession ultérieur.

3.2 Traitement côté émetteur

Pour l'émetteur qui initie un hard fork, la situation est plus complexe. Si l'émetteur est à l'origine de la scission de la chaîne, il doit :

• Évaluer si le fork modifie les droits attachés aux tokens existants (impact sur les dettes au passif).
• Comptabiliser les éventuels nouveaux tokens émis selon les règles de l'article 619-13 (émission de crypto-actifs).
• Analyser les clauses du white paper relatives aux forks et leur impact sur les obligations de l'émetteur.

4. Distinction entre hard fork et soft fork

Le traitement comptable ne s'applique qu'aux hard forks, c'est-à-dire aux scissions créant un nouveau token distinct et incompatible avec la chaîne originelle. Les soft forks (mises à jour rétrocompatibles) ne génèrent pas de nouveaux tokens et n'ont donc pas d'impact comptable direct.

Critères de distinction :

• Hard fork : scission de la blockchain, création d'un nouveau token, incompatibilité entre les deux chaînes. Exemple : Ethereum → Ethereum Classic.
• Soft fork : mise à jour du protocole, rétrocompatible, pas de nouveau token. Exemple : SegWit sur Bitcoin.

5. Les airdrops complexes : cas particuliers

5.1 Airdrops conditionnels (retroactive airdrops)

Certains airdrops sont conditionnés à l'utilisation antérieure d'un protocole (ex. airdrop UNI de Uniswap, airdrop ARB d'Arbitrum). Le traitement comptable dépend du moment où les conditions sont remplies :

• Si les conditions sont remplies et les tokens sont réclamables : comptabilisation immédiate en produit à la valeur vénale.
• Si les conditions ne sont pas encore toutes remplies : pas de comptabilisation tant que le droit n'est pas acquis.

5.2 Airdrops avec vesting (déblocage progressif)

Lorsque les tokens airdropés sont soumis à une période de vesting (déblocage progressif), le traitement comptable suit le rythme de déblocage :

• Les tokens non débloqués ne sont pas comptabilisés au bilan (engagement hors-bilan possible).
• À chaque déblocage, les tokens sont comptabilisés au compte 522 à leur valeur vénale du jour du déblocage.

5.3 Airdrops de tokens de gouvernance

Les tokens de gouvernance (UNI, AAVE, COMP...) reçus par airdrop sont comptabilisés comme tout autre crypto-actif au compte 522. Leur valeur vénale à la date de réception sert de coût d'acquisition. Le droit de vote ou de gouvernance attaché au token ne modifie pas le traitement comptable mais doit être mentionné en annexe.

6. Évaluation à la clôture des tokens reçus

Les tokens reçus par fork ou par airdrop suivent les règles d'évaluation à la clôture applicables à tous les crypto-actifs (Art. 619-12) :

« Les crypto-actifs et assimilés comptabilisés dans les comptes 522 selon les dispositions de l'article 619-10 sont évalués à leur valeur vénale à chaque clôture. »

— Art. 619-12, Règlement ANC N°2026-01

• Si la valeur vénale est inférieure au coût d'entrée (valeur vénale à la date du fork/airdrop) : perte latente comptabilisée au compte 4742, provision au compte 1517.
• Si la valeur vénale est supérieure au coût d'entrée : gain latent porté au compte 4752, non reconnu en résultat.

7. Obligations déclaratives CARF

Le règlement d'exécution (UE) 2025/2263 relatif au CARF impose la déclaration des airdrops reçus sous le code CARF501 — Airdrop. Les revenus issus de forks ne font pas l'objet d'un code spécifique mais doivent être déclarés dans le cadre du reporting général des crypto-actifs détenus.

Les opérateurs de plateformes (Reporting Crypto-Asset Service Providers — RCASP) doivent inclure les airdrops dans les données transmises aux administrations fiscales des États membres.

8. Cas pratique complet : fork Ethereum et airdrop ARB

8.1 Hard fork Ethereum → Ethereum PoW (ETHW)

En septembre 2022, lors du Merge d'Ethereum (passage en PoS), un hard fork a créé Ethereum PoW (ETHW). Sous le régime ANC 2026-01, une entreprise détenant 500 ETH aurait comptabilisé :

• Les 500 ETH restent au compte 522 à leur valeur comptable d'origine.
• 500 ETHW reçus, valeur vénale au jour du fork : 5 € par ETHW.
• Débit : 522 (sous-compte ETHW) — 2 500 €
• Crédit : 7674 — 2 500 €

Si, à la clôture, ETHW ne vaut plus que 0,50 € (valeur totale : 250 €), une perte latente de 2 250 € est constatée :

• Débit : 6866 « Dotation aux provisions financières » — 2 250 €
• Crédit : 1517 « Provisions pour dépréciation crypto-actifs » — 2 250 €

8.2 Airdrop ARB (Arbitrum)

Entreprise ayant utilisé le bridge Arbitrum et éligible à l'airdrop de 10 000 ARB (valeur au jour du claim : 1,20 €) :

• Débit : 522 (sous-compte ARB) — 12 000 €
• Crédit : 7674 — 12 000 €

Si l'entreprise vend les 10 000 ARB à 1,50 € :

• Débit : 512 « Banque » — 15 000 €
• Crédit : 7674 — 15 000 €
• Débit : 6674 — 12 000 € (coût d'acquisition = valeur du jour du claim)
• Crédit : 522 (sous-compte ARB) — 12 000 €
• Résultat de cession : +3 000 €

9. Impact fiscal

Sur le plan fiscal, les tokens reçus par fork ou par airdrop constituent un produit imposable à l'impôt sur les sociétés dès leur comptabilisation. La valeur retenue est la valeur vénale à la date de réception, conformément au traitement comptable. Lors de la cession ultérieure, le résultat de cession est calculé par rapport à cette valeur d'entrée.

Les entreprises doivent être particulièrement vigilantes sur les airdrops de faible valeur qui, cumulés, peuvent représenter des montants significatifs. Un suivi systématique de tous les airdrops reçus est indispensable pour respecter les obligations déclaratives.

10. Obligations d'annexe

L'annexe doit mentionner :

• Les tokens reçus par fork au cours de l'exercice, avec leur valeur vénale à la date du fork.
• Les airdrops reçus, avec leur nature (promotionnel, rétroactif, gouvernance) et leur valeur.
• La méthodologie de valorisation utilisée pour les tokens non cotés au moment de la réception.
• L'évolution de la valeur des tokens reçus entre la date de réception et la clôture.

« L'entité mentionne dans l'annexe [...] la dénomination, le nombre et la valeur vénale des crypto-actifs et assimilés détenus, en précisant les modalités de détermination de leur valeur vénale. »

— Art. 838-15, Règlement ANC N°2026-01

11. Conclusion

Le traitement comptable des hard forks et des airdrops sous le régime ANC 2026-01 repose sur des principes clairs : les tokens reçus gratuitement sont comptabilisés à leur valeur vénale en contrepartie d'un produit (côté récepteur) ou d'une charge (côté émetteur). Le coût d'acquisition ainsi déterminé sert de base au calcul des résultats de cession ultérieurs et à l'évaluation à la clôture.

Les entreprises doivent mettre en place des procédures de veille pour identifier rapidement les forks et les airdrops affectant leurs positions, et documenter systématiquement la valorisation retenue à la date de l'événement.