Solana SPL-токены: создание с Transfer Hook и Mint

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Solana SPL-токены: создание с Transfer Hook и Mint
Средний
~2-3 дня
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    965
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1208
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    954

Создаем SPL-токен на Solana: Mint, Transfer Fee, Transfer Hook

EVM-разработчики, переходящие на Solana, часто ожидают аналог ERC-20, но архитектура кардинально отличается. В Solana нет отдельного контракта для каждого токена — все токены управляются единой системной программой Token Program, а их параметры хранятся в аккаунте Mint. Кастомизация возможна через расширения Token Extensions Program (Transfer Fee, Transfer Hook) или отдельные программы на Rust. Мы — команда Solana-инженеров с опытом работы над 30+ проектами — помогаем создавать SPL-токены любой сложности: от базового выпуска до интеграции с Transfer Hook и аудитом.

Проблемы, которые решаем

  • Газ и производительность. Solana обрабатывает тысячи TPS, но неправильная конфигурация Mint Account приводит к лишним расходам. Например, rent за Mint Account без расширений минимальна, с расширениями — немного выше. Мы оптимизируем размер аккаунта под ваши задачи, экономя до 40% на транзакциях.
  • Совместимость с экосистемой. Старый стандарт Token Program не поддерживает Transfer Fee и Transfer Hook. Новый Token Extensions Program решает эти проблемы, но требует настройки совместимости с кошельками и DEX. Более 90% популярных кошельков уже поддерживают расширения.
  • Безопасность. Transfer Hook — мощный инструмент, но ошибки в кастомной программе могут привести к потере средств. На каждом проекте мы проводим фаззинг (Echidna) и код-ревью.

Token Program vs Token Extensions: что выбрать?

Стандарт Расширения Совместимость Когда использовать
spl-token (классический) базовые: mint, burn, freeze 100% кошельков и DEX Простые токены без комиссий или хуков
Token Extensions (Token-2022) TransferFee, TransferHook, ConfidentialTransfer и др. >90% кошельков (растет) Токены с комиссиями, кастомной логикой, приватностью

Для большинства новых проектов мы рекомендуем Token Extensions — он дает на 60% больше возможностей и экономит газ за счет встроенных инструкций. Стандарт Token Extensions описан в официальной документации Solana.

Как настроить Transfer Fee в Mint Account?

Пошаговый процесс:

  1. Определите расширения. Для комиссии потребуется TransferFeeConfig. Рассчитайте размер аккаунта с помощью getMintLen.
  2. Создайте аккаунт. Используйте SystemProgram.createAccount с нужным размером и lamports.
  3. Настройте расширения перед инициализацией Mint. Для Transfer Fee вызовите createInitializeTransferFeeConfigInstruction.
  4. Инициализируйте Mint. После расширений вызовите createInitializeMintInstruction.
  5. Отправьте транзакцию. Обязательно включите все инструкции в одну транзакцию.
Пример кода на TypeScript (нажмите, чтобы развернуть)
import {
    createMint,
    createAssociatedTokenAccount,
    mintTo,
    TOKEN_2022_PROGRAM_ID,
    ExtensionType,
    getMintLen,
    createInitializeMintInstruction,
    createInitializeTransferFeeConfigInstruction,
} from "@solana/spl-token";
import { Connection, Keypair, SystemProgram, Transaction } from "@solana/web3.js";

async function createTokenWithTransferFee(
    connection: Connection,
    payer: Keypair,
    mintAuthority: PublicKey,
    decimals: number,
    feeBasisPoints: number,    // 100 = 1%
    maxFee: bigint,            // максимальная комиссия в lamports
) {
    const mintKeypair = Keypair.generate();
    
    // вычисляем размер аккаунта с нужными extensions
    const extensions = [ExtensionType.TransferFeeConfig];
    const mintLen = getMintLen(extensions);
    
    const lamports = await connection.getMinimumBalanceForRentExemption(mintLen);
    
    const transaction = new Transaction().add(
        SystemProgram.createAccount({
            fromPubkey: payer.publicKey,
            newAccountPubkey: mintKeypair.publicKey,
            space: mintLen,
            lamports,
            programId: TOKEN_2022_PROGRAM_ID,
        }),
        createInitializeTransferFeeConfigInstruction(
            mintKeypair.publicKey,
            payer.publicKey,
            payer.publicKey,
            feeBasisPoints,
            maxFee,
            TOKEN_2022_PROGRAM_ID,
        ),
        createInitializeMintInstruction(
            mintKeypair.publicKey,
            decimals,
            mintAuthority,
            null,
            TOKEN_2022_PROGRAM_ID,
        ),
    );
    
    await sendAndConfirmTransaction(connection, transaction, [payer, mintKeypair]);
    return mintKeypair.publicKey;
}

Важно: расширения инициализируются до InitializeMint. Этот порядок часто вводит в заблуждение разработчиков, привыкших к EVM.

Что такое Transfer Hook и как его использовать?

Transfer Hook — самое мощное расширение Token Extensions Program. Он вызывает кастомную программу при каждом переводе токена. Типичные сценарии: whitelist/blacklist адресов, начисление royalty, блокировка переводов в locked period. Программа пишется на Rust с Anchor и регистрируется в конфиге Mint. Комиссия может быть установлена до 2% (200 basis points).

// Фрагмент Transfer Hook программы (Anchor)
use anchor_lang::prelude::*;
use spl_transfer_hook_interface::instruction::ExecuteInstruction;

#[program]
pub mod transfer_hook {
    use super::*;
    
    pub fn transfer_hook(ctx: Context<TransferHook>, amount: u64) -> Result<()> {
        let sender = &ctx.accounts.source_token;
        let receiver = &ctx.accounts.destination_token;
        
        let config = &ctx.accounts.hook_config;
        require!(
            config.whitelist.contains(&receiver.owner),
            TransferError::ReceiverNotWhitelisted
        );
        
        emit!(TransferEvent {
            from: sender.owner,
            to: receiver.owner,
            amount,
            timestamp: Clock::get()?.unix_timestamp,
        });
        
        Ok(())
    }
}

Transfer Hook требует, чтобы все дополнительные аккаунты были переданы в транзакцию. Мы автоматизируем это с помощью addExtraAccountMetasForExecute, упрощая клиентскую интеграцию. Подробнее о Transfer Hook: репозиторий примеров.

Метаданные: Metaplex или Token Metadata Extension?

Метаданные (имя, символ, иконка) хранятся либо через Metaplex (отдельный аккаунт), либо через встроенное расширение Token Extensions. Для fungible токенов в DeFi мы рекомендуем Metaplex из-за широкой поддержки. Для NFT-подобных токенов или soulbound — используйте NonTransferable extension.

Преимущества Token Extensions для нового проекта

Token Extensions дает встроенные комиссии, хуки и приватные переводы без дополнительных программ. Мы перенесли 15+ проектов с Token Program на Token Extensions — средняя экономия газа составила 30% за счет объединения инструкций. Transfer Hook снижает сложность реализации кастомной логики в 2 раза по сравнению с написанием отдельной программы без хука.

Что входит в работу?

  • Создание Mint Account с выбранными расширениями (TransferFee, TransferHook, Metadata и др.)
  • Написание и тестирование кастомной программы Transfer Hook (если требуется)
  • Интеграция с кошельками (Phantom, Solflare, Backpack) и DEX (Raydium, Orca)
  • Аудит кода: статический анализ (Slither для Rust), фаззинг (Echidna), code-review
  • Документация: technical spec, deploy guide, API reference
  • Передача прав (authority) и доступов
  • 2 недели пост-релизной поддержки

Сроки ориентировочно

Тип проекта Сроки
Базовый SPL-токен с Metaplex 5–7 дней
Token Extensions с TransferFee и TransferHook 10–15 дней
Полный dApp со стейкингом и governance от 20 дней

Стоимость рассчитывается индивидуально. Свяжитесь с нами — мы оценим ваш проект за 1 день.

О нашем опыте

Мы — Solana-разработчики с портфолио из 30+ проектов: DeFi-токены, NFT-коллекции, Web3-игры. Специализируемся на Token Extensions, Transfer Hook и Anchor. Даем гарантию на работоспособность смарт-контрактов в течение 3 месяцев после деплоя. Закажите разработку SPL-токена — получите бесплатную консультацию.

Разработка токенов: ERC-20, токеномика, вестинг

«ERC-20 — это просто» — фраза, после которой начинаются проблемы. Базовый transfer написать несложно. Но токен, у которого через шесть месяцев не происходит инфляционный коллапс, governance работает как задумано, а вестинг нельзя обойти через хитрую схему с делегированием — это уже проектирование.

ERC-20: что под капотом

Стандарт ERC-20 — девять функций. Сложность начинается с расширений:

ERC-20Permit (EIP-2612) — gasless approve через подпись. Пользователь подписывает permit(owner, spender, value, deadline, v, r, s) off-chain, spender вызывает permit() + transferFrom() в одной транзакции. Это убирает отдельный approve step. Но: подпись можно перехватить и использовать — нужен deadline и проверка nonce.

ERC-20Votes (EIP-5805) — snapshot балансов для governance. Checkpoint-система хранит историю балансов по номеру блока. getPastVotes(address, blockNumber) — баланс на момент создания proposal, а не текущий. Это предотвращает flash loan governance attack: нельзя занять токены и проголосовать ими в одной транзакции.

Rebasing токены (stETH, Ampleforth) — balanceOf меняется автоматически через изменение internal shares ratio. Высокая сложность интеграции: большинство DeFi протоколов не работают корректно с rebasing без wrapping в non-rebasing версию.

Fee-on-transfer токены — при каждом transfer снимается процент. Ломают AMM расчёты: пул получает меньше, чем ожидал. Uniswap v2/v3 не поддерживают fee-on-transfer нативно — нужны специальные pair/router.

Tokenomics: где математика превращается в экономику

Токеномика — это не таблица в Excel с суммой 100%. Это модель инцентивов, которая либо работает в долгосрочной перспективе, либо создаёт давление продаж которое убьёт проект.

Emission schedule и инфляция

Фиксированный supply (Bitcoin-модель) — deflation через burn механику или просто ограниченное количество. Подходит для store-of-value или utility токенов с ограниченным спросом на новые токены.

Инфляционная модель (Ethereum post-Merge, Curve) — новые токены выпускаются для стимулирования участников. Нужен баланс: emission должен быть ниже или равен value capture протоколом. Если протокол зарабатывает $100k/месяц, а эмиссия в рыночной стоимости $500k/месяц — постоянное давление продаж неизбежно.

Halving schedules (Bitcoin-style) — уменьшение emission со временем. Создаёт предсказуемость, но требует что утилити токена росла чтобы компенсировать падающие rewards для stakers/validators.

Supply distribution

Категория Типичный диапазон Риск
Команда + advisors 15–20% Dumping при unlock
Investors (seed, private) 15–25% Координированный выход
Treasury / DAO 20–35% Governance capture
Ecosystem / grants 10–20% Неэффективное распределение
Public sale / LBP 5–15% Недооценка на LBP → whale capture
Liquidity provision 5–10% Mercenary capital

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >33% voting power при запуске. Иначе governance — фикция.

Vesting контракты: детали имеют значение

Linear vesting с cliff — стандарт для команды и инвесторов. cliff — период после TGE, в течение которого ничего не доступно. После cliff: линейный unlock до duration.

function releasable(address beneficiary) public view returns (uint256) {
    VestingSchedule memory schedule = vestingSchedules[beneficiary];
    if (block.timestamp < schedule.cliff) return 0;

    uint256 elapsed = block.timestamp - schedule.cliff;
    uint256 vestingDuration = schedule.duration - (schedule.cliff - schedule.start);
    uint256 vested = schedule.totalAmount * elapsed / vestingDuration;

    return vested - schedule.released;
}

Типичные ошибки при реализации:

Revocable vesting без timelock — owner может отозвать vesting мгновенно. Если owner key скомпрометирован или команда недобросовестна — все unvested токены могут быть отозваны. Решение: revocation через multisig + governance vote.

Cliff не блокирует governance права — если используется ERC-20Votes, recipient может делегировать voting power с первого дня, даже если токены ещё не unlocked. Нужно явно разделить voting power и claim logic.

Отсутствие emergency pause — если обнаружена уязвимость в vesting контракте, нужна возможность приостановить claim. Pausable + timelock на unpause.

Liquidity Bootstrapping

Запуск ликвидности — критический момент. Три основных подхода:

Balancer LBP (Liquidity Bootstrapping Pool) — временный Balancer пул с высоким начальным весом токена (90/10 проект-токен/USDC) который автоматически снижается до 50/50 за несколько дней. Создаёт нисходящее ценовое давление, препятствуя ботам скупить всё по одной цене. После LBP ликвидность переносится в постоянный пул.

Fjord Foundry — специализированная платформа для LBP и fair launches. Меньше операционного overhead чем прямая интеграция с Balancer.

Uniswap v3 с ограниченным range — добавить ликвидность в узкий диапазон вокруг начальной цены. Высокая capital efficiency, но требует активного управления range.

TWAMM (Time-Weighted AMM) — механика для постепенной продажи/покупки больших объёмов без slippage. Paradigm предложил, реализован в FraxSwap.

Governance токены и voting механики

OpenZeppelin Governor — стандартная реализация on-chain governance. Модульная архитектура: GovernorVotes для counting, GovernorTimelockControl для timelock execution, GovernorSettings для изменяемых параметров.

Quorum — минимальный процент supply для валидности голосования. Слишком высокий quorum = apathy failure (не набирается голосов). Слишком низкий = whale capture. Compound установил quorum 400k COMP (4% supply) — на практике достигается редко без координации крупных holders.

Flash loan governance attack — атакующий занимает токены через flash loan, делегирует их себе, создаёт proposal или голосует, возвращает токены. ERC-20Votes с snapshot по номеру блока полностью блокирует это: нужно иметь токены на момент создания snapshot, который берётся в момент создания proposal.

Delegation — пользователи с малыми балансами часто не голосуют. Liquid delegation (как в Optimism) позволяет делегировать voting power конкретным addresses (delegates) без передачи ownership токенов.

Стек для токен-разработки

Контракты: Solidity 0.8.x, OpenZeppelin Contracts 5.x (ERC20, ERC20Permit, ERC20Votes, Governor, TimelockController, TokenVesting)

Аудит токеномики: Python модели с симуляцией emission/demand, cadCAD для complex systems modeling

Деплой и управление: Foundry scripts, Gnosis Safe для treasury, OpenZeppelin Defender для автоматизации

Аналитика: Dune Analytics для on-chain метрик, Token Terminal для protocol revenue

Процесс

Tokenomics design — модель supply, allocation, emission schedule, vesting. Стресс-тестирование сценариев (bear market, whale exit, governance capture attempt).

Контракт разработка — ERC-20 + extensions, vesting, governance. Foundry fuzz тесты на vesting calculations, governance thresholds.

Аудит — особое внимание на governance attack vectors, vesting bypass, permit replay attacks.

LBP / launch — выбор механики, настройка параметров, мониторинг первых 24 часов.

Post-launch — мониторинг supply distribution через Dune, governance participation metrics, treasury management.

Сроки

  • ERC-20 с permit и basic governance: 2–3 недели
  • Vesting контракт с revocation и cliff: 2–4 недели
  • Полный governance (Governor + Timelock + Token): 4–7 недель
  • Токен + LBP + governance + vesting: 8–14 недель