BNB Chain RPC: endpoints, configuración y límites de tasa para 2026

BNB Chain (BNB Smart Chain) es una red compatible con EVM, lo que significa que su superficie RPC es la misma interfaz JSON-RPC que ya usa para Ethereum. El trabajo práctico no es aprender una nueva API, sino configurar correctamente los parámetros de la cadena, conectar el endpoint en su billetera o biblioteca, y comprender cómo los límites de tasa y los patrones de solicitud afectan la confiabilidad a medida que crece su tráfico.

Esta referencia cubre la configuración de la red principal y la testnet, una ruta de configuración funcional, y las preguntas sobre límites y carga de trabajo que importan cuando pasa de una prueba rápida a tráfico de producción.

¿Con qué endpoint de BNB Chain debería empezar?

Elija su punto de partida según lo que está haciendo ahora, no según lo que podría hacer más adelante.

Si aún está explorando, comience con un endpoint público y avance una vez que alcance su primer límite de tasa o tiempo de espera. Si ya sabe que ejecutará tráfico de producción, omita el nivel público y evalúe una API RPC administrada desde el principio: migrar más tarde cuesta más tiempo que elegir bien desde el principio.

Para un marco más amplio, consulte cómo elegir un proveedor de RPC.

Configuración de la red BNB Chain de un vistazo

Estos son los valores que pega en una billetera, un archivo .env o una configuración de framework. Mantenga la red principal y la testnet separadas: mezclarlas es uno de los errores de configuración más comunes.

OnFinality expone endpoints públicos para ambas redes:

• Mainnet: https://bnb.api.onfinality.io/public
• Testnet: https://bnb-testnet.api.onfinality.io/public

Estos son endpoints públicos compartidos, así que trátelos como un punto de partida en lugar de una garantía de producción. Para acceso administrado con límites más altos, consulte BNB Chain RPC y BNB Chain Testnet RPC.

Agregar BNB Chain a una billetera

La mayoría de las billeteras EVM aceptan una red personalizada. Los campos se asignan directamente a la configuración anterior:

{
  "chainId": "0x38",
  "chainName": "BNB Smart Chain Mainnet",
  "nativeCurrency": {
    "name": "BNB Chain Native Token",
    "symbol": "BNB",
    "decimals": 18
  },
  "rpcUrls": ["https://bnb.api.onfinality.io/public"],
  "blockExplorerUrls": ["https://bscscan.com"]
}

Tenga en cuenta que chainId está en hexadecimal en las configuraciones de billetera: 56 decimal es 0x38, y 97 decimal es 0x61. Si una billetera rechaza su red, un chain ID hexadecimal incorrecto es la causa habitual.

Probar el endpoint con curl

Antes de conectar cualquier cosa a una aplicación, confirme que el endpoint responde e informa la cadena que espera:

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

Una respuesta correcta de la red principal devuelve 0x38. Para verificar que el nodo está sincronizado, llame a eth_blockNumber y compárelo con un explorador de bloques:

curl -s https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_blockNumber","params":[]}'

Si eth_chainId devuelve el valor incorrecto, está apuntando a la red equivocada. Si eth_blockNumber está muy por detrás del explorador, el nodo puede estar poniéndose al día o el endpoint puede estar degradado.

Conectar BNB Chain a JavaScript

Con ethers o viem, la configuración es un cambio de una línea una vez que tiene el endpoint:

import { JsonRpcProvider } from "ethers";

const provider = new JsonRpcProvider(
  "https://bnb.api.onfinality.io/public",
  { chainId: 56, name: "bnb" }
);

const block = await provider.getBlockNumber();
console.log("Latest BNB Chain block:", block);

Para la testnet, cambie la URL a https://bnb-testnet.api.onfinality.io/public y establezca chainId: 97. Mantenga estos valores en variables de entorno en lugar de codificarlos, para que pueda rotar endpoints sin un redespliegue.

Cómo afectan realmente los límites de tasa a las aplicaciones de BNB Chain

Los límites de tasa generalmente se expresan como solicitudes por segundo o por minuto, pero el número por sí solo no le dice si un endpoint resistirá. Lo que importa es cómo su carga de trabajo se asigna a esos límites.

• Peso del método. Las llamadas baratas como eth_blockNumber y eth_chainId consumen mucha menos capacidad que eth_getLogs, eth_call contra contratos complejos o métodos de trace. Un límite que parece generoso para el sondeo de bloques puede desaparecer rápidamente bajo consultas de logs.
• Ráfaga vs sostenido. Muchos proveedores permiten ráfagas cortas por encima de la tasa sostenida. Un bot que dispara 200 solicitudes en un segundo y luego se queda inactivo se comporta de manera muy diferente a uno que envía 20 solicitudes cada segundo para siempre.
• Compartido vs aislado. Los endpoints públicos y compartidos agrupan capacidad entre todos los usuarios, por lo que su rendimiento efectivo puede caer cuando el grupo está ocupado. Los nodos dedicados eliminan esa variabilidad.
• Tamaño de la carga útil. Los rangos grandes de eth_getLogs devuelven respuestas grandes. Algunos proveedores limitan el tamaño del resultado o el rango de bloques independientemente del número de solicitudes.

Una forma práctica de planificar: mida su mezcla real de solicitudes, no una suposición. Registre los nombres de los métodos y los recuentos durante un día, luego dimensione su endpoint según los métodos más pesados en lugar del promedio.

Asignar la carga de trabajo al tipo de endpoint

Si su fila en esta tabla cae en "dedicado", la decisión es menos sobre límites de tasa y más sobre aislamiento y capacidad predecible. Consulte nodo dedicado para saber cómo funciona ese modelo.

Problemas comunes de configuración y límites

Chain ID incorrecto. Una billetera o biblioteca configurada con 0x1 (Ethereum) en lugar de 0x38 se conectará pero devolverá resultados confusos. Verifique siempre con eth_chainId.

Claves de testnet en producción. El tBNB de testnet no tiene valor. Si un despliegue apunta silenciosamente a la cadena 97, las transacciones parecerán tener éxito pero nunca se liquidarán en la red principal.

Rango de eth_getLogs demasiado amplio. Muchos endpoints rechazan o truncan rangos de bloques muy grandes. Divida las consultas en ventanas más pequeñas y pagine.

Respuestas 429 bajo carga. Un pico repentino de 429 Too Many Requests generalmente significa que el tráfico en ráfaga superó el plan. Agregue reintentos con retroceso exponencial y considere un nivel superior o un nodo dedicado si se repite.

Caídas de WebSocket. Los intermediarios pueden cerrar suscripciones de larga duración. Implemente lógica de reconexión y vuelva a suscribirse al reconectar en lugar de asumir que el socket permanece abierto.

Altura de bloque obsoleta. Si eth_blockNumber deja de avanzar, el endpoint puede estar resincronizándose. Cambie a un segundo endpoint en lugar de reintentar el mismo.

Ejecutar BNB Chain RPC en producción

Una vez superada la configuración, las preguntas operativas cambian. Tres cosas son las más importantes:

1. Conmutación por error. Configure al menos dos endpoints y cambie ante error o retraso. Un solo endpoint es un punto único de falla independientemente del proveedor.
2. Monitoreo. Realice un seguimiento de la tasa de éxito de solicitudes, los percentiles de latencia y el retraso de la altura de bloque. Alerte sobre el retraso antes de que los usuarios lo noten.
3. Planificación de capacidad. Vuelva a medir su mezcla de solicitudes después de cada lanzamiento importante de funciones. Las funciones con muchos logs cambian su perfil más que el crecimiento de usuarios.

OnFinality ofrece acceso a la API RPC de BNB Chain e infraestructura de nodo dedicado para equipos que necesitan una capacidad más predecible que la que proporcionan los endpoints públicos. Compare opciones en Precios de RPC y revise redes RPC compatibles si trabaja con múltiples cadenas.

Puntos clave

• BNB Smart Chain usa el chain ID 56 (mainnet) y 97 (testnet), con métodos JSON-RPC estándar de EVM.
• Los endpoints públicos son adecuados para pruebas; el tráfico de producción necesita límites predecibles y conmutación por error.
• Los límites de tasa dependen del peso del método y los patrones de ráfaga, no solo de las solicitudes por segundo.
• eth_getLogs y las consultas de archivo son las fuentes más comunes de problemas de límites y tiempos de espera.
• Verifique el chain ID y la altura de bloque antes de depurar cualquier otra cosa.
• Las API RPC administradas y los nodos dedicados intercambian costo por aislamiento y capacidad.

Preguntas frecuentes

¿Cuál es la URL RPC de la red principal de BNB Chain? El endpoint público de la red principal de OnFinality es https://bnb.api.onfinality.io/public. Para acceso administrado, consulte la página de la red BNB Chain.

¿Qué chain ID usa BNB Smart Chain? 56 para la red principal (0x38 en hexadecimal) y 97 para la testnet (0x61 en hexadecimal).

¿BNB Chain RPC admite WebSocket? La red principal admite transporte HTTP y WebSocket. Verifique el endpoint y el plan específicos, ya que los endpoints públicos pueden restringir las suscripciones.

¿Por qué recibo errores 429? Probablemente está superando un límite de tasa de ráfaga o sostenido. Agregue reintentos con retroceso exponencial, reduzca la frecuencia de solicitudes o pase a un nivel superior o nodo dedicado.

¿Puedo usar el mismo endpoint para testnet y mainnet? No. Son redes separadas con chain IDs y endpoints separados. Manténgalos en configuraciones separadas.

¿Cómo sé si un endpoint está sincronizado? Llame a eth_blockNumber y compárelo con un explorador de bloques. Una gran diferencia sugiere que el nodo se está poniendo al día o está degradado.