On-Chain Governance: The Tech Stack Explained

Governance के बारे में एक राजनीतिक प्रक्रिया की तरह बातचीत होती है, लेकिन इसके पीछे का तंत्र शुद्ध सॉफ़्टवेयर इंजीनियरिंग है: smart contracts, token accounting, और consensus rules जो तय करते हैं कि कौन एक सिस्टम को बदल सकता है और कैसे। अगर आप एक DAO या protocol upgrade path का मूल्यांकन कर रहे हैं, तो tech stack को समझना mission statement पढ़ने से ज्यादा महत्वपूर्ण है।

मुख्य components

अधिकांश on-chain governance systems भागों के एक छोटे set से बनाए गए हैं:

• Voting contracts — proposals को track करते हैं, votes को tally करते हैं, और quorum thresholds को enforce करते हैं
• Token or reputation weighting — निर्धारित करता है कि दिए गए address का vote कितना counted होता है (token-weighted, quadratic, या delegated)
• Timelock contracts — पारित proposals के execution को delay करते हैं, आमतौर पर 24-72 घंटे, ताकि users changes से पहले react कर सकें
• Execution modules — code path जो वास्तव में प्रभावित contracts को call करता है जब एक vote पारित हो

Compound का Governor Bravo और OpenZeppelin का Governor contracts संदर्भ implementations हैं जिन्हें ज्यादातर नए projects fork या extend करते हैं। अगर आप pattern को समझने के लिए एक codebase पढ़ते हैं, तो OpenZeppelin से Governor.sol पढ़ें — यह अच्छी तरह से commented है और पूरे proposal lifecycle को दिखाता है: propose, vote, queue, execute।

कैसे एक proposal वास्तव में सिस्टम के through move करता है

एक proposal सिर्फ एक forum post नहीं है जिस पर informally voted जाता है। On-chain, यह calldata है: एक target contract address, एक function selector, और encoded parameters। जब कोई governance proposal submit करता है, तो वे उस exact transaction को submit कर रहे हैं जो execute होगा अगर vote पारित हो।

Flow आमतौर पर इस तरह दिखता है:

1. Proposer calldata को एक description के साथ submit करता है, अक्सर spam को prevent करने के लिए एक minimum token balance की आवश्यकता होती है
2. एक voting delay (आमतौर पर 1 block से कुछ दिन) holders को voting शुरू होने से पहले review करने का समय देता है
3. Voting period चलता है (Compound default से लगभग 3 दिन का उपयोग करता है, हालांकि कई forks लंबी windows configure करते हैं)
4. अगर quorum और approval thresholds पूरी हो जाती हैं, तो proposal एक timelock में queue होता है
5. Timelock delay खत्म होने के बाद, कोई भी execute को call कर सकता है transaction को चलाने के लिए

Voting close और execution के बीच का वह gap security backstop है। यह वह window है जहां एक community एक malicious या buggy proposal को नोटिस कर सकता है और, extreme cases में, एक emergency response को coordinate कर सकता है — मानते हुए कि protocol के पास एक emergency guardian role या multisig override है, जिसके पास कई लोग early-stage governance में हैं।

जहां weighting logic complicated हो जाता है

Simple token-weighted voting की एक ज्ञात समस्या है: जो भी सबसे ज्यादा tokens hold करता है वह outcomes को control करता है, और voter turnout आमतौर पर कम होता है। कुछ governance forums routine proposals के लिए circulating supply के single-digit percentages में turnout report करते हैं।

Projects ने कई fixes की कोशिश की है:

• Delegation — token holders अपनी voting power को एक delegate को tokens transfer किए बिना assign करते हैं, जो Compound और Uniswap अपने representative voting को कैसे handle करते हैं
• Quadratic voting — अतिरिक्त votes की cost quadratically बढ़ती है, जो whale dominance को reduce करने का इरादा रखता है, हालांकि Sybil resistance (एक person कई addresses create करना) अभी भी एक open problem है
• Conviction voting — कुछ Gitcoin-adjacent tooling द्वारा used किया जाता है, जहां voting power accumulate होता है जितना लंबे tokens एक position के लिए committed रहते हैं, sustained preference को snapshot votes से favor करते हुए

इनमें से कोई भी token voting की low-turnout, plutocracy-leaning dynamics को पूरी तरह solve नहीं करता है। ये mitigations हैं, fixes नहीं, और कोई भी glossary entry जो अन्यथा claim करता है वह tech को oversell कर रहा है।

Off-chain signaling versus on-chain execution

जो कुछ governance के रूप में called जाता है उसका अधिकांश off-chain