NEP-141: Стандарт токенов для сети NEAR

Ключевые выводы
• NEP-141 — это стандарт заменяемых токенов для сети NEAR, обеспечивающий интеграцию и совместимость.
• Стандарт гарантирует предсказуемое поведение для межконтрактных вызовов и управление хранилищем.
• NEP-141 отличается асинхронными вызовами и отсутствием паттерна «approve/transferFrom» по умолчанию.
• Токены, соответствующие NEP-141, легко интегрируются с мостами и DeFi-приложениями.
Заменяемые токены (fungible tokens, FT) являются основой большинства решений web3: от стейблкоинов и LP-токенов в DeFi до бонусных баллов и платежных систем. В сети NEAR заменяемые токены реализуются с помощью NEP-141 — канонического стандарта токенов, который определяет, как контракты должны выпускать, передавать и учитывать балансы в сети. В этом руководстве мы объясним, что такое NEP-141, чем он отличается от знакомых стандартов Ethereum, и что разработчикам и пользователям следует знать в 2025 году.
Что такое NEP-141?
NEP-141 — это стандарт заменяемых токенов (FT) для NEAR. Он определяет минимальный интерфейс и поведение, которым должен соответствовать каждый FT-контракт, включая:
- Основные методы передачи
- Управление хранилищем
- Метаданные токена
- Семантика межконтрактных переводов и возвратов средств
Официальная спецификация опубликована в репозитории NEAR Improvement Proposals и является лучшим единым источником информации для разработчиков. Ознакомьтесь со стандартом и сопутствующими спецификациями на GitHub NEAR:
- Стандарт NEP-141 для заменяемых токенов (методы, колбэки, логика разрешения) — FungibleToken.md
- Метаданные токена (название, символ, количество десятичных знаков, иконка и т. д.) — FungibleTokenMetadata.md
- Управление хранилищем (регистрация аккаунтов и депозиты) — Storage.md
- Соглашения о событиях/логировании — Events.md
Для получения информации о NEAR и его текущей дорожной карте посетите официальный сайт и блог:
Почему NEP-141 важен
- Единая интеграция кошельков и dApp: Соответствие стандарту гарантирует, что токены «просто работают» везде — от эксплореров, таких как NEAR Explorer, до DeFi-приложений, таких как Ref Finance.
- Предсказуемое поведение для межконтрактных вызовов: Асинхронная модель NEAR делает межконтрактные переводы мощными, но сложными; NEP-141 стандартизирует колбэки и семантику возврата средств.
- Учет использования хранилища: NEAR требует, чтобы аккаунты оплачивали используемое ими хранилище. NEP-141 интегрирует депозиты за хранение и регистрацию балансов, что обеспечивает безопасность и эффективность контрактов.
- Компонуемость экосистемы: Токены, соответствующие стандартам, обеспечивают гладкую интеграцию с мостами, индексаторами и инструментами, например, с Rainbow Bridge или библиотеками контрактов на Rust.
Чем NEP-141 отличается от ERC-20
Хотя NEP-141 и ERC-20 концептуально схожи, существуют важные архитектурные различия:
- Асинхронные вызовы и возвраты средств: Межконтрактные вызовы в NEAR асинхронны. Метод
ft_transfer_call
стандарта NEP-141 вызывает методft_on_transfer
получателя, а затем — резолвирующий колбэк, чтобы неиспользованные токены могли быть возвращены отправителю. Это отличается от синхронного потока, типичного для ERC-20. См. механику разрешения в стандарте — FungibleToken.md. - Отсутствие паттерна «approve/transferFrom» по умолчанию: NEP-141 полагается на
ft_transfer_call
и явную логику получателя, а не на глобальную систему разрешений. Это снижает поверхность атаки, связанную с разрешениями, и лучше соответствует исполнению на основе промисов в NEAR. - Депозиты за хранение: Пользователям часто приходится «регистрировать» аккаунты в контракте токена, внося небольшую сумму NEAR для покрытия расходов на хранение. Это формализовано в стандарте Storage — Storage.md.
- Логирование событий: NEAR использует стандартные форматы логов вместо событий EVM. Стандарт Events описывает, как генерировать структурированные логи, которые могут быть разобраны индексаторами — Events.md.
Эти различия отражают фокус дизайна NEAR на масштабируемом, асинхронном исполнении и низких комиссиях, сохраняя при этом эргономичность для разработчиков и безопасность для пользователей.
Интерфейс NEP-141 в общих чертах
Типичные методы, видимые пользователям:
ft_transfer(receiver_id, amount, memo?)
: Перевод токенов другому аккаунту.ft_transfer_call(receiver_id, amount, memo?, msg)
: Перевод токенов и вызов логики контракта получателя; неиспользованные токены возвращаются.ft_balance_of(account_id)
: Запрос баланса.ft_total_supply()
: Запрос общего количества токенов в обращении.ft_metadata()
: Чтение метаданных (название, символ, количество десятичных знаков, иконка, хэш ссылки).- Методы, связанные с хранилищем:
storage_deposit
,storage_balance_of
,storage_withdraw
(из стандарта Storage).
Требования к контрактам получателей:
ft_on_transfer(sender_id, amount, msg) -> String
: Возвращает количество токенов, которое получатель не использовал (для возврата отправителю). Затем токен-контракт вызывает свой собственный резолвер для завершения перевода и обработки возвратов.
Если вы разрабатываете на Rust, используйте канонические библиотеки:
- near-sdk (фреймворк для контрактов) — docs.rs/near-sdk
- near-contract-standards (готовая реализация FT) — docs.rs/near-contract-standards
Минимальный шаблон FT на Rust (near-contract-standards)
Ниже приведен упрощенный пример; производственные контракты должны полагаться на near_contract_standards::fungible_token
и реализовывать стандарты хранения и событий.
use near_contract_standards::fungible_token::FungibleToken;
use near_contract_standards::fungible_token::metadata::{FungibleTokenMetadata, FT_METADATA_SPEC};
use near_sdk::{near_bindgen, AccountId, PanicOnDefault, BorshDeserialize, BorshSerialize};
#[near_bindgen]
#[derive(BorshDeserialize, BorshSerialize, PanicOnDefault)]
pub struct Token {
pub ft: FungibleToken,
pub metadata: FungibleTokenMetadata,
}
#[near_bindgen]
impl Token {
#[init]
pub fn new(owner_id: AccountId, total_supply: near_sdk::json_types::U128) -> Self {
let mut this = Self {
ft: FungibleToken::new(b"t".to_vec()),
metadata: FungibleTokenMetadata {
spec: FT_METADATA_SPEC.to_string(),
name: "Example Token".to_string(),
symbol: "EXT".to_string(),
icon: None,
reference: None,
reference_hash: None,
decimals: 24,
},
};
this.ft.internal_register_account(&owner_id);
this.ft.internal_deposit(&owner_id, total_supply.0);
this
}
// Экспортируем методы NEP-141, делегируя их `ft` (transfer, transfer_call, balance_of и т.д.)
}
Используйте вспомогательные функции управления хранилищем, чтобы пользователи могли регистрировать аккаунты, а вы могли точно отслеживать использование хранилища. Реализуйте структурированные логи в соответствии со стандартом Events для индексаторов.
Рекомендации для токен-контрактов
- Обеспечивайте правильные депозиты за хранение: Требуйте
storage_deposit
перед переводами и выпуском токенов для новых аккаунтов, чтобы избежать раздувания состояния и крайних случаев — Storage.md. - Следуйте стандартам метаданных и событий: Полные метаданные и структурированные логи улучшают обнаруживаемость и аналитику — FungibleTokenMetadata.md, Events.md.
- Используйте
ft_transfer_call
осторожно: Относитесь к логике получателя как к недоверенной. Проверяйте суммы, обрабатывайте возвраты средств через резолвер и избегайте небезопасных предположений — FungibleToken.md. - Храните балансы в 128-битных целых числах и соблюдайте единообразие десятичных знаков: В NEAR часто используется 24 десятичных знака; четко документируйте свой выбор в метаданных.
- Генерируйте читаемые человеком и машиной разбираемые логи: Индексаторы и аналитические системы полагаются на стандартизированные логи; не создавайте собственный формат.
- Предоставьте понятные административные методы с контролем доступа: Выпуск, приостановка и обновление должны быть прозрачными и поддающимися аудиту.
Влияние на экосистему в 2025 году
NEP-141 обеспечивает работу разнообразных активов в NEAR, включая крупные стейблкоины. Например, Tether интегрировал USDT в NEAR, улучшив варианты расчетов и ликвидность для пользователей DeFi — Tether запускает USDT в NEAR. Токены перемещаются между экосистемами через мосты, такие как Rainbow Bridge, и торгуются на площадках, таких как Ref Finance.
На уровне протокола NEAR продолжает развивать абстракцию цепочек и межсетевой пользовательский опыт, в первую очередь через инициативы, такие как Chain Signatures, которые направлены на упрощение межсетевых взаимодействий и управления ключами. Вы можете следить за текущими релизами и техническими обновлениями в официальном блоге — NEAR Blog, а также за подробным обзором абстракции цепочек — Chain Signatures.
Для разработчиков это означает, что токены NEP-141 все больше участвуют в межсетевых потоках, упрощенном онбординге на мобильных устройствах и композиции фронтенда через стек разработчика экосистемы NEAR. Соответствие стандартам сейчас гарантирует совместимость ваших активов по мере расширения этих возможностей.
Советы по интеграции для кошельков и dApp
- Обрабатывайте потоки хранения в пользовательском интерфейсе: Предлагайте пользователям зарегистрироваться с помощью
storage_deposit
перед первыми переводами или обменами. - Поддерживайте как
ft_transfer
, так иft_transfer_call
: Многие dApp используют последний для выполнения атомарных операций и возвратов средств. - Чисто отображайте метаданные: Используйте десятичные знаки для правильного форматирования балансов; отображайте иконки и хэши ссылок, если они доступны.
- Разбирайте стандартизированные логи: Индексируйте события NEP-141 для обеспечения уведомлений, аналитики и исторических просмотров.
Пользователи могут отслеживать балансы токенов и переводы через NEAR Explorer, а dApp могут проверять контракты или верифицировать развертывания, используя официальные спецификации в репозитории NEAR NEPs — NEPs on GitHub.
Хранение и безопасность
Низкие комиссии и быстрая финализация транзакций в NEAR делают его удобным для частых переводов, однако хранение остается критически важным. Если вы храните значительные объемы токенов NEP-141 или взаимодействуете с DeFi, рассмотрите возможность переноса ключей на оффлайн-аппаратный кошелек для верификации транзакций и снижения риска фишинга. OneKey обеспечивает подтверждение на устройстве и поддержку нескольких блокчейнов, что помогает гарантировать, что вы одобряете именно те параметры ft_transfer
или ft_transfer_call
, которые предназначены для вас, во время критически важных операций. Для активных пользователей NEAR комбинация аппаратного кошелька, разумных разрешений аккаунта и проверенных dApp может существенно снизить вашу поверхность атаки.
Ключевые выводы
- NEP-141 — это авторитетный стандарт FT в NEAR, объединяющий переводы, депозиты за хранение, метаданные и логирование событий в компонуемый интерфейс — FungibleToken.md.
- Асинхронная модель и семантика возврата средств обеспечивают более безопасные межконтрактные взаимодействия по сравнению с паттернами, основанными на разрешениях.
- Реализуйте стандарты хранения и метаданных; генерируйте структурированные логи для индексаторов.
- Токены, соответствующие NEP-141, беспрепятственно интегрируются с мостами, кошельками и DeFi-приложениями в растущей экосистеме NEAR — Rainbow Bridge, Ref Finance, NEAR Explorer.
- По мере развития NEAR в 2025 году в области абстракции цепочек и онбординга пользователей соответствие стандартам гарантирует, что ваши токены останутся переносимыми и защищенными от будущих изменений — NEAR Blog, Chain Signatures.
Независимо от того, выпускаете ли вы новый актив или держите существующие токены NEP-141, относитесь к стандарту как к своему плану — а затем добавьте надежную безопасность и понятный пользовательский интерфейс.