פיתוח מערכת רישום טוקנים בבורסת קריפטו: מבקשה ועד מסחר

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

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

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

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

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

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

מה נותן ליסטינג טוקנים מנוהל

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

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

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

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

דרכי אישור טוקנים למסחר: השוואה

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

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

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

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

כיצד מתבצע היישום: שלבי עבודת ההנדסה

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

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

חבילת המסירה: קונפיגורציות ותקנונים

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

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

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

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

כיצד היה

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

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

מה שינו ומה התקבל

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

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

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

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

מה לעשות אם הפאנל כבר פרוס?

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

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

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

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

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

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

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

שאלות טכניות והתלבטויות של לקוחות

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

האם תעמוד בגידול בזרימה?

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

אילו בדיקות חיצוניות נלקחות בחשבון?

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

מה עם ההיסטוריה של החלטות קודמות?

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

מי אחראי לאחר המסירה?

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

נדון במשימה ונחזור עם תוכנית

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

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

כדי לחזור עם תוכנית יישום, ולא עם מילים כלליות, נדרשים נתוני פתיחה:

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

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