Freeze authority у SPL Token — це необов'язковий привілей, що дозволяє визначеному обліковому запису блокувати та розблоковувати токен-рахунки користувачів. Нижче наведено інженерний розбір механізму, коректні сценарії застосування, репутаційні ризики та архітектурні альтернативи.
Механізм freeze authority в SPL Token
Freeze authority — це один із чотирьох типів авторитетів у SPL Token (поряд із mint authority, update authority та close authority). Він прив'язується до токен-mint під час створення і визначає, який обліковий запис має право викликати інструкції FreezeAccount та ThawAccount.
Коли freeze authority викликає FreezeAccount для конкретного токен-рахунку, стан цього рахунку змінюється на Frozen. У цьому стані:
- заборонені всі інструкції переказу (Transfer, TransferChecked);
- заборонене спалювання (Burn, BurnChecked);
- заборонене закриття рахунку (CloseAccount);
- дозволені інструкції Approve та встановлення делегатів, але делегат не зможе виконати переказ із замороженого рахунку.
Інструкція ThawAccount повертає рахунок у стан Initialized (або Account у Token-2022), відновлюючи повну функціональність.
Налаштування під час створення mint
Передумови: встановлено @solana/web3.js, @solana/spl-token, налаштовано з'єднання з кластером (devnet або mainnet-beta).
У конструкторі CreateMint параметр freezeAuthority приймає публічний ключ або null. Якщо передати null, freeze authority не призначається, і змінити це пізніше неможливо — це незворотне рішення на рівні програми.
Очікуваний результат: створено mint із заданим freeze authority. Перевірити можна через getMint — поле freezeAuthority має містити вказаний публічний ключ.
Передача та відкликання freeze authority
Інструкція SetAuthority з типом авторитету FreezeAuthority дозволяє поточному власнику freeze authority передати цей привілей іншому обліковому запису або встановити null, остаточно відкликавши можливість заморожування.
Відкликання через SetAuthority із null — це стандартний спосіб довести відсутність централізації. Після відкликання перевірте поле freezeAuthority через getMint: воно має бути null.
План відкату: якщо freeze authority передано помилковому ключу, відкликання неможливе без доступу до цього ключа. Тому передачу авторитету слід виконувати лише через multi-sig (наприклад, Squads) або тимчасове сховище (escrow) із затримкою.
Типова помилка: плутанина з Token-2022
У Token-2022 (SPL Token Extension) існують додаткові механізми, зокрема розширення ConfidentialTransfer із власною логікою заморожування. Якщо ваш mint створено через Token-2022, інструкції FreezeAccount зі стандартного SPL Token не спрацюють. Перевірте програму mint-рахунку перед викликом — вона має збігатися з тією, до якої ви звертаєтеся.
Сценарії законного використання
Freeze authority має обмежене коло застосування, де централізований контроль виправданий бізнес- або регуляторними вимогами.
Регульовані реальні активи (RWA)
Токенізація цінних паперів, нерухомості або кредитних інструментів часто вимагає дотримання юрисдикційних обмежень. Freeze authority дозволяє блокувати рахунки, якщо користувач потрапив під санкції, втратив акредитацію або порушив умови емісії. Це типовий вимог для токенів категорії RWA на Solana.
Відповідність KYC/AML
Деякі платформи вимагають верифікації користувачів перед наданням доступу до токенів. У такій моделі токени спочатку розподіляються на заморожені рахунки, а після проходження KYC — розблоковуються індивідуально. Це альтернатива моделі з whitelist на рівні смарт-контракту.
Екстрене реагування на вразливість
Якщо виявлено критичну вразливість у суміжній програмі (не в самій SPL Token), freeze authority може тимчасово зупинити рух токенів, поки уразливість не усунуто. Це радикальний захід, але він технічно можливий і застосовувався в екосистемі.
Міграція та оновлення контракту
Під час міграції ліквідності з одного контракту в інший freeze authority дозволяє заморозити старі рахунки, запобігаючи подвійним витратам під час переходного періоду. Після завершення міграції авторитет відкликається.
Ризики для користувачів та репутації
Наявність активної freeze authority — це централізаційний вектор, який впливає на сприйняття проєкту різними стейкхолдерами.
Довіра користувачів
Досвідчені користувачі Solana перевіряють freezeAuthority перед взаємодією з токеном. Ненульове значення сигналізує про можливість довільного блокування коштів. Для DeFi-протоколів, DEX-ів і lending-платформ це зазвичай дискваліфікуючий фактор — інтегратори відмовляються від лістингу таких токенів.
Інтеграційні обмеження
Деякі агрегатори, мости та автоматизовані маркет-мейкери фільтрують токени з активною freeze authority на рівні конфігурації. Це не технічна блокада (SPL Token дозволяє операції), а політика ризику інтегратора.
Юридичний сигнал
У певних юрисдикціях наявність freeze authority може трактуватися як ознака контролю над фінансовим інструментом, що тягне додаткові регуляторні наслідки для емітента. Це не є універсальним правилом — конкретні вимоги залежать від юрисдикції та класифікації токена.
Репутаційний ризик при використанні
Навіть якщо freeze authority ніколи не активувався, сам факт його наявності стає аргументом у критиці. Єдине технічно обґрунтоване застосування без репутаційних втрат — це прозоро задекларовані RWA-проєкти з публічною політикою заморожування.
Альтернативи замість freeze authority
У більшості випадків, де розробник схильний використовувати freeze authority «на всякий випадок», існують архітектурні рішення з меншим централізаційним слідом.
Whitelist на рівні власної програми
Замість глобального freeze authority можна реалізувати перевірку дозволених адрес у логіці переказу вашої програми. Це не блокує рахунок на рівні SPL Token, а запобігає переказам через бізнес-логіку. Перевага: користувач бачить правила в коді програми, а не довіряє невидимому привілею.
Тимчасові блокування через escrow
Замість заморожування рахунку можна вимагати депонування токенів у програму-escrow із визначеним терміном розблокування. Це підходить для вестинг-схем та lock-up періодів без надання довільного права заморожування.
Off-chain комплаєнс із on-chain доказами
Замість on-chain заморожування можна реалізувати off-chain перевірку (KYC/AML) і видавати on-chain атестацію (наприклад, через Verifiable Credentials). Ваша програма або інтегратори перевіряють наявність атестації перед операцією. Це зсуває контроль з емітента на інфраструктуру верифікації.
Відкликання freeze authority після розгортання
Якщо freeze authority потрібен лише на етапі початкового розподілу (наприклад, для заморожування рахунків до завершення верифікації), його слід відкликати одразу після завершення цього етапу. Це можна автоматизувати через умовну логіку в скрипті розгортання або через Cron job, що моніторить стан розподілу.
Multi-sig із затримкою (timelock)
Якщо відкликання неможливе через регуляторні вимоги, freeze authority має бути покладено на multi-sig з мінімум трьома підписантами та додатковим timelock-періодом (через Squads або аналогічне рішення). Це не усуває централізацію, але робить довільне використання значно складнішим і прозорішим.
У кожному з цих варіантів вибір залежить від того, чи є freeze authority юридичною вимогою, чи інженерним забобоном. Якщо це перше — документуйте обґрунтування і мінімізуйте поверхню атаки через multi-sig. Якщо друге — відмовляйтеся на користь архітектурних альтернатив.