Сторінка NFT-дропу має відповідати не лише на запитання «який вигляд має робота?», а й на важливіше: що саме отримає покупець, скільки це коштуватиме та від чого залежить доступ до контенту. Гарна ілюстрація й короткий анонс не замінюють зрозумілих умов.
Для автора або невеликої команди головне завдання — відокремити підтверджені факти від планів. Нижче розглянемо, як підготувати бриф, пояснити права й технічні обмеження та перевірити текст до публікації.
Почніть із брифу: що саме покупець отримує за NFT
Перш ніж писати рекламний опис, складіть внутрішній документ із фактами про випуск. Зазначте назву мережі, кількість токенів, спосіб і дату мінтингу, ціну, адресу контракту після її підтвердження та місце публікації. Окремо опишіть пов’язану роботу, спосіб доступу до неї та умови використання.
Додайте до брифу відповіді на запитання: хто створив контент і чи має проєкт дозвіл його використовувати; які можливості доступні відразу; хто відповідає за підтримку; що станеться, якщо обіцяний сервіс перестане працювати. Якщо відповіді ще немає, позначте питання як відкрите, а не заповнюйте прогалину припущенням.
Для необов’язкового редакційного зворотного зв’язку можна використати OhlasAi: робочий простір дає змогу надати бриф і отримати пропозиції щодо тексту з урахуванням мети та аудиторії. Попросіть знайти нечіткі пояснення пропозиції та запропонувати зрозумілішу структуру. Передавайте лише матеріали, якими маєте право ділитися, без приватних ключів, seed-фраз і персональних даних покупців. Така редактура не перевіряє права на твір або безпеку коду.
Перетворіть бриф на короткий блок «Що ви отримуєте». Наприклад: «Один токен із колекції та доступ до завантаження цифрового зображення через сайт проєкту». Далі окремо поясніть, чи включена ліцензія, як працює доступ і які умови можуть його обмежувати. Цей приклад придатний лише тоді, коли команда справді може підтвердити кожне твердження.
Токен, файл і ліцензія: розділіть три різні об’єкти
NFT — це токен, облік якого ведеться за правилами відповідного смартконтракту. Пов’язаний із ним файл може зберігатися окремо, а дозвіл використовувати творчий твір визначається умовами ліцензії або іншою правовою домовленістю. Купівля токена сама по собі не означає автоматичного отримання авторських прав на зображення, музику чи інший контент.
Технічний стандарт ERC-721: Non-Fungible Token Standard описує, зокрема, облік власників, передавання токенів і дозволи операторам. Його розширення метаданих ERC721Metadata є необов’язковим: воно передбачає name, symbol і tokenURI, який може вказувати на JSON із метаданими. Сам стандарт не встановлює, яку ліцензію покупець отримує на пов’язаний твір.
У матеріалі WIPO Non-fungible tokens (NFTs) and copyright автор Андрес Гуадамус пояснює різницю між придбанням NFT та отриманням авторських прав. Це корисне аналітичне пояснення, а не юридичний висновок для конкретного дропу.
Замість розпливчастого «ви володієте мистецтвом» напишіть, що саме дозволено: наприклад, показувати зображення в особистому профілі або використовувати його лише некомерційно. Якщо дозволене комерційне використання, визначте його межі; якщо права передаються за окремою угодою, не називайте звичайну купівлю токена таким передаванням.
Умови також мають пояснювати, кому надається ліцензія, коли вона починає діяти та що відбувається після перепродажу токена. Не припускайте, що всі права автоматично переходять до нового власника: сформулюйте це відповідно до фактичної угоди. Для складних або комерційно важливих випадків залучіть юриста, який врахує застосовне право та права всіх авторів.
Де зберігається контент і від чого залежить доступ
Покупцеві важливо знати, чи міститься сам файл у блокчейні, чи метадані або контракт посилаються на зовнішній ресурс. Не називайте контент «назавжди збереженим у блокчейні», якщо там розміщене лише посилання. Поясніть окремо, де зберігаються метадані, де лежить повний файл і хто відповідає за їхню доступність.
Якщо файл розміщений на сервері проєкту, доступ може залежати від роботи сервера, домену та облікової системи. Якщо використовується децентралізована система зберігання, назвіть її та поясніть, як команда забезпечує доступність файлу: сам факт використання такої системи не замінює плану підтримки. Не обіцяйте необмежений доступ без перевіреного механізму його забезпечення.
Опишіть шлях користувача простими кроками: як підтвердити володіння токеном, де знайти файл і чи потрібен сторонній сервіс. Якщо доступ діє лише під час володіння NFT, це варто сказати прямо. Якщо власник може завантажити копію, поясніть, чи впливає подальший продаж токена на право користуватися нею згідно з ліцензією.
У FAQ передбачте проблемні ситуації: сайт недоступний, гаманець не підключається або посилання на файл не працює. Вкажіть канал підтримки та реалістичний порядок звернення. Не просіть користувача надсилати seed-фразу чи приватний ключ: вони не потрібні для звичайного підтвердження володіння токеном.
Ціна мінтингу, комісії та роялті: що потрібно пояснити заздалегідь
Мінтинг — це створення токена відповідно до правил контракту. На сторінці зазначте ціну в конкретній валюті або токені та мережу платежу. Окремо попередьте про комісію мережі за транзакцію: вона може змінюватися і не обов’язково входить до оголошеної ціни. За наявності інших платежів, зокрема комісії платформи, назвіть їх і поясніть, хто їх сплачує.
Наприклад, формулювання «ціна — 0,02 ETH плюс комісія мережі» корисніше за «повна вартість — 0,02 ETH», якщо газ оплачується додатково. Не наводьте фіксований розмір мережевої комісії як гарантію: покупець має перевірити суму в гаманці перед підтвердженням операції. Також вкажіть, чи є ліміт токенів на гаманець і чи передбачено повернення коштів, якщо це визначено умовами продажу.
Роялті — окрема тема від первинної ціни. Якщо команда очікує винагороду з перепродажів, наведіть заявлений відсоток і поясніть, що його фактичне стягнення залежить від механізму контракту та правил торговельного майданчика. Не подавайте роялті як гарантований платіж у кожній можливій угоді. Покупцеві також варто знати, що комісії та умови вторинного продажу слід перевіряти на обраному майданчику.
До запуску звірте всі цифри з налаштуваннями контракту й платформи. Якщо ціна або час продажу можуть змінитися, вкажіть, де команда публікуватиме офіційні оновлення. Актуальна адреса контракту має бути однаково подана на офіційному сайті та в перевірених каналах проєкту: це допоможе користувачам не перейти до підробленого дропу.
Як описати дорожню карту без обіцянок доходу й гарантованих переваг
Дорожня карта корисна, коли відділяє готовий продукт від намірів. Розбийте її на три категорії: вже доступно, перебуває в роботі та розглядається на майбутнє. Для кожного запланованого пункту поясніть, від чого залежить виконання, хто за нього відповідає і коли команда планує повідомити про стан роботи. Дата оцінки не повинна виглядати як безумовна гарантія запуску.
Порівняйте два формулювання. «Власники отримають доступ до гри наступного місяця» створює конкретне очікування. Якщо гри ще немає і дата не підтверджена, точніше написати: «Команда розробляє прототип гри; доступ для власників розглядається, рішення та строки ще не визначені». Якщо перевага вже працює, навпаки, поясніть спосіб і умови її отримання.
Уникайте заяв на кшталт «ціна токена зросте», «дохід гарантований» або «роялті окуплять покупку», якщо для них немає підстав. Навіть популярність проєкту не гарантує ліквідності: власник може не знайти покупця за бажаною ціною. NFT варто описувати через реальні властивості й ризики, а не через припущення про майбутню вартість.
Якщо проєкт передбачає членство чи доступ до подій, уточніть тривалість, обмеження кількості учасників і залежність від сторонніх організаторів. У разі скасування або зміни плану повідомляйте про це тим самим офіційним каналом, що й про запуск. Необхідність юридичної або податкової консультації залежить від конкретної моделі й обставин учасників.
Перевірка перед публікацією: що може підказати ШІ, а що перевіряє команда
ШІ може допомогти знайти неоднозначні речення, згрупувати запитання для FAQ або запропонувати простіший виклад. Корисний запит: «На основі цього брифу познач твердження, які можуть звучати як гарантії, та запропонуй нейтральні формулювання; не додавай нових фактів». Навіть після такого запиту кожну пропозицію потрібно звірити з документами проєкту.
На сторінці https://www.ohlas.uk/about OhlasAi описує принцип, за яким користувач переглядає та коригує рекомендації ШІ й ухвалює остаточне рішення. У редакційному процесі це означає розподіл відповідальності, а не автоматичне підтвердження правильності: автор перевіряє склад пропозиції, технічний учасник — фактичну поведінку контракту та доступ до контенту, а юрист за потреби — правові формулювання.
Фінальний чекліст перед запуском:
- Звірте мережу, адресу контракту, кількість токенів, ціну та час продажу з офіційними налаштуваннями.
- Переконайтеся, що опис окремо пояснює володіння токеном, доступ до файлу та обсяг ліцензії, включно з умовами перепродажу.
- Перевірте посилання на метадані й контент, спосіб підтвердження володіння та канал підтримки.
- Розкрийте відомі комісії, умови роялті й можливі обмеження майданчика; не приховуйте змінні витрати.
- Позначте плани як плани, приберіть непідтверджені гарантії та призначте відповідального за оновлення сторінки.
Попросіть людину, яка не брала участі у створенні дропу, прочитати сторінку й переказати умови власними словами. Якщо вона не може пояснити, що купує і які витрати можливі, текст варто доопрацювати. Зрозумілий опис не усуває всіх ризиків NFT, але допомагає покупцеві оцінити їх до підтвердження транзакції.
