Как устроен стандарт токенов SPL в сети Solana

Стандарт токенов SPL в сети Solana устроен не как контракт с таблицей балансов, а как набор аккаунтов, которыми распоряжается общая программа. Сам токен описан в mint-аккаунте: там хранятся объём выпуска, число десятичных знаков и права на выпуск и заморозку. Баланс владельца лежит в отдельном токен-аккаунте, привязанном к этому mint. Логика у всех токенов одна и общая, а различаются они только данными своих аккаунтов.

Одна программа на все токены

Главное отличие от привычной модели — отсутствие индивидуального кода. Вся логика работы с токенами собрана в программах токенов, которые, по документации Solana, прочитанной 16 октября 2026 года, содержат все инструкции взаимодействия с токенами в сети — как взаимозаменяемыми, так и невзаимозаменяемыми.

Программ две. Первая — исходная программа токенов, дающая базовые возможности вроде выпуска и перевода; документация называет её неизменяемой и широко используемой. Вторая — программа с расширениями, известная как Token-2022: она включает все возможности первой и добавляет новые через механизм расширений.

Код под токен писать не нужно. Создаются аккаунты. Программа остаётся та же.

Mint-аккаунт: паспорт токена

Полей в mint-аккаунте немного. Все они описаны в документации. Право на выпуск — адрес, которому разрешено создавать новые единицы. Объём выпуска — текущее общее количество. Число десятичных знаков — точность отображения. Признак инициализации — служебный флаг. Право на заморозку — адрес, способный, по формулировке документации, заморозить токены в токен-аккаунте, запретив перевод и сжигание.

Два последних пункта важнее. Право на выпуск, если оно не снято, позволяет увеличивать объём в любой момент. Право на заморозку останавливает операции по аккаунту. Оба права существуют на уровне стандарта, а не как чья-то надстройка.

Токен-аккаунт: где лежит баланс

Баланс лежит не в mint. И не в кошельке. Он в отдельном токен-аккаунте, и у того свой набор полей: mint — какой токен учитывается, owner — кто вправе переводить, amount — текущий остаток, delegate и delegated_amount — кому и сколько делегировано право траты, close_authority — кто может закрыть аккаунт.

Здесь спотыкаются многие. Поле owner в данных токен-аккаунта — это не то же, что владелец аккаунта в базовой структуре: последним всегда выступает сама программа токенов. То есть распоряжаться балансом вправе адрес из поля owner, а менять данные аккаунта — только программа.

Правило количества жёсткое. Кошельку нужен токен-аккаунт под каждый токен, которым он хочет владеть, и при этом один кошелёк может иметь несколько токен-аккаунтов для одного токена.

Ассоциированный аккаунт и плата за хранение

Чтобы адрес токен-аккаунта не приходилось запоминать, стандарт вводит ассоциированный аккаунт. Его адрес выводится детерминированно из адреса владельца и адреса mint — это применение концепции программно выводимого адреса, когда адрес получается из заранее заданных входных данных.

Создание аккаунта стоит денег. Но это не комиссия. Документация формулирует это как возвратный минимальный баланс за хранение аккаунта, и вносит его плательщик инструкции — независимо от того, кому аккаунт достанется.

Возврат тут не метафора. При закрытии токен-аккаунта удержанный баланс возвращается, и право на закрытие прописано в полях самого аккаунта.

Как создаётся токен: порядок шагов

1. Создаётся mint-аккаунт: задаются число десятичных знаков, право на выпуск и, по желанию, право на заморозку.
2. Создаётся токен-аккаунт получателя — обычно ассоциированный, с адресом, выведенным из адреса владельца и mint.
3. За токен-аккаунт вносится возвратный минимальный баланс; платит тот, кто подаёт инструкцию.
4. Выполняется выпуск: держатель права на выпуск увеличивает объём и зачисляет единицы в токен-аккаунт.
5. При необходимости право на выпуск снимается — это фиксирует объём и видно в данных mint.
6. Дальнейшие переводы идут между токен-аккаунтами одного и того же mint, программа при этом не меняется.

Чем модель отличается от ERC-20

Сравнение показывает конструкцию целиком. В модели Ethereum у каждого токена свой контракт, и балансы держателей — записи в таблице внутри него; как эта модель развивается, описано в разборе о том, что меняет обновление Glamsterdam для сети Ethereum. В Solana контракта под токен нет. Есть аккаунты и общая программа.

Отсюда разница в проверках. В EVM-сети читают код и состояние контракта; в Solana смотрят поля mint-аккаунта и список токен-аккаунтов. Привычка выяснять, кто вызывал контракт и с какими параметрами, переносится на разбор инструкций в транзакции.

Что проверяется в обозревателе

• Адрес mint: именно он, а не символ, опознаёт токен
• Поля прав: сохранены ли право на выпуск и право на заморозку
• Число десятичных знаков: от него зависит, как читается остаток
• Какая из двух программ токенов используется — исходная или с расширениями
• Список токен-аккаунтов адреса: их может быть несколько на один mint

Серию зачислений удобно разбирать так же, как разбирают групповые операции в других сетях: приём описан в материале о том, как отследить пакет переводов одной операцией. Публичный обозреватель сети принимает и адрес mint, и адрес кошелька.

Итог

SPL — стандарт на аккаунтах, а не на коде. Токен опознаётся адресом mint, параметры лежат там же, баланс хранится в отдельном токен-аккаунте с возвратным минимальным балансом за место, а логику исполняет общая программа — исходная или с расширениями. Для пользователя это означает другой набор проверок, чем в EVM-сетях: смотрят права mint и состав токен-аккаунтов. Для выпуска токена не нужно публиковать код, и это снижает порог входа как для добросовестных эмитентов, так и для подделок.

Частые вопросы

Устройство аккаунтов описано в официальной документации Solana о модели аккаунтов, а проверить конкретный mint можно в публичном обозревателе Solana Explorer.