הקמת פלטפורמת P2P מאובטחת להחלפת מטבעות קריפטו: אסקרו ודירוג

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

שירותי פיתוח בלוקצ'יין

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1376
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1350
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    798
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1090
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1035
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1131

מדוע מחליף P2P לקריפטו מאבד משתמשים בגלל סכסוכים

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

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

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

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

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

מה נותנת לוגיקת האסקרו: תוצאות מדידות עבור הפלטפורמה

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

בירור סכסוכים אוטומטי

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

זמן העסקה

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

שיעור העסקאות שהושלמו

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

פעולות חוזרות

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

השוואת מודלי סליקה: אסקרו, בוררות ידנית, היברידי

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

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

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

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

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

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

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

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

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

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

מקרה בוחן: כיצד הסרנו בירורים ידניים של סכסוכים בפלטפורמה

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

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

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

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

התוצאה

אחרי רבעון ירד שיעור העסקאות השנויות במחלוקת מ-4% ל-1.2%, הבירור הממוצע התקצר משלושה ימים לארבע שעות, ושיעור הפעולות שהושלמו עלה מ-92% ל-99.3%. משיכת הכספים לאחר אישור הרשת אורכת דקות במקום המתנה לפסיקת המפעיל.

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

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

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

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

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

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

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

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

כיצד מחושבות מגבלות העסקאות?

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

כיצד נחסמים חשבונות מרובים?

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

האם אפשר לנפח את הדירוג?

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

באיזה סדר מוחזרים הכספים?

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

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

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

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

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