הגדרת תמלוגים ב-Magic Eden: EIP-2981, Solana, אכיפה

למה רויאליטי NFT לא מגיעים ליוצרים בעת החלפת פלטפורמה

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

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

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

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

מה נותנת הגדרה נכונה של תמלוגים במכירות משניות

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

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

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

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

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

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

תקן רויאליטי NFT והחזקה כפויה: מה לבחור

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

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

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

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

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

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

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

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

ערכת מסירה: תצורות, תרשימים ותקנונים

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

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

הערכה מתעדכנת יחד עם המכניקה: פער בין החוזה לתיעוד יקר יותר מהיעדרו.

מקרה בוחן: איך החזרנו תמלוגים במכירות משניות

לפני: שיעור התשלומים ירד בכל סבב

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

המוכרים עקפו את העמלה בהעברות ישירות של הטוקן: בסבב השלישי-רביעי חלק היוצרים ירד מ-5% ל-1–2%, וחיובים שנויים במחלוקת טופלו ידנית לפי כל לוט.

מה שינינו ומה קרה

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

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

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

במה שונה תקן החוזה מהחזקה כפויה?

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

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

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

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

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

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

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

מה לעשות עם פלטפורמות שלא בודקות תמלוגים?

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

למי שייכים מפתחות הניהול?

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

אפשר להציב תמלוגים אפס?

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

איך לשלוט בכללים אחרי עריכות?

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

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

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

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

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