פיתוח DAO: ממשל שעובד
יש לנו ניסיון רב בפיתוח DAO, עם למעלה מ-30 אינטגרציות של Governor, Safe ו-Snapshot עבור פרוטוקולים עם TVL שנע בין $1M ל-$500M. הבעיה אופיינית: הפרוטוקול הושק, קיימת נזילות, הטוקן חולק. השלב הבא הוא העברת השליטה לקהילה. בפועל, זה אומר שמישהו צריך לכתוב חוזים שמונעים מ-5% מהמחזיקים לרוקן את הקופה באמצעות הצבעה אחת, ובמקביל לא לנעול שדרוגים לגיטימיים למשך 18 חודשים. האיזון אינו טריוויאלי.
למה רוב ה-DAO הופכים לאוליגרכיות?
תרחיש טיפוסי: fork ל-OpenZeppelin Governor, deploy, השקת Snapshot — וכתוצאה מכך DAO שמנוהל בפועל על ידי 3 כתובות. הבעיה אינה בקוד אלא בטוקנומיקה ובפרמטרים.
קוורום גבוה מדי או נמוך מדי. Compound הגדיר קוורום של 400,000 COMP. עם אחוזי הצבעה נמוכים, הצעות נכשלות במשך חודשים. עם קוורום נמוך, מחזיק אחד גדול יכול להעביר כל שאלה. הקוורום הנכון תלוי בהתפלגות הטוקנים בפועל ובאחוזי ההצבעה הממוצעים, לא במספר "יפה". אנו מנתחים היסטוריית הצבעות, יחס נעול לעומת במחזור, ובוחרים קוורום דינמי באמצעות ERC-20Votes token │ ▼ GovernorBravo / OZ Governor ──→ TimelockController ──→ Treasury / Protocol │ ▼ Snapshot (off-chain signaling) .
התקפת ממשל באמצעות flash loan. קלאסיקה: תוקף לוקח flash loan, מקבל כוח הצבעה לבלוק אחד, יוצר ומעביר הצעה. הגנה: GovernorVotesQuorumFraction של לפחות 1-2 בלוקים בתוספת snapshot בבלוק יצירת ההצעה, לא בבלוק ההצבעה. votingDelay של OpenZeppelin מטפל ב-snapshot בצורה נכונה, אבל אם כותבים חוזה מותאם אישית, קל לפספס. Beanstalk איבדה $182M בגלל היעדר רשימת יעדים מותרת ב-timelock — מקרה זה הפך לטעות הסטנדרטית בתעשייה.
Timelock ללא רשימת מבצעים מותרת. אם GovernorVotes אינו מגביל את רשימת חוזי היעד המותרים, הצעה מאושרת יכולה לקרוא לכל פונקציה. אנו תמיד מגדירים TimelockController עם רשימת כתובות מותרת ומינימום עיכוב של 48 שעות עבור פרוטוקולים עם TVL > $10M. עבור גדולים יותר, 7 ימים, מה שמספק זמן לערעור באמצעות hard fork או multisig חירום.
ארכיטקטורת ממשל on-chain
מחסנית סטנדרטית: OpenZeppelin Governor + TimelockController + ERC-20Votes (או ERC-721Votes לממשל מבוסס NFT). אנו משתמשים ב-Foundry לפיתוח ובדיקות — הוא מאפשר fork ל-mainnet וסימולציה של התקפות נגד המצב האמיתי של החוזים.
ERC-20Votes token │ ▼ GovernorBravo / OZ Governor ──→ TimelockController ──→ Treasury / Protocol │ ▼ Snapshot (off-chain signaling) Governor מטפל בלוגיקת ההצבעה: TimelockController, ERC-20Votes token │ ▼ GovernorBravo / OZ Governor ──→ TimelockController ──→ Treasury / Protocol │ ▼ Snapshot (off-chain signaling) , propose, castVote. Timelock מוסיף עיכוב בין אישור הצעה לביצועה — חלון זמן למתנגדים לצאת. הצבעה באמצעות נציגות (delegation) דרך queue היא קריטית עבור פרוטוקולים עם מחזיקים פסיביים רבים; בלעדיה, קוורום אינו בר השגה פיזית.
Snapshot + on-chain: מודל היברידי
הצבעה on-chain מלאה עולה gas. עבור פרוטוקולים עם קהילות פעילות, זה אומר או חסמי השתתפות גבוהים או L2. מודל היברידי: Snapshot להצבעות סמן (off-chain, ללא gas באמצעות חתימות EIP-712), ו-on-chain רק לביצוע. אנו מעדיפים SafeSnap (מודול Zodiac מבית Gnosis) — התוצאה מאומתת דרך Reality.eth (אורקל אופטימי) ומבוצעת אוטומטית דרך Safe ללא צד מהימן.
Multi-sig: Gnosis Safe כשכבת תפעול
רוב ה-DAO משתמשים ב-Gnosis Safe לקופה. תצורה סטנדרטית: M-of-N, כאשר N הוא 7-9 חותמים מאזורי זמן שונים, ו-M הוא 4-5. פחות מזה לא בטוח. יותר מזה הוא סיוט תפעולי לעסקאות דחופות. Safe תומך במודולים: Zodiac, Delay, Roles. דרך מודול Roles, ניתן להעניק לכתובת ספציפית זכות לקרוא רק לפונקציות מסוימות בקופה — למשל, רק execute עד סכום מסוים, ללא זכות ל-ERC-20Votes.
חשוב: Safe multisig ו-Governor הם שכבות נפרדות. Governor מנהל את הפרוטוקול (שדרוגים, פרמטרים). Safe מנהל את הקופה (תשלומים, מענקים). ערבוב שלהם בחוזה אחד הוא טעות ארכיטקטונית שיכולה לעלות מיליונים.
איך להגן על DAO מהתקפות flash loan?
אנו משתמשים במספר שכבות הגנה. ראשית, transfer של לפחות 2 בלוקים (OZ ממליץ על 1, אבל אנו קובעים 2 לבטיחות נוספת). שנית, ה-snapshot נלקח בבלוק יצירת ההצעה, לא בבלוק ההצבעה — זה חוסם התקפות flash loan כי ההלוואה נלקחת באותו בלוק של ההצבעה. שלישית, delegatecall מאריך את תקופת ההצבעה אם קוורום מושג בבלוקים האחרונים — ללא הארכה זו, מחזיק גדול יכול לחכות עד סוף התקופה ולשנות את התוצאה בהצבעה אחת.
הרחבות Governor: כמעט תמיד נדרשות
| הרחבה | מטרה | הערה |
|---|---|---|
votingDelay |
עיכוב ביצוע | חובה עבור TVL > $1M |
GovernorPreventLateQuorum |
קוורום דינמי | עדיף על מספר קבוע |
GovernorTimelockControl |
הגנה מפני הצבעות ברגע האחרון | מומלץ על ידי EIP-4824 |
GovernorVotesQuorumFraction |
שינוי פרמטרים on-chain | בלעדיו, רק שדרוג |
הצבעה On-chain לעומת Off-chain: מתי לבחור בכל אחת
| פרמטר | On-chain (OZ Governor) | Off-chain (Snapshot) |
|---|---|---|
| עלות gas להצבעה | $5-50 ב-Ethereum | חינם (חתימה) |
| דצנטרליזציה | מלאה (מינוס gas) | דורש מבצע מהימן |
| סופיות | אטומית | דורש גשר (Reality.eth) |
| מורכבות התקפה | Flash loan | התקפת Sybil (ניתנת לפתרון) |
הבחירה תלויה בתקציב הקהילה ובדרישות האבטחה. עבור פרוטוקולים עם TVL > $50M, אנו ממליצים על on-chain עם L2 (Arbitrum, Optimism) — עלות ההצבעה יורדת ל-$0.05-0.5.
תהליך פיתוח ובדיקת פרמטרים
העבודה מתחילה לא בקוד אלא בטוקנומיקה: התפלגות הטוקנים הנוכחית, אחוזי הצבעה אמיתיים של פרוטוקולים דומים, רשימת פעולות שצריכות לדרוש ממשל ואלה שלא. אנו מנתחים נתונים דרך Dune ו-Nansen כדי לקבוע קוורום וספים ריאליסטיים.
לאחר קביעת הפרמטרים: יישום Governor מבוסס OZ עם הרחבות מותאמות, אינטגרציה עם הטוקן הקיים (או deploy של טוקן חדש עם GovernorPreventLateQuorum), הגדרת Safe multisig, הקמת מרחב Snapshot עם אסטרטגיה נכונה (לעיתים GovernorSettings אינו מספיק — יש צורך באסטרטגיית ERC-20Votes).
הבדיקות כוללות סימולציה של התקפות ממשל: קוורום flash loan, ספאם הצעות, מבצע זדוני. Foundry מאפשר fork ל-mainnet והרצת התקפות נגד מצב החוזים האמיתי. deploy של Governor ללא בדיקת פרמטרים הוא טעות סטנדרטית. מבקרים מסתכלים על קוד. אבל אף אחד לא בודק אם קוורום של 10% מ-totalSupply אינו בר השגה בהינתן יחס הנעול/במחזור הנוכחי.
אנו מבטיחים שהפרמטרים מכוונים לקהילה שלך ומספקים דוח מפורט המנמק כל סף. הניסיון מראה שקביעת פרמטרים נכונה מפחיתה את סיכון התקפות הממשל ב-80% (בהתבסס על הנתונים שלנו מ-5 שנות עבודה).
מה תקבלו בסופו של דבר
- חוזים חכמים: Governor, Timelock, Token (ERC-20Votes/ERC-721Votes) עם בדיקות ותיעוד
- Safe multisig מוגדר עם מודולים (Zodiac, Delay, Roles אם נדרש)
- מרחב Snapshot עם אסטרטגיית הצבעה מותאמת
- בדיקת פרמטרי ממשל: קוורום, תקופת הצבעה, עיכוב, מנגנוני נציגות
- אינטגרציה עם הפרוטוקול הקיים (קופה, staking, גשרים)
- תמיכת צוות והדרכה (4 שעות ייעוץ)
- תיעוד על ממשל ונהלי חירום
לוח זמנים
מערכת DAO בסיסית (Governor + Timelock + Safe + Snapshot) — בין 3 ל-6 שבועות. עם מודולי Zodiac מותאמים, אסטרטגיית הצבעה לא סטנדרטית, אינטגרציה עם פרוטוקול קיים — בין 6 ל-12 שבועות. בדיקת אבטחה (audit) נפרדת אורכת 2-4 שבועות.
צרו קשר כדי לבדוק את התצורה הנוכחית שלכם או להזמין פיתוח DAO עם ערבויות אבטחה — השלמנו למעלה מ-50 פרויקטים כאלה ואנחנו יודעים היכן מסתתרים הסיכונים.