Gouvernance veKAL

Le module gouvernance de Kal Mydas regroupe trois contrats Solidity centraux. Le contrat VeKAL implémente le verrouillage des jetons KAL et la conversion en veKAL — c'est le cœur du modèle vote-escrow popularisé par Curve. Le contrat KalGovernance reçoit les propositions, organise les votes et applique les décisions adoptées. Le contrat KalTimelock impose un délai d'exécution entre l'adoption d'une décision administrative et son application effective, ce qui laisse à chaque utilisateur la possibilité de retirer ses fonds si un vote ne lui convient pas.

Cette architecture suit un principe simple : la gouvernance n'est pas instantanée et n'est pas anonyme. Toute proposition exige un seuil minimum de veKAL pour être déposée, un quorum minimum pour être validée, une période publique de vote, et un délai d'exécution avant application. À chaque étape, les utilisateurs gardent la main sur leurs dépôts.

Une protection spécifique a été ajoutée fin 2025 contre les attaques dites de flash-lock — verrouiller massivement du KAL juste avant un vote pour faire pencher la balance, puis se retirer. Cette protection, décrite plus loin, rend l'attaque mécaniquement impossible.

Pour participer à la gouvernance, un détenteur de KAL doit verrouiller ses jetons via le contrat VeKAL. La durée de verrouillage est choisie librement entre une semaine (constante MIN_LOCK_DURATION) et quatre ans (constante MAX_LOCK_DURATION = 4 × 365 jours). En échange, le détenteur reçoit une quantité de veKAL proportionnelle à son engagement temporel : la formule est strictement linéaire — `veKAL = KAL × durée / 4 ans`.

Cette linéarité est délibérée. Elle évite les sauts d'incitation qui rendent certains modèles concurrents difficiles à interpréter. Verrouiller deux fois plus longtemps donne exactement deux fois plus de poids dans la gouvernance, deux fois plus de part dans le partage des frais, deux fois plus de multiplicateur de liquidité. La table ci-dessous illustre quelques cas concrets.

Le veKAL est non-transférable et non-échangeable par construction. Il ne peut pas être vendu sur un marché secondaire, prêté, ou utilisé en collatéral. C'est une représentation de l'engagement personnel d'un détenteur pendant une durée donnée — pas un actif financier.

À l'expiration du verrouillage, le détenteur peut retirer ses KAL initiaux. Les bénéfices accumulés (frais USDC reçus, récompenses LP boostées) ont déjà été versés régulièrement et restent acquis. Le détenteur peut aussi prolonger sa position avant échéance — la nouvelle durée doit toujours respecter les bornes 1 semaine / 4 ans.

Détenir des veKAL ouvre trois droits cumulables. Le premier est la voix dans la gouvernance : chaque veKAL pèse une voix sur les paramètres protocolaires modifiables — taux de frais en deçà des plafonds, autorisation de nouveaux pools, allocation de la trésorerie, validation des opérations administratives sensibles. Plus la position en veKAL est large, plus le poids dans le vote est grand. Mais aucune voix n'est jamais discrétionnaire : toutes les propositions passent par le processus public décrit plus loin.

Le deuxième droit est le partage hebdomadaire des frais. Le contrat FeeDistributor reçoit chaque semaine la part de 10 % des frais sur résultats prélevés par les pools (cf page Tokenomics, section frais et redistribution). Cette part est distribuée en USDC aux détenteurs de veKAL au prorata de leur position au début de la période. Aucun verrouilleur ne reçoit jamais une obligation d'accepter du KAL au lieu de stablecoin — la rémunération est en USDC, ce qui la rend immédiatement utilisable hors écosystème.

Le troisième droit est le multiplicateur de récompenses de liquidité. Un fournisseur de liquidité qui verrouille en parallèle voit ses récompenses LP multipliées par un facteur jusqu'à 2,5×, en fonction de son ratio veKAL / KAL fourni en liquidité. Ce mécanisme aligne les intérêts entre fournisseurs de liquidité et engagement long terme : les fournisseurs qui s'engagent durablement reçoivent une part plus grande de l'émission KAL programmée.

Le processus de gouvernance suit toujours la même séquence. Un détenteur qui souhaite proposer une modification doit d'abord vérifier qu'il détient au moins 1 % du veKAL total en circulation — c'est la constante PROPOSAL_THRESHOLD_BPS = 100. Cette barrière empêche le spam de propositions par des comptes marginaux. Une fois la proposition déposée, un délai de 24 heures s'applique avant qu'un nouveau dépôt par le même proposeur ne soit possible (PROPOSAL_COOLDOWN).

La proposition entre alors en période de vote pendant 3 jours (DEFAULT_VOTING_PERIOD). Pendant cette fenêtre, tout détenteur de veKAL peut voter pour ou contre. À la clôture, deux conditions doivent être remplies pour qu'une proposition soit adoptée : le total des votes exprimés doit représenter au moins 10 % du veKAL en circulation au moment du dépôt (QUORUM_BPS = 1000), et le total `pour` doit dépasser le total `contre`.

Si la proposition est adoptée, elle entre dans une fenêtre d'exécution. Un délai de 48 heures (EXECUTION_DELAY) doit s'écouler avant que la proposition puisse être exécutée — cette fenêtre laisse aux utilisateurs en désaccord le temps de retirer leurs dépôts. L'exécution doit ensuite intervenir dans les 7 jours suivants (GRACE_PERIOD), faute de quoi la proposition expire et doit être redéposée.

Pour limiter la complexité d'une proposition unique, le contrat impose un maximum de 10 actions par proposition (MAX_ACTIONS). Une proposition complexe doit donc être découpée en plusieurs propositions distinctes, ce qui force l'auteur à argumenter chaque modification séparément.

Le flash-lock est une attaque connue contre les modèles de gouvernance vote-escrow. Le principe est simple : un attaquant emprunte une grande quantité de jetons via un prêt instantané, les verrouille juste avant qu'une proposition entre en vote, vote dans le sens souhaité, puis retire son verrouillage et rembourse l'emprunt. L'attaque permet de peser disproportionnellement dans une décision sans engagement réel.

Kal Mydas neutralise cette attaque par une mécanique de snapshot. Lorsque KalGovernance enregistre une proposition, il prend un instantané (snapshot) de la position veKAL de chaque adresse au début de la période de vote. C'est cet instantané qui sert de base au calcul du poids dans le vote — pas la position au moment où l'utilisateur vote effectivement. Un attaquant qui verrouille après le snapshot ne pèse rien dans le scrutin, même s'il vote.

Cette implémentation utilise les checkpoints hebdomadaires de VeKAL et l'interface ERC20Votes standardisée. Elle est documentée dans le code source de VeKAL.sol (lignes 38 et 455) et dans KalGovernance.sol (lignes 20, 137 et 481). Elle a été validée par les audits Omniscient Security Labs.

À côté du délai d'exécution interne à KalGovernance, le protocole dispose d'un contrat de verrou temporel séparé : KalTimelock. Ce contrat est utilisé pour les opérations administratives sensibles qui ne passent pas nécessairement par un vote complet — par exemple les modifications de paramètres techniques par le multi-signature Gnosis Safe pendant la période de décentralisation progressive.

Toute opération soumise à KalTimelock doit passer par trois étapes : la programmation (l'opération est annoncée publiquement avec un délai), l'attente (le délai s'écoule, période pendant laquelle les utilisateurs peuvent réagir), puis l'exécution. Le délai applicable est paramétrable entre 24 heures (MIN_DELAY) et 7 jours (MAX_DELAY). Une fois le délai écoulé, l'opération doit être exécutée dans les 48 heures suivantes (GRACE_PERIOD), faute de quoi elle expire.

Cette double couche — KalGovernance pour les votes ouverts, KalTimelock pour les opérations administratives encadrées — garantit qu'aucun changement protocolaire n'est instantané. Quel que soit le canal, il y a toujours une fenêtre publique pendant laquelle un utilisateur en désaccord peut retirer ses dépôts.

L'efficacité d'une gouvernance vote-escrow dépend de la masse critique du veKAL en circulation. Au lancement du protocole, cette masse est par construction nulle. Pour densifier rapidement la base et atteindre le seuil opérationnel d'environ 30 % de l'offre verrouillée dans les six premiers mois, le contrat FeeShareBooster verse un bonus USDC en surcouche du partage de frais standard, selon un calendrier dégressif sur trois phases.

Le bonus s'ajoute aux 10 % de frais sur résultats déjà reversés en USDC aux détenteurs veKAL via FeeDistributor. Il est financé par une enveloppe USDC dédiée allouée par la trésorerie protocolaire, indépendante des flux de frais courants — le FeeDistributor continue de fonctionner normalement pendant que le Booster ajoute du USDC en parallèle.

Après les 26 premières semaines, le multiplicateur retombe à la base 1× et le partage des frais redevient standard. À ce moment, l'objectif est qu'une masse veKAL suffisante soit en place pour que les votes aient un poids significatif et que la gouvernance puisse fonctionner sans incitation supplémentaire.

Au lancement du mainnet le 14 septembre 2026, le protocole reste sous le contrôle d'un Gnosis Safe multi-signature pour les paramètres critiques — pause d'urgence, modification des plafonds en deçà des constantes, ajout de pools de stratégie. Cette concentration initiale est temporaire et délibérée : tant que la base veKAL n'a pas atteint une masse suffisante, une gouvernance entièrement on-chain serait fragile face à des attaquants ayant des moyens de capital significatifs.

La transition vers une gouvernance entièrement décentralisée est inscrite dans la feuille de route, sans calendrier précipité. Trois conditions cumulatives sont visées avant le transfert progressif des pouvoirs au seul KalGovernance : une base veKAL d'au moins 30 % de l'offre verrouillée, une diversité minimale d'adresses détentrices, et un historique d'au moins six mois de votes effectifs sans incidents majeurs.

Une décentralisation crédible se construit, elle ne se décrète pas. Le protocole préfère un calendrier non précipité à une cosmétique de gouvernance qui masquerait une concentration de fait. Les paramètres modifiables par KalGovernance sont précisément délimités par les constantes inscrites dans les contrats — aucun vote ne peut faire dépasser les plafonds techniques (MAX_PERFORMANCE_FEE_BPS, MAX_MANAGEMENT_FEE_BPS, MAX_SUPPLY) qui sont par construction immuables.