RPC BNB: ¿Cómo conectarse a BNB Smart Chain y elegir el endpoint correcto?

Si buscaste "RPC BNB", probablemente quieras una de dos cosas: la configuración exacta para conectarte a BNB Smart Chain, o una forma clara de decidir qué endpoint usar para tu aplicación. Esta página te da ambas. Comienza con la configuración de la cadena que puedes pegar en una billetera o en un archivo de configuración, luego recorre las opciones de endpoint, un ejemplo de solicitud funcional y los modos de fallo que aparecen con más frecuencia cuando los equipos pasan de una prueba rápida a tráfico real.

BNB Smart Chain (a menudo llamada BSC, y parte del ecosistema más amplio de BNB Chain) es una red compatible con EVM. Eso significa que cualquier herramienta que hable JSON-RPC estándar de Ethereum — ethers, viem, web3.js, Hardhat, Foundry, MetaMask — puede comunicarse con ella una vez que la apuntas a una URL RPC de BNB Chain. Las principales diferencias que notarás son el chain ID, el token nativo, el explorador de bloques y la forma en que algunas cargas de trabajo (consultas de logs, lecturas de archivo) se comportan bajo carga.

Configuración de la cadena de un vistazo

Usa estos valores al agregar BNB Smart Chain a una billetera, una configuración de backend o un script de despliegue. Coinciden con la configuración de red que OnFinality publica para BNB Chain.

Algunas notas prácticas sobre esta tabla:

• El Chain ID es el campo que con mayor frecuencia causa errores de "red incorrecta". Si una billetera o SDK está en 56 pero tu contrato está desplegado en 97, las transacciones fallarán o terminarán en la cadena equivocada.
• El símbolo del token nativo importa para la estimación de gas y para cualquier cosa que muestre saldos. En testnet es tBNB, no BNB.
• Los endpoints públicos anteriores son adecuados para desarrollo, scripts y lecturas de bajo volumen. Para tráfico de producción, planifica un endpoint gestionado o dedicado — consulta la siguiente sección.

Cuándo un endpoint público es suficiente y cuándo no

Esta es la decisión que la mayoría de los lectores realmente necesita tomar. La respuesta correcta depende menos de la red y más de la forma de tu carga de trabajo.

Un endpoint público suele ser suficiente cuando:

• Estás prototipando, ejecutando un script local o probando un despliegue de contrato.
• Estás leyendo un puñado de saldos o llamando a unas pocas funciones de vista por minuto.
• Estás validando que la configuración de tu cadena es correcta antes de conectar cualquier otra cosa.

Pasa a un endpoint gestionado o dedicado cuando:

• Ejecutas un backend que sirve a muchos usuarios, un bot o un indexador.
• Dependes de eth_getLogs sobre rangos de bloques amplios, lo cual es pesado en cualquier nodo compartido.
• Necesitas datos de archivo (estado histórico) o métodos de trace/debug.
• Necesitas suscripciones WebSocket y quieres una conexión estable en lugar de una compartida.
• Quieres rendimiento predecible y un lugar claro donde pedir ayuda cuando algo se rompe.

OnFinality ofrece RPC de BNB Chain como servicio de API gestionada y como infraestructura de nodos dedicados. La API gestionada es el camino más rápido para la mayoría de los equipos; los nodos dedicados tienen sentido cuando necesitas aislamiento, configuración personalizada o un perfil de capacidad específico. Puedes comparar planes en la página de precios de RPC y ver la lista completa de redes RPC compatibles.

Si aún estás decidiendo entre proveedores en general, la guía de selección de proveedor de RPC cubre los criterios de evaluación con más profundidad. Para BNB Chain específicamente, la página de red de BNB Chain lista los detalles del endpoint y del transporte.

Hacer tu primera solicitud

La forma más rápida de confirmar que un endpoint funciona es una sola llamada JSON-RPC. Esta le pide al nodo el número de bloque actual:

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

Una respuesta saludable se ve como un número de bloque en hexadecimal:

{"jsonrpc":"2.0","id":1,"result":"0x2a1f3c4"}

Si obtienes un campo result, tu endpoint y la configuración de la cadena están funcionando. Si en su lugar obtienes un objeto de error, salta a la sección de solución de problemas a continuación.

En JavaScript, la misma llamada a través de viem se ve así:

import { createPublicClient, http } from 'viem'
import { bsc } from 'viem/chains'

const client = createPublicClient({
  chain: bsc,
  transport: http('https://bnb.api.onfinality.io/public'),
})

const blockNumber = await client.getBlockNumber()
console.log(blockNumber)

Para una billetera, la configuración de red son los mismos datos en una forma diferente:

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

Ten en cuenta que 0x38 es 56 en hexadecimal. Las billeteras esperan la forma hexadecimal; la mayoría de los SDK aceptan la forma decimal. Mezclar las dos es una fuente común de confusión.

Soporte de WebSocket y suscripciones

BNB Chain admite transportes HTTP y WebSocket. HTTP es solicitud/respuesta: preguntas, el nodo responde, la conexión se cierra. WebSocket mantiene una conexión abierta para que el nodo pueda enviarte eventos — nuevos bloques, transacciones pendientes o logs que coincidan con un filtro.

Usa WebSocket cuando necesites:

• Reacción en tiempo real a nuevos bloques (por ejemplo, un bot que actúa en cada bloque).
• Suscripciones a logs en lugar de sondear eth_getLogs con un temporizador.
• Menor sobrecarga para lecturas de alta frecuencia donde abrir una nueva conexión HTTP cada vez es un desperdicio.

Una suscripción mínima con ethers se ve así:

import { WebSocketProvider } from 'ethers'

const provider = new WebSocketProvider('wss://bnb.api.onfinality.io/public')

provider.on('block', (blockNumber) => {
  console.log('new block', blockNumber)
})

Dos notas operativas. Primero, las conexiones WebSocket pueden caerse; tu cliente debe reconectarse y volver a suscribirse en lugar de asumir que el flujo es permanente. Segundo, si estás ejecutando muchas suscripciones, eso es una señal de que podrías querer un endpoint dedicado en lugar de uno compartido.

Modos de fallo comunes y cómo interpretarlos

La mayoría de los problemas de "RPC BNB" caen en un pequeño conjunto de categorías. Aquí te mostramos cómo distinguirlos rápidamente.

Una secuencia de diagnóstico rápida cuando algo va mal:

1. Ejecuta el curl de eth_blockNumber de arriba. Si falla, el problema es de conectividad o del endpoint, no de tu contrato.
2. Ejecuta eth_chainId y confirma que devuelve 0x38 para mainnet. Si no, estás apuntando a la red equivocada.
3. Si las llamadas simples funcionan pero las consultas de logs fallan, el problema suele ser la forma de la consulta o el nivel del nodo, no el endpoint en sí.
4. Si todo funciona localmente pero falla en producción, compara el volumen de solicitudes y la concurrencia entre ambos entornos.

Elegir entre compartido, gestionado y dedicado

Una vez que superas el prototipado, la decisión se trata principalmente de aislamiento, capacidad y cuánto trabajo operativo quieres asumir.

Una regla útil: si tu aplicación tiene usuarios esperando una respuesta, o un bot que no debe perder bloques, no lo ejecutes en un endpoint público. Pasa primero a una API gestionada, y solo ve a dedicado cuando puedas señalar una razón específica — lecturas de archivo, llamadas de trace, tasas de solicitud altas sostenidas o una necesidad de aislamiento.

Lista de verificación operativa antes de lanzar

Antes de dirigir tráfico de producción a cualquier endpoint de BNB Chain, confirma lo siguiente:

• El chain ID y el token nativo son correctos en cada entorno (mainnet y testnet).
• Tienes un endpoint o proveedor de respaldo en caso de que el principal tenga un problema.
• Tus consultas de logs usan rangos de bloques acotados y no escanean todo el historial de la cadena en cada llamada.
• Los clientes WebSocket se reconectan y vuelven a suscribirse automáticamente.
• Monitoreas tasas de error y latencia, no solo el tiempo de actividad.
• Sabes qué métodos necesita tu carga de trabajo (estándar, archivo, trace) y que tu endpoint los soporta.

Una sonda de monitoreo simple que puedes ejecutar de forma programada:

#!/usr/bin/env bash
RESP=$(curl -s -X POST https://bnb.api.onfinality.io/public \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}')
echo "$RESP" | grep -q '"result"' && echo "OK" || echo "FAIL: $RESP"

Ejecuta algo como esto desde la misma región que tu aplicación para que la latencia que midas refleje la realidad.

Puntos clave

• BNB Smart Chain es compatible con EVM, por lo que las herramientas estándar de JSON-RPC de Ethereum funcionan una vez que configuras el chain ID correcto (56 mainnet, 97 testnet) y la URL RPC.
• Los endpoints públicos son adecuados para desarrollo y lecturas de bajo volumen; las aplicaciones de producción, bots e indexadores deberían usar un endpoint gestionado o dedicado.
• El soporte de WebSocket importa para suscripciones en tiempo real a bloques y logs; planifica reconexiones.
• La mayoría de los fallos se remontan a desajustes de chain ID, métodos no soportados, consultas de logs amplias o límites de tasa del endpoint compartido.
• OnFinality proporciona RPC de BNB Chain como API gestionada y como nodos dedicados; consulta precios de RPC y redes compatibles para más detalles.

Preguntas frecuentes

¿Cuál es la URL RPC para BNB Smart Chain? OnFinality publica un endpoint público en https://bnb.api.onfinality.io/public para mainnet y https://bnb-testnet.api.onfinality.io/public para testnet. Para producción, usa un endpoint gestionado o dedicado desde la página de red de BNB Chain.

¿Cuál es el chain ID de BNB Chain? BNB Smart Chain mainnet usa el chain ID 56 (0x38 en hexadecimal). BNB Smart Chain testnet usa el chain ID 97 (0x61 en hexadecimal).

¿El RPC de BNB Chain admite WebSocket? Sí. El endpoint de mainnet de BNB Chain de OnFinality admite transportes HTTP y WebSocket. Testnet es solo HTTP en la configuración publicada.

¿Por qué eth_getLogs se agota el tiempo de espera en BNB Chain? Los rangos de bloques amplios son costosos. Los nodos compartidos pueden rechazar o agotar el tiempo de espera en rangos grandes. Reduce el rango, pagina o pasa a un endpoint dedicado si necesitas consultas históricas amplias.

¿Necesito un nodo de archivo para BNB Chain? Solo si necesitas estado histórico — saldos o almacenamiento de contratos en bloques antiguos. Los endpoints estándar sirven estado reciente; el acceso de archivo es una capacidad separada.

¿Puedo usar MetaMask con un endpoint RPC de BNB Chain? Sí. Agrega una red personalizada con chain ID 56, la URL RPC y la URL del explorador BscScan. El ejemplo de configuración de billetera anterior muestra los campos exactos.

¿Cómo pruebo BNB Chain sin gastar BNB real? Usa BNB Smart Chain testnet (chain ID 97) con tBNB de un faucet, y apunta tu aplicación al endpoint de testnet. Consulta la página de BNB Chain Testnet.

¿Cuándo debería pasar de un endpoint público a un nodo dedicado? Cuando tengas volumen de solicitudes sostenido, necesites métodos de archivo o trace, requieras aislamiento o quieras capacidad predecible. Hasta entonces, una API gestionada suele ser el siguiente paso correcto — consulta nodos dedicados para saber cuándo vale la pena el aislamiento.