תשלום Stablecoin אינו בינארי: סופיות, זיכוי והתאמה כספית

1. מפרידים בין ארבע אמיתות

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

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

2. בונים מכונת מצבים שאפשר לשחזר

מסלול שימושי כולל לפחות created, quoted, submitted, observed, confirming, accepted, settled, exception ו-refunded. כל מעבר נרשם כאירוע בלתי־ניתן לעריכה עם זמן, גרסת מדיניות וסיבה. אם observer אחר מפיק שוב את אותו אירוע, מפתח idempotency מונע זיכוי כפול.

המעבר מ־submitted ל־observed דורש יותר מהופעת hash: chain ID נכון, חוזה token מאושר, receipt מוצלח, אירוע Transfer או אירוע ייעודי, יעד וסכום תואמים. כאשר smart account, router או batch מעורבים, from ו-to החיצוניים אינם מספיקים. יש לפרש את הלוגים ואת השפעתם הכלכלית.

• שומרים block number ו-block hash.
• מקשרים כל תצפית ל-payment intent אחד.
• מתעדים underpayment, overpayment ונכס שגוי כחריגים.
• מפרסמים webhooks ממכונת המצבים, לא ישירות מ-RPC.

3. סופיות היא מדיניות, לא מספר קסם

אישור אחד אינו בעל אותה משמעות בכל רשת. במערכות proof-of-stake יש הבדל בין inclusion, confirmations וה-finality שמגדיר הפרוטוקול. ברשתות L2 יש לבחון גם את מצב ה-sequencer ואת מסלול הפרסום או ההוכחה ל-L1. לכן רשימת רשתות נתמכות צריכה לכלול adapter למדדי סופיות ולא רק RPC URL.

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

4. זיכוי מוקדם הוא מוצר אשראי

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

עיצוב טוב מפריד בין pending balance, available balance ו-reserve. במקרה של reorg או כשל סופי אין מוחקים את האירוע; יוצרים posting נגדי ומעבירים את העסקה לטיפול. כך הלקוח והצוות הפיננסי רואים סיפור עקבי במקום סטטוס שנעלם.

5. Ledger פנימי נשאר מקור האמת העסקי

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

אל תערבבו יתרה on-chain עם יתרת לקוח. כתובת custody אחת יכולה להחזיק נכסים עבור אלפי intents, וכתובת ייעודית אחת יכולה לקבל כמה תשלומים. ההקצאה היא תוצאה של כללי attribution, לא של balanceOf בלבד. זה המקום שבו מוצר תשלומים הופך מממשק ארנק למערכת פיננסית.

6. התאמה כספית היא לולאת בקרה

תהליך reconciliation משווה ארבע שכבות: intents צפויים, אירועי chain מפוענחים, postings ב-ledger ויתרות custody בפועל. הבדיקה צריכה לפעול באופן רציף ובסוף כל תקופת דיווח. סכום חסר, נכס לא נתמך, posting ללא ראיה או יתרת treasury שאינה מתיישבת הופכים לחריג עם בעלים ו-SLA.

לא די להפעיל מחדש indexer. rebuild צריך להפיק אותה תוצאה מאותו גובה בלוק, והמערכת צריכה לזהות fork או שינוי decoding. snapshot יומי, checkpoints וגרסת decoder מאפשרים לשחזר. התאמה טובה גם מודדת aged pending transactions כדי למנוע כסף תקוע שאיש אינו בודק.

7. תכנון רב־רשתי דורש חוזה אחיד ו-adapters שונים

API אחיד יכול להחזיר observed, accepted ו-settled בכל רשת, אך הדרך להגיע אליהם שונה. adapter אחראי ל-chain identifiers, token allowlist, decoding, finality signal, reorg handling ו-health. שכבת המדיניות מעליו מחליטה מתי לשחרר ערך.

לפני הוספת רשת בודקים happy path וגם שיבושים: RPC מאחר, בלוק מוחלף, receipt חסר זמנית, token מזויף, decimals שגויים ו-webhook שנמסר פעמיים. התמיכה ברשת מסתיימת רק כאשר finance יכול להתאים אותה וה-support יכול להסביר אותה.

8. מדדים שמחברים מוצר, סיכון וכסף

הדשבורד צריך להציג זמן מ-submit ל-observed, מ-observed ל-settled, שיעור exceptions, reorgs, סכום pending לפי גיל, פערי reconciliation וזיכוי מוקדם פתוח. לצד אלה מודדים conversion ונטישה כדי לא להפוך בטיחות לעיכוב בלתי־נראה.

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