פיתוח טוקנים: ERC-20, טוקונומיקה, וסטינג
ראינו יותר טוקנים שנכשלו ממה שאפשר לספור — לא כי הקוד היה שבור, אלא כי ההנחות הכלכליות היו נאיביות. טוקן שלא קורס מאינפלציה תוך שישה חודשים, שבו ממשל תקין באמת עובד, ושבו אי אפשר לעקוף את הווסטינג באמצעות טריקים של האצלה — זה הנדסה אמיתית. אנחנו בונים בסטנדרט הזה.
איך אנחנו נמנעים ממלכודות ERC-20 נפוצות
תקן ERC-20 כולל תשע פונקציות. המורכבות מתחילה עם הרחבות:
ERC-20Permit (EIP-2612) — אישור ללא גז באמצעות חתימה. המשתמש חותם על permit(owner, spender, value, deadline, v, r, s) מחוץ לשרשרת, והמוציא לפועל קורא ל-permit() + transferFrom() בעסקה אחת. מסיר את שלב האישור הנפרד. סיכון: החתימה יכולה להיות מיורטת — יש צורך בבדיקת מועד אחרון ו-nonce. אנחנו תמיד מיישמים EIP-712 עם נתונים מובנים כדי למנוע מניפולציה של חתימות.
ERC-20Votes (EIP-5805) — צילומי מצב של יתרות לממשל. מערכת checkpoints מאחסנת היסטוריית יתרות לפי מספר בלוק. getPastVotes(address, blockNumber) מחזיר את היתרה ברגע יצירת ההצעה, לא הנוכחית. מונע ממשל באמצעות הלוואות פלאש: אי אפשר לשאול טוקנים ולהצביע בעסקה אחת.
טוקנים עם התאמת אספקה (stETH, Ampleforth) — balanceOf משתנה אוטומטית דרך יחס מניות פנימי. מורכבות אינטגרציה גבוהה: רוב פרוטוקולי ה-DeFi לא עובדים נכון עם התאמת אספקה ללא wrapper שאינו מתאים. פרסנו wrappers שמנתקים את היתרה ממחיר המניה לתאימות עם Uniswap.
טוקנים עם עמלת העברה — אחוז ניכוי על כל העברה. שובר חישובי AMM: הבריכה מקבלת פחות מהצפוי. Uniswap v2/v3 לא תומכים בכך באופן טבעי — צריך pair/router מיוחדים. בנינו נתבים מותאמים שמטפלים בטוקנים עם עמלת העברה ללא revert.
למה קיימות טוקונומיקה חשובה יותר מאקסל
טוקונומיקה היא לא טבלת אקסל שמסתכמת ל-100%. זה מודל תמריצים שעובד לאורך זמן או יוצר לחץ מכירה שהורג את הפרויקט.
לוח פליטה ואינפלציה — אספקה קבועה (מודל ביטקוין) עובדת לאחסון ערך, אבל לטוקני שירות צריך אינפלציה מבוקרת. מודל אינפלציוני (כמו Ethereum אחרי המיזוג) מייצר טוקנים חדשים כדי לתמרץ משתתפים. האיזון המרכזי: הפליטה צריכה להיות <= הערך שהפרוטוקול לוכד. אם הפרוטוקול מרוויח $100k בחודש אבל הפליטה היא $500k בחודש בערך שוק — לחץ מכירה קבוע הוא בלתי נמנע. אנחנו מדמים תרחישים אלה באמצעות סימולציות Python עם cadCAD למערכות מורכבות.
חלוקת אספקה — אין נוסחה אוניברסלית. עיקרון: לאף ישות אחת לא תהיה יותר מ-33% מכוח ההצבעה בהשקה. אחרת הממשל הוא בדיוני.
| קטגוריה | טווח אופייני | סיכון |
|---|---|---|
| צוות + יועצים | 15–20% | זריקת טוקנים בפתיחת הווסטינג |
| משקיעים (Seed, פרטיים) | 15–25% | יציאה מתואמת |
| אוצר / DAO | 20–35% | השתלטות על הממשל |
| אקוסיסטם / מענקים | 10–20% | הקצאה לא יעילה |
| מכירה ציבורית / LBP | 5–15% | תמחור נמוך → השתלטות של לווייתנים |
| אספקת נזילות | 5–10% | הון שכיר חרב |
מהן הטעויות הקריטיות ביותר בחוזי וסטינג?
וסטינג ליניארי עם תקופת צינון (cliff) הוא הסטנדרט לצוות ולמשקיעים. cliff היא התקופה אחרי TGE שבה אין זמינות. אחרי הצינון: שחרור ליניארי עד duration. שגיאות יישום אופייניות שאנחנו תופסים באודיט:
- וסטינג בר-ביטול ללא timelock — הבעלים יכול לבטל מיד. פתרון: ביטול דרך multisig + הצבעת ממשל עם עיכוב של 7 ימים.
- צינון לא חוסם זכויות ממשל — עם ERC-20Votes, הנמען יכול להאציל כוח הצבעה מהיום הראשון גם אם הטוקנים לא שוחררו. אנחנו מפרידים במפורש בין כוח הצבעה ללוגיקת תביעה.
- אין הפסקת חירום — אם מתגלה פרצה בחוזה הווסטינג, צריך יכולת להשהות תביעות. Pausable + timelock על ביטול ההשהיה.
ראינו פרויקט שבו הצינון הוגדר ל-0 בטעות — הצוות יכול היה לזרוק מיד. בדיקות ה-fuzz שלנו תופסות מקרי קצה כאלה לפני פריסה.
פרטי יישום חוזה וסטינג
Pausable ו-Ownable2Step מ-OpenZeppelin הם הסטנדרט. אנחנו מוסיפים timelock של 7 ימים על פונקציות ביטול. כל פונקציות המשיכה פולטות אירועים למעקב מחוץ לשרשרת. בדיקות fuzz מוודאות שהסכום המצטבר ששוחרר לעולם לא חורג מההקצאה הכוללת, גם אחרי ביטולים מרובים או תביעות חלקיות.
למה חשוב לבצע Bootstrap של נזילות בהשקת טוקן?
מכניקת ההשקה היא קריטית. שלוש גישות עיקריות:
- Balancer LBP — בריכה זמנית עם משקל טוקן ראשוני גבוה (90/10 טוקן פרויקט/USDC) שיורד אוטומטית ל-50/50 במשך ימים. יוצר לחץ מחירים כלפי מטה שמונע קניות בוטים במחיר אחד. אחרי ה-LBP הנזילות עוברת לבריכה קבועה.
- Fjord Foundry — פלטפורמה ייעודית ל-LBP והשקות הוגנות. פחות עומס תפעולי מאינטגרציה ישירה עם Balancer.
- Uniswap v3 עם טווח מוגבל — הוספת נזילות בטווח צר סביב המחיר ההתחלתי. יעילות הון גבוהה אבל דורשת ניהול טווח פעיל.
- TWAMM — מכניקה למכירות הדרגתיות של הזמנות גדולות ללא החלקה. מיושם ב-FraxSwap.
LBP עדיף פי 3-5 על רישום AMM סטנדרטי לגילוי מחירים; ראינו השקות הוגנות עם ירידה ראשונית קטנה ב-50% בהשוואה לרישומים ישירים ב-Uniswap.
טוקני ממשל ומכניקת הצבעה
OpenZeppelin Governor הוא הסטנדרט. מודולרי: function releasable(address beneficiary) public view returns (uint256) { VestingSchedule memory schedule = vestingSchedules[beneficiary]; if (block.timestamp < schedule.cliff) return 0; uint256 elapsed = block.timestamp - schedule.cliff; uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start); uint256 vested = schedule.totalAmount * elapsed / vestingDuration; return vested - schedule.released; } לספירה, GovernorVotes לביצוע דרך timelock, GovernorTimelockControl לפרמטרים מתכווננים. Quorum הוא אחוז המינימום מהאספקה לתקפות ההצבעה. Compound קבע quorum של 400k COMP (4% מהאספקה). אנחנו קובעים quorum דינמי על סמך השתתפות היסטורית כדי למנוע אדישות או השתלטות של לווייתנים.
מתקפת ממשל באמצעות הלוואת פלאש — תוקף שואל טוקנים דרך הלוואת פלאש, מאציל לעצמו, יוצר הצעה או מצביע, ומחזיר את הטוקנים. ERC-20Votes עם צילום מבוסס בלוק חוסם זאת לחלוטין: חייבים להחזיק טוקנים ברגע יצירת צילום המצב, לא ברגע ההצבעה.
האצלה — מחזיקים קטנים לעתים קרובות לא מצביעים. האצלה נוזלית (כמו ב-Optimism) מאפשרת להאציל כוח הצבעה לכתובות ללא העברה. קריטי לפרוטוקולים עם הרבה מחזיקים פסיביים.
| סוג טוקן | מקרה שימוש | הסטאק שלנו |
|---|---|---|
| ERC-20 utility | תשלומים, תגמולים, גז | Solidity 0.8.x, OpenZeppelin 5.x |
| ERC-20Permit | אישורים ללא גז | EIP-2612, EIP-712 |
| ERC-20Votes | ממשל על השרשרת | Governor, TimelockController |
| ERC-1155 | רב-טוקן (NFT + פונג'יבילי) | Solidity, OpenZeppelin |
| חוזי וסטינג | נעילת צוות/משקיעים | LinearVesting, CliffVesting |
סטאק פיתוח טוקנים
חוזים: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting). אודיט טוקונומיקה: מודלים ב-Python עם סימולציות פליטה/ביקוש, cadCAD למודלים של מערכות מורכבות. פריסה וניהול: סקריפטים של Foundry, Gnosis Safe לאוצר, OpenZeppelin Defender לאוטומציה. אנליטיקה: Dune Analytics למדדים על השרשרת, Token Terminal להכנסות פרוטוקול.
מה כלול בעבודה (תוצרים)
- מודל טוקונומיקה עם מבחני לחץ (שוק דובי, יציאת לווייתן, השתלטות ממשל)
- פיתוח חוזים עם בדיקות fuzz של Foundry (אופטימיזציית גז, בדיקות reentrancy, בדיקות גלישה)
- סיכום אודיט ורשימת מקרי קצה מכוסים
- סקריפטי פריסה עם מפתחות אדמין של Gnosis Safe
- תיעוד לשדרוגים ותחזוקה עתידיים
- תמיכת ניטור ל-30 יום אחרי ההשקה
תהליך
- עיצוב טוקונומיקה — מודל אספקה, הקצאה, לוח פליטה, וסטינג. תרחישי מבחני לחץ.
- פיתוח חוזים — ERC-20 + הרחבות, וסטינג, ממשל. בדיקות fuzz של Foundry על חישובי וסטינג, ספי ממשל.
- אודיט — תשומת לב מיוחדת לוקטורי התקפה על ממשל, עקיפת וסטינג, התקפות replay של permit. אנחנו משתמשים ב-Slither ו-Echidna לאימות פורמלי.
- LBP / השקה — בחירת מכניקה, הגדרת פרמטרים, ניטור 24 השעות הראשונות.
- אחרי השקה — ניטור חלוקת אספקה דרך Dune, מדדי השתתפות בממשל, ניהול אוצר.
לוחות זמנים
- ERC-20 עם permit וממשל בסיסי: 2–3 שבועות
- חוזה וסטינג עם ביטול וצינון: 2–4 שבועות
- ממשל מלא (Governor + Timelock + Token): 4–7 שבועות
- טוקן + LBP + ממשל + וסטינג: 8–14 שבועות
אנחנו יכולים להעריך את הפרויקט שלכם תוך 24 שעות אחרי דיון בדרישות. צרו קשר כדי להתחיל את השיחה — ללא התחייבות, רק שיחה טכנית על מודל הטוקן שלכם. קבלו הצעה מפורטת המותאמת לטוקונומיקה ולצורכי הציות שלכם.