Resumen
Los desarrolladores que buscan Alchemy BNB Smart Chain RPC normalmente quieren un endpoint de BSC funcional, la configuración correcta de la cadena y una forma de juzgar si un proveedor gestionado se ajusta a su carga de trabajo. Esta página te proporciona los parámetros de la mainnet y testnet de BNB Smart Chain, un ejemplo de solicitud y los criterios que separan un endpoint compartido de una infraestructura de nodo dedicada. También explica cuándo una API RPC gestionada como OnFinality es una mejor opción que ejecutar tu propio nodo de BSC, y qué verificar antes de migrar el tráfico de producción.
Si estás buscando un endpoint de Alchemy BNB Smart Chain RPC, lo más probable es que necesites dos cosas a la vez: los parámetros exactos de la red BSC para que tu billetera o aplicación se conecte, y una forma de decidir si una API RPC gestionada o un nodo dedicado es el hogar adecuado a largo plazo para tu tráfico. Esta página cubre ambos aspectos. Te proporciona la configuración de mainnet y testnet de BNB Smart Chain, un ejemplo de solicitud funcional y los criterios de evaluación que importan cuando pasas de una prueba rápida a producción.
BNB Smart Chain (BSC) es una cadena compatible con EVM, por lo que cualquier endpoint que hable JSON-RPC estándar sobre HTTP o WebSocket funcionará con las herramientas que ya usas: ethers, viem, web3.js, Hardhat, Foundry y la mayoría de los diálogos de red de billeteras. El nombre del proveedor importa menos que el comportamiento del endpoint bajo tu carga de trabajo real, que es lo que el resto de esta página te ayuda a evaluar.
Configuración de la cadena de un vistazo
Usa estos valores cuando agregues BNB Smart Chain a una billetera, una configuración de Hardhat o un cliente backend. El chain ID es el campo que con mayor frecuencia causa una conexión fallida, así que confírmalo primero.
| Configuración | BNB Smart Chain mainnet | BNB Chain testnet |
|---|---|---|
| Chain ID | 56 | 97 |
| Nombre de la cadena | BNB Smart Chain Mainnet | BNB Smart Chain Testnet |
| Moneda nativa | BNB (18 decimales) | tBNB (18 decimales) |
| Explorador de bloques | https://bscscan.com | https://testnet.bscscan.com |
| Transportes | HTTP, WebSocket | HTTP |
| Endpoint público de OnFinality | https://bnb.api.onfinality.io/public | https://bnb-testnet.api.onfinality.io/public |
OnFinality expone un endpoint público para ambas redes, y puedes revisar los detalles completos de la red en la página de BNB Smart Chain RPC y la página de BNB Chain Testnet RPC. Los endpoints públicos son útiles para prototipos y lecturas de bajo volumen. Para tráfico sostenido, consultas de archivo o suscripciones WebSocket, un plan gestionado o un nodo dedicado suele ser la mejor opción.
Cuándo un endpoint compartido es suficiente y cuándo no
Antes de comprometerte con un proveedor, haz coincidir el tipo de endpoint con la carga de trabajo. El mismo endpoint de BSC que es perfecto para una demo de hackathon puede convertirse en un cuello de botella para un indexador que escanea años de registros.
- Prototipos y pruebas de billetera: un endpoint público o compartido es suficiente. Necesitas configuración rápida y ajustes de cadena correctos, no garantías de capacidad.
- Lecturas y escrituras de dApp en producción: una API RPC gestionada con un presupuesto de solicitudes definido y failover es el valor predeterminado práctico. Obtienes acceso predecible sin operar un nodo.
eth_getLogsintensivo, lecturas de archivo o llamadas de trace: estas son las cargas de trabajo que estresan la infraestructura compartida. Planifica soporte de archivo y límites más altos, o pasa a un nodo dedicado.- Trading o bots sensibles a la latencia: los endpoints compartidos introducen latencia variable. Un nodo dedicado te da recursos aislados y una conexión estable.
Si no estás seguro de en qué categoría encajas, comienza con un endpoint gestionado e instrumentalo. Mide las tasas de error y la latencia bajo carga real antes de decidir si actualizar. La guía de selección de proveedor analiza esa decisión con más profundidad.
Conexión a BNB Smart Chain
Una forma rápida de confirmar tu endpoint y chain ID es una única llamada JSON-RPC. El ejemplo a continuación utiliza el endpoint público de BSC de OnFinality.
curl -X POST https://bnb.api.onfinality.io/public \
-H "Content-Type: application/json" \
--data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
Una respuesta correcta devuelve el chain ID en hexadecimal:
{"jsonrpc":"2.0","id":1,"result":"0x38"}
0x38 es 56 en decimal, lo que confirma que estás en la mainnet de BNB Smart Chain. Si obtienes un valor diferente, estás apuntando a la red incorrecta.
En JavaScript, la misma verificación con 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 chainId = await client.getChainId()
const block = await client.getBlockNumber()
console.log({ chainId, block })
Para billeteras, agrega una red personalizada con chain ID 56, símbolo BNB y la URL RPC anterior. Para trabajo en testnet, usa chain ID 97, símbolo tBNB y el endpoint de testnet. Los BNB de testnet están disponibles en faucets públicos; el endpoint de testnet no proporciona fondos.
Qué comparar entre proveedores de RPC de BSC
La elección del proveedor es un equilibrio entre control, costo y esfuerzo operativo. La siguiente tabla enmarca la comparación por carga de trabajo en lugar de por afirmaciones de marketing. OnFinality aparece primero porque es la opción que este sitio documenta en detalle, pero las columnas se aplican a cualquier proveedor que evalúes.
| Proveedor / opción | Mejor para | Archivo y trace | WebSocket | Esfuerzo operativo |
|---|---|---|---|---|
| API RPC de OnFinality | dApps en producción, indexadores, equipos que quieren acceso gestionado | Disponible en planes compatibles — confirma en la página de la red | Compatible | Bajo: endpoints gestionados y failover |
| Nodo dedicado de OnFinality | Cargas de trabajo de alto rendimiento, sensibles a la latencia o aisladas | Configurable | Compatible | De bajo a medio: nodo gestionado, tú controlas la capacidad |
| Nodo BSC autoalojado | Equipos con estrictas necesidades de control de datos o personalizadas | Control total | Control total | Alto: hardware, sincronización, actualizaciones, monitoreo |
| Otros proveedores gestionados | Varía según el plan y la región | Varía | Varía | Bajo, pero verifica límites y soporte de archivo |
Dos preguntas separan a los proveedores serios de los superficiales. Primero, ¿el proveedor admite los métodos que realmente llamas — eth_getLogs con rangos de bloques amplios, debug_traceTransaction o estado de archivo en bloques históricos? Segundo, ¿qué sucede cuando un nodo falla: hay failover automático o tu aplicación ve errores hasta que intervienes? Haz ambas preguntas antes de migrar.
Puntos de control de migración
Si te estás moviendo de otro endpoint de BSC a un nuevo proveedor, trátalo como un cambio controlado en lugar de un simple cambio de URL.
- Inventario de tus métodos. Enumera cada método JSON-RPC que llama tu aplicación, incluidos los métodos de depuración o trace. Confirma que cada uno sea compatible con el plan de destino.
- Verifica las necesidades de archivo. Si consultas estado histórico o rangos amplios de registros, confirma la disponibilidad de archivo antes del cambio.
- Prueba en staging. Apunta un entorno de staging al nuevo endpoint y ejecuta tus pruebas de integración, incluidos los caminos de error.
- Agrega failover. Configura un endpoint secundario para que una caída de un solo proveedor no derribe tu aplicación.
- Monitorea después del cambio. Rastrea la tasa de error, los percentiles de latencia y las respuestas de límite de velocidad durante al menos un ciclo completo de tráfico.
Mantén el endpoint antiguo configurado hasta que el nuevo haya demostrado ser estable bajo tu carga real. La reversión debe ser un cambio de configuración, no un redespliegue.
Modos de fallo comunes y cómo depurarlos
La mayoría de los problemas de RPC de BSC caen en un pequeño conjunto de categorías. La siguiente tabla asigna síntomas a causas probables.
| Síntoma | Causa probable | Primera verificación |
|---|---|---|
eth_chainId devuelve el valor incorrecto | El endpoint apunta a una red diferente | Confirma la URL y el chain ID |
| Las solicitudes fallan bajo carga | Límites de velocidad en un endpoint compartido | Revisa el presupuesto de solicitudes de tu plan |
eth_getLogs agota el tiempo o da error | Rango de bloques demasiado amplio, o sin soporte de archivo | Reduce el rango; confirma el acceso al archivo |
| WebSocket se desconecta | Tiempo de espera inactivo o límites de conexión | Agrega lógica de reconexión con retroceso |
| Las llamadas de estado histórico fallan | Nodo no archivador | Cambia a un endpoint con capacidad de archivo |
| Resultados inconsistentes entre llamadas | Nodos balanceados en diferentes alturas | Fija a un solo nodo o acepta consistencia eventual |
Una sonda de monitoreo simple te ayuda a detectar estos problemas temprano. Consulta eth_blockNumber de forma programada y alerta si deja de avanzar o si las tasas de error se disparan.
# Sonda de salud mínima: confirma que el nodo está avanzando
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}'
Ejecuta esto desde la misma región que tu aplicación para que la latencia que midas refleje lo que experimentan tus usuarios.
Construir versus comprar para BSC
Ejecutar tu propio nodo de BNB Smart Chain te da control total, pero también significa aprovisionar hardware que pueda seguir el rendimiento de BSC, gestionar el crecimiento del disco, aplicar actualizaciones del cliente y manejar eventos de sincronización y reorganización. Para muchos equipos, esa carga operativa no es el producto que quieren construir.
Una API RPC gestionada elimina la mayor parte de esa carga: obtienes un endpoint y el proveedor se encarga de las operaciones del nodo, las actualizaciones y la disponibilidad. Un nodo dedicado se sitúa en el medio: obtienes recursos aislados y rendimiento predecible sin gestionar la infraestructura subyacente tú mismo. OnFinality ofrece ambos, y puedes comparar planes en la página de precios de RPC o leer sobre nodos dedicados.
Si tu carga de trabajo es irregular o está en etapa temprana, comienza con gestionado y escala. Si tienes un alto rendimiento constante o requisitos estrictos de aislamiento, un nodo dedicado suele ser la opción más económica y predecible.
Puntos clave
- La mainnet de BNB Smart Chain usa chain ID 56; la testnet usa chain ID 97. Confirma el chain ID primero cuando fallen las conexiones.
- Los endpoints públicos son suficientes para prototipos; el tráfico de producción se beneficia de una API RPC gestionada con failover.
- El soporte de archivo, los límites de
eth_getLogsy el comportamiento de WebSocket son los campos que con mayor frecuencia deciden si un proveedor encaja. - Trata la migración de proveedor como un cambio controlado: inventario de métodos, prueba en staging, agrega failover y monitorea después del cambio.
- OnFinality proporciona endpoints gestionados de BSC y nodos dedicados; revisa las redes RPC compatibles y los precios de RPC para ajustar un plan a tu carga de trabajo.
Preguntas frecuentes
¿El RPC de BNB Smart Chain de Alchemy es lo mismo que cualquier otro endpoint de BSC? Cualquier endpoint que hable JSON-RPC estándar para el chain ID 56 funcionará con herramientas EVM. Las diferencias entre proveedores se manifiestan en el soporte de métodos, el acceso a archivo, los límites de velocidad y el comportamiento de failover, no en el formato básico de solicitud.
¿Qué chain ID uso para BNB Smart Chain?
La mainnet es 56 (0x38). La testnet es 97 (0x61). Usar el chain ID incorrecto es la causa más común de una conexión fallida de billetera.
¿Necesito un nodo de archivo para BSC? Solo si consultas estado histórico o rangos amplios de registros. Las lecturas y escrituras estándar de bloques recientes funcionan en un nodo completo regular. Confirma la disponibilidad de archivo antes de depender de ella.
¿Puedo usar WebSockets en BNB Smart Chain? Sí. BSC admite suscripciones WebSocket para eventos y nuevos bloques. Si las usas en producción, agrega lógica de reconexión con retroceso, ya que las conexiones inactivas pueden ser eliminadas.
¿Cómo muevo mi aplicación de un proveedor de RPC de BSC a otro? Cambia la URL del endpoint en tu configuración, mantén un endpoint secundario para failover y ejecuta tus pruebas de integración en staging primero. No se requieren cambios de contrato o billetera porque el chain ID sigue siendo el mismo.
¿Dónde puedo ver qué redes admite OnFinality? La página de redes RPC compatibles enumera las redes actuales, y la página de BNB Smart Chain RPC tiene los detalles específicos del endpoint y la cadena.