Doctrine Zero Burn

Le protocole ne détruit aucun KAL. Aucun contrat du protocole n’appelle burn() ni burnFrom() sur le jeton KAL. Le dernier appel qui subsistait, celui du contrat de Pass d’accès, a été supprimé le 7 juin 2026. La vérification a été refaite dans le code source et sur la chaîne le 25 juillet 2026.

Le contrat KalToken hérite néanmoins de l’extension ERC20Burnable de la bibliothèque OpenZeppelin. Cet héritage rend les fonctions burn() et burnFrom() appelables par n’importe quel détenteur, sur son propre solde uniquement. Nous publions cette précision plutôt que de la taire. Elle ne contredit pas la doctrine, elle en délimite la portée exacte. La doctrine engage le protocole. Elle n’ôte à personne la libre disposition de ses propres jetons.

Tous les flux de KAL issus des frais passent par un contrat unique, le BuybackRecirculator. Ce contrat rachète du KAL sur le marché, puis le replace en liquidité. Il ne détruit rien.

La doctrine Zero Burn énonce une règle unique. Aucun jeton KAL n’est détruit à l’intérieur du protocole. Cette règle vaut pour l’ensemble des contrats, des scripts de déploiement et des robots opérateurs.

Elle sert un objectif d’autonomie. Chaque KAL émis reste mobilisable dans l’économie du protocole, de la liquidité détenue par le protocole aux récompenses des fournisseurs de liquidité, jusqu’au partage hebdomadaire des frais en USDC versé aux détenteurs de veKAL au titre de l’indemnité de service technique.

Elle écarte aussi une mécanique dont l’usage est fréquent ailleurs, la réduction volontaire de l’offre en circulation. Une telle mécanique suggère un effet de prix. Le protocole s’en tient à l’écart, par choix de qualification autant que par choix économique.

Concrètement, les flux de KAL générés par les frais de performance et par les frais de gestion mensuels sont entièrement traités par le contrat BuybackRecirculator. Ce contrat rachète du KAL sur le marché du protocole, via KalSwap, puis redirige le KAL racheté vers la liquidité détenue par le protocole et vers les contrats de récompense. Aucune part de ce KAL n’est dirigée vers une adresse de destruction. Aucune part n’est rendue indisponible.

Un lecteur qui examine le code source du contrat KalToken constatera un fait précis. Le contrat importe l’extension ERC20Burnable de la bibliothèque OpenZeppelin à la ligne 5, et il en hérite à la ligne 27 de sa déclaration. Un commentaire de la ligne 126 le rappelle explicitement.

Cette extension est l’une des briques les plus utilisées de la bibliothèque OpenZeppelin pour les jetons ERC-20. Elle expose 2 fonctions publiques, burn(uint256 amount) et burnFrom(address account, uint256 amount). Ces 2 fonctions permettent à un détenteur de réduire son propre solde de KAL, ou celui d’une adresse qui lui a donné une autorisation.

L’héritage existe au niveau du code déployé sur Base. Il n’est pas une option désactivable après coup. Tout détenteur de KAL peut donc appeler burn() depuis son portefeuille et faire diminuer son propre solde, exactement comme il le ferait avec n’importe quel jeton ERC-20 héritant de la même extension.

Nous préférons publier cette précision plutôt que d’afficher une formule absolue que le code contredirait. La portée exacte de la doctrine est la suivante. Aucun chemin protocolaire ne détruit de KAL. La libre disposition qu’un détenteur a de ses propres jetons ne relève pas du protocole et n’a pas à en relever.

Jusqu’au 7 juin 2026, un seul chemin protocolaire appelait encore la fonction burn(). Le contrat du Pass d’accès, lorsqu’un utilisateur réglait son Pass en KAL, détruisait le KAL reçu. C’était la dernière exception à la doctrine, et elle était documentée comme telle.

Le contrat KalAccessPassV5_2, déployé le 7 juin 2026, ferme cette exception. L’appel a été remplacé par un transfert du KAL vers le BuybackRecirculator, effectué par safeTransferFrom. Le code porte la trace explicite de la substitution, aux lignes 310 à 317, puis 377 et 464. L’héritage et l’import d’ERC20Burnable ont été retirés de ce contrat, et la référence au jeton a été retypée en IERC20, de sorte que le contrat de Pass ne dispose plus, techniquement, de la fonction de destruction.

Le résultat est vérifiable. Plus aucun chemin protocolaire ne détruit de KAL. Le KAL réglé pour un Pass part vers le recirculateur, qui le remet en liquidité. Cette vérification a été refaite dans le code source et sur la chaîne le 25 juillet 2026.

Reste la question de l’héritage au niveau du jeton lui-même. Neutraliser burn() et burnFrom() sur KalToken exigerait le déploiement d’un nouveau contrat de jeton, avec la migration que cela implique. 2 approches sont documentées, sans qu’aucune ne soit à ce jour arbitrée. La première consiste à remplacer les 2 fonctions par un rejet immédiat de l’appel, assorti d’un message d’erreur explicite. La seconde consiste à les remplacer par une redirection vers le BuybackRecirculator, qui recevrait alors le KAL au lieu de l’adresse de destruction. Les 2 approches produisent le même effet au niveau du protocole.

Cette évolution n’est ni décidée ni datée. La présente page ne l’annonce donc pas comme un engagement. Elle sera documentée ici si elle est arbitrée.

Toute personne dispose des moyens de vérifier l’application de la doctrine, sans nous croire sur parole. 4 lectures suffisent. Les adresses ci-dessous sont celles de la documentation technique, lues sur Base le 25 juillet 2026.

Première lecture, le contrat KalToken. Adresse : 0xe99556D5594faf533fcB346A8a9B11259D29afA8. Le code source est vérifié sur Basescan. L’héritage ERC20Burnable y est visible à la ligne 27, l’import à la ligne 5. Le plafond MAX_SUPPLY de 10 000 000 KAL y est également lisible, et il est contrôlé à chaque frappe.

Deuxième lecture, le contrat BuybackRecirculator. Adresse : 0xaCc08D87EaB0fdaC2f519d8a12C01BD5e20E9Ad0. Ce contrat est le routeur unique des flux de KAL issus des frais. Son code source vérifié ne contient aucun appel à burn() ni à burnFrom(). Les seules opérations sont des échanges d’USDC contre du KAL sur KalSwap, suivis d’un apport de liquidité sur la paire KAL et USDC.

Troisième lecture, le contrat de Pass d’accès en service. Adresse : 0x2e9d8CC025144c1E57C0139e76a668261B66c6F3. Sa fonction de lecture buybackRecirculator() retourne l’adresse du recirculateur citée ci-dessus. C’est la preuve du câblage. Le KAL réglé pour un Pass ne peut aller nulle part ailleurs.

Quatrième lecture, l’historique des transactions de KalToken. Le filtre de Basescan permet de lister tous les appels passés à burn() et à burnFrom() depuis le déploiement. Aucun appel émis par une adresse appartenant au protocole n’y figure.

Le déroulé suivant retrace le chemin des frais en USDC, depuis les pools de stratégie jusqu’à la liquidité. Il montre où le KAL entre dans le circuit, et où il en ressort.

Chemin des frais, du pool de stratégie jusqu’à la liquidité.

1. Les pools de stratégie prélèvent des frais de gestion et des frais de
   performance. Ces frais sont prélevés en USDC.

2. Le contrat KalFeeSplitV7 répartit ces deux flux selon des parts fixes,
   inscrites dans le code sous forme de constantes.

3. 20 pour cent des frais de performance et 50 pour cent des frais de gestion
   sont envoyés au contrat BuybackRecirculator.

4. Le BuybackRecirculator rachète du KAL contre des USDC sur KalSwap.

5. Le KAL racheté est replacé en liquidité sur KalSwap, avec les USDC restants.

6. Les jetons de liquidité obtenus alimentent la liquidité détenue par le
   protocole. Le KAL reste dans la réserve du marché.

À aucune étape, burn() ou burnFrom() n’est appelé par un contrat du protocole.
À aucune étape, le protocole ne fait diminuer totalSupply() du KAL.
À aucune étape, du KAL n’est envoyé vers une adresse de destruction.

Aucun contrat du protocole n’appelle burn() ni burnFrom() sur KalToken. Aucun script de déploiement, aucun robot opérateur, aucune fonction d’administration ne déclenche une destruction de KAL. L’intégralité des flux de KAL passe par le BuybackRecirculator, qui redirige le KAL racheté vers la liquidité et vers les contrats de récompense.

Cette discipline de chemin unique a une raison simple. Un protocole qui détruit ses propres jetons agit sur son offre, donc sur son prix. Ce n’est pas le rôle que Kal Mydas se donne. Le rôle du protocole est de faire fonctionner ses stratégies, de répartir ses frais selon des parts inscrites dans le code et de tenir la liquidité de son marché. Le prix reste une affaire de marché.

Les seuls appels à burn() qui pourraient un jour figurer dans l’historique de KalToken seraient ceux émis volontairement par des détenteurs, depuis leur propre portefeuille. Cette action relève de leur autonomie. Le protocole ne la provoque jamais, ne l’encourage pas et n’en tire aucun effet.

La doctrine Zero Burn est défendable au niveau du code parce qu’elle se vérifie. Un héritage ERC20Burnable assorti d’une absence vérifiable d’appel côté protocole, et d’un câblage explicite de chaque flux de KAL vers le recirculateur, matérialise l’engagement de manière contrôlable par un tiers.

Cette position soutient la qualification du KAL en jeton d’utilité, au sens de la loi suisse sur la technologie des registres électroniques distribués et du règlement européen MiCA. Le KAL ne représente aucune part d’une entité. Il ne donne aucun droit à une distribution de bénéfices au sens financier réglementé. Il ne porte aucune promesse de gain. Il donne accès aux fonctionnalités du protocole décrites dans la présente documentation.

La doctrine s’inscrit dans cette qualification en ce qu’elle écarte toute mécanique de réduction volontaire de l’offre, susceptible de suggérer un effet de prix.

Cette page est tenue à jour à chaque évolution du code ou de la qualification. Elle décrit un état vérifié, elle n’anticipe rien.