מדוע מכירת NFT באפליקציה לנייד נשברת בשלב ה-approve
מכירת NFT באפליקציה לנייד כמעט תמיד נתקעת בשלב אחד — approve של הטוקן. המשתמש לוחץ "אשר", הארנק פותח את מסך החתימה, העסקה נשלחת לרשת — ומכאן שקט. המסך תלוי בהמתנה, כפתור הרישום אינו פעיל, ובהיסטוריית הארנק מתנוססת עסקה תקועה. מבחוץ זה נראה כמו "האפליקציה נשברה", אם כי מבחינה טכנית קריאה אחת לא עברה.
הסיבה היא ש-approve הוא עסקה נפרדת, ולא חלק מהמכירה. כל עוד היא לא אושרה בבלוק, ל-marketplace אין הרשאה לחייב את הטוקן, וכל קריאת רישום מתבטלת. אם האפליקציה שולחת approve ומיד אחריו רישום, העסקה השנייה נשלחת עם אותו nonce ונופלת או נתקעת. שגיאת האישור כאן אינה באג בממשק, אלא תוצאה של סדר קריאות שגוי ומצב בלוקצ'יין שלא נלקח בחשבון.
המקור השני לתקלות — gas. המשתמש חתם על approve בתעריף נמוך, העסקה נתקעה ב-mempool, והאפליקציה כבר מציגה "הטוקן הוצג למכירה". ביטול דורש החלפת העסקה עם אותו nonce ותעריף גבוה יותר — בלי זה העסקה התקועה חוסמת את כל הפעולות הבאות בארנק.
ב-Android וב-iOS התנהגות הארנקים שונה: חלק מחזירים סירוב בשקט, חלק משאירים את מסך החתימה פתוח, והאפליקציה לא מקבלת לא הצלחה ולא שגיאה.
השכבה השלישית — עמלות ה-marketplace. תמלוגים, עמלת הפלטפורמה ו-gas מחויבים ברגע החישוב, ואם האפליקציה מחשבת את הסכום מראש, המספרים לא תואמים את מה שהמשתמש רואה באישור. מכאן הסירובים בשלב האחרון: האדם רואה סכום גבוה מהצפוי וסוגר את החלון.
מפרקים כיצד זה נסגר: רצף נכון של approve → המתנה לאישור → רישום, טיפול בעסקאות תקועות וחישוב מוקדם של עמלות לפני החתימה.
מה נותן מחזור מכירה בנוי נכון
מחזור מכירה בנוי נכון הוא כאשר אישור העסקה, הרישום וחישוב העמלות פועלים כקו ייצור אחד, ולא כאוסף של קריאות מפוזרות.
במכירת NFT אפליקציה לנייד מנצחת לא באמצעות הפונקציה "להעמיד למכירה", אלא בכך שכל שלב במחזור צפוי מראש: המשתמש רואה סטטוס, האפליקציה לא מאבדת מצב בעת מזעור, והרשת לא מכריחה אותו ללחוץ בעיוורון על "אישור" פעם נוספת.
האפקט המדיד הראשון — מהירות הרישום. כאשר הרשאה לניהול הנכס מתבקשת פעם אחת ומשמשת מחדש, ולא נשאלת מחדש עבור כל לוט, יציאת המוצר לשוק מתקצרת מדקות המתנה לכמה שניות. המשתמש לא נוטש את העסקה באמצע, ושיעור הלוטים שהגיעו לפרסום עולה.
האפקט השני — הפחתת הסירובים. אישורים תקועים מתרחשים במקום שבו האפליקציה לא עוקבת אחר החלפת עסקה ולא מבחינה בין "עדיין בעיבוד" לבין "נדחה על ידי הרשת". טיפול מפורש במצבים אלה מסיר חתימות חוזרות, כפילויות של רישומים ומצבים שבהם הנכס נגבה והלוט לא נוצר.
האפקט השלישי — תמיכת משתמשים. כאשר הסטטוס של כל פעולה גלוי בממשק, והשגיאה מלווה בשלב הבא מובן, מספר הפניות בנושאים "לא נמכר", "חויבו עמלות", "העסקה תקועה" יורד פי כמה. העומס על התמיכה עובר מבדיקה ידנית של כל עסקה למקרים חריגים נדירים.
בסך הכל המחזור נותן משפך צפוי מראש: המשתמש מגיע מהעמדה למכירה בלי לאבד מצב, והצוות מקבל פחות בדיקות ידניות ועומס יציב על הרשת.
אפשרויות מימוש: ארנק מובנה, חיצוני, היברידי
בחירת סכמת החתימה קובעת את כל השאר: היכן נשמרים המפתחות, מי משלם על gas, כיצד מתבצע approve ומה המשתמש רואה בעת האישור. להלן שלוש תצורות עבודה שממש בוחרים ביניהן בשלב ההתחלה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| ארנק מובנה | מוצר המוני, קהל ללא ניסיון בקריפטו, נדרשת כניסה חלקה | המפתחות בשליטת האפליקציה — נדרש מודול חומרה לאחסון ומדיניות שחזור; approve ורישום מתבצעים בפנים, ללא קפיצות לאפליקציות צד שלישי |
| ארנק חיצוני | הקהל כבר מחזיק נכסים, חשובה משמורת עצמאית על המפתחות | חתימת העסקאות עוברת לאפליקציה זרה — חלק מהמשתמשים נושרים בחזרה; תלות עמוקה יותר בארנקים ספציפיים |
| סכמה היברידית | נדרשת גם כניסה המונית וגם תמיכה במחזיקים מנוסים | מערך כפול של תרחישי approve, רישום וטיפול בסירובים — יקר יותר בפיתוח ובבדיקות |
ארנק מובנה מספק את המסלול הקצר ביותר עד למכירה הראשונה: approve והצגת לוט מתרחשים במסך אחד, המשתמש לא מאבד הקשר. המחיר — אחריות לשמירת המפתחות ושחזור גישה מחושב היטב.
ארנק חיצוני מסיר אחריות זו מהמוצר, אך מוסיף נתק: חתימת העסקאות מתרחשת מחוץ לאפליקציה, ויש לשחזר ידנית את החזרה למסך הרצוי. סכמה היברידית מכסה את שני התרחישים, אם לצוות יש את המשאב לנהל שני ענפי לוגיקה במקביל.
בפועל הבחירה תלויה בקהל ובשאלה מי אחראי על המפתחות. תארו למי מיועד המוצר ואילו ארנקים הקהל כבר משתמש בהם — נחזור עם הערכה ותוכנית לפי הסכמה הנבחרת.
איך אנחנו בונים את מחזור המכירה: מביקורת ועד מסירה
מכירת NFT באפליקציית מובייל היא לא קריאה אחת, אלא שרשרת: אימות זכויות על הטוקן, אישור למרקטפלייס לחייב אותו, הצגת לוט, חישוב תמלוגים ועמלות, והעברה סופית. טעות בכל שלב — עסקה תקועה, גז שנגבה בלי מכירה, או טוקן שנתקע בסטטוס "למכירה". לכן אנחנו מפרקים את המחזור לשלבים עם תוצאה ניתנת לבדיקה בכל אחד.
- ביקורת הסכימה הנוכחית. בודקים איך האפליקציה עובדת כיום עם הארנק והחוזים: היכן נחתמת העסקה, מי משלם את הגז, איך מטופלת סירוב המשתמש. מתעדים צווארי בקבוק — בדרך כלל אלו אישורים חוזרים והיעדר סטטוסים בין השלבים.
- תכנון הקריאות. מפרקים את המכירה לרצף: approve לטוקן ספציפי במקום בלתי מוגבל, בדיקת בעלים, ליסטינג, ביטול. לכל קריאה מגדירים מה המשתמש רואה בממשק ומה קורה בעת ניתוק החיבור.
- הגדרת עמלות. מחשבים תמלוגים ליוצר, עמלת מרקטפלייס ופלטפורמה, חלוקת תשלומים בין מקבלים. את כל השיעורים מוציאים לקונפיגורציה ולא לקוד — ניתן לשנות אותם בלי לבנות מחדש את האפליקציה.
- בדיקה ברשת טסט. מריצים את המחזור המלא על טוקנים לטסט: מכירה מוצלחת, סירוב לחתום, חוסר באמצעים, ליסטינג חוזר של טוקן שכבר נמכר. כל תרחיש — עם מצב צפוי של יתרה וסטטוס לוט.
- טיפול בסירובים ושחזור. מלמדים את האפליקציה להוביל את המשתמש לתוצאה: אם העסקה לא עברה, מציגים את הסיבה ומציעים לחזור על השלב, ולא להתחיל את המחזור מחדש.
- בנייה ל-iOS ול-Android. בודקים התנהגות זהה בשתי הפלטפורמות: חזרה מהארנק, שחזור סשן, עדכון סטטוס הלוט לאחר אישור.
- מסירה. מוסרים קוד מקור, סכימת קריאות, קונפיגורציית עמלות והוראות להוספת רשתות וטוקנים חדשים.
תארו את סכימת המכירה הנוכחית שלכם — נחזור עם הערכה ותוכנית עבודה לפי שלבים.
מה הלקוח מקבל לידיו לאחר ההטמעה
לאחר ההטמעה, מכירת NFT באפליקציית המובייל מפסיקה להיות תלויה במהנדס אחד ש"זוכר איך הכל בנוי כאן". כל ההחלטות מתועדות בארטיפקטים: ניתן להעביר אותם לצוות אחר, לבדוק אותם בסקירה, ולשחזר לפיהם את העבודה בלי לחפור בהתכתבויות.
- תצורות סביבה: פרמטרים של רשתות וחוזים, כתובות קולקציות, מגבלות עמלות וכללי עיגול — בקבצים מנוהלי גרסאות, ולא בקוד המסך.
- תרשימי קריאות: רצף approve → הצגה ברשימה → אישור רכישה, נקודות המתנה לאישור וטיפול בעסקאות שנדחו בכל שלב.
- מדיניות גישה: תפקידים להנפקת קולקציות, שינוי עמלות ופעולות ידניות, עם יומן של מי ומתי שינה אותם.
- מודל העמלות: מאיפה מגיעים הפלטפורמה, הרויאלטי והעמלה ברשת, איך הם מצטברים לסכום הסופי ואיפה הם מוצגים למשתמש לפני האישור.
- טיפול בכשלים: תרחישים במקרה של חוסר באמצעים, approve שנדחה, עסקה שבוטלה וניסיון חוזר — עם מצבים ברורים בממשק.
- תיעוד האינטגרציה: תיאור החוזים, פורמטי התגובות והתנהגות האפליקציה ב-iOS וב-Android, כולל ההבדלים בתשלומים בין הפלטפורמות.
- נהלי תמיכה: רמות תגובה, סדר עדכון כתובות החוזים והוצאת תיקונים בלי לעצור את המכירות.
כל סעיף סוגר סוג מסוים של תקלה: approve שנתקע, עמלה כפולה, ביטול לאחר חיוב. צוות התחזוקה מקבל לא אוסף קבצים, אלא מערכת עובדת שבה רואים מה לשנות ובמה זה נבדק. תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לפי הארטיפקטים האלה.
מקרה בוחן: כיצד צומצם שיעור האישורים התלויים פי שלושה
לקוח הגיע עם הכאב הקלאסי של מרקטפלייס: המשתמש לוחץ "קנה", האפליקציה מציגה "שולחים את העסקה" — ומכאן שקט. חלק מהפעולות נתקעו בסטטוס "ממתין לאישור": הרשת כבר דחתה את ההעברה, אך הממשק המשיך לסובב את המחוון.
האדם סגר את האפליקציה, פתח מחדש, ניסה שוב — וקיבל או חיוב כפול, או ליסטינג שאבד. התמיכה טבעה בפניות חד-גוניות "הכסף חויב, ה-NFT לא הגיע".
OpenSea ומרקטפלייסים אחרים פותרים זאת בצד שלהם, אך הלקוח המובייל מחויב לעבור כל תוצאה באופן תקין. פירקנו את השרשרת: approve על חוזה הטוקן, ואז safeTransferFrom בעת המכירה.
הבעיה לא הייתה בבלוקצ'יין, אלא בכך שהאפליקציה ראתה את העסקה כמושלמת ברגע השליחה לרשת, בלי להמתין לאישור ובלי לעקוב אחרי שינוי הסטטוס.
כתבנו מחדש את מחזור החיים של הפעולה: כל פעולה קיבלה מזהה ומצב משלה, האפליקציה נרשמת לשינויים ומעדכנת את המסך לפי רגע האישור בפועל, ולא לפי טיימאאוט. אם הרשת דחתה את ההעברה — המשתמש רואה מיד את הסיבה וכפתור ניסיון חוזר, והליסטינג לא הולך לאיבוד. בנפרד טיפלנו בלחיצות חוזרות: כל עוד הפעולה בתהליך, הכפתור חסום ברמת המצב, ולא ויזואלית.
התוצאה לאחר חודש של תצפיות: שיעור האישורים המוצלחים עלה מ-71% ל-96%, הפעולות התלויות הצטמצמו פי שלושה, ופניות לתמיכה בנושא "העסקה לא עברה" ירדו בכ-60%. הדחיות מגיעות כעת עם סיבה מובנת, ולא כתקיעה שקטה — זה הסיר את העומס העיקרי מהקו הראשון.
במה שונה approve מרישום ומה לעשות אם הארנק כבר פרוס
Approve ורישום הם שני שלבים שונים שלעתים קרובות מבלבלים ביניהם, מכיוון ששניהם נראים כמו "אישור בארנק". Approve הוא מתן הרשאה חד-פעמית לחוזה החכם של מרקטפלייס לחייב טוקן מסוים מכתובת הבעלים.
כל עוד ההרשאה לא ניתנה, המרקטפלייס פיזית לא יכול להעביר את הטוקן לקונה, גם אם הלוט כבר נוצר ונראה בקטלוג. רישום הוא כבר רשומת מכירה: האפליקציה קובעת מחיר, תקופה, מטבע תשלום ומעבירה את הנתונים למרקטפלייס כדי שהלוט יופיע בתוצאות.
ההבדל עקרוני: approve עונה על השאלה "האם לפלטפורמה יש זכות לנהל את הטוקן", רישום — "באילו תנאים הטוקן נמכר".
הניואנס השני הוא היקף ההרשאה. Approve ניתן либо על טוקן מסוים אחד, либо על כל הקולקציה, וזה משפיע ישירות על מספר האישורים שהמשתמש יראה. הרשאה על הקולקציה חוסכת טרנזקציות במכירה המונית, אך מרחיבה את זכויות הפלטפורמה על כל טוקני הסדרה — חלק מהקהל לא מקבל זאת.
אנחנו כברירת מחדל שמים approve ממוקד על טוקן מסוים ומשאירים את הבחירה בהגדרות, ובממשק מציגים מה בדיוק ובאיזה היקף המשתמש מאשר.
אם הארנק כבר פרוס ועובד, הטמעת לוגיקה חדשה לא דורשת לכתוב מחדש את האפליקציה כולה. אנחנו מוסיפים שכבת עבודה עם חוזים מעל מודול החתימה הקיים: היא מרכיבה טרנזקציית approve, ממתינה לאישור ברשת, בודקת ש-allowance מוגדר, ורק לאחר מכן שולחת את הרישום.
שכבה כזו מבודדת — תרחישי השליחה והחתימה הנוכחיים ממשיכים לעבוד, והתרחיש החדש של מכירה מתחבר אליהם כענף נפרד.
בנפרד אנחנו מכסים מצבים שלרוב שוברים את המכירה: המשתמש דחה את ה-approve, הטרנזקציה נתקעה בממפול, ההרשאה כבר ניתנה קודם לכן, הרישום בוטל לפני הרכישה. כל מצב מקבל מסך משלו וטקסט ברור, ולא שגיאה כללית. זה מסיר את עיקר הפניות לתמיכה — האדם רואה באיזה שלב הוא נמצא ומה לעשות הלאה.
אנחנו בודקים את התרחיש ברשת בדיקה לפני השחרור: מחזור מלא approve → רישום → רכישה → תשלום, ובנוסף ביטול רישום ומכירה חוזרת. רק לאחר מכן הלוגיקה עוברת לפרודקשן, כדי שהמשתמש האמיתי הראשון לא יתקל במקרה לא מטופל.
ספקות טכניים נפוצים של לקוחות
מכירת NFT באפליקציה לנייד היא שרשרת של טרנזקציות: תחילה הארנק מקבל הרשאה לטוקן (approve), לאחר מכן המרקטפלייס מציג את הלוט, ובעת המכירה נגבים עמלת הפלטפורמה והתמלוגים של היוצר.
כל שלב הוא חתימה נפרדת ותגובת רשת נפרדת, ולכן תקלות כאן אינן נדירות: המשתמש סגר את האפליקציה בין האישורים, הטרנזקציה נתקעה, והטוקן כבר נגבה. להלן הספקות שעולים לרוב בשלב ההערכה, וכיצד אנו סוגרים אותם ברמת הארכיטקטורה.
כיצד מובטחת האבטחה של מפתחות פרטיים וחתימות?
המפתחות אינם יוצאים מהמעגל המאובטח של המכשיר: ב-iOS זה Secure Enclave, וב-Android זה Keystore חומרתי. החתימה נוצרת באופן מקומי, והאפליקציה מקבלת רק את התוצאה, ולא את המפתח עצמו.
עבור פעולות ללא גישה קבועה אנו משתמשים בארנקים עם הפרדת תפקידים ואישור באמצעות ביומטריה — פגיעה במכשיר אחד אינה פותחת גישה לשאר הנכסים.
האם המכירה עובדת באופן זהה ב-iOS וב-Android?
הלוגיקה של הטרנזקציות אחידה, אך הפלטפורמות מטילות מגבלות: כללי החנויות לגבי מוצרים דיגיטליים, מנגנונים שונים של משימות רקע ושחזור פעולות שהופסקו.
אנו מוציאים את החתימה והשליחה לשכבה משותפת, ומבודדים את ההבדלים הפלטפורמיים — התנהגות הארנק זהה, ותרחישים בעייתיים אנו סוגרים באמצעים מקוריים של כל מערכת.
כיצד מחושבות עמלות המרקטפלייס והתמלוגים?
עמלת הפלטפורמה והתשלום ליוצר מוטמעים בחוזה החכם ונגבים באופן אטומי ברגע העסקה — המשתמש רואה את הסכום הסופי לפני האישור, ללא חיובים נסתרים. אנו בודקים את החישוב ברשת בדיקה ומשווים את הזיכוי בפועל לזה הצפוי, כדי שפערים לא יצופו כבר בפרודקשן.
מה קורה בעת תקלת רשת או טרנזקציה שנתקעה?
האפליקציה שומרת את מצב כל פעולה ובהפעלה הבאה משווה אותו לבלוקצ'יין: שלבים מאושרים אינם חוזרים על עצמם, ושלבים שנתקעו נשלחים מחדש עם עלות הגז העדכנית. המשתמש רואה סטטוס ברור במקום "נתקע", וביטול הליסטינג מחזיר את הטוקן לארנק ללא פעולות ידניות.
תארו את המשימה שלכם — נחזור עם הערכה ותוכנית לכל אחד מהתרחישים הללו.
נדון במשימה שלכם ונחזור עם תוכנית
הדיון מתחיל לא בבריף של עשרה עמודים, אלא בניתוח המצב הנוכחי: אילו רשתות ומרקטפלייסים כבר נתמכים, כיצד בנוי הארנק, והיכן בדיוק נשברת השרשרת approve → ליסטינג → מכירה. חשוב לנו להבין מה כבר עובד בפרודקשן ומה עוד צריך לתכנן — מכך נגזרים היקף העבודה וסדר השלבים.
לאחר מכן מקבעים את הדרישות לעמלות ולתפקידים: מי משלם גז, כיצד מתחלקים התמלוגים, ומה רואה הקונה במסך האישור. לאחר מכן נחזור עם הערכה ותוכנית — בלי לוחות זמנים מופשטים, עם פירוט לפי שלבים ונקודות ברורות שבהן נדרשת ההחלטה שלכם.
- ניתוח המשימה. בוחנים את האפליקציה הנוכחית, את האינטגרציות עם הבלוקצ'יין ואת תרחישי מכירת ה-NFT ב-iOS וב-Android.
- חידוד הדרישות. מתאמים את הרשתות הנתמכות, המרקטפלייסים, סכימת העמלות וכללי התמלוגים.
- הערכת היקפים. מחשבים את מאמץ העבודה לכל שלב, מסמנים סיכונים ותלויות בשירותים חיצוניים.
- תוכנית עבודה. מפרקים לשלבים עם תוצאה ברורה בכל אחד: אינטגרציה, ליסטינג, מכירה, תשלומים.
- תיאום. דנים בתוכנית, מתקנים סדרי עדיפויות ומקבעים את סדר ההשקה.
- התחלה. מתחילים בשלב שנותן תוצאה ניתנת לבדיקה מוקדם יותר מאחרים.
בסיום תקבלו הערכה ותוכנית עבודה עם שלבים, תלויות ונקודות בקרה — מסמך שאפשר לקבל לפיו החלטה, ולא הבטחות כלליות. תארו את המשימה: אילו רשתות ומרקטפלייסים נדרשים, כיצד בנויה כעת מכירת ה-NFT, ומה כבר עובד. נחזור עם הערכה ותוכנית.