פיתוח פרוטוקול מסחר מבוסס כוונות

פיתוח פרוטוקול מסחר מבוסס כוונות

אנו מתמחים בתכנון ופריסה של פרוטוקולים מבוססי כוונות — ארכיטקטורה שבה המשתמש חותם על כוונה ("אני רוצה למכור 1 ETH במחיר USDC הטוב ביותר לפני 15:00 UTC"), והביצוע מואצל לפותרי בעיות (solvers) מתמחים. בניגוד למודל ה-DEX הקלאסי שבו עסקה מתארת בדיוק את הפרטים, הגישה מבוססת הכוונות מתאימה את עצמה לתנאי השוק ומגנה מפני החלקת מחיר (slippage). ארכיטקטורה זו יכולה להפחית את החלקת המחיר בעד 50% בהשוואה ל-AMM על זוגות תנודתיים, וכן לקצץ בעלויות גז באמצעות עיבוד הזמנות בקבוצות. פיתוח פרוטוקול DeFi בפרדיגמה זו דורש הבנה מעמיקה של רכיבים הן על-גבי השרשרת והן מחוצה לה.

גישה זו מיושמת ב-CoW Protocol, UniswapX ו-1inch Fusion, שלכל אחת מהן יש יתרונות וחסרונות משלה. אנו עוזרים לכם לבחור את המודל האופטימלי למשימות שלכם: מכירה פומבית בקבוצות (batch auction) לנפחים גבוהים או פותר ראשון לנזילות נמוכה. בפועל, עסקת מילוי ברשת הראשית עולה $5-15, שבנפחים גבוהים יכול להסתכם ב-$10-20 אלף בעמלות חודשיות. שימוש במילוי קבוצתי יכול להפחית את עלויות הגז בעד 40%, ולחסוך $20 אלף על הוצאה חודשית של $50 אלף. עבור פרוטוקול המעבד נפח חודשי של $10 מיליון, מילוי קבוצתי יכול לחסוך $40 אלף בגז בלבד.

כיצד פועל פרוטוקול מסחר מבוסס כוונות?

המשתמש חותם על הודעה מובנית באמצעות EIP-712 (נתונים מוקלדים הנראים ב-MetaMask). מפרט EIP-712 מבטיח חתימה מאובטחת מחוץ לשרשרת על נתונים מובנים. מבנה הזמנה מינימלי:

struct Order {
    address maker;
    address inputToken;
    address outputToken;
    uint256 inputAmount;
    uint256 minOutputAmount;
    uint256 deadline;
    uint256 nonce;
    bytes32 partialFillable;
}

נקודה מרכזית: ניהול ה-nonce מתבצע לפי סכמת struct Order { address maker; address inputToken; address outputToken; uint256 inputAmount; uint256 minOutputAmount; uint256 deadline; uint256 nonce; bytes32 partialFillable; } (כמו ב-UniswapX), המאפשרת עד 256 הזמנות פעילות בו-זמנית. ביטול הזמנה — פסילת ביט במיפוי על-גבי השרשרת ללא עסקה נפרדת.

למה לבחור במודל מבוסס כוונות?

רכיבי מערכת מרכזיים

חוזה סילוק (Settlement)

החוזה המרכזי מאמת את החתימה (שחזור EIP-712), בודק nonce ומועד אחרון, ומעביר טוקנים אטומית באמצעות word + bit. אטומיות ה-EVM מבטיחה: אם הפותר לא מאשר את ה-outputToken — כל העסקה מתבטלת.

function fill(Order calldata order, bytes calldata signature, uint256 fillAmount) external {
    address signer = ECDSA.recover(_hashTypedData(order), signature);
    require(signer == order.maker, "Invalid signature");
    require(!_usedNonces[order.maker][order.nonce], "Nonce used");
    require(block.timestamp <= order.deadline, "Expired");
    IERC20(order.inputToken).safeTransferFrom(order.maker, msg.sender, fillAmount);
    IERC20(order.outputToken).safeTransferFrom(msg.sender, order.maker, outputAmount);
    emit OrderFilled(orderHash, msg.sender, fillAmount, outputAmount);
}

רשת פותרים ותחרות

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

• מכירה פומבית על-גבי השרשרת (CoW Protocol): כל ההזמנות לתקופה מקובצות יחד, פותר מנצח אחד מבצע הכל במחיר אחד. מבטל front-running בתוך הקבוצה. מודל זה יעיל פי 3 בגז מאשר רצף של מילוי אישי.
• פותר ראשון מחוץ לשרשרת (UniswapX): הראשון שמבצע את ההזמנה על-גבי השרשרת לפני המועד האחרון מקבל את התגמול. פשוט יותר, אך עלול להוביל למירוץ MEV.

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

שילוב Permit2

במקום ה-function fill(Order calldata order, bytes calldata signature, uint256 fillAmount) external { address signer = ECDSA.recover(_hashTypedData(order), signature); require(signer == order.maker, "Invalid signature"); require(!_usedNonces[order.maker][order.nonce], "Nonce used"); require(block.timestamp <= order.deadline, "Expired"); IERC20(order.inputToken).safeTransferFrom(order.maker, msg.sender, fillAmount); IERC20(order.outputToken).safeTransferFrom(msg.sender, order.maker, outputAmount); emit OrderFilled(orderHash, msg.sender, fillAmount, outputAmount); } הקלאסי (עסקה נפרדת), אנו משתמשים ב-Permit2 — האישור נחתם מחוץ לשרשרת יחד עם ההזמנה. אישור בקבוצות (batch permit) מאפשר אישור חד-פעמי של Permit2 לכל טוקן, ולאחר מכן כל ה-dApps משתמשים בו. זהו שיפור משמעותי בחוויית המשתמש.

יישום פותר: חיפוש והגנה

הפותר מביא הצעות מחיר מ-AMMs (Uniswap, Curve, Balancer), CEX (Binance API), ספרי הזמנות על-גבי השרשרת ומהמלאי שלו. הוא בוחר את המחיר הטוב ביותר תוך התחשבות בגז ובעמלות. אם רווח < גז * מחיר גז * מכפיל בטיחות — ההזמנה נדחית. טעות נפוצה של פותרים מתחילים: לקיחת הזמנות לא רווחיות בתקווה ל-MEV — זה לא בר-קיימא.

אופטימיזציית גז

ברשת הראשית, מילוי אחד עולה $5-15 במחיר גז של $50. עבור הזמנות קטנות, זה בלתי מתקבל על הדעת. פתרונות:

• פריסה על L2 (Arbitrum, Optimism) מפחיתה את הגז פי 10-50.
• מילוי קבוצתי — מספר הזמנות בעסקה אחת מאזנות את עלות הגז הבסיסית.
• Calldata קומפקטי: בתים אפסיים זולים יותר, חוסכים 20-40% מעלות גז ה-calldata.

טבלת מחסנית ורכיבים

פיתוח חוזים חכמים משתמש ב-Solidity 0.8.x עם Foundry ו-OpenZeppelin 5. ביקורת חוזים חכמים מתבצעת על ידי צוותים חיצוניים.

תהליך

1. אנליטיקה (3-5 ימים): בחירת מודל (קבוצתי או פותר ראשון), טוקנים ושרשראות יעד, דרישות רשת פותרים.
2. עיצוב (5-7 ימים): סכמת EIP-712, מנגנון nonce, ארכיטקטורת סילוק.
3. פיתוח (6-10 שבועות): חוזה סילוק, שילוב Permit2, ספר הזמנות, פותר, חזית.
4. ביקורת: ביקורת חיצונית חובה המתמקדת בגמישות חתימה, כניסה חוזרת, nonce.
5. פריסה ותמיכה: פריסה לרשתות יעד, ניטור, תיעוד.

מה כלול

• פיתוח חוזים חכמים (Settlement, עטיפת Permit2)
• פותר מחוץ לשרשרת עם שילוב נזילות
• ספר הזמנות (REST API + WebSocket)
• חזית עם חתימת הזמנות (wagmi + viem)
• תיעוד API וחוזה
• הגדרת פריסה וניטור
• הכשרת צוות לתפעול
• תמיכת אחריות ל-3 חודשים

הערכות לוחות זמנים

MVP עם סילוק בסיסי ופותר אחד — 4-6 שבועות. פרוטוקול מוכן לייצור עם מכירה פומבית בקבוצות, רשת פותרים פתוחה ואופטימיזציית גז — 2-3 חודשים. העלות מחושבת לאחר הגדרת המודל וההיקף. עלויות MVP טיפוסיות נעות בין $25 אלף ל-$50 אלף, בעוד שמערכת ייצור מלאה עשויה לעלות $60 אלף עד $120 אלף. אנו מציעים פיתוח turnkey מעיצוב ועד ביקורת. צרו קשר להערכת פרויקט חינמית — ננתח את הדרישות שלכם ונציע ארכיטקטורה המותאמת לנפח ולמטרות שלכם.

הזמינו פיתוח פרוטוקול — תארו את המשימה שלכם, ואנו נבחר ארכיטקטורה התואמת לנפח ולדרישות שלכם. קבלו ייעוץ לדיון בפרטי הפרויקט שלכם.