Чому продаж NFT у мобільному застосунку ламається на етапі approve
Продаж NFT у мобільному застосунку майже завжди впирається в один крок — approve токена. Користувач натискає «Підтвердити», гаманець відкриває екран підпису, транзакція вирушає в мережу — і далі тиша.
Екран висить в очікуванні, кнопка лістингу неактивна, а в історії гаманця красується зависла транзакція. Ззовні це виглядає як «застосунок зламався», хоча технічно не пройшов один виклик.
Причина в тому, що approve — це окрема транзакція, а не частина продажу. Поки вона не підтверджена в блоці, маркетплейс не має прав списати токен, і будь-який виклик лістингу відкочується.
Якщо застосунок надсилає approve і одразу за ним лістинг, друга транзакція йде з тим самим nonce і падає або зависає. Помилка підтвердження тут не баг інтерфейсу, а наслідок неправильного порядку викликів і неврахованого стану блокчейну.
Друге джерело збоїв — газ. Користувач підписав approve за низькою ставкою, транзакція застрягла в мемпулі, а застосунок уже показує «токен виставлено».
Скасування вимагає заміни транзакції з тим самим nonce і вищою ставкою — без цього зависла транзакція блокує всі подальші операції по гаманцю.
На Android і iOS поведінка гаманців різниться: частина повертає відмову мовчки, частина залишає екран підпису відкритим, і застосунок не отримує ні успіху, ні помилки.
Третій шар — комісії маркетплейсу. Роялті, плата платформи і газ списуються в момент розрахунку, і якщо застосунок рахує підсумок заздалегідь, цифри не сходяться з тим, що бачить користувач на підтвердженні. Звідси відмови на останньому кроці: людина бачить суму більшу за очікувану і закриває вікно.
Розбираємо, як це закривається: правильна послідовність approve → очікування підтвердження → лістинг, обробка завислих транзакцій і попередній розрахунок комісій до підпису.
Що дає коректно вибудуваний цикл продажу
Коректно вибудуваний цикл продажу — це коли підтвердження транзакції, лістинг і розрахунок комісій працюють як єдиний конвеєр, а не як набір розрізнених викликів.
У продажу NFT мобільний застосунок виграє не функцією «виставити на продаж», а тим, що кожен крок циклу передбачуваний: користувач бачить статус, застосунок не втрачає стан при згортанні, а мережа не змушує його наосліп натискати «підтвердити» ще раз.
Перший вимірюваний ефект — швидкість лістингу. Коли дозвіл на розпорядження активом запитується один раз і перевикористовується, а не перепитується на кожен лот, вихід товару на маркетплейс скорочується з хвилин очікування до кількох секунд. Користувач не кидає угоду на середині, а частка лотів, що дійшли до публікації, зростає.
Другий ефект — зниження відмов. Завислі підтвердження виникають там, де застосунок не відстежує заміну транзакції й не розрізняє «ще в обробці» та «відхилено мережею».
Явна обробка цих станів прибирає повторні підписи, дублі лістингів і ситуації, коли актив списано, а лот не створено.
Третій ефект — підтримка користувачів. Коли статус кожної операції видно в інтерфейсі, а помилка супроводжується зрозумілим наступним кроком, кількість звернень на теми «не продається», «списалися комісії», «зависла транзакція» падає в рази.
Навантаження на підтримку зміщується з ручного розбору кожної угоди на рідкісні нестандартні випадки.
У сумі цикл дає передбачувану воронку: користувач доходить від виставлення до продажу без втрати стану, а команда отримує менше ручних розборів і стабільне навантаження на мережу.
Варіанти реалізації: вбудований гаманець, зовнішній, гібрид
Вибір схеми підпису визначає все інше: де зберігаються ключі, хто платить за газ, як проходить 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, що вже працює. Повернемося з оцінкою та планом.
