BEP20

BEP-20 (также часто пишется BEP20) — технический стандарт смарт-контрактов взаимозаменяемых токенов в BNB Smart Chain (BSC). Аббревиатура BEP означает BNB Evolution Proposal; BEP-20 является действующим предложением стандарта в репозитории предложений BNB Chain. Его интерфейс основан на стандарте ERC-20 сети Ethereum и определяет общие методы и события для балансов, переводов и делегированного расходования.

Взаимозаменяемость означает, что единицы, учитываемые одним контрактом токена, равноценны друг другу, а не обладают индивидуальными различиями. Контракт хранит балансы, закреплённые за адресами, и применяет к каждой единице одинаковые правила перевода. BEP-20 определяет, как совместимые контракты предоставляют эти операции кошелькам, биржам, другим контрактам и программам индексирования. Стандарт не задаёт денежную политику токена, обеспечение, управление, полномочия администраторов, рыночную стоимость или безопасность.

Интерфейс

Стандарт определяет следующие открытые методы:

Метод	Назначение	Статус в BEP-20
name()	Возвращает удобочитаемое название токена	Необязательный
symbol()	Возвращает символ токена, подобный биржевому тикеру	Обязательный
decimals()	Возвращает точность десятичного представления	Обязательный
totalSupply()	Возвращает сообщаемое контрактом общее предложение токена	Обязательный
balanceOf(address)	Возвращает баланс, закреплённый за адресом	Обязательный
transfer(address, uint256)	Переводит токены от вызывающей стороны на другой адрес	Обязательный
approve(address, uint256)	Устанавливает сумму, которой может распорядиться получившая разрешение сторона	Обязательный
allowance(address, address)	Возвращает оставшуюся разрешённую сумму	Обязательный
transferFrom(address, address, uint256)	Переводит токены на основании ранее выданного разрешения	Обязательный

Совместимые контракты создают событие Transfer при переводе и событие Approval при успешной выдаче разрешения. Переводы нулевой суммы допустимы и также создают Transfer. Спецификация требует, чтобы вызывающая сторона обрабатывала логический результат false, а не считала успешным любой вызов, завершившийся без ошибки.

Балансы, предложение и десятичное отображение

Интерфейс учитывает суммы токенов как целые беззнаковые числа. Значение decimals указывает пользовательским интерфейсам, как масштабировать эти базовые единицы для отображения. Например, если контракт сообщает о восьми десятичных знаках, целочисленный баланс в 100 000 000 базовых единиц отображается как одна единица токена. Эта настройка не создаёт дробей в хранилище контракта и не определяет рыночную стоимость токена.

totalSupply сообщает количество, существующее по правилам контракта, а balanceOf — количество, закреплённое за конкретным адресом. Ни один из методов не определяет способ создания предложения. Контракт может назначить фиксированное начальное предложение при развёртывании либо реализовать дополнительную логику выпуска или сжигания; такая политика находится за пределами основного интерфейса. Спецификация указывает, что создание новых единиц должно порождать событие Transfer с нулевым адресом в качестве источника, но не требует открытого метода выпуска.

Переводы и разрешения

Прямой вызов transfer перемещает сумму с баланса вызывающей стороны получателю. Контракт проверяет и обновляет собственное состояние и создаёт стандартное событие. Поэтому перевод токена представляет собой вызов контракта токена и отличается от перевода BNB — нативного актива сети.

Для делегированного расходования используются три метода. Сначала владелец вызывает approve, чтобы установить максимальную сумму, которой может распорядиться другая сторона. Программа может прочитать оставшуюся сумму с помощью allowance. Затем получившая разрешение сторона вызывает transferFrom, чтобы в пределах этого разрешения перевести токены с баланса владельца. Такая схема позволяет другому смарт-контракту действовать с разрешения владельца токенов, не получая контроль над всем его балансом.

Повторный вызов approve заменяет текущее разрешение, а не прибавляет к нему сумму. Спецификации BEP-20 и ERC-20 предупреждают разработчиков клиентских программ об изменении одного ненулевого разрешения непосредственно на другое: порядок транзакций может позволить использовать оба значения. Рекомендуются интерфейсы, которые сначала устанавливают разрешение в ноль, а затем задают новое ненулевое значение. Разрешение даёт право расходования, но само по себе не переводит токены.

События и совместимость

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

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

Связь с ERC-20

BEP-20 сохраняет основной интерфейс переводов и разрешений ERC-20, благодаря чему совместимые с EVM программы могут взаимодействовать с ним привычным способом. Одно из различий между действующими письменными спецификациями относится к метаданным: в ERC-20 методы name, symbol и decimals необязательны, тогда как BEP-20 требует symbol и decimals, оставляя name необязательным.

Стандарты не определяют консенсус, пропускную способность, комиссии за транзакции или порядок подтверждения и достижения окончательности в своих сетях. Это свойства базовых блокчейнов и их текущих конфигураций. BSC совместима с EVM, а её нативный токен BNB используется для оплаты комиссий за транзакции BSC. Совместимость с EVM позволяет повторно использовать многие инструменты и шаблоны контрактов для Ethereum, но не приводит к автоматическому совместному использованию одного контракта токена или его балансов в BSC и Ethereum.

Применение и представление активов

Контракты BEP-20 могут учитывать взаимозаменяемые единицы приложения, вес голоса, единицы поощрения или доступа, требования, предназначенные для отслеживания другого актива, и иные взаимозаменяемые величины. Эти функции выбираются реализацией и связанным с ней приложением, а не предоставляются стандартом как отдельные возможности.

В частности, интерфейс не проверяет, обеспечен ли токен другим активом, допускает ли погашение, стабилен ли по цене, управляется ли децентрализованным процессом или принимается ли каким-либо сервисом. Обёрнутое или перемещённое через мост представление также зависит от внешних по отношению к BEP-20 механизмов, которые выпускают и погашают его. Стандарт лишь делает распознаваемыми общие операции контракта токена.

История BNB Beacon Chain

В ранних материалах BEP-20 описывалась межсетевая привязка к активам BEP-2 в BNB Beacon Chain. BNB Chain вывела Beacon Chain из эксплуатации в рамках процесса BNB Chain Fusion 2024 года: окончательное ответвление для прекращения работы состоялось в ноябре, а остановка валидаторов была запланирована на декабрь.

Прежний интерфейс также содержал getOwner(), который использовался для привязки токенов BEP-20 и BEP-2. BNB Chain удалила этот метод из действующей спецификации BEP-20 изменением, объединённым 12 февраля 2025 года, поскольку Beacon Chain больше не существовала. Документация или шаблоны контрактов, где getOwner() всё ещё называется требованием BEP-20, описывают выведенный из эксплуатации процесс, а не текущий интерфейс.

Идентификация токена и выбор сети

Развёрнутый токен BEP-20 идентифицируется сетью BNB Smart Chain и адресом контракта. Названия и символы являются отображаемыми метаданными и могут повторяться, поэтому их недостаточно, чтобы установить, представляет ли контракт требуемый актив. Программа-кошелёк может потребовать выбрать BSC и импортировать точный адрес контракта, прежде чем показывать токен.

BSC и Ethereum используют совместимые форматы адресов, но балансы токенов существуют в контрактах конкретной сети. Отправка через непредусмотренную сеть не имеет единого результата: возможность восстановления зависит от того, контролирует ли отправитель или получатель адрес назначения и может ли помочь кастодиальный сервис.

Расширения и ограничения безопасности

Соответствие BEP-20 не означает одинакового поведения всех контрактов токенов. Реализации могут добавлять выпуск, сжигание, приостановку, комиссии за перевод, списки блокировки, возможность обновления или привилегированные административные функции. Основной интерфейс BEP-20 не требует ни одной из них, и каждая изменяет допущения о безопасности и доверии для контракта.

Унаследованный интерфейс также не предусматривает обязательного обратного вызова, с помощью которого принимающий контракт подтверждает возможность учесть поступающие токены. Поэтому стандартный перевод на адрес контракта может завершиться успешно, даже если принимающий контракт не способен использовать или вернуть эти токены. Приложениям, принимающим депозиты токенов, необходим явно предусмотренный механизм обработки; им не следует считать совместимым любой контракт-получатель.

Соответствие стандарту не доказывает, что исходный код был проверен, отображаемые метаданные достоверны, заявления о предложении или обеспечении верны, привилегированные ключи защищены или приложение безопасно. Конкретный развёрнутый контракт, его байт-код и конфигурацию, полномочия администраторов и взаимодействующее приложение следует оценивать отдельно. BEP-20 стандартизирует совместимость на уровне интерфейса, но не является сертификацией актива или эмитента.