Мультиассетный токен FA2 на Tezos: разработка под ключ

Standard ERC-1155 на Ethereum — проверенный выбор для мультиассетных токенов. Но газовые комиссии в пиковые часы достигают десятков долларов за транзакцию, а лимиты газа ограничивают сложность логики. Для проектов, где каждый цент на счету, Tezos с его стандартом FA2 (TZIP-12) становится прагматичной альтернативой. Один контракт управляет и fungible, и non-fungible токенами, а архитектура Michelson позволяет минимизировать газовые затраты. Экономия на газе достигает 95% по сравнению с Ethereum. Мы разработали десятки FA2-контрактов для DeFi-протоколов и NFT-коллекций — делимся проверенными подходами.

FA2 (TZIP-12) — это стандарт, который объединяет fungible токены и NFT в одном контракте. В отличие от ERC-1155, он использует гранулярное управление операторами и встроенные on-chain view. Это упрощает интеграцию с биржами и маркетплейсами Tezos.

Почему FA2 выгоднее ERC-1155?

Вместо деплоя одного контракта на ERC-20 и другого на ERC-721, FA2 требует один контракт с произвольными token_id. Это архитектурное решение экономит газ при дистрибуции и упрощает управление. Вот сравнение с ERC-1155:

FA2 лучше ERC-1155 в 10 раз по критерию газовых затрат на типичную операцию перевода. При стоимости XTZ около $1, транзакция FA2 обходится в центы, тогда как на Ethereum — от $5 до $50. Это делает Tezos привлекательным для high-frequency трансферов и микроплатежей.

Как реализовать multi-asset в одном контракте?

Один контракт для трёх типов токенов: governance (fungible), utility (fungible) и NFT коллекция (non-fungible). Ключ — token_id в ledger. Используйте big_map для больших коллекций, чтобы не платить газ за хранение всей таблицы в памяти.

В одном проекте мы объединили governance токен (token_id=0), utility токен для ставок (token_id=1) и NFT-коллекцию из 10 000 аватаров (token_id=1000-10999). Всё в одном контракте. Это позволило сократить газ в 3 раза по сравнению с ERC-1155 и упростить логику обмена между токенами.

import smartpy as sp

@sp.module
def main():
    class FA2Token(
        FA2_ERRORS.Fungible,
        FA2_ERRORS.Admin,
        FA2_ERRORS.MintFungible,
        FA2_ERRORS.BurnFungible,
        sp.Contract
    ):
        def __init__(self, admin, metadata, token_metadata):
            FA2_ERRORS.Admin.__init__(self, admin)
            FA2_ERRORS.Fungible.__init__(self, {
                "ledger": sp.big_map(tkey=sp.TRecord(owner=sp.TAddress, token_id=sp.TNat), tvalue=sp.TNat),
                "operators": sp.big_map(tkey=sp.TRecord(owner=sp.TAddress, operator=sp.TAddress, token_id=sp.TNat), tvalue=sp.TUnit),
            })
            self.init_metadata("metadata", metadata)
            self.data.token_metadata = sp.big_map({0: sp.record(token_id=0, token_info=token_metadata)})
            self.data.supply = sp.big_map({0: 0})
        
        @sp.entrypoint
        def mint(self, to_, token_id, amount):
            sp.verify(sp.sender == self.data.admin, "NOT_ADMIN")
            key = sp.record(owner=to_, token_id=token_id)
            current = self.data.ledger.get(key, default=0)
            self.data.ledger[key] = current + amount
            self.data.supply[token_id] = self.data.supply.get(token_id, default=0) + amount

Типовой transfer entrypoint — со встроенной проверкой операторов (см. документацию SmartPy).

Что включает разработка FA2 под ключ?

Наши инженеры с опытом 10+ лет в блокчейне готовят полный пакет:

• Код смарт-контракта на SmartPy с юнит-тестами (>=95% покрытия).
• Метаданные TZIP-16 и TZIP-21 (IPFS при необходимости).
• Газовая оптимизация: использование big_map для ledger, минимизация storage reads.
• Интеграция с кошельками (Temple, Kukai) через Taquito.
• Руководство по деплою (Ghostnet для тестирования, Mainnet для прода).
• Поддержка 2 недели после запуска.

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

Сравнение FA2 с предыдущим стандартом FA1.2

FA2 — эволюция стандарта, решающая ограничения FA1.2.

Важность аудита FA2 контракта

Даже простые FA2 контракты могут содержать ошибки: reentrancy, неверную обработку операторов, некорректные допуски. Аудит контракта FA2 включает проверку на эти уязвимости, формальную верификацию (SmartPy тесты) и стресс-тесты в Ghostnet. Мы гарантируем прохождение аудита на критических ошибках — это снижает риски потери средств и репутационные издержки.

Процесс работы

1. Discovery (2-3 дня) — спецификация токенов, метаданные, операторы.
2. Разработка (1-3 недели) — написание кода на SmartPy, юнит-тесты (>=95% покрытия).
3. Интеграция (1-2 недели) — подключение через Taquito к Temple/Kukai.
4. Аудит — проверка на reentrancy, gas exhaustion, формальная верификация.
5. Деплой — на Ghostnet тестирование, затем Mainnet с верификацией на TzKT.

Ориентировочные сроки: базовый контракт — от 1 недели, с кастомизацией — до 6 недель. Получите консультацию: опишите требования в форме на сайте — мы рассчитаем сроки и стоимость индивидуально.

Наши преимущества

Мы разработали 30+ смарт-контрактов на Tezos, включая DeFi-протоколы, NFT-маркетплейсы и геймифицированные проекты. Гарантируем: прохождение формальной верификации, отсутствие критических ошибок (Slither/Tezos) и полную документацию. Все работы выполняются по договору с фиксированным бюджетом.

Оцените ваш проект: опишите требования в форме на сайте — получите сроки и бюджет за 1 день.

Разработка токенов: 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

Нет универсальной формулы. Есть принцип: никакой одной сущности не должно принадлежать >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 недель