ما هو الـ governance token

ملاحظة: هذا المستند هو ترجمة آلية للنسخة الإنجليزية الأصلية.

ما هو الـ governance token

الـ governance token هو token مشفّر يمنح حامله حق التصويت على قرارات تؤثر في بروتوكول أو منظمة لامركزية. ويمكن أن تتراوح هذه القرارات من إنفاق الخزينة وتغيير معلمات الرسوم إلى ترقيات البروتوكول وتخصيص المنح والتوجّه الاستراتيجي. وتُرسِّخ governance tokens صنع القرار الجماعي على السلسلة: فبدلًا من أن يتخذ فريق مركزي كل الخيارات، يقترح حاملو الـ token ويصوّتون على التغييرات وفق قواعد مُشفَّرة في عقود ذكية.

باختصار: الـ governance token يحوّل ملكية البروتوكول من مفهوم غير رسمي إلى حق تصويت قابل للقياس على السلسلة — لكن الاحتفاظ بالـ token لا يضمن تأثيرًا ذا معنى أو تحكمًا لامركزيًا.

كيف يعمل

تتبع الآلية الأساسية للـ governance token دورة اقتراح–تصويت–تنفيذ:

1. إنشاء الاقتراح — يقدّم حامل token (أو أي عنوان يستوفي حدًا أدنى) اقتراحًا رسميًا. ويصف هذا الاقتراح إجراءً محددًا: تغيير معلمة بروتوكول، أو تخصيص أموال الخزينة، أو إضافة ميزة جديدة، أو تعديل بنية الرسوم.

2. فترة التصويت — يدخل الاقتراح نافذة تصويت محدودة الزمن. ويدلي حاملو الـ token بأصواتهم — عادةً token واحد يساوي صوتًا واحدًا، وإن كانت بعض البروتوكولات تستخدم التصويت التربيعي، أو تصويت القناعة، أو التفويض لتعديل هذه الصيغة.

3. النصاب والحد — لكي يُمرَّر تصويت، يحتاج عادةً إلى بلوغ مستوى مشاركة أدنى (نصاب) ونسبة موافقة دنيا (حد). وهذه المعلمات تحددها الحوكمة نفسها.

4. التنفيذ — إذا مُرِّر التصويت، يُنفَّذ الإجراء المقترَح إما تلقائيًا بعقد ذكي أو عبر آلية timelock تُدخِل تأخيرًا قبل التنفيذ.

ويمكن أن تكون هذه الدورة على السلسلة بالكامل (الاقتراحات والأصوات مُسجَّلة كمعاملات) أو جزئيًا خارج السلسلة (الأصوات تُجمَع عبر Snapshot أو أدوات مشابهة، ثم تُنفَّذ بواسطة multisig أو مجلس). وتتفاوت درجة الأتمتة والإنفاذ المُلزِم تفاوتًا كبيرًا بين البروتوكولات.

التفويض

تتيح كثير من أنظمة الحوكمة التفويض (delegation) — إذ يمكن لحامل token أن يُسنِد قوته التصويتية إلى عنوان آخر دون تحويل العملات نفسها. ويمكّن التفويض من صنع قرار أكثر اطلاعًا: فالحاملون الذين يفتقرون إلى الوقت أو الخبرة لتقييم كل اقتراح يمكنهم التفويض إلى ممثلين يشاركون بنشاط في الحوكمة. ويمكن إلغاء التفويض عادةً في أي وقت.

وزن التصويت والتركّز

لأن معظم governance tokens تستخدم نموذج token واحد لصوت واحد، تكون القوة التصويتية متناسبة مع حيازات الـ token. وهذا يعني أن كبار الحاملين (الذين يُسمَّون غالبًا "حيتان") قد يكون لهم تأثير غير متناسب. وتعالج بعض البروتوكولات هذا عبر:

• التصويت التربيعي — تتناسب القوة التصويتية مع الجذر التربيعي لعدد العملات، ما يقلّل هيمنة الحيتان.
• التصويت الموزون بالزمن — تحصل العملات المقفلة لفترات أطول على وزن تصويتي أعلى.
• أنظمة المجالس — تُرشِّح مجالس مُنتخَبة الاقتراحات أو تنقضها قبل وصولها إلى تصويت كامل للـ token.

ويؤثر توزيع governance tokens مباشرةً في مدى لامركزية صنع القرار فعليًا. فالـ governance token الذي يتحكم فيه عدد صغير من العناوين بأغلبية المعروض قد ينتج أصواتًا على السلسلة تبدو لامركزية لكنها مركزية فعليًا.

نطاق الحوكمة

لا تمنح كل governance tokens النطاق نفسه من التحكم. فبعض أنظمة الحوكمة تتيح لحاملي الـ token التصويت على كل شيء تقريبًا — ترقيات العقود الذكية، معلمات الرسوم، تخصيصات الخزينة، قرارات التوظيف. وأخرى تقصر الحوكمة على مجموعة ضيقة من المعلمات (مثل معدلات الرسوم وتوزيعات المكافآت) بينما يحتفظ الفريق بالتحكم في ترقيات البروتوكول والتوجّه الاستراتيجي.

ونطاق سلطة الحوكمة لا يقل أهمية عن الآلية نفسها. فالـ token الذي يحكم مجموعة ذات معنى من معلمات البروتوكول يخلق مواءمة أقوى من token لا يصوّت إلا على قرارات شكلية.

لماذا يهم

تهم governance tokens لأنها تحدّد من يتحكم في البروتوكول وكيف تُجرى التغييرات. ففي البرمجيات التقليدية، تقرر الشركة ماذا تبني وكيف تسعّره ومتى تغيّره. وفي البروتوكولات اللامركزية، تنقل governance tokens هذه السلطة — جزئيًا على الأقل — إلى مجتمع الحاملين.

وبالنسبة للقارئ الذي يقيّم مشاريع الذكاء الاصطناعي المعتمدة على الكريبتو، يكشف نموذج الحوكمة عدة أمور:

• بنية صنع القرار — هل يؤثر المجتمع فعلًا في البروتوكول، أم يحتفظ الفريق بالتحكم الكامل عبر أغلبية حيازات الـ token، أو مفاتيح إدارية، أو سلطة الترقية؟
• مواءمة الحوافز — يمكن لـ governance tokens أن توائم مصالح الحاملين مع نجاح البروتوكول، إذ يصوّت الحاملون على معلمات تؤثر في البروتوكول الذي يستخدمونه ويستثمرون فيه.
• سطح المخاطر — تُدخِل الحوكمة مخاطرها الخاصة: لامبالاة الناخبين، والاستحواذ البلوتوقراطي، وهجمات الحوكمة (حيث يحوز مهاجم ما يكفي من العملات لتمرير اقتراحات خبيثة)، وبطء صنع القرار.

governance tokens ليست جيدة أو سيئة بطبيعتها. إنها آلية. وتعتمد قيمتها كليًا على مدى جودة تصميم نظام الحوكمة، ومدى اتساع توزيع العملات، ومدى نشاط مشاركة المجتمع.

وبالنسبة لمشاريع الذكاء الاصطناعي المعتمدة على الكريبتو، تكون governance tokens ذات أهمية خاصة لأن بروتوكولات الذكاء الاصطناعي تواجه قرارات تصميم مستمرة تؤثر في جميع المشاركين: أي نماذج ذكاء اصطناعي تُدعَم، وكيف تُخصَّص مكافآت الحوسبة، وأي معايير قياس جودة تُفرَض، وكيف تُدار تحديثات النماذج. ويحدّد الـ governance token من يتخذ تلك الخيارات — مجتمع حاملي الـ token، أم الفريق المؤسِّس وحده.

أين يظهر في بطاقات مشاريع DecAIHub

في سجل DecAIHub، تظهر governance tokens في حقل Token model بالقيمة Governance. ويدل هذا على أن أحد الأدوار الموثّقة للـ token هو منح حقوق تصويت على قرارات البروتوكول.

وقد تُدرِج بطاقة مشروع Governance كـ نموذج token وحيد أو كأحد عدة نماذج (مثل Utility | Governance | Staking). وعندما تظهر الحوكمة إلى جانب نماذج أخرى، فهذا يعني أن الـ token يؤدي وظائف متعددة — دفع ثمن الوصول، والـ staking للمكافآت، والتصويت على الاقتراحات.

حقول رئيسية للمقارنة المتقاطعة عند إدراج الحوكمة:

• Token model — هل Governance الدور الأساسي، أم أنه مدمج مع آليات utility أو رسوم أو staking؟
• DAO / بنية الحوكمة — هل للمشروع DAO أو إطار حوكمة موثّق؟
• Onchain necessity — هل آلية الحوكمة فعلًا على السلسلة، أم أنها غير رسمية؟
• Token necessity — هل يجب أن يوجد الـ token لكي تعمل الحوكمة، أم يمكن اتخاذ القرارات نفسها عبر آلية أبسط؟

ما الذي لا يثبته هذا المصطلح وحده

• إدراج Governance كنموذج token لا يثبت أن الحوكمة لامركزية. فإذا احتفظ الفريق المؤسِّس بأغلبية العملات، كانت نتيجة التصويت محسومة سلفًا.
• وجود governance token لا يثبت أن المجتمع يستخدمه فعلًا. فكثير من أنظمة الحوكمة يعاني من معدلات مشاركة منخفضة للغاية، ما يترك القرارات فعليًا لمجموعة صغيرة من الناخبين النشطين.
• التصويت على السلسلة لا يثبت أن الأصوات مُلزِمة. فبعض البروتوكولات تستخدم الحوكمة كآلية إشارة بينما تحتفظ بـ مفاتيح إدارية يمكنها تجاوز نتائج التصويت.
• governance token لا يثبت أن الـ token يجب أن يوجد. فبعض المشاريع يمكنها تحقيق الحوكمة نفسها عبر آليات أبسط مثل مجالس multisig أو استطلاعات خارج السلسلة دون اشتراط token قابل للتداول.
• الحوكمة لا تثبت جودة المشروع أو قدرة الذكاء الاصطناعي أو الجدارة التقنية. إنها آلية صنع قرار، لا تزكية.

لا تخلط بين

المصطلح	التمييز
الـ utility token	يوفّر الـ utility token وصولًا، أو يدفع ثمن خدمات، أو يكسب مكافآت داخل بروتوكول. أما الـ governance token فيمنح تحديدًا حقوق تصويت. وكثير من العملات يكون من نوعَي utility وgovernance في آنٍ واحد.
الـ DAO	الـ DAO هو البنية التنظيمية؛ والـ governance token هو أداة التصويت داخل تلك البنية. وليست كل governance tokens تعمل داخل DAO رسمي، وليست كل DAOs تستخدم governance token مستقلًا.
الـ staking	يقفل الـ staking العملات لأمن الشبكة أو المشاركة في البروتوكول. وتتطلب بعض أنظمة الحوكمة الـ staking للتصويت، لكن الـ staking والحوكمة وظيفتان متمايزتان يمكن أن توجدا باستقلال.
الأسهم / الحصص	تُقارَن governance tokens أحيانًا بأسهم الشركات، لكنها عادةً لا تحمل حقوق ملكية قانونية، أو أرباحًا موزَّعة، أو حمايات تنظيمية. فالقياس بنيوي، لا قانوني.

الأسئلة المتكررة

هل يجعلني الاحتفاظ بـ governance token مالكًا للبروتوكول؟

ليس بالمعنى القانوني. فالـ governance token يمنحك حقوق تصويت ضمن نظام صنع القرار على السلسلة الخاص بالبروتوكول، لكنه لا يمنح ملكية قانونية، أو حقوق ملكية، أو حقوق مشاركة في الأرباح، أو حمايات تنظيمية مرتبطة بالأوراق المالية التقليدية. فـ"الملكية" وظيفية — يمكنك التأثير في معلمات البروتوكول — لا قانونية. ويهم هذا التمييز لأن حاملي governance tokens عادةً لا يملكون ملاذًا إذا تجاهل الفريق الأصوات أو غيّر قواعد الحوكمة.

ماذا يحدث إذا لم يصوّت أحد؟

انخفاض المشاركة من أكثر مشكلات الحوكمة شيوعًا. فعندما يصوّت قلة من الحاملين، يمكن أن تُمرَّر الاقتراحات بدعم جزء ضئيل من إجمالي معروض الـ token. وتضع بعض البروتوكولات متطلبات نصاب دنيا (يحتاج الاقتراح إلى مشاركة نسبة معينة من إجمالي المعروض لكي يكون التصويت صحيحًا). وأخرى تستخدم تصويت القناعة، حيث يتراكم الدعم بمرور الوقت ولا يتطلب حدًا أدنى من الإقبال. وعمليًا، ترى بروتوكولات كثيرة معدلات مشاركة في الحوكمة بنسب من خانة واحدة، ما يعني أن مجموعة صغيرة من المفوَّضين النشطين أو كبار الحاملين تتحكم فعليًا في البروتوكول.

هل يمكن مهاجمة الحوكمة؟

نعم. تحدث هجمات الحوكمة عندما يحوز كيان ما قوة تصويتية كافية — عبر الشراء أو القروض الفورية (flash loans) أو التراكم — لتمرير اقتراحات تنفعه على حساب البروتوكول. وتشمل الدفاعات الشائعة timelocks (تأخير التنفيذ ليتمكن المجتمع من التفاعل)، وآليات حجز التصويت (اشتراط قفل العملات قبل منحها قوة تصويتية)، وأوصياء multisig يمكنهم نقض الاقتراحات الخبيثة. ويعتمد أمن نظام الحوكمة على توزيع العملات، وكلفة حيازة حصة مسيطِرة، والضمانات المُدمجة في آلية التصويت.

كيف تتصل الحوكمة بـ DecAI Fit؟

في إطار DecAI Fit، تؤثر الحوكمة في بُعد Token necessity. فإذا أدّى الـ governance token دورًا حقيقيًا في صنع قرار البروتوكول — التحكم في المعلمات أو الخزينة أو سلطة الترقية — دعم ذلك الحجة بأن للـ token وظيفة بنيوية. وإذا كانت الحوكمة شكلية (يمكن للفريق تجاوز الأصوات، أو المشاركة لا تُذكر، أو دور حوكمة الـ token لا يُمارَس أبدًا)، أضعف ذلك حجة ضرورة الـ token.

مراجع خارجية

• Compound Governance documentation — أحد أقدم أطر الحوكمة وأكثرها استنساخًا؛ يوضّح دورة اقتراح–تصويت–تنفيذ عمليًا.
• DAOs, DACs, DAs and More — Vitalik Buterin — إطار مفاهيمي مبكر لبنى الحوكمة اللامركزية ومقايضات تصميمها.
• Governance overview — a16z Crypto — تحليل لمتجهات هجمات الحوكمة وآليات الدفاع.

انظر أيضًا

• ما هو نموذج الـ token
• ما هو الـ DAO
• ما هو الـ utility token
• ما هو الـ staking
• ماذا يعني عدم وجود token
• ما هو الـ multisig
• ما هو العقد الذكي
• ما هو DecAI Fit
• ما هو الـ timelock
• كيف تقرأ بطاقة مشروع