BEP20

BEP-20 (también escrito habitualmente BEP20) es un estándar técnico para contratos inteligentes de tokens fungibles en BNB Smart Chain (BSC). «BEP» significa BNB Evolution Proposal, y BEP-20 es una propuesta de estándar habilitada en el repositorio de propuestas de BNB Chain. Su interfaz, derivada del estándar ERC-20 de Ethereum, define métodos y eventos comunes para saldos, transferencias y gastos delegados.

La fungibilidad significa que las unidades registradas por un mismo contrato de token son intercambiables entre sí, en vez de ser individualmente distintas. El contrato registra los saldos asignados a direcciones y aplica las mismas reglas de transferencia a cada unidad. BEP-20 especifica cómo exponen esas operaciones los contratos compatibles a monederos, plataformas de intercambio, otros contratos y programas de indexación. No prescribe la política monetaria, el respaldo, la gobernanza, los privilegios administrativos, el valor de mercado ni la seguridad de un token.

Interfaz

El estándar define los siguientes métodos públicos:

Método	Finalidad	Estado en BEP-20
name()	Devuelve un nombre de token legible	Opcional
symbol()	Devuelve el símbolo del token, similar a un código bursátil	Obligatorio
decimals()	Devuelve la precisión decimal usada para la visualización	Obligatorio
totalSupply()	Devuelve la oferta total comunicada por el contrato	Obligatorio
balanceOf(address)	Devuelve el saldo asignado a una dirección	Obligatorio
transfer(address, uint256)	Transfiere tokens desde quien realiza la llamada a otra dirección	Obligatorio
approve(address, uint256)	Establece la cantidad que puede utilizar un tercero autorizado	Obligatorio
allowance(address, address)	Devuelve la cantidad autorizada restante	Obligatorio
transferFrom(address, address, uint256)	Transfiere tokens mediante una autorización concedida previamente	Obligatorio

Los contratos compatibles emiten un evento Transfer para las transferencias y un evento Approval cuando una autorización se completa correctamente. Las transferencias de valor cero son válidas y también emiten Transfer. La especificación exige que quien llama gestione un resultado booleano false, en lugar de suponer que toda llamada que termina con normalidad ha tenido éxito.

Saldos, oferta y visualización decimal

La interfaz contabiliza las cantidades de tokens como enteros sin signo. El valor decimals indica a las interfaces de usuario cómo escalar esas unidades básicas para mostrarlas. Por ejemplo, si un contrato declara ocho decimales, un saldo entero de 100 000 000 unidades básicas se muestra como una unidad de token. Este ajuste no crea fracciones en el almacenamiento del contrato ni determina el valor de mercado del token.

totalSupply informa de la cantidad existente conforme a las reglas del contrato, mientras que balanceOf informa de la cantidad asignada a una dirección concreta. Ninguno de los dos métodos determina cómo se creó la oferta. Un contrato puede asignar una oferta inicial fija al desplegarse o implementar lógica adicional de emisión o quema; esas políticas quedan fuera de la interfaz básica. La especificación indica que la creación de nuevas unidades debe emitir Transfer con la dirección cero como origen, pero no exige una función pública de emisión.

Transferencias y autorizaciones

Una solicitud directa de transfer mueve una cantidad del saldo de quien llama a un destinatario. El contrato comprueba y actualiza su propio estado y emite el evento estándar. Por tanto, una transferencia de tokens es una llamada al contrato del token; no es lo mismo que transferir BNB, el activo nativo de la red.

El gasto delegado utiliza tres métodos. Primero, un propietario llama a approve para establecer la cantidad máxima que puede utilizar un tercero autorizado. El programa puede consultar la cantidad restante mediante allowance. Después, el tercero autorizado llama a transferFrom para mover tokens desde el saldo del propietario, con el límite de esa autorización. Este patrón permite que otro contrato inteligente actúe con la autorización del titular sin recibir el control de todo su saldo.

Volver a llamar a approve sustituye la autorización actual; no se suma a ella. Las especificaciones BEP-20 y ERC-20 advierten a los desarrolladores de clientes sobre el cambio directo de una autorización distinta de cero a otra, porque el orden de las transacciones puede permitir usar ambos valores. Recomiendan interfaces que primero establezcan la autorización en cero antes de fijar otro valor distinto de cero. Una autorización concede facultad de gasto; por sí misma no transfiere tokens.

Eventos e interoperabilidad

Las firmas de métodos, los tipos de retorno y los eventos estandarizados ofrecen a las aplicaciones una forma común de interactuar con distintos contratos de tokens. Una aplicación puede utilizar la interfaz binaria de aplicaciones (ABI) de un contrato para consultar metadatos, saldos, oferta y autorizaciones, o enviar llamadas estándar de transferencia y aprobación sin depender del diseño de almacenamiento interno del contrato.

Los eventos Transfer y Approval permiten que exploradores, monederos e indexadores observen operaciones estándar en los registros de las transacciones. Los eventos ayudan a reconstruir la actividad, pero los saldos y autorizaciones actuales pueden seguir dependiendo de la implementación y el estado concretos del contrato. Un programa no debe asumir que unos metadatos conocidos o un evento emitido demuestran la identidad o la calidad de un token.

Relación con ERC-20

BEP-20 conserva la interfaz básica de transferencias y autorizaciones de ERC-20, lo que permite que el software compatible con la EVM interactúe con ella de una forma conocida. Una diferencia entre las especificaciones escritas actuales afecta a los metadatos: ERC-20 considera opcionales name, symbol y decimals, mientras que BEP-20 exige symbol y decimals, pero mantiene name como opcional.

Los estándares no definen el consenso, la capacidad, las comisiones de transacción ni el comportamiento de confirmación y finalidad de sus redes. Son propiedades de las cadenas de bloques subyacentes y de sus configuraciones vigentes. BSC es compatible con la EVM y su token nativo BNB se utiliza para pagar las comisiones de transacción de BSC. La compatibilidad con la EVM permite reutilizar muchas herramientas y patrones de contratos orientados a Ethereum, pero no hace que un contrato de token ni sus saldos se compartan automáticamente entre BSC y Ethereum.

Usos y representación

Los contratos BEP-20 pueden contabilizar unidades intercambiables de una aplicación, peso de voto, unidades de incentivo o acceso, derechos diseñados para seguir otro activo u otras magnitudes fungibles. Son funciones elegidas por la implementación y la aplicación que la rodea, no capacidades distintas otorgadas por el estándar.

En particular, la interfaz no comprueba que un token esté respaldado por otro activo, sea reembolsable, mantenga un precio estable, esté controlado por un proceso descentralizado o sea aceptado por algún servicio. Una representación envuelta o puenteada también depende de mecanismos externos a BEP-20 que la emiten y reembolsan. El estándar solo permite reconocer las operaciones comunes del contrato del token.

Historia de BNB Beacon Chain

Los primeros materiales de BEP-20 incluían la vinculación entre cadenas con activos BEP-2 de BNB Beacon Chain. BNB Chain retiró Beacon Chain mediante el proceso BNB Chain Fusion de 2024, con la bifurcación final de cierre en noviembre y la desconexión de validadores programada para diciembre.

La interfaz anterior también incluía getOwner(), utilizado para vincular tokens BEP-20 y BEP-2. BNB Chain lo eliminó de la especificación BEP-20 vigente mediante un cambio integrado el 12 de febrero de 2025, porque Beacon Chain ya no existía. La documentación o las plantillas de contratos que aún describen getOwner() como un requisito de BEP-20 se refieren al proceso retirado, no a la interfaz actual.

Identidad del token y selección de red

Un token BEP-20 desplegado se identifica por BNB Smart Chain y por la dirección de su contrato. Los nombres y símbolos son metadatos de visualización y pueden duplicarse, por lo que no bastan para determinar que un contrato representa el activo previsto. El programa de un monedero puede exigir que el usuario seleccione BSC e importe la dirección exacta del contrato antes de mostrar un token.

BSC y Ethereum utilizan formatos de dirección compatibles, pero los saldos de tokens existen en contratos de una red concreta. Enviar mediante una red no prevista no tiene un resultado universal: la recuperación depende de si el remitente o el destinatario controla la dirección de destino y de si un custodio puede prestar ayuda.

Extensiones y limitaciones de seguridad

El cumplimiento de BEP-20 no implica que todos los contratos de tokens se comporten igual. Las implementaciones pueden añadir emisión, quema, pausas, comisiones de transferencia, listas de bloqueo, capacidad de actualización o funciones administrativas privilegiadas. Ninguna es obligatoria en la interfaz básica de BEP-20 y cada una modifica los supuestos de seguridad y confianza del contrato.

La interfaz heredada tampoco incluye una retrollamada obligatoria con la que un contrato receptor confirme que puede contabilizar los tokens entrantes. Por ello, una transferencia estándar a la dirección de un contrato puede completarse aunque el contrato receptor no tenga un mecanismo para utilizar o devolver esos tokens. Las aplicaciones que aceptan depósitos de tokens necesitan un diseño de gestión explícito, en lugar de suponer que todo contrato destinatario es compatible.

El cumplimiento del estándar no demuestra que el código fuente haya sido revisado, que los metadatos mostrados sean veraces, que las afirmaciones sobre oferta o respaldo sean correctas, que las claves privilegiadas estén protegidas ni que una aplicación sea segura. El contrato desplegado exacto, su bytecode y configuración, las facultades de los administradores y la aplicación que interactúa con él deben evaluarse por separado. BEP-20 estandariza la interoperabilidad en el nivel de la interfaz; no certifica un activo ni un emisor.