Раніше я вважав, що створення NFT на Solana означає боротьбу з Metaplex. Саме такий шлях пропонував кожен туторіал: запустити Candy Machine, керувати акаунтами метаданих, маневрувати між окремими програмами лише для того, щоб прикріпити назву та зображення до токена. Виявляється, це припущення застаріло. Програма Token Extensions, також відома як Token-2022, об'єднала всю цю складність безпосередньо в самому мінті. Тепер ви можете створити повноцінний NFT, не торкаючись програми метаданих і не фінансуючи додаткові акаунти. Ви просто змінюєте кілька прапорців, записуєте дані безпосередньо в акаунт мінту, і готово.
Це змінює підхід розробників до мислення про цифрові активи на Solana. У традиційній веброзробці NFT сприймається як окрема структура даних, що потребує власної таблиці та схеми. На Solana реальність є простішою та елегантнішою. NFT — це не спеціальний об'єкт, керований зовнішнім протоколом. Це просто акаунт мінту, налаштований із пропозицією (supply) рівно в одну одиницю та нульовою кількістю знаків після коми (decimals). Стандартний токен дозволяє розділяти одиниці, оскільки він має велику пропозицію та кілька знаків після коми. NFT фіксує пропозицію на одній, неподільній одиниці. Усе, що робить його унікальним, зберігається в розширеннях (extensions), які працюють разом із основним акаунтом мінту.
Старий і новий підходи
До появи Token Extensions канонічний стек включав програму SPL Token для самого мінту, а також Metaplex для метаданих, колекцій та іноді офчейн-індексації (off-chain indexing). Метадані зберігалися в окремих акаунтах, пов'язаних адресами, які потрібно було відстежувати. Це працювало, але збільшувало кількість точок взаємодії. Більше акаунтів означало більше витрат на оренду (rent), більше шляхів підпису та більше логіки на стороні клієнта для отримання повної картини токена.
Token Extensions замінює цей розрізнений підхід, вбудовуючи можливості безпосередньо в мінт. Потрібні назва, символ і посилання на офчейн-медіа? Увімкніть розширення метаданих (metadata extension). Потрібно згрупувати токени в колекцію? Використовуйте розширення Group та Member. Мінт стає єдиним джерелом істини (single source of truth). Для розробників, звиклих до реляційних баз даних, цей перехід схожий на перехід від розподіленої мікросервісної архітектури назад до нормалізованої таблиці з добре спроектованими зовнішніми ключами (foreign keys).
Анатомія NFT на основі розширень
Створення NFT за допомогою Token Extensions вимагає розуміння того, що саме робить токен незамінним (non-fungible) у цій мережі. Пропозиція (supply) має дорівнювати одиниці. Кількість знаків після коми (decimals) має дорівнювати нулю. Ці два обмеження запобігають дробленості (fractionalization). Після встановлення цих параметрів ви вмикаєте розширення, які зберігають додаткові поля безпосередньо в акаунті мінту.
Розширення метаданих містить назву, символ і URI. Цей URI вказує на JSON-файл, який зазвичай розміщується у децентралізованому сховищі або на стандартному вебсервері, і описує зображення, атрибути та риси (traits). Немає окремого акаунта метаданих, який потрібно було б шукати та десеріалізувати. Дані зберігаються в самому мінті, а це означає, що експлорери, гаманці та клієнтське програмне забезпечення можуть зчитати основну ідентичність токена, перевіривши лише один акаунт.
Я протестував це особисто на devnet. Я створив новий мінт із увімкненим розширенням метаданих, а потім записав назву та символ безпосередньо в стан мінту (mint state). Транзакція пройшла успішно, і результат миттєво з'явився в Solana Explorer. Не потрібно було фінансувати чи шукати другий акаунт. Ця простота майже приголомшувала після тижнів роботи з багатоакаунтними метаданими Metaplex.
Створення колекцій подібно до рядків бази даних
Колекції стали наступним логічним кроком. У застарілій моделі групування NFT зазвичай означало використання Metaplex Certified Collections або офчейн-реєстрів. Token Extensions впроваджує два специфічні примітиви: розширення Group та розширення Member.
Ось як працює логіка. Ви створюєте один мінт, який виступає заголовком колекції, і вмикаєте на ньому розширення Group. Потім для кожного окремого NFT у колекції ви створюєте мінт із увімкненим розширенням Member. Кожен мінт учасника (member mint) зберігає посилання на адресу мінту колекції. Цей зв'язок працює точно так само, як зовнішній ключ (foreign key) у реляційній базі даних. Рядок колекції існує в одному екземплярі, а кожен рядок учасника посилається на нього, не дублюючи ідентичність колекції.
Я побудував так невелику тестову колекцію на devnet. Основний мінт колекції мав прапорець group. Окремі токени мали прапорець member і посилалися на адресу батьківського об'єкта. Запити до блокчейну давали мені чисту, прохідну структуру. Не було потреби в сторонньому індексаторі, щоб вгадувати, чи належать токени до однієї групи. Зв'язок є явним і знаходиться безпосередньо в мережі (on-chain).
Open Schema and On-Chain Experimentation
One detail that stands out is the open schema of the metadata extension. Older standards often enforce a fixed field list. If you wanted to store something non-standard on-chain, you were stuck putting it in off-chain JSON or hacking around rigid account layouts.
Token Extensions takes a different approach. Because the metadata extension accepts custom fields, I was able to add a rarity attribute directly to the mint account. I wrote the field, sent the transaction, and refreshed the Solana Explorer. The rarity value appeared instantly alongside the name and symbol. For game developers or anyone building dynamic assets, this flexibility matters. You can surface critical traits on-chain without needing an external verifier to parse JSON.
The Off-Chain Gap: URIs and Caching
For all the elegance of on-chain storage, one lesson cut through clearly: identity still lives off-chain. The mint does not store your image. It stores a URI. When I updated that URI and committed the change to devnet, the chain reflected the new pointer immediately. Block explorers showed the updated link without delay.
But my wallet lagged. It continued displaying the old image for minutes, stubbornly serving a cached version while the underlying data on-chain had already changed. This is a practical reality developers must plan for. The Solana ledger is fast. Confirmation times are short. Yet the visual layer that users interact with depends on HTTP caches, CDN propagation, and wallet-specific refresh intervals. If you build a dynamic NFT that changes based on real-world events, you cannot assume the user sees the change the moment the transaction lands. You need cache-busting strategies, versioning in your URI paths, or explicit refresh triggers in your frontend.
What Comes Next
My devnet experiments have laid the groundwork for a more dynamic project. The next step is a collection