URL RPC pública de BNB Smart Chain: ¿cómo te conectas y cuándo deberías cambiar?

Configuración de la cadena de un vistazo

Si solo necesitas una cosa de esta página, es el detalle de conexión. La mainnet de BNB Smart Chain usa el chain ID 56, el token nativo BNB (18 decimales) y el explorador de bloques en https://bscscan.com. OnFinality publica un endpoint HTTPS público que puedes usar en una billetera o en un script:

Esa única URL es suficiente para leer saldos, llamar a eth_call, estimar gas y transmitir transacciones firmadas. Lo que no es, es una garantía de capacidad. Un endpoint público es compartido, así que trátalo como un punto de partida y no como la columna vertebral de un sistema en producción.

Cuándo un endpoint público es la opción adecuada

Antes de copiar la URL en un archivo de configuración, decide en cuál de estas tres situaciones te encuentras.

Prototipado y desarrollo local. Estás conectando una dApp, probando un contrato o consultando un saldo. Un endpoint público elimina la necesidad de sincronizar un nodo, lo que en BNB Smart Chain implica una gran descarga y un costo operativo continuo. Úsalo, avanza rápido y no sobreingenierices.

Configuración de billetera y red manual. Estás agregando BNB Smart Chain a una billetera o a una herramienta que solo necesita lecturas ocasionales. La RPC pública es un valor predeterminado razonable aquí, y el chain ID más la URL del explorador de arriba son lo que piden la mayoría de las billeteras.

Tráfico de producción, indexación o trading. Estás ejecutando un backend que consulta bloques, un indexador que rellena el historial, un bot que necesita escrituras de baja latencia o un servicio con un compromiso de soporte. En este punto, la capacidad pública compartida se convierte en un lastre: no puedes ver tu propio uso, no puedes aumentar tus propios límites y un vecino ruidoso te afecta. Aquí es donde una API RPC gestionada o un nodo dedicado empiezan a valer la pena. Si estás evaluando ese paso, la guía de selección de proveedor de RPC repasa los criterios, y precios de RPC muestra cómo se estructuran los niveles.

Una regla útil: si te daría vergüenza explicarle a un usuario por qué falló una solicitud, has superado el endpoint público.

Agregar BNB Smart Chain a una billetera

La mayoría de las billeteras aceptan una red personalizada. Los campos se corresponden directamente con la tabla anterior. En JSON estilo MetaMask, una configuración de red se ve así:

{
  "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"]
}

Ten en cuenta que 0x38 es 56 en hexadecimal. Las billeteras esperan la forma hexadecimal; JSON-RPC y la mayoría de los SDK esperan la forma decimal. Mezclar las dos es uno de los errores de configuración más comunes.

Para trabajo en testnet, se aplica el mismo patrón con chain ID 97, el token tBNB, el explorador en https://testnet.bscscan.com y el endpoint de testnet. Consulta la página RPC de BNB Chain Testnet para la URL de testnet actual.

Llamar al endpoint desde código

La verificación más rápida es una llamada JSON-RPC sin procesar. Esta pide el número de bloque actual:

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

Una respuesta con un result hexadecimal significa que el endpoint es accesible y está sirviendo. Si en su lugar obtienes un objeto de error, verifica el nombre del método y los parámetros antes de asumir que el endpoint está caído.

En una aplicación JavaScript, rara vez llamas a JSON-RPC a mano. Con viem:

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

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

const block = await client.getBlockNumber()
console.log('BNB Smart Chain head:', block)

El mismo endpoint funciona con ethers, web3.js y la mayoría de las herramientas EVM, porque BNB Smart Chain es compatible con EVM. Esa compatibilidad también es la razón por la que la cadena es atractiva: los contratos y bibliotecas de Ethereum existentes suelen portarse con cambios mínimos.

Leer logs, datos de archivo y suscripciones

Tres tipos de carga de trabajo se comportan de manera diferente en un endpoint público, y vale la pena entenderlos antes de comprometerte con uno.

eth_getLogs e indexación de eventos. Las consultas de logs son la solicitud común más pesada. Un rango de bloques amplio con muchos eventos coincidentes puede ser lento o rechazado en un endpoint compartido. Si estás indexando, reduce tus rangos, pagina y espera necesitar un nivel de proveedor o un nodo dedicado que tolere consultas de logs sostenidas.

Archivo y estado histórico. Leer el estado en un bloque antiguo requiere un nodo de archivo. No todos los endpoints conservan el historial completo. Si tu aplicación necesita saldos históricos o un relleno, confirma el soporte de archivo antes de construir sobre un endpoint. La página de BNB Smart Chain de OnFinality es el lugar para verificar las capacidades actuales.

Suscripciones WebSocket. Los endpoints HTTP públicos son de solicitud/respuesta. Si necesitas eth_subscribe para nuevas cabezas o transacciones pendientes, necesitas un transporte WebSocket. OnFinality admite HTTP y WebSocket para BNB Smart Chain, pero el volumen de suscripciones es exactamente el tipo de carga de trabajo que se beneficia de una configuración gestionada o dedicada en lugar de una URL pública compartida.

Modos de fallo y cómo interpretarlos

Cuando una solicitud falla, el error suele señalar la causa. Esta tabla asigna el síntoma a la solución probable.

La mayoría de estos son problemas de configuración o de forma de la carga de trabajo, no caídas del endpoint. Diagnostica la solicitud antes de culpar a la URL.

De URL pública a RPC de producción

La transición no se trata tanto de un momento único como de un patrón. Empiezas en un endpoint público, notas que las lecturas se cachean y las escrituras se reintentan, y con el tiempo quieres visibilidad y margen. En ese punto tienes dos opciones principales.

Una API RPC gestionada te da un endpoint con clave y tu propio uso, normalmente en muchas cadenas, y es el siguiente paso habitual para aplicaciones que necesitan fiabilidad sin ejecutar servidores. Un nodo dedicado te da capacidad aislada para cargas de trabajo sensibles a la contención, como trading de alta frecuencia, indexación pesada o necesidades estrictas de residencia de datos. Ambos están cubiertos en las ofertas de servicio API de OnFinality y nodo dedicado, y la lista completa de cadenas está en la página de redes RPC compatibles.

Una ruta de migración práctica:

1. Mantén el endpoint público para desarrollo local y CI.
2. Mueve las lecturas de staging y producción a un endpoint gestionado con clave.
3. Agrega un proveedor de respaldo o una segunda región para que un solo endpoint no sea un punto único de fallo.
4. Mueve la carga de trabajo más pesada, normalmente indexación o trading, a un nodo dedicado.
5. Agrega monitoreo de tasa de errores y latencia para notar la degradación antes que los usuarios.

Puntos clave

• La mainnet de BNB Smart Chain usa chain ID 56, token BNB, explorador https://bscscan.com.
• El endpoint público de OnFinality es https://bnb.api.onfinality.io/public, compatible con HTTP y WebSocket.
• Los endpoints públicos son ideales para prototipado, configuración de billeteras y lecturas ligeras, pero son capacidad compartida.
• eth_getLogs pesados, lecturas de archivo y suscripciones son las cargas de trabajo que empujan a los equipos hacia RPC gestionado o dedicado.
• La testnet usa chain ID 97 y tBNB; mantén las configuraciones de mainnet y testnet separadas.
• La mayoría de los fallos son de configuración o de forma de la carga de trabajo, no de caída del endpoint.

Preguntas frecuentes

¿La URL RPC pública de BNB Smart Chain es gratuita? Es un endpoint público compartido destinado a desarrollo y uso ligero. Para tráfico de producción, un plan gestionado o dedicado te da tu propia capacidad y visibilidad.

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

¿Puedo usar el endpoint público para suscripciones WebSocket? OnFinality admite HTTP y WebSocket para BNB Smart Chain, pero las cargas de trabajo de suscripción sostenidas se sirven mejor con una configuración gestionada o dedicada.

¿Por qué se agota el tiempo de espera de mi llamada eth_getLogs? El rango de bloques suele ser demasiado amplio para un endpoint compartido. Pagina el rango y reintenta, o mueve la indexación a un nivel de proveedor que maneje consultas de logs sostenidas.

¿Necesito un nodo de archivo? Solo si lees estado histórico en bloques antiguos. Confirma el soporte de archivo en la página de BNB Smart Chain antes de construir un relleno sobre un endpoint.

¿Cómo paso de RPC público a producción? Comienza con un endpoint gestionado con clave para staging y producción, agrega un respaldo y luego mueve tu carga de trabajo más pesada a un nodo dedicado. Consulta precios de RPC para los niveles.