פיתוח חוזי Launchpad: מכירות טוקנים, רשימת היתרים, Vesting

אנו מתכננים חוזי launchpad המטפלים ב-TVL של עד 50 מיליון דולר, חוסכים 30-40% בגז באמצעות רשימות היתרים מבוססות Merkle tree, וחוסמים 99% מהבוטים באמצעות מכירה פומבית הולנדית ומנגנוני אנטי-סנייפינג. אם החוזה שלך אינו מותאם, עלויות הגז להשתתפות יכולות לעלות על 100 דולר למשתמש, ובוטים יכולים לחטוף הקצאות לפני משתמשים אמיתיים. כך אנו בונים חוזים שעוברים ביקורות ועובדים עם מיליונים ב-TVL.

לצוות שלנו יש ניסיון של 5+ שנים בפיתוח חוזים חכמים והוא השלים 50+ פרויקטים, עם סכום כולל שגויס של מעל 200 מיליון דולר. חוזי ה-launchpad שלנו ניהלו מעל 50 מיליון דולר ב-TVL, ולקוחות בדרך כלל רואים חיסכון של 30-40% בגז בהשוואה לחוזים לא מותאמים. אנו מבצעים מעל 100 בדיקות יחידה ו-10 קמפיינים של fuzzing לכל חוזה, והחוזים שלנו בדרך כלל מטפלים ב-10,000+ משתתפים ללא בעיות גז.

המבנה הבסיסי

חוזה launchpad סטנדרטי כולל סבבי seed, private ו-public עם מחירים ומגבלות שונים. כדי להגביל גישה, אנו משתמשים ב-רשימת היתרים מבוססת Merkle tree — היא טובה פי 1000 מאחסון כל הכתובות על השרשרת. לכל סבב יש פרמטרים משלו: זמן התחלה, מחיר ($0.01–$0.50 לטוקן), הקצאה מינימלית ומקסימלית ($100–$5,000), תקרה כוללת (עד 5 מיליון דולר), ושורש רשימת ההיתרים. בדיקות KYC מתבצעות ברמת הפרונטאנד; החוזה מקבל רק את שורש ה-Merkle ממשתתפים מאומתים.

struct Round {
    uint256 startTime;
    uint256 endTime;
    uint256 price; // в stablecoin (6 decimals для USDC)
    uint256 minAllocation;
    uint256 maxAllocation;
    uint256 totalCap;
    uint256 raised;
    bytes32 merkleRoot; // whitelist
    bool requiresKYC;
    bool isActive;
}

הפונקציה struct Round { uint256 startTime; uint256 endTime; uint256 price; // в stablecoin (6 decimals для USDC) uint256 minAllocation; uint256 maxAllocation; uint256 totalCap; uint256 raised; bytes32 merkleRoot; // whitelist bool requiresKYC; bool isActive; } מאמתת משתמש באמצעות הוכחת Merkle. מגבלות ארנק מגנות מפני ריכוז "לווייתנים". (מידע נוסף על עצי Merkle ב-ויקיפדיה.)

למה Vesting הוא האתגר הטכני הקשה ביותר

רוב הפגיעויות ב-launchpad מסתתרות בלוגיקת ה-vesting. מקרי קצה כוללים שחרורים ב-TGE, התנהגות revoke, ואובדן דיוק. הנה יישום נכון עם cliff:

function claimable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliffEnd) return 0;
    uint256 elapsed = block.timestamp - schedule.vestingStart;
    uint256 total = schedule.vestingEnd - schedule.vestingStart;
    uint256 vested = elapsed >= total ? schedule.totalAmount : (schedule.totalAmount * elapsed) / total;
    return vested - schedule.claimed;
}

הגנה מפני Reentrancy

Reentrancy היא פגיעות קריטית ב-launchpads, במיוחד במהלך החזרים או קריאות חיצוניות. אנו משתמשים במודיפיקטור function claimable(address beneficiary) public view returns (uint256) { VestingSchedule memory schedule = vestingSchedules[beneficiary]; if (block.timestamp < schedule.cliffEnd) return 0; uint256 elapsed = block.timestamp - schedule.vestingStart; uint256 total = schedule.vestingEnd - schedule.vestingStart; uint256 vested = elapsed >= total ? schedule.totalAmount : (schedule.totalAmount * elapsed) / total; return vested - schedule.claimed; } של OpenZeppelin ועוקבים אחר תבנית Checks-Effects-Interactions. כל הקריאות החיצוניות מתרחשות בסוף, לאחר עדכוני המצב.

טיפול ב-Softcap והחזרים

אם הסכום שגויס נמוך מה-softcap (לדוגמה, 50% מהתקרה הקשיחה), מנגנון החזר מופעל: כל משתתף יכול לתבוע בחזרה את כספו, מה שמגן על משקיעים מסבבים שנכשלו.

function finalizeSale() external onlyOwner {
    require(block.timestamp > saleEndTime, "Sale not ended");
    if (getTotalRaised() < softcap) {
        status = SaleStatus.Failed;
    } else {
        status = SaleStatus.Finalized;
        paymentToken.transfer(treasury, getTotalRaised());
    }
}

הגנות נגד "לווייתנים" ובוטים

• הקצאה מקסימלית לארנק: מגבלה בסיסית (לדוגמה, 5,000 דולר למשתמש).
• מודיפיקטור אנטי-סנייפינג: 30 השניות הראשונות של סבב מוגבלות למשתתפי tier-1.
• מכירה פומבית הולנדית: המחיר יורד ב-5% כל 10 דקות, מה שהופך בוטים ללא יעילים.

אינטגרציית טוקנים

Launchpads לא מנפיקים טוקנים מיד; ההקצאות נרשמות והטוקנים מחולקים באמצעות vesting. קיימות שתי גישות: pre-funded (טוקנים מועברים לחוזה מראש) או mint-on-claim (החוזה מקבל תפקיד MINTER ומטביע בעת התביעה). mint-on-claim פופולרי בגלל גמישות בהיצע הכולל, ומפחית את נעילת הנזילות. הניסיון שלנו מראה שזה מוריד את דרישות ההון הראשוניות ב-20-30%.

תהליך העבודה

1. ניתוח: איסוף דרישות, הגדרת סבבים, מחירים, מגבלות, פרמטרי vesting.
2. עיצוב: ארכיטקטורת חוזה, Merkle tree, KYC, אנטי-לווייתנים.
3. יישום: קוד Solidity עם Foundry, בדיקות יחידה.
4. ביקורת: ניתוח סטטי (Slither), fuzzing (Echidna), סקירה ידנית, בדיקות fork על mainnet.
5. פריסה: פריסה על השרשרת היעד (Ethereum, Polygon, Arbitrum), הגדרת ניטור (Tenderly).

אנו מבטיחים שכל שלב עומד בשיטות האבטחה הטובות ביותר.

טעויות נפוצות שיש להימנע מהן

• קידוד קשיח של משכי vesting — השתמשו בפרמטרים של קונסטרוקטור.
• התעלמות משגיאות עיגול — תמיד בדקו סכום תביעה כולל מול סכום ששוחרר.
• חוסר בלוגיקת revoke — שליטה אדמיניסטרטיבית מבלי לאבד טוקנים שנצברו.

מה כלול בעבודה שלנו

תוצרים כוללים: מפרט טכני, קוד מקור של החוזה החכם, ערכת בדיקות, דוח ביקורת, סקריפטים לפריסה, תיעוד פריסה, ו-30 ימי תמיכה לאחר פריסה.

משך מחזור כולל משוער: 8-14 שבועות. העלות נעה בין 15,000 ל-30,000 דולר בהתאם למורכבות. אנו מספקים פיתוח launchpad עם ביקורת מלאה ובדיקות fork.

אם הפרויקט שלך זקוק לחוזה launchpad אמין, פנו אלינו להערכת הדרישות שלכם. אנו מספקים פיתוח מקצה לקצה — מארכיטקטורה ועד פריסה.