arrow_backRetour aux notes de terrain
OFFENSIVE Publié 8 Aug 2026

On-Chain Governance: The Tech Stack Explained

Un glossaire pratique des smart contracts, mécanismes de vote, et couches de consensus qui implémentent réellement la gouvernance décentralisée.

La gouvernance se décrit comme un processus politique, mais le mécanisme derrière c'est de l'ingénierie logicielle pure: smart contracts, comptabilité des tokens, et règles de consensus qui décident qui peut changer un système et comment. Si vous évaluez une DAO ou un chemin de mise à niveau de protocole, comprendre la tech stack compte plus que lire la déclaration de mission.

Les composants fondamentaux

La plupart des systèmes de gouvernance on-chain sont construits à partir d'un petit ensemble de parties:

  • Contrats de vote — suivent les propositions, tallent les votes, et appliquent les seuils de quorum
  • Pondération par token ou réputation — détermine combien de poids le vote d'une adresse donnée compte (pondéré par token, quadratique, ou délégué)
  • Contrats timelock — retardent l'exécution des propositions adoptées, généralement 24-72 heures, pour que les utilisateurs puissent réagir avant que les changements prennent effet
  • Modules d'exécution — le chemin de code qui appelle réellement les contrats affectés une fois qu'un vote passe

Compound's Governor Bravo et OpenZeppelin's Governor contracts sont les implémentations de référence que la plupart des nouveaux projets forkent ou étendent. Si vous lisez une seule base de code pour comprendre le motif, lisez Governor.sol d'OpenZeppelin — c'est bien commenté et montre tout le cycle de vie de la proposition: propose, vote, queue, execute.

Comment une proposition se déplace réellement dans le système

Une proposition n'est pas juste un post de forum qui reçoit un vote informel. On-chain, c'est du calldata: une adresse de contrat cible, un sélecteur de fonction, et des paramètres encodés. Quand quelqu'un soumet une proposition de gouvernance, il soumet la transaction exacte qui s'exécutera si le vote passe.

Le flux ressemble typiquement à ceci:

  1. Le proposeur soumet le calldata plus une description, souvent en exigeant un solde minimum de tokens pour prévenir le spam
  2. Un délai de vote (généralement 1 bloc à quelques jours) donne aux détenteurs le temps de réviser avant que le vote s'ouvre
  3. La période de vote s'exécute (Compound utilise environ 3 jours par défaut, bien que beaucoup de forks configurent des fenêtres plus longues)
  4. Si les seuils de quorum et d'approbation sont atteints, la proposition se met en file d'attente dans un timelock
  5. Après l'expiration du délai timelock, n'importe qui peut appeler execute pour lancer la transaction

Cet écart entre la fermeture du vote et l'exécution est le filet de sécurité. C'est la fenêtre où une communauté peut remarquer une proposition malveillante ou bugguée et, dans les cas extrêmes, coordonner une réaction d'urgence — en supposant que le protocole ait un rôle de gardien d'urgence ou un override multisig, ce que beaucoup ont au cours de la gouvernance en phase précoce.

Où la logique de pondération devient compliquée

Le vote simple pondéré par token a un problème connu: celui qui détient le plus de tokens contrôle les résultats, et la participation électorale est généralement faible. Une poignée de forums de gouvernance rapportent une participation dans les pourcentages à un seul chiffre de l'offre en circulation pour les propositions de routine.

Les projets ont essayé plusieurs solutions:

  • Délégation — les détenteurs de tokens assignent leur pouvoir de vote à un délégué sans transférer les tokens, c'est ainsi que Compound et Uniswap gèrent le vote représentatif
  • Vote quadratique — le coût des votes supplémentaires augmente quadratiquement, prévu pour réduire la domination des baleines, bien que la résistance Sybil (une personne créant plusieurs adresses) reste un problème ouvert
  • Vote de conviction — utilisé par certains outils adjacents à Gitcoin, où le pouvoir de vote s'accumule plus longtemps les tokens restent engagés dans une position, favorisant la préférence soutenue sur les votes de snapshot

Aucune de ces solutions ne résout complètement les dynamiques de faible participation et de ploutocratie du vote par token. Ce sont des atténuations, pas des corrections, et toute entrée de glossaire qui prétend le contraire vend trop la technologie.

Signalisation off-chain versus exécution on-chain

Beaucoup de ce qui s'appelle

Rédigé avec l'aide de l'IA, relu et publié par Michal Pilch (CISSP), Korra Studio.

Prêt à aller plus loin ?

Ceci est une note de la base de connaissances de Korra Studio — la plateforme associe chaque sujet à un mentorat individuel.

Commencer gratuitementarrow_forward