פיתוח NFT עם תמלוגים מחייבים: חוזים והגנה

פיתוח NFT: היכן אובדים תמלוגים נאכפים

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

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

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

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

מה נותן ניכוי תמלוגים ברמת החוזה

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

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

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

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

שיטות ניכוי תמלוגים: השוואת גישות

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

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

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

שלבי הטמעת חוזה עם תמלוגים נאכפים

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

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

בסוף הלקוח מקבל חישוב תשלומים מאומת, חוזה בניהולו וסדר שינויים ברור.

מה כלול בפיתוח NFT עם הגנת תמלוגים

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

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

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

מקרה בוחן: קולקציה שבה לא הצליחו לעקוף את התמלוגים

לפני השינוי

קולקציה של 10,000 טוקנים עם תמלוגים של 5%: בחוזה היה רק אות תמלוגים לפי התקן ERC-2981, שאותו הפלטפורמה רשאית להתעלם ממנו, והחישוב עצמו חי במטא-נתונים של הליסטינג.

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

מה שינו בסכמת הניכוי

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

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

תוצאת ההטמעה

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

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

במה שונים תמלוגים בחוזה מהגדרה בפלטפורמה?

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

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

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

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

ספקות טכניים בנוגע לתמלוגים נאכפים

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

איך מחלקים תמלוגים בין כמה יוצרים של הקולקציה?

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

ארנק המקבל אינו זמין — מה קורה לתשלומים?

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

אפשר להחליף חוזה שכבר נפרס?

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

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

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

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

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