פיתוח Fork מותאם אישית של GMX ל-DEX תמידי
אנו מפתחים forks של GMX עבור DEX תמידיים, תוך התאמת הארכיטקטורה לדרישות ספציפיות. GMX הוא לא רק פרוטוקול—זוהי ארכיטקטורה מוכחת: מאגר GLP כצד נגדי, ביצוע הזמנות ללא השפעת מחיר (עד לסף מסוים), ותמחור מבוסס אורקל במקום ספר הזמנות. Fork ל-GMX אינו "העתקת חוזים"; זה הבנת מערכת ניהול הסיכונים בין ספקי נזילות לסוחרים והתאמתה למטרותיך.
ניסיוננו בפיתוח בלוקצ'יין עולה על 10 שנים, ופרסנו בהצלחה 5+ forks של GMX ברשתות L2, תוך שמירה על זמינות של 99.9% של רשת ה-keeper. הזמינו פיתוח fork ל-GMX מאיתנו—נבצע ביקורת לדרישותיכם ונציע את הפתרון הארכיטקטוני האופטימלי.
כיצד GLP מנהל סיכון?
ב-GMX v1, ספקי נזילות מפקידים נכסים ב-כספת GLP—מאגר רב-נכסי המשמש כצד נגדי לסוחרים. כאשר סוחר פותח פוזיציית לונג על ETH, הוא לווה ETH מה-GLP (באמצעות מנגנון הסכום השמור). אם המחיר עולה, GLP מפסיד; הסוחר מרוויח—ולהיפך. רווחיות GLP מתואמת עם אחוז הסוחרים המפסידים. האיזון נשמר באמצעות עמלות וגודל הפוזיציות הפתוחות.
בעת ביצוע fork, עליך להחליט במפורש: אילו נכסים נכנסים למאגר? מהי ההקצאה המקסימלית לכל נכס (ב-GMX: ETH ~35%, BTC ~25%, stablecoins ~40%)? כיצד מנוהל האיזון מחדש באמצעות עמלות mint/redeem דינמיות? איזון הקצאה שגוי מוביל לסיכון חדלות פירעון של המאגר תחת לחץ שוק כיווני.
מדוע חשובה הגנה מפני מניפולציית אורקל?
GMX משתמש באגרגציית מחירים של Chainlink + Binance/Coinbase עם מרווח bid/ask. המרווח ביניהם הוא מנגנון ההגנה העיקרי. פוזיציה נפתחת במחיר ask ונסגרת במחיר bid. ב-GMX v2, הוצג שוק סינתטי באמצעות כספת GLV ומערכת keeper המבטלת MEV.
אם אתה משתמש רק ב-Chainlink ללא אגרגטור מחירים מותאם אישית, השהיה של 1–3 בלוקים במהלך תנודתיות קיצונית יוצרת חלון לארביטראז' מחירים. מספר forks של GMX v1 איבדו כספים בשל כך—סוחרים פתחו פוזיציות בידיעה מה יהיה מחיר האורקל הבא. אנו מיישמים אגרגציית multi-oracle עם מרווח דינמי וניטור סטיות.
אילו סיכונים נושא fork של GMX?
סיכונים עיקריים: ארביטראז' אורקל בזמן תנודתיות, חוב אבוד מפוזיציות שלא חוסלו, כשל ברשת keeper, ואיזון לא אופטימלי של מאגר GLP. לדוגמה, במהלך אירוע ברבור שחור ללא ADL (Auto-Deleveraging), המאגר עלול להפוך לחדל פירעון. אנו ממזערים סיכונים באמצעות keepers מיותרים, בדיקות fuzz, ופרמטרים נוקשים של ניהול סיכונים.
כיצד למנוע חוב אבוד וחיסולים?
ב-GMX, פוזיציה מחוסלת כאשר הפסדים + עמלות עולים על הבטוחה פחות liquidationFeeUsd. הבעיה: במהלך תנועות קיצוניות, פוזיציה יכולה להפוך לבעלת בטוחה שלילית מהר יותר ממה ש-keeper יכול לחסל—וכתוצאה מכך נוצר חוב אבוד. ב-v2, בעיה זו נפתרת באמצעות ADL: כאשר הניצול גבוה, הפוזיציות הרווחיות ביותר נסגרות בכפייה. fork ללא ADL מסתכן בחדלות פירעון מערכתית במהלך ברבור שחור.
ארכיטקטורת ה-Fork ושינויים מרכזיים
| חוזה | תפקיד | מה אנו משנים ב-Fork |
|---|---|---|
| Vault | אחסון נכסים, חישוב רווח והפסד | עמלות, טוקנים נתמכים |
| GlpManager | Mint/redeem של GLP | הרכב הסל, מגבלות |
| PositionRouter | ניהול הזמנות | עמלת ביצוע, השהיה |
| OrderBook | הזמנות limit/stop | גודל tick, גודל מינימלי |
| PriceFeed | אגרגציית אורקל | מקורות, לוגיקת מרווח |
| RewardRouter | Staking, חלוקת APR | לוח זמנים להנפקה |
ב-GMX v1, בסיס הקוד כתוב ב-Solidity 0.6.x. אנו מבצעים הגירה ל-0.8.x עם הגנה מפורשת מפני גלישה, הסרת SafeMath והפעלת בדיקות מובנות של המהדר.
מהי תשתית Keeper?
עבור fork בייצור, נדרשת תשתית keeper: לפחות 2–3 keepers עם failover, ניטור הזמנות ממתינות, והגדלת גז אוטומטית לעסקאות תקועות. ה-keeper הוא תשתית קריטית—אם הוא נכשל, הזמנות לא מבוצעות, חיסולים לא מתרחשים, והמאגר צובר סיכון. אנו בונים מערכות keeper ב-TypeScript עם viem, תור Redis להזמנות ממתינות, מדדי Prometheus, והתראות PagerDuty. השהיית הביצוע חייבת להיות <2 בלוקים מרגע הופעת פוזיציה הניתנת לביצוע.
פרטים טכניים של ארכיטקטורת ה-keeper
ה-keeper עוקב אחר אירועי IncreasePositionRequest ו-DecreasePositionRequest. כאשר מופיע אירוע חדש, הוא יוצר multicall עם executeIncreasePosition או executeDecreasePosition. כדי למנוע מצבי מרוץ, הוא משתמש בנעילת Redis לכל פוזיציה. במקרה של שגיאה (למשל, out-of-gas), הוא מנסה שוב עם מחיר גז מוגדל.
השוואת גרסאות GMX
| פרמטר | GMX v1 | GMX v2 |
|---|---|---|
| חיסול | קריאת keeper | Keeper + ADL |
| אורקל | Chainlink + אגרגציה | שווקים סינתטיים |
| עמלה | 0.1% עמלת מסחר | דינמית |
| הרכב המאגר | משקלים קבועים | סל גמיש |
מה כלול בעבודה
- ביקורת ותיעוד של חוזים חכמים
- הקמת תשתית keeper עם ניטור
- אינטגרציה של subgraph של The Graph להיסטוריית פוזיציות
- התאמת frontend (TradingView, wagmi, viem)
- הכשרת צוות ותמיכה לאחר ההשקה
תהליך העבודה
ניתוח (שבוע 1). ביקורת של הרשת היעד (Arbitrum, Avalanche, Base—forks של GMX חיים על L2 בשל עלויות גז), ניתוח תחרותי, טוקנומיקס.
עיצוב (1–2 שבועות). התאמת חוזים, פריסת אחסון, רשימת נכסים, פרמטרים של ניהול סיכונים (מינוף מקסימלי, OI מקסימלי לשוק).
פיתוח (6–10 שבועות). חוזים חכמים + תשתית keeper + subgraph + frontend.
בדיקות (שבועיים). בדיקות fork עם סימולציות חיסול מדורגות, השהיית אורקל, כשל keeper. בדיקות fuzz ללוגיקת PnL וחיסול.
ביקורת. שני מבקרים חיצוניים בלתי תלויים לפני mainnet.
פריסה וניטור. תחילה testnet עם keepers אמיתיים, ולאחר מכן mainnet עם פוזיציות מוגבלות ב-30 הימים הראשונים.
הערכות לוחות זמנים
fork של GMX v1 על רשת EVM חדשה עם הרכב מאגר מותאם אישית אורך 2–3 חודשים. fork של GMX v2 עם מערכת keeper מלאה ו-subgraph אורך 3–4 חודשים. לוחות הזמנים כוללים ביקורת והשקה מדורגת. העלות מחושבת באופן אישי בהתאם למורכבות האינטגרציה וההתאמות הנדרשות.
לפי תיעוד GMX, מאגר GLP משתמש בסל רב-נכסי עם הקצאה דינמית.
צרו קשר לייעוץ—נעזור להעריך את היקף העבודה ונציע את הפתרון האופטימלי לפרויקט שלכם.