On-Chain Governance: The Tech Stack Explained

Governance کے بارے میں سیاسی عمل کی طرح بات کی جاتی ہے، لیکن اس کے پیچھے کا طریقہ کار خالص software engineering ہے: smart contracts، token accounting، اور consensus rules جو فیصلہ کرتے ہیں کہ کون نظام میں تبدیلی کر سکتا ہے اور کیسے۔ اگر آپ کسی DAO یا protocol upgrade کے راستے کا جائزہ لے رہے ہیں، تو tech stack کو سمجھنا mission statement پڑھنے سے زیادہ اہم ہے۔

بنیادی اجزاء

زیادہ تر on-chain governance کے نظام چھوٹے سے حصے سے بنے ہوتے ہیں:

• Voting contracts — proposals کو ٹریک کرتے ہیں، votes کو شمار کرتے ہیں، اور quorum thresholds کو نافذ کرتے ہیں
• Token یا reputation weighting — یہ طے کرتا ہے کہ کسی دیے گئے address کی vote کتنی اہمیت رکھتی ہے (token-weighted، quadratic، یا delegated)
• Timelock contracts — منظور شدہ proposals کی execution کو delay کرتے ہیں، عام طور پر 24-72 گھنٹے، تاکہ صارفین تبدیلیوں سے پہلے ردعمل دے سکیں
• Execution modules — وہ code path جو vote پاس ہونے کے بعد متاثر ہونے والے contracts کو واقعی call کرتا ہے

Compound کے Governor Bravo اور OpenZeppelin کے Governor contracts یہ reference implementations ہیں جو زیادہ تر نئے projects fork یا extend کرتے ہیں۔ اگر آپ اس pattern کو سمجھنے کے لیے ایک codebase پڑھیں، تو OpenZeppelin سے Governor.sol پڑھیں — یہ اچھی طرح commented ہے اور مکمل proposal lifecycle کو ظاہر کرتا ہے: propose، vote، queue، execute۔

ایک proposal درحقیقت نظام میں کیسے آگے بڑھتا ہے

ایک proposal محض ایک forum post نہیں ہے جس پر غیر رسمی طور پر vote ہو۔ On-chain میں، یہ calldata ہے: ایک target contract address، ایک function selector، اور encoded parameters۔ جب کوئی governance proposal submit کرتا ہے، تو وہ بالکل وہی transaction submit کر رہا ہے جو vote پاس ہونے کی صورت میں execute ہوگی۔

یہ flow عام طور پر اس طرح نظر آتا ہے:

1. Proposer calldata اور ایک description submit کرتا ہے، اکثر spam سے بچنے کے لیے کم سے کم token balance کی ضرورت ہوتی ہے
2. ایک voting delay (عام طور پر 1 block سے کچھ دن) holders کو voting شروع ہونے سے پہلے review کرنے کے لیے وقت دیتا ہے
3. Voting period چلتی ہے (Compound ڈیفالٹ طور پر تقریباً 3 دن استعمال کرتا ہے، اگرچہ بہت سے forks طویل windows کو کنفیگر کرتے ہیں)
4. اگر quorum اور approval thresholds پوری ہوں، تو proposal ایک timelock میں queue ہوتا ہے
5. Timelock delay ختم ہونے کے بعد، کوئی بھی execute کو کال کر کے transaction چلا سکتا ہے

Voting بند ہونے اور execution کے درمیان یہ خلا security backstop ہے۔ یہ وہ window ہے جہاں کمیونٹی ایک malicious یا buggy proposal کو نوٹ کر سکتی ہے اور، انتہائی صورتوں میں، ایک emergency response کو coordinate کر سکتی ہے — بشرطیکہ protocol کے پاس ایک emergency guardian role یا multisig override ہو، جو بہت سارے کے پاس early-stage governance کے دوران ہے۔

جہاں weighting logic پیچیدہ ہو جاتی ہے

سادہ token-weighted voting کا ایک معروف مسئلہ ہے: جو کوئی سب سے زیادہ tokens رکھتا ہے وہ نتائج کو کنٹرول کرتا ہے، اور voter turnout عام طور پر کم ہے۔ کچھ governance forums روٹین proposals کے لیے circulating supply کے single-digit percentages میں turnout کی رپورٹ کرتے ہیں۔

Projects نے متعدد fixes کی کوشش کی ہے:

• Delegation — token holders اپنی voting power کو ایک delegate کو بغیر tokens transfer کیے assign کرتے ہیں، جو Compound اور Uniswap representative voting کو handle کرنے کا طریقہ ہے
• Quadratic voting — اضافی votes کی cost quadratically بڑھتی ہے، whale dominance کو کم کرنے کے لیے بنایا گیا، اگرچہ Sybil resistance (ایک شخص متعدد addresses بناتا ہے) ایک کھلا مسئلہ رہتا ہے
• Conviction voting — کچھ Gitcoin-adjacent tooling کے ذریعے استعمال ہوتا ہے، جہاں voting power اس وقت جمع ہوتی ہے جب tokens ایک position میں زیادہ دیر commitment میں رہتے ہیں، sustained preference کو snapshot votes کے بجائے ترجیح دیتے ہوئے

ان میں سے کوئی بھی low-turnout، plutocracy-leaning dynamics کو مکمل طور پر حل نہیں کرتا token voting کے۔ یہ mitigations ہیں، fixes نہیں، اور کوئی بھی glossary entry جو دوسری صورت میں دعویٰ کرتا ہے وہ tech کو oversell کر رہا ہے۔

Off-chain signaling بمقابلہ on-chain execution

بہت سی چیزوں کو جو governance کہا جاتا ہے