פיתוח טראקר תיק קריפטו מקצה לקצה

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

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

שאלות נפוצות

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

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1365
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

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

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

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

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

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

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

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

אפקט מדיד: דיוק תחזוקת הקריפטו ומהירות ההתאמה

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

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

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

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

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

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

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

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

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

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

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

סדר העבודות: מביקורת מקורות ועד מסירת המערכת

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

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

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

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

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

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

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

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

מה היה לפני ההטמעה

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

מה שינו

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

מה נהיה אחרי

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

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

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

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

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

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

לאחד מהשירותים אין בכלל API — מה עושים איתו?

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

למי שייכים הנתונים ומה עם ההרשאות לאחר המסירה?

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

מה לעשות אם התחזוקה כבר פרוסה בטבלאות ובארנקים?

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

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

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

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

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

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

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

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

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

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

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

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

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