מערכת גילוי מחירים הוגנת לטוקנים חדשים

פיתוח מערכת גילוי מחירים הוגנת לטוקנים חדשים

אנו פותרים את אחת הבעיות הקשות ביותר בהשקות טוקנים — קביעה הוגנת של המחיר הראשוני. מנגנונים קלאסיים — מחיר קבוע ב-IDO או רישום ב-CEX — אינם הוגנים באופן שיטתי: מקורבים יודעים את המחיר מראש, בוטים חוטפים את הבלוקים הראשונים, וקונים קמעונאיים נכנסים בגל ההייפ. התוצאה צפויה: זינוק חד בהשקה, קריסה תוך שעות, והקהילה נשארת עם הפסדים. בפועל ראינו פרויקטים שבהם המחיר צנח ב-80% תוך 24 שעות לאחר הרישום, והרס אמון והון.

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

כיצד לבחור מנגנון גילוי מחירים הוגן?

השוואת גישות

מכירה פומבית הולנדית (מכירה יורדת)

המחיר מתחיל גבוה ויורד באופן ליניארי (או אקספוננציאלי) עד שמתמלא ביקוש מספק. המשתתפים רואים את המחיר הנוכחי ומחליטים: לקנות עכשיו או לחכות לירידה. מחיר שיווי המשקל הוא זה שבו כל ההנפקה נמכרת.

יישום ב-Solidity:

contract DutchAuction {
    uint256 public immutable startPrice;
    uint256 public immutable endPrice;
    uint256 public immutable startTime;
    uint256 public immutable duration;
    uint256 public immutable totalTokens;
    uint256 public tokensSold;

    function currentPrice() public view returns (uint256) {
        if (block.timestamp >= startTime + duration) return endPrice;
        uint256 elapsed = block.timestamp - startTime;
        uint256 priceDrop = (startPrice - endPrice) * elapsed / duration;
        return startPrice - priceDrop;
    }

    function buy(uint256 tokenAmount) external payable {
        uint256 price = currentPrice();
        uint256 cost = price * tokenAmount / 1e18;
        require(msg.value >= cost, "Insufficient ETH");
        require(tokensSold + tokenAmount <= totalTokens, "Sold out");
        tokensSold += tokenAmount;
        // transfer tokens + refund excess
    }
}

יתרונות: התמחור נקבע על ידי השוק, ללא הקצאה קבועה. חסרונות: אסטרטגיית "לחכות לרגע האחרון" יוצרת עומס בסוף — כולם מחכים למחיר המינימלי ואז קונים בו-זמנית. זהו גן עדן ל-MEV. Gnosis השתמשה במכירה פומבית הולנדית למכירת GNO. התוצאות היו מעורבות: המכניקה עבדה, אבל מלחמות גז בבלוקים האחרונים ביטלו חלק מהיתרונות למשתתפים קמעונאיים.

בריכת נזילות בוטסטראפ (LBP)

מנגנון של Balancer: פול עם משקלים משתנים. הוא מתחיל עם נטייה כבדה לטוקן הפרויקט (לדוגמה, 96/4 TOKEN/USDC) ועובר בהדרגה לחלוקת שיווי משקל (50/50). המחיר הגבוה הראשוני יורד ככל שמתרחשות מכירות ושינויי משקל.

ההבדל המרכזי מהמכירה הפומבית ההולנדית: המחיר מגיב לביקוש בזמן אמת. אין עקומת ירידה קבועה מראש — יש AMM שמתאים את עצמו לקניות ומכירות.

// Параметры LBP в Balancer v2
const poolParams = {
  tokens: [projectToken, USDC],
  startWeights: [0.96, 0.04], // 96% TOKEN, 4% USDC в начале
  endWeights: [0.50, 0.50], // 50/50 в конце
  swapFeePercentage: ethers.utils.parseEther("0.01"), // 1%
  duration: 3 * 24 * 60 * 60, // 72 часа
};

למה זה הוגן יותר: לווייתן גדול לא יכול לקנות הכל בבלוק הראשון — המשקל הגבוה הראשוני של הטוקן מעלה את המחיר באופן אקספוננציאלי בקניות גדולות. בוטים ללא יתרון מידע לא יכולים לחזות את שיווי המשקל. פרויקטים שהשתמשו ב-LBP: Gitcoin, Radicle, והשקות DeFi רבות דרך Copper. זהו הסטנדרט דה-פקטו להשקות טוקנים של DeFi ב-Ethereum. Balancer Protocol מספק קוד פתוח ל-LBP ב-GitHub.

כיצד להגן על מכירה פומבית הולנדית מפני MEV?

MEV בבלוקים האחרונים של מכירה פומבית הולנדית היא בעיה קריטית. פתרונות: מועד סיום אקראי באמצעות Chainlink VRF, או מכירה פומבית הולנדית רציפה ללא סיום קבוע. ביישומים שלנו אנו משתמשים גם ב-Flashbots Protect RPC לביצוע עסקאות פרטיות, מה שמפחית עלויות גז ב-30-50% למשתתפים. נפח הנזילות הממוצע בפרויקטי המכירה הפומבית ההולנדית שלנו הוא $200k-$500k.

TWAMM (Time-Weighted Average Market Maker)

גישה שונה מהותית: הזמנות גדולות מבוצעות בחתיכות קטנות לאורך תקופה ארוכה (שעות, ימים). אין רגע "רישום" יחיד — המחיר נוצר בהדרגה דרך מסחר רציף. FraxSwap יישמה TWAMM על השרשרת. להשקה הוגנת זה אומר: במקום "רישום ביום שישי בשעה 14:00 UTC", זה "הפצה מיום שני עד שישי, נפח קטן בכל בלוק". בוטים מאבדים את היתרון שלהם — אין רגע התקפה יחיד.

עקומת אג"ח עם Commit-Reveal

גישה נוספת: עקומת אג"ח עם שלב commit-reveal למלחמה ב-frontrunning. משתתפים בשלב ה-commit שולחים contract DutchAuction { uint256 public immutable startPrice; uint256 public immutable endPrice; uint256 public immutable startTime; uint256 public immutable duration; uint256 public immutable totalTokens; uint256 public tokensSold; function currentPrice() public view returns (uint256) { if (block.timestamp >= startTime + duration) return endPrice; uint256 elapsed = block.timestamp - startTime; uint256 priceDrop = (startPrice - endPrice) * elapsed / duration; return startPrice - priceDrop; } function buy(uint256 tokenAmount) external payable { uint256 price = currentPrice(); uint256 cost = price * tokenAmount / 1e18; require(msg.value >= cost, "Insufficient ETH"); require(tokensSold + tokenAmount <= totalTokens, "Sold out"); tokensSold += tokenAmount; // transfer tokens + refund excess } } מבלי לחשוף את הסכום. לאחר סיום שלב ה-commit — reveal: כולם חושפים את ההצעות שלהם, והמחיר הסופי נקבע על ידי העקומה בהתבסס על הביקוש הכולל.

// Фаза commit
mapping(address => bytes32) public commitments;

function commit(bytes32 commitment) external payable {
    require(block.timestamp < commitDeadline, "Commit phase ended");
    commitments[msg.sender] = commitment;
    // ETH депозит — максимально возможная сумма
}

// Фаза reveal
function reveal(uint256 amount, bytes32 salt) external {
    require(block.timestamp >= revealStart, "Reveal not started");
    bytes32 expected = keccak256(abi.encodePacked(amount, salt, msg.sender));
    require(commitments[msg.sender] == expected, "Invalid reveal");
    // записываем реальный спрос для расчёта финальной цены
}

הגנה מפני התקפות ספציפיות

התקפות Sybil

משתתף יחיד יוצר אלפי כתובות כדי להיראות כ"בסיס רחב" ולקבל נתח לא פרופורציונלי. פתרונות:

• Proof of Humanity / Worldcoin: אימות אדם ייחודי. קשה לשילוב בחוזה, אבל אפשרי דרך Merkle proofs.
• שקילת מימון ריבועית: הקצאה פרופורציונלית לשורש הריבועי של הסכום, לא לסכום עצמו. Sybil מאבדת את היתרון: 100 כתובות ב-$1 כל אחת נותנות "משקל" של $10, כתובת אחת ב-$100 נותנת "משקל" של $10. שווה ערך למשתתפים כנים, יקר עבור Sybil.
• Snapshot + רשימת היתרים: שימוש בקריטריונים מחוץ לשרשרת (פעילות על השרשרת, בעלות על NFT) ליצירת רשימת היתרים דרך Merkle tree.

מניפולציה של לווייתנים

לווייתן מגיש נפח עצום ברגע האחרון של המכירה הפומבית, ומזיז את המחיר. הגנה:

• הקצאה מקסימלית לכתובת: מגביל את החלק לכתובת. לא פותר Sybil, אבל מגביל השפעת לווייתנים מפורשת.
• התאמת מחיר הדרגתית: LBP עמיד מכנית לכך — עליית מחיר אקספוננציאלית בקניות גדולות.
• השתתפות עם נעילת זמן: משתתפים חייבים להירשם N ימים לפני המכירה הפומבית. מפחית מניפולציות ברגע האחרון.

כיצד ליישם מכירה פומבית הולנדית: מדריך שלב-אחר-שלב

1. הגדירו פרמטרים: מחיר התחלה וסיום, משך (בדרך כלל 24-72 שעות), נפח טוקנים כולל.
2. פרסו את החוזה החכם על בסיס התבנית למעלה, תוך הוספת הגנת reentrancy ובדיקה עבור // Параметры LBP в Balancer v2 const poolParams = { tokens: [projectToken, USDC], startWeights: [0.96, 0.04], // 96% TOKEN, 4% USDC в начале endWeights: [0.50, 0.50], // 50/50 в конце swapFeePercentage: ethers.utils.parseEther("0.01"), // 1% duration: 3 * 24 * 60 * 60, // 72 часа }; .
3. הקימו את הפרונטאנד עם תצוגת זמן אמת של keccak256(amount + salt) באמצעות wagmi + viem.
4. שלבו הגנת MEV: התחברו ל-Flashbots RPC ואופציונלית ל-Chainlink VRF לנקודת סיום אקראית.
5. בדקו על fork של mainnet (לדוגמה, Tenderly Fork) עם נפח של 10-20% מהצפוי.
6. בצעו ביקורת חוזה חכם — חובה ליישומים מותאמים אישית; LBP על Balancer יורש את הביקורת של Balancer.
7. לאחר המכירה הפומבית, הוסיפו נזילות אוטומטית ל-DEX (Uniswap v3 או Balancer) דרך סקריפטים.

VRGDA (Variable Rate Gradual Dutch Auction)

מנגנון שפותח על ידי צוות Art Gobblers. המחיר מתכוונן בהתבסס על הסטייה של מכירות בפועל מהלוח הזמנים המתוכנן. אם טוקנים נמכרים מהר מהמתוכנן — המחיר עולה; אם לאט — הוא יורד.

function getVRGDAPrice(
    int256 timeSinceStart, // в секундах, signed
    uint256 sold // уже продано токенов
) public view returns (uint256) {
    return targetPrice.mulWadUp(
        decayConstant.mulWadUp(timeSinceStart - getTargetSaleTime(sold + 1)).expWad()
    );
}

VRGDA מתאים להנפקות רציפות (סדרות NFT, טוקני ממשל עם הפצה מתמשכת), פחות מתאים ל-IDO חד-פעמיים.

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

כאשר אתם מזמינים מערכת גילוי מחירים הוגנת מאיתנו, אתם מקבלים:

• ניתוח טוקנומיקה ובחירת מנגנון
• פיתוח חוזה חכם עם אופטימיזציית גז ושיטות עבודה מומלצות לאבטחה
• אינטגרציית פרונטאנד (wagmi + viem) ואינטגרציית DEX (Uniswap v3, Balancer)
• הגדרת הגנת MEV ו-Sybil
• בדיקות על fork של mainnet
• ביקורת חוזה חיצונית על ידי מבקרים מוסמכים
• הזרמת נזילות אוטומטית לאחר המכירה הפומבית
• תיעוד ותמיכה טכנית במהלך ההשקה

ערימת טכנולוגיות ותהליך הפיתוח

שלב 1 (1-2 שבועות): בחירת מנגנון לטוקנומיקה הספציפית, ביקורת פרמטרים (מחיר התחלה, משך, הקצאה מינימלית/מקסימלית), ניתוח משפטי (לא כל המנגנונים ניטרליים רגולטורית בכל תחומי השיפוט).

שלב 2 (3-4 שבועות): פיתוח חוזים, אינטגרציה עם Balancer או חוזה מכירה פומבית מותאם, בדיקות על fork של mainnet.

שלב 3 (1-2 שבועות): בניית פרונטאנד השתתפות, ניטור, סקריפטים לנזילות לאחר המכירה.

שלב 4: ביקורת חוזה חיצונית — חובה, במיוחד למנגנונים מותאמים אישית. LBP על Balancer יורש את הביקורת של Balancer; יישומים מותאמים אישית לא.

גילוי מחירים הוגן משפיע ישירות על אמון הקהילה בפרויקט. טכנית זה פתיר, ובחירת המנגנון הנכון לפרויקט ספציפי חשובה יותר מיישום מושלם של מנגנון לא מתאים. צרו קשר לייעוץ — נעזור לכם לפתח מכירת טוקנים מאובטחת ושקופה על בסיס ניסיון של 5+ שנים ב-DeFi ועשרות השקות מוצלחות. הזמינו פיתוח — אנו מבטיחים שקיפות ואבטחה למכירת הטוקנים שלכם.