BNB Smart Chain (BSC) ha activado un nuevo mecanismo llamado Payment Lane en su testnet, que reserva el 5% del límite de gas de cada bloque para transacciones de pago elegibles. La función llega bajo BEP-703 como parte del hardfork Jenner, que ya está activo en la testnet de BSC, y está diseñada para proteger el tráfico de pagos de la congestión causada por la actividad general de la red.

Los comerciantes y los servicios de pago enfrentan con frecuencia una inclusión de transacciones impredecible durante los picos de actividad, y la nueva regla apunta precisamente a ese problema. Para los negocios de pagos, una transacción que queda en espera durante un pico de congestión es un asentamiento retrasado y no una simple cuestión abstracta de tarifas, razón por la cual la capacidad de bloque garantizada se ha convertido en una consideración de diseño relevante. Los desarrolladores y constructores de bloques ahora pueden probar integraciones en la testnet antes de cualquier posible despliegue en la mainnet.

BNB Smart Chain es la red de BNB Chain compatible con la Ethereum Virtual Machine, con BNB como el activo nativo utilizado para pagar las tarifas de gas. El gas es la unidad que mide el trabajo computacional de las transacciones, y cada bloque tiene una cantidad máxima de este. Debido a que ese límite convierte el espacio de bloque en un recurso finito, las transacciones compiten por su inclusión siempre que la demanda es alta, la condición que Payment Lane está diseñado para suavizar.

Anuncio en X

BNB Chain Developers dijo en X que los mecanismos de gobernanza para CAS20 y Payment Lane han sido implementados y verificados. El hardfork Jenner también trae las bases de CAS20 y marcas de tiempo de milisegundos a la testnet de BSC.

Governance mechanisms for CAS20 and Payment Lane have been implemented and verified. The Jenner hardfork now brings three key updates to BSC testnet: CAS20 functionality: Lays the groundwork for a new Compliant Asset Standard, with tools to manage token transfers, supply,… pic.twitter.com/gNUDLT2KsO

— BNB Chain Developers (@BNBChainDevs) November 1, 2026

Cómo Payment Lane reserva la capacidad de bloque

Payment Lane funciona como una regla de contabilidad de gas aplicada durante la validación de bloques, que limita cuánto gas pueden consumir las transacciones generales. Las transacciones de pago y las generales pueden seguir apareciendo en cualquier orden dentro de un bloque.

Las transacciones generales no pueden tocar el gas reservado, incluso cuando la demanda de pagos es baja. Mientras tanto, los pagos elegibles pueden utilizar la reserva y seguir compitiendo por la capacidad restante bajo las reglas de tarifas existentes. Por lo tanto, la cuota del 5% establece un mínimo para la capacidad de pagos sin imponer un techo a la actividad de pagos. A modo de ejemplo, un bloque con un límite de gas de 100 millones reservaría 5 millones de gas para pagos, dejando 95 millones para transacciones generales.

Esa estructura de piso y no de techo es lo que separa una reserva de simplemente ampliar el límite de gas del bloque: un límite mayor añade capacidad para todos los tipos de tráfico a la vez, mientras que una reserva protege una cuota para los pagos sin importar cuán pesada se vuelva la actividad general.

Qué transacciones califican

Dos vías conducen a la clase de pago. La primera cubre las transacciones enviadas directamente a un contrato incluido en la lista de pagos administrada por la gobernanza. La segunda cubre las transferencias de BNB distintas de cero a cuentas que no contienen código.

Ambas vías requieren una dirección de destino y excluyen las transacciones del sistema. Admiten los tipos de transacción 0x00, 0x01 y 0x02. La creación de contratos, las transacciones blob y las transacciones de tipo 0x04 cuentan como tráfico general.

Para los contratos listados, la clasificación depende de la dirección de destino, independientemente de la función llamada. Una transferencia de stablecoin enviada directamente a un contrato de token listado puede calificar, mientras que una transacción enviada a un router no listado no califica, incluso si el router posteriormente mueve esa stablecoin. La lista de contratos de pago comienza vacía. Hasta que la gobernanza agregue los primeros contratos, la vía de transferencia de BNB será el único camino hacia la clase de pago.

Reglas de gobernanza y validadores

La gobernanza controla tanto la lista de contratos de pago como la proporción de reserva, que por defecto es del 5% y tiene un máximo protocolar del 10%. Los nodos leen la configuración del estado del bloque padre, lo que significa que una actualización no puede alterar la clasificación a mitad de un bloque.

Los constructores de bloques deben tener en cuenta la reserva al ensamblar bloques, y los validadores rechazan cualquier bloque cuya asignación de gas rompa la regla. Bajo el flujo SendBidBlock de BEP-675, la verificación se realiza durante la importación local después de la difusión, y las violaciones se canalizan a través del mecanismo de revocación del constructor.

El gas reservado sin usar permanece ocioso por diseño. Si los productores pudieran reasignarlo, podrían llenar los bloques con tráfico general y dejar fuera los pagos por completo.

El mecanismo no garantiza inclusión, tarifas fijas ni transferencias gratuitas. Los equipos pueden usar la testnet para verificar destinos, tipos de transacción y listado por gobernanza, y la reserva se aplica por primera vez en el bloque inmediatamente posterior a la activación del fork. A partir de aquí, los indicadores observables son las decisiones de gobernanza sobre qué contratos entran en la lista de pagos, cualquier ajuste de la proporción dentro de su techo protocolar del 10% y el comportamiento de la testnet antes de cualquier posible despliegue en la mainnet.

Reportaje vía Blockonomi.