פיתוח NFT-מרקטפלייס: היכן נשברת הכלכלה של הפרויקט
פיתוח NFT-מרקטפלייס לעיתים רחוקות נתקע בממשק יפה — את הכלכלה של הפרויקט שוברים שלושה דברים שמתגלים כבר אחרי ההשקה. הראשון: דליפת תמלוגים.
אם התשלום ליוצר מוטמע רק בלוגיקת המינט, עוקפים אותו דרך עטיפת טוקן או מכירה בעקיפין לחוזה — היוצר מפסיק לקבל אחוזים, והפלטפורמה מאבדת את האמון של יוצרים מרכזיים. יש להעביר תמלוגים דרך חוזה העסקה עצמו, ולא דרך ה-UI, אחרת המוכר הטכני הראשון שיבין את המערכת יאפס את התשלומים.
הבעיה השנייה — פרונטראנינג של מכרזים. בזמן שההצעה נשלחת ל-mempool, הבוט רואה אותה ומציע הצעה גבוהה יותר בצעד מינימלי, ולוקח את הלוט מידי משתתף הוגן. זה לא מתוקן ב"ממשק חכם", אלא במכניקה: הצעות מוסתרות, commit-reveal או באצ'ינג של הצעות בבלוק אחד. בלי זה המכרז הופך לתחרות של בוטים, ולא של אספנים.
השלישית — עסקאות תקועות בעומס שיא. ברגע ה-drop הרשת עמוסה, העמלה קופצת, וחלק מהעסקאות תלויות שעות: הטוקן נגבה, התשלום לא עבר, והמשתמש בפאניקה כותב לתמיכה. יש צורך בטיימאאוטים מפורשים, שליחה חוזרת עם מחיר gas נכון, ומצבי עסקה ברורים בכל שלב.
בנפרד יש להתייחס לרויалти-ספליטים בין כמה יוצרים ולמשיכת כספים — טעות בחלוקה כאן עולה ביוקר מכול. ננתח כיצד זה נסגר ברמת החוזים והתשתית.
מה מספק מרקטפלייס שתוכנן נכון
מהירות הוצאת קולקציה
חוזה הקולקציה מורכב ממודולים מוכחים: תקן הטוקן, לוגיקת המינט, הרשאות מנהל, הקפאת מטא-נתונים. פרויקט חדש הוא קונפיגורציה ופרמטרים, לא קוד מאפס, ולכן הוצאת קולקציה אורכת ימים ולא שבועות.
המטא-נתונים והתמונות עוברים לאחסון מבוזר, ובחוזה נשארת הפניה בלתי ניתנת לשינוי — הקולקציה לא "תיסחף" אם האחסון החיצוני ייפסק.
שיעור העסקאות המוצלחות
המרקטפלייס מרוויח מעסקאות שהתממשו, לא מארנקים רשומים. אנחנו סוגרים את הסיבות הטיפוסיות לקטיעות: אי-התאמה בין המחיר ליתרה עד לרגע האישור, מרוץ אחרי טוקן אחד, אישורים שנדחו.
הליסטינג, הרכישה והמכרז עוברים בטרנזקציה אחת עם סיבת דחייה ברורה — שיעור העסקאות שהושלמו עד הסוף עולה, ומקרים שנויים במחלוקת נבחנים לפי לוגים, לא "בעין".
עמידות לשיאי עומס
שיא בתחילת המכירה הוא אלפי בקשות בו-זמניות לחוזה אחד. הגבלת קצב הפניות ותור בצד השירות מסירים עומס מצומת הרשת, ומטמון המטא-נתונים מגיש כרטיסים ללא המתנה. האינדקסר אוסף אירועים למסד נתונים משלו, ולכן הקטלוג, היסטוריית המכירות והדירוגים נפתחים באופן מיידי גם בפעילות שיא.
סוג הכשל שנעלם
בנפרד אנחנו מתכננים תמלוגים ומכרזים: התשלומים ליוצר מוטמעים בלוגיקת המכירה, לא ברצון הטוב של הפלטפורמה, וההצעות נרשמות עם הבטחת החזר. נעלם סוג שלם של כשלים — "מכרו בעקיפין לתמלוגים", "איבדו את ההצעה", "הטוקן נתקע בליסטינג". כל תרחיש מכוסה בבדיקות לפני השחרור, ולכן השקת קולקציה לא הופכת לתורנות חירום.
דרכי מסחר: מחיר קבוע, מכרז, מינט עצלן
מצב המסחר קובע כיצד החוזה מקבל הצעות, מתי נסגרת העסקה ומי משלם על גז בעת הצגת הלוט. טעות ברמה הזו עולה ביוקר: מודל שגוי למשימה מוביל ללוטים ריקים, הצעות תקועות וטיפול ידני בעסקאות שנויות במחלוקת. להלן שלושה מצבים בסיסיים והמגבלות האמיתיות שלהם.
| מצב | מתי מתאים | מגבלות |
|---|---|---|
| מחיר קבוע | קולקציות מוכנות, דרופים עם ביקוש ידוע, מחזור מהיר | אין תחרות על הלוט: המחיר או שנקלע נכון, או שהמכירה נמשכת חודשים. תמחור מחדש — רק באמצעות הסרה והצגה מחדש |
| מכרז | פריטים נדירים, דברים עם מחיר לא ברור, מכירות ראשוניות | נדרשים כללי אנטי-סנייפינג ומחיר רזרבה, אחרת הלוט נמכר בפחות מהציפיות. הצעות דורשות אסקרו או חתימה — מורכבות החוזה עולה |
| מינט עצלן | דרופים המוניים, שבהם המינט עולה יותר מהמכירה עצמה | הטוקן מופיע ברשת רק ברגע הרכישה: עד אז הלוט קיים כפקודה חתומה. ביטול — באמצעות nonce, ולא מחיקת רשומה |
מה חשוב ברמת החוזה
מכרז ומינט עצלן נשענים על פקודות חתומות: המוכר לא משלם על גז בעת הצגת הלוט, אך חייב לעקוב אחר תוקף החתימה ואחר עדכניות ה-nonce. עבור מכרז מתווספים כללי הארכה בעת הצעה בדקות האחרונות ונוהל החזרת כספים למפסידים — זוהי לוגיקה נפרדת שאין להשאיר "לאחר כך".
מחיר קבוע הוא הפשוט ביותר לתמיכה, אך דווקא הוא נתקל לרוב בתמחור מחדש: ללא מנגנון עדכון הלוט, המוכר נאלץ לשלם על הסרה ורישום חדש. מינט עצלן פותר בעיה זו עבור דרופים, אך מעביר את הסיכון לרגע הרכישה — אם המטא-נתונים או הזכויות על התוכן אינם מוכנים, הקונה מקבל טוקן ללא ערך.
תמלוגים פועלים מעל כל מצב, אך ביצועם תלוי בפלטפורמה: תשלומים כפויים אפשריים רק במקום שבו החישוב מתבצע דרך החוזה שלכם, ולא דרך מחליפים חיצוניים. יש להטמיע זאת בארכיטקטורה מראש, ולא לכוונן לאחר ההשקה.
שלבי פיתוח NFT-מרקטפלייס מהיסוד
אנחנו מתחילים את העבודה לא מהקוד, אלא מניתוח הכלכלה של המרקטפלייס: מי משלם תמלוגים, איך מתחלק ההכנסה בין היוצר לפלטפורמה, והאם נדרשים חישובים בפיאט. מהתשובות תלויה סכמת החוזים — וממנה לא ניתן לאחר מכן "לפרק" חצי מהלוגיקה בלי לשכתב את שכבת האחסון.
- ביקורת המשימה ומודל המונטיזציה. מגדירים את סוגי העסקאות (מחיר קבוע, מכרז עם מחיר מינימום, מכרז הולנדי), עמלות הפלטפורמה, כללי התמלוגים, ואיך הם ישרדו החלפת בעלים של הטוקן.
- סכמת החוזים. מפרידים בין הליבה לתוספות: חוזה הטוקן, חוזה המרקטפלייס, מודול החישוב, מרשם התמלוגים. ההפרדה מאפשרת לעדכן את לוגיקת המסחר בלי לגעת בטוקנים שכבר הונפקו.
- הגדרת החישובים. מפרטים את סדר חיוב העמלות, חלוקת התמלוגים, נאמנות (escrow) עבור מכרזים, והגנה מפני ביצוע חוזר של פקודות. כאן גם — מנגנון החזר כספים בעסקה שבוטלה.
- בדיקת החישובים ברשת בדיקה. מריצים מחזור מלא: הנפקה (mint), הצגת לוט, הצעת מחיר, ביצוע, תשלום. משווים יתרות של כל המשתתפים לפני ואחרי — פער של יחידה אחת בלבד מעיד על שגיאה בסדר הפעולות.
- בדיקות חיצוניות. בנפרד בודקים מקרי קצה: הצעת מחיר שנייה לפני הסגירה, ביטול לוט עם הצעות מחיר פעילות, מכירת טוקן עם מקבל תמלוגים שהוחלף.
- חיבור הממשק. מחברים את החוזים לפרונטאנד, בודקים את תקינות חתימת העסקאות ואת הטיפול בפעולות שנדחו.
- מסירת הפרויקט. מוסרים קוד מקור, סכמת חוזים פרוסה, הוראות עדכון, וניתוח של איך לקרוא אירועים ברשת לצורך השוואת תשלומים.
כל שלב מסתיים בארטיפקט שניתן לבדוק: סכמה, דוח הרצה, יומן חישובים. המסירה — לא ארכיון עם קוד, אלא מערכת עובדת עם מסלול תמיכה ברור.
מדיניות תמלוגים וזכויות גישה לחוזים
תמלוגים בחוזה הם לא "אחוז שמוצג בממשק", אלא כלל חלוקה של כל מכירה. אנו קובעים את מקבלי התשלום, החלקים וסדר התשלומים ברמת החוזה, ולא במסד הנתונים של מרקטפלייס: כך התשלום ליוצרים נשמר בעת מכירה חוזרת בכל פלטפורמה שתומכת בתקן, ואינו תלוי במי שיזם את העסקה.
זכויות גישה נבנות לפי עקרון ההרשאות המינימליות. תפקידי המנהל מופרדים: אחד מנהל את עמלת הפלטפורמה, אחר את רשימת הקולקציות, שלישי את פרמטרי המכרזים, ואף אחד מהם אינו יכול למשוך כספים או לשנות את היגיון התשלומים לבדו.
פעולות קריטיות עוברות דרך חתימה מרובה, ועצם עדכון ההיגיון — רק דרך חוזה-מאגר עם השהיית ביצוע, כדי שלמחזיקי הטוקנים יהיה חלון זמן להבחין בשינוי חשוד ולהגיב עליו.
הגנת החוזים היא שכבה נפרדת של עבודה, ולא שורה ברשימת בדיקה:
- הפרדה בין ההיגיון למאגר: מעדכנים את ההתנהגות בלי לגעת ביתרות וברשומות הבעלות;
- חתימה מרובה על שינוי עמלות, רשימות קולקציות וכתובות מקבלי תשלום;
- השהיית ביצוע של פעולות מנהליות עם לוג אירועים פומבי;
- מגבלות על שינויים חד-פעמיים בפרמטרים — קפיצה חדה בעמלה לא עוברת בשקט;
- השהיה לעסקאות חדשות בלי לעצור תשלומים ומשיכת כספים שכבר הורווחו;
- תפקידים בלי זכות משיכת כספים: המנהל מגדיר, אך אינו שולט ביתרה;
- יומן אירועים לכל תשלום — היוצר רואה עבור איזו מכירה וכמה קיבל.
מעגל כזה ניתן לבדיקה: אנו מריצים תרחישים של "מנהל שנפרץ", "מקבל תמלוגים שהחליף כתובת", "קולקציה שהועברה להיגיון חדש" ובודקים שאף אחד מהם אינו פותח גישה לכספים של אחרים.
את סכמת התפקידים, מטריצת ההרשאות ומדיניות התמלוגים אנו מוסרים יחד עם החוזים — צוות הלקוח יכול לפתח את המרקטפלייס בלעדינו, בלי לאבד שליטה על התשלומים.
מקרה בוחן: מרקטפלייס עמד בעומס שיא המכירות בלי עסקאות תקועות
הלקוח הגיע עם מוצר מוכן: קולקציה של 10,000 טוקנים, מכניקת מכרזים ותמלוגים כבר מתוארים בתיעוד, אבל המרקטפלייס בהשקה לא עמד בגל המכירות הראשון. בעומס שיא חלק מהעסקאות נפלו בגלל timeout, והקונים ראו "נמכר" על לוט שלמעשה נשאר פנוי.
שיעור העסקאות המוצלחות בחלונות כאלה ירד מתחת ל-60% — בעוד שהעמלה מכל עסקה היא עצם מודל ההכנסה של הפלטפורמה.
מה היה לפני
העסקאות בוצעו בטרנזקציה אחת: בדיקת בעלים, העברת טוקן ותשלום תמלוגים הלכו בקריאה אחת. בשיא זה יצר תחרות על אותו לוט — מי ראשון, הוא קנה, השאר קיבלו שגיאה והלכו. התמלוגים חושבו בצד הפלטפורמה, ולכן בעת כשל התשלום ליוצר או שלא עבר, או שעבר פעמיים.
הוצאת קולקציה חדשה ארכה כמעט יממה של עבודה ידנית: מטא-נתונים ומדיה הועלו אובייקט אחר אובייקט, בלי העלאה מרוכזת.
מה שינו
המהנדסים שלנו העבירו את החישובים למודל של פקודות חתומות: הקונה חותם על כוונה, הביצוע הולך בקריאה נפרדת, והתמלוגים מוקצים באותה טרנזקציה כמו ההעברה. זה הסיר את המרוץ על הלוט ואת החיובים הכפולים — ביצוע חוזר של אותה פקודה פשוט נדחה.
מטא-נתונים ומדיה הועברו להעלאה מרוכזת עם עיבוד מקבילי, נוספה תור לאישור טרנזקציות וניסיונות חוזרים עם השהיה הולכת וגדלה.
מה נהיה
שיעור העסקאות המוצלחות בשיא עלה מ-58% ל-99.4% — אין יותר לוטים תקועים ותמלוגים "כפולים". הוצאת קולקציה הצטמצמה מ-20 שעות ל-40 דקות: הלקוח מעלה ארכיון, השאר עושה הקונ�вейер. הפלטפורמה מחזיקה פעילות בו-זמנית גבוהה פי כמה מקודם בלי התערבות ידנית ברגע האמת.
הסטאק — Seaport לפקודות ולמכרזים, מה שנותן תאימות לפלטפורמות חיצוניות ולא כובל את הלקוח לויטרינה אחת.
במה נבדל מכרז במחיר קבוע ממכרז אנגלי?
מכרז במחיר קבוע ומכרז אנגלי נבדלים לא בעיצוב הכרטיס, אלא במכניקת ההצעות וברגע סגירת העסקה. במקרה הראשון המוכר מכריז מראש על המחיר שבו הוא מוכן למכור, והקונה או מקבל אותו מיד, או מתמקח באופן פרטי — אין מרוץ הצעות פומבי.
במקרה השני ההצעות מתנהלות באופן פתוח ורציף: כל משתתף חדש חייב לעקוף את ההצעה הנוכחית, והלוט עובר למי שהחזיק מעמד הכי הרבה זמן עד לרגע הסגירה.
ההבדל המרכזי הוא במה שקובע את המחיר הסופי. במחיר קבוע התקרה נקבעת על ידי המוכר, והתוצאה צפויה: אם המחיר הולם את השוק, הלוט נמכר במהירות, ואם הוא מנופח — הוא נתקע ללא קונים.
במכרז אנגלי המחיר נוצר על ידי תחרות, והוא יכול לעלות באופן ניכר מעל מחיר הפתיחה — אבל רק אם נמצאו ללוט לפחות שני משתתפים ממש מעוניינים. קונה אחד באולם משמעו מכירה בהצעת המינימום, וזה הסיכון העיקרי של המוכר.
בנפרד יש להתייחס לרגע הסגירה. מכרז אנגלי כמעט תמיד דורש אנטי-סנייפינג: אם הצעה מגיעה בדקות האחרונות, הטיימר מוארך, אחרת כל ההיגיון של מאבק פתוח אובד, והלוט נלקח על ידי בוט במחיר המינימלי.
במכרז במחיר קבוע אין בעיה כזו — אין שם מרוץ, אבל יש סיכון שהקונה ימצא מקבילה זולה יותר בזמן שהמוכר מחזיק במחיר.
עבור הקונה הסיכונים הם מראה. במכרז אנגלי קל לשלם יותר מדי מתוך התלהבות ולהתקל בחוסר אמצעים ברגע התשלום, ולכן ההצעה נשמרת מראש. במחיר קבוע הסיכון אחר — לקנות במחיר גבוה מהשוק, אם המוכר העריך את הביקוש באופן שגוי.
בפועל, מרקטפלייסים תומכים בשני המצבים ומאפשרים למוכר לעבור ביניהם בשלב הצגת הלוט. אנו מיישמים את מכניקת ההצעות, האנטי-סנייפינג, שמירת האמצעים וסגירת העסקה באופן תקין כך שהתנהגות החוזה תתאים למה שהקונה רואה בממשק.
ספקות טכניים נפוצים לפני ההתחלה
לפני תחילת הפיתוח של NFT מרקטפלייס, לקוחות בודקים לרוב שלושה דברים: כיצד מוגנים הכספים והנכסים של המשתמשים, כיצד הפלטפורמה משתלבת עם מערכות קיימות ומה קורה לפרויקט לאחר ההשקה. להלן — תשובות לספקות טכניים שעולים בשלב ההערכה.
כיצד מובטחת האבטחה של המרקטפלייס ושל נכסי המשתמשים?
חוזים חכמים עוברים בדיקה פנימית וביקורת חיצונית לפני העלאה לרשת הראשית: אנו בודקים את לוגיקת החישובים, הרשאות תפקידים, תרחישי ביטול וטיפול בקריאות חיצוניות.
הכספים והטוקנים אינם נשמרים בשרתים שלנו — הפעולות מתבצעות ישירות דרך החוזים, והגישה לפונקציות ניהוליות חסומה באמצעות ריבוי חתימות. בנוסף, אנו מגדירים ניטור של עסקאות חשודות ומגבלות על משיכה.
כיצד המרקטפלייס משתלב עם המערכות והארנקים שלנו?
אנו מחברים ארנקים ורשתות פופולריות, שערי תשלום, CRM ואנליטיקה פנימית דרך API. אם כבר יש לכם קטלוג מוצרים, מערכות חשבונאות או חיוב — אנו מקשרים אותם למרקטפלייס כך שהנתונים לא ישוכפלו ידנית. בתחילת הדרך אנו מקבעים את רשימת האינטגרציות ובודקים כל אחת מהן ברשת בדיקה לפני היציאה לרשת הראשית.
מה כלול בתמיכה לאחר ההשקה וכמה מהר אתם מגיבים לתקלות?
לאחר השחרור אנו נשארים בקשר: עוקבים אחרי עומסים, מעדכנים חוזים בעת שינוי דרישות הרשתות, ומתקנים תקלות לפי זמני תגובה שסוכמו מראש. אנו מעבירים לצוות תיעוד, הרשאות והוראות פריסה, כדי שלא תהיו תלויים בנו במשימות שגרתיות. במידת הצורך אנו מלווים את פיתוח הפונקציונליות — מכירות פומביות, תמלוגים, רשתות חדשות.
אם נותרו שאלות לגבי תרחיש מסוים — תארו את המשימה, ונחזור עם הערכה ותוכנית עבודה.
נדון במשימה שלכם ונחזור עם הערכה
כדי שההערכה של הפרויקט תהיה ריאלית ולא "ממוצעת בשוק", אנחנו צריכים להבין את המודל שלכם: שרשראות, תקני טוקנים, לוגיקת תמלוגים, אופן קבלת התשלומים ודרישות למודרציה של תוכן. לאחר מכן אנחנו מקבעים את היקף הגרסה הראשונה ואת מה שאנחנו מוציאים ממנה במודע.
מה מבהירים כבר בהתחלה
- מודל עסקי: מכירה ראשונית, שוק משני, מכירות פומביות, דרופים, מנויים — מזה נגזרת המבנה של החוזים והעמלות.
- דרישות לתמלוגים: תשלומים מחייבים ליוצרים, חלקים של שותפים ליצירה, התנהגות בעת מכירה חוזרת ובמרקטפלייסים-אגרגטורים.
- תשלומים ורשת: הרשת הראשית, סביבות בדיקה, קבלת כספים, משיכה, עבודה עם ארנקים חיצוניים.
- מודרציה ואחסון: היכן נמצאים המטא-דאטה והמדיה, מי ואיך מסיר תוכן ממכירה, מה לעשות במקרה של תלונה על העתק.
- תפקידים והרשאות: פאנל ניהול, ניהול קולקציות, התאמות ידניות, יומן פעולות.
איך בונים את תוכנית העבודה
- ניתוח המשימה ותיאום היקף הגרסה הראשונה: מה נכלל, מה נדחה, אילו תלויות מהצד שלכם.
- תכנון חוזים וסכמת נתונים: תקני טוקנים, לוגיקת תמלוגים, הרשאות מנהל, תרחישי rollback.
- הרכבת הליבה של המרקטפלייס: חלון ראווה, כרטיסים, מסננים, ארנק, ביצוע עסקה.
- מכירות פומביות ומכניקת הצעות: כללי סגירה, אנטי-סנייפינג, מחירי רזרבה, החזר כספים בעת ביטול.
- אינטגרציות: תשלומים, אחסון מדיה, אנליטיקה, התראות, חלונות ראווה חיצוניים.
- בדיקות ברשת בדיקה: תרחישי רכישה, מכירה חוזרת, תשלום תמלוגים, התנהגות בעת תקלות.
- השקה ומסירה: פריסה, הוראות למנהלים, ליווי לאחר ההשקה.
לאחר הניתוח אנחנו חוזרים עם הערכה לפי שלבים, לוחות זמנים ותוכנית עבודה, שבה רואים מה אנחנו עושים ומה נדרש מהצוות שלכם. תארו את המשימה בצורה נוחה — נחזור עם הערכה והצעה לשלבים הבאים.