פיתוח צ'יינג'ר קריפטו מפתח-אל-מפתח: מודל היברידי, מרווח, אבטחה

פיתוח חלפן קריפטו: היכן נשברת ההמרה והנזילות

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

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

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

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

מה משתנה לאחר ההטמעה: מהירות, מרווח, עמידות

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

זמן עיבוד ההזמנה ותור הפעולות

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

המפעיל מתערב רק במקום שבו הבדיקות האוטומטיות סימנו דגל של טיפול ידני; שיעור ההזמנות הללו הוא מדד מהירות העיבוד.

מחלקת התקלות שהוסרה וחישוב המרווח

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

המרווח של החלפן מחושב עבור כל עסקה: עמלה, עלות גיוס הנזילות, החלקה. הפער נראה בזמן אמת, ולכן הלימיטים מתוקנים לפי המצב בפועל ולא לפי דוח חודשי. הפרדת ההרשאות והבדיקות מיושמות בהתאם לדרישות ISO/IEC 27001.

המודל ההיברידי של החלפן לעומת עסקאות ישירות: מה לבחור

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

היברידי: מלאי עצמי בתוספת נזילות חיצונית

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

עסקאות ישירות בין משתמשים וחלפן מבוסס ספר פקודות

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

סדר ההטמעה: מהביקורת ועד למסירה להפעלה

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

1. ביקורת התשתית של החלפן. משרטטים מפת צמתים, מקורות שער ונזילות חיצוניים, מקומות אחסון המפתחות ורשימת כל מי שיש לו גישה. בנפרד מתעדים את כל מה שעדיין נעשה ביד.
2. תרשים תנועת הכספים. מתארים את המסלול מקבלת הכספים לכתובת ועד זיכוי ביתרת המשתמש: מלאי, אישורי רשת, לימיטים, עמלות, פעולות תקועות והאופן שבו הן מטופלות.
3. הגדרת הסביבות. מפרידים בין מעגלי הפיתוח, הבדיקות והעבודה, שומרים על קונפיגורציות זהות, סודות — מחוץ למאגר הקוד, ולכל מעגל מפתחות משלו. הבדיקות והניסויים מפסיקים לגעת בכספים האמיתיים.
4. כללי החישוב. קובעים ספרֵד ומרווח, את אופן החלת השער, עיגול, לימיטים לפעולה ולצמד — עם תיעוד ביומן של כל החלטה, כדי שאת החישוב ניתן יהיה להסביר ולחשב מחדש.
5. בדיקות קבלה על נתונים היסטוריים. מריצים את הכללים החדשים על רשומות עסקאות העבר ומשווים את התוצאה עד לספרה האחרונה. אי-התאמה היא סיבה לחזור לתרשים, ולא לייחס לטעות מדידה.
6. מסירה להפעלה. מוסרים תקנונים, דשבורדים, התראות על חריגות ונוהל חזרה למצב הקודם, ומאמנים את המשמרת התורנית.

מי עושה מה בכל שלב

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

ערכת המסירה: קונפיגורציות, תרשימים ומדיניות הרשאות

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

תיעוד ותרשימים

• תרשימי אינטגרציות: זרימות ההזמנות בין ליבת החלפן, מעגל הנזילות, הארנקים, מערכת מניעת ההונאה ומקורות השער — עם נקודות כשל וזמני פסק.
• קונפיגורציות הסביבות: הפרמטרים של מעגלי הבדיקות, הקדם-ייצור והייצור — לימיטים, ספרֵדים, רשימת הנכסים, הגדרות חזרה על בקשות.
• תיאור מודל הנתונים: עסקאות, רשומות הנהלת החשבונות הפנימית, יתרות והיסטוריית הסטטוסים; אופן ההתאמה מול הבלוקצ'יין.
• הנחיות למפעילים: טיפול בהזמנה תקועה, תשלום ידני, העברת צמד למצב קריאה בלבד.

תקנונים ומטריצת אחריות

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

מקרה בוחן: כיצד צמצמנו פעולות ידניות והסרנו מחלקת תקלות

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

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

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

מה היה לפני ומה נהיה אחרי

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

מה לעשות אם הפלטפורמה כבר פרוסה על פתרון מדף?

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

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

בתקופת המעבר שתי המערכות כותבות להנהלת חשבונות משותפת או מסתנכרנות בחליפין דו-כיווני, וההתאמה לכל לקוח נעשית עד להתאמה מלאה של היתרות.

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

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

ספקות טכניים: אחזקת הכספים, מרווח, בדיקות

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

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

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

התאמה אוטומטית סדירה משווה בין היתרות הפנימיות ליתרות בפועל בכתובות, ופער מעל הסף עוצר את המשיכות עד לבירור.

כיצד נבדקת תקינות הזיכויים?

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

מה קורה בעסקה שנויה במחלוקת?

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

נדון במשימה: מה נדרש להערכה ולתוכנית העבודה

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

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

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