On-Chain Governance: De Tech Stack Uitgelegd

Governance wordt besproken als een politiek proces, maar het mechanisme erachter is pure software engineering: smart contracts, token-boekhouding en consensus-regels die bepalen wie een systeem mag wijzigen en hoe. Als je een DAO of protocol upgrade-pad evalueert, is inzicht in de tech stack belangrijker dan het missionstatement lezen.

De kerncomponenten

De meeste on-chain governance-systemen worden opgebouwd uit een kleine set onderdelen:

• Voting contracts — volgen proposities, tellen stemmen en handhaven quorum-drempels
• Token of reputation weighting — bepaalt hoe veel de stem van een bepaald adres telt (token-weighted, quadratisch of gedelegeerd)
• Timelock contracts — stellen uitvoering van aangenomen proposities uit, meestal 24-72 uur, zodat gebruikers kunnen reageren voordat wijzigingen worden doorgevoerd
• Execution modules — het code path dat daadwerkelijk de betreffende contracts aanroept zodra een stem is aangenomen

Compound's Governor Bravo en OpenZeppelin's Governor contracts zijn de referentie-implementaties die meeste nieuwere projecten forken of uitbreiden. Als je één codebase leest om het patroon te begrijpen, lees Governor.sol van OpenZeppelin — het is goed geannoteerd en toont de volledige proposal lifecycle: propose, vote, queue, execute.

Hoe een propositie daadwerkelijk door het systeem beweegt

Een propositie is niet alleen een forumpost waar informeel over wordt gestemd. On-chain is het calldata: een doeladres van een contract, een functieselector en gecodeerde parameters. Wanneer iemand een governance-propositie indient, dienen ze de exacte transactie in die zal worden uitgevoerd als de stem slaagt.

De flow ziet er meestal als volgt uit:

1. Proposer dient calldata plus een beschrijving in, vaak met vereenvoudigde minimale token-balans om spam te voorkomen
2. Een stemvertraging (meestal 1 blok tot enkele dagen) geeft houders tijd om te reviewen voordat stemming begint
3. De stemmingsperiode verloopt (Compound gebruikt standaard ongeveer 3 dagen, hoewel veel forks langere vensters configureren)
4. Als quorum en goedkeuringdrempels worden bereikt, wordt de propositie in een timelock in de wachtrij gezet
5. Nadat de timelock-vertraging is verstreken, kan iedereen execute aanroepen om de transactie uit te voeren

Die kloof tussen stemmingsafsluiting en uitvoering is de veiligheidsstop. Het is het moment waarin een community een kwaadaardige of buggy propositie kan opmerken en, in extreme gevallen, een noodrespons kan coördineren — aangenomen dat het protocol een noodbeschermingsrol of multisig override heeft, wat veel doen in vroege governance-fasen.

Waar de weighting-logica ingewikkelder wordt

Eenvoudige token-weighted voting heeft een bekend probleem: wie de meeste tokens houdt, bepaalt de uitkomsten, en deelname aan stemming is meestal laag. Een handvol governance-forums rapporteren deelname in enkelvoudige percentages van circulerend aanbod voor routinevoorstellen.

Projecten hebben verschillende oplossingen geprobeerd:

• Delegation — token-houders wijzen hun stemkracht toe aan een gemachtigde zonder tokens over te dragen, hoe Compound en Uniswap representative voting afhandelen
• Quadratic voting — kosten van extra stemmen nemen kwadratisch toe, bedoeld om whale-dominantie te verminderen, hoewel Sybil-weerstand (één persoon die veel adressen aanmaakt) een open probleem blijft
• Conviction voting — gebruikt door sommige Gitcoin-nabijgelegen tooling, waarbij stemkracht toeneemt naarmate tokens langer aan een positie blijven vastzitten, waarbij langdurige voorkeur boven snapshot-stemmen wordt begunstigd

Geen van deze lost volledig de lage deelname, plutocratische dynamiek van token-voting op. Het zijn mitigaties, geen oplossingen, en elk glossary-item dat het tegengestelde beweert, overschat de technologie.

Off-chain signalering versus on-chain uitvoering

Veel van wat wordt genoemd