Logo
RPC Assistant

¿Cómo encuentro y configuro un endpoint de BNB Smart Chain?

Resumen

BNB Smart Chain (BSC) expone endpoints JSON-RPC para leer datos de la cadena de bloques y enviar transacciones. El endpoint de mainnet es https://bsc-dataseed.bnbchain.org con ID de cadena 56, y el endpoint de testnet usa el ID de cadena 97. Los endpoints públicos son adecuados para prototipos, pero tienen límites de tasa y restricciones de funciones.

Esta guía cubre la configuración de la cadena, cómo verificar un endpoint con eth_chainId y qué comprobar al elegir un endpoint público o gestionado para producción. También explica cuándo vale la pena invertir en un nodo dedicado de BNB Smart Chain.

Lista de verificación para decidir el endpoint de BNB Smart Chain

Un endpoint de BNB Smart Chain es la URL HTTP o WebSocket que tu aplicación usa para enviar solicitudes JSON-RPC a los nodos de BSC. Antes de elegir uno, revisa esta lista:

  • ¿Mainnet o testnet? Mainnet usa el ID de cadena 56; testnet (Chapel) usa 97. Cambiar de endpoint sin cambiar el ID de cadena es una causa común de fallos en las transacciones.
  • ¿Endpoint público o gestionado? Los endpoints públicos como https://bsc-dataseed.bnbchain.org son adecuados para pruebas rápidas y prototipos locales. Las aplicaciones de producción suelen necesitar RPC gestionado con límites de tasa más altos y mejores diagnósticos.
  • ¿Tu carga de trabajo necesita logs o archivos? Los endpoints públicos a menudo deshabilitan o restringen eth_getLogs y pueden no ofrecer datos de archivo. Si construyes análisis, indexadores o exploradores de bloques, necesitas un endpoint que soporte esos métodos y datos históricos.
  • ¿Necesitas actualizaciones en tiempo real? Usa un endpoint WebSocket para eth_subscribe y así transmitir nuevos bloques y transacciones pendientes en lugar de hacer polling.
  • Prueba antes de comprometerte. Ejecuta eth_chainId y eth_blockNumber contra cualquier endpoint que planees usar. Confirma que la respuesta coincida con la red que esperas.
  • Verifica el límite de tasa. Los endpoints públicos oficiales tienen límites de uso justo publicados. Para picos de tráfico, un nodo dedicado o un plan RPC de pago serán más predecibles.
  • Planifica para fallos. Si un endpoint deja de responder, ¿tienes un respaldo? Considera usar múltiples proveedores o una configuración de conmutación por error.
  • Revisa el costo y el soporte. Compara los precios de RPC para niveles de pago, acceso a archivos y soporte WebSocket antes de escalar.

Configuración de cadena para BNB Smart Chain

Si estás configurando una billetera, SDK o middleware, usa estos valores:

RedID de cadenaMonedaURL RPC
BNB Smart Chain Mainnet56 (0x38)BNBhttps://bsc-dataseed.bnbchain.org
BNB Smart Chain Testnet (Chapel)97 (0x61)tBNBhttps://data-seed-prebsc-1-s1.bnbchain.org:8545

Otros endpoints públicos se enumeran en la documentación oficial de BNB Chain. La lista de endpoints cambia con el tiempo a medida que se agregan o retiran nodos, así que verifica las URLs antes de confiar en ellas en producción.

Explorador de bloques: https://bscscan.com

También hay endpoints WebSocket disponibles de algunos proveedores. Por ejemplo, wss://bsc-rpc.publicnode.com es una puerta de enlace mantenida por la comunidad. Más adelante en este artículo, cubrimos las ventajas y desventajas entre estas opciones y las ofertas gestionadas de OnFinality y otros proveedores.

Cómo agregar el endpoint de BNB Smart Chain a una billetera

La mayoría de las billeteras EVM te permiten agregar una red personalizada. El proceso es similar en MetaMask, Rabby y otras:

  1. Abre el menú de Configuración o Redes de la billetera.
  2. Elige Agregar red o Agregar red personalizada.
  3. Ingresa los siguientes valores:
    • Nombre de la red: BNB Smart Chain
    • URL RPC: https://bsc-dataseed.bnbchain.org
    • ID de cadena: 56
    • Símbolo de moneda: BNB
    • URL del explorador de bloques: https://bscscan.com
  4. Guarda y cambia a la red.

Cuando agregues un endpoint manualmente, verifica dos veces el ID de cadena. Muchas transacciones fallidas de BSC son causadas por configurar el ID de cadena 1 (mainnet de Ethereum) o 5 (Goerli) en lugar de 56. Si usas una URL RPC personalizada de un proveedor, el ID de cadena debe seguir siendo 56 incluso si la URL pertenece a un tercero.

Para testnet, usa el ID de cadena 97, el símbolo tBNB y el explorador de testnet en https://testnet.bscscan.com. Puedes solicitar BNB de prueba desde el faucet oficial si necesitas fondos para desarrollo.

Verificación del endpoint con JSON-RPC

Una vez que tengas una URL, verifica que funcione con una simple llamada curl:

curl -X POST https://bsc-dataseed.bnbchain.org \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'

Una respuesta exitosa devuelve 0x38, que es el ID de cadena decimal 56 en hexadecimal:

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

También puedes confirmar el último bloque:

curl -X POST https://bsc-dataseed.bnbchain.org \
  -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'

En una aplicación JavaScript, usa ethers.js o viem para conectarte:

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://bsc-dataseed.bnbchain.org");

provider.getNetwork().then((network) => {
  console.log("Chain ID:", Number(network.chainId)); // 56
});

Si el ID de cadena no es 56, probablemente estás apuntando al endpoint incorrecto. Si la solicitud agota el tiempo de espera, verifica tu conexión de red, las reglas del firewall y la disponibilidad del endpoint.

Endpoints públicos vs servicios RPC gestionados

Los endpoints oficiales de BNB Smart Chain son infraestructura compartida operada por el equipo de BNB Chain y participantes de la comunidad. Son gratuitos y fáciles de usar, pero tienen limitaciones:

  • Límites de tasa: Los endpoints públicos son compartidos por todos los desarrolladores y dApps. La documentación oficial indica un límite de tasa de 10,000 solicitudes por 5 minutos por endpoint, que es aproximadamente 33 solicitudes por segundo. Puede parecer mucho hasta que tu dApp comience a transmitir transacciones y sincronizar datos históricos.
  • Límites de funciones: Algunos endpoints públicos de mainnet deshabilitan eth_getLogs para proteger el rendimiento del nodo. Si dependes de consultas de logs, necesitarás un endpoint que las soporte.
  • Disponibilidad: Los endpoints públicos pueden no estar disponibles durante períodos de congestión o cuando las actualizaciones de red cambian la lista de servidores. No hay una garantía de nivel de servicio en la que puedas confiar.

Los servicios RPC gestionados ejecutan sus propios clústeres de nodos BSC y exponen endpoints con capacidad dedicada. Proveedores como OnFinality ofrecen tanto acceso RPC API compartido como nodos dedicados para BNB Smart Chain. Las principales ventajas son:

  • Soporte WebSocket más sólido para suscripciones en tiempo real.
  • Acceso a datos de archivo y métodos que mejoran los flujos de indexación y análisis.
  • Precios claros y contabilidad de solicitudes para que puedas planificar el crecimiento.
  • Mejor aislamiento: tu tráfico no compite con todos los demás desarrolladores en el mismo endpoint público.

Para un pequeño script de prueba, los endpoints públicos son suficientes. Para una dApp de producción, un endpoint gestionado suele valer el costo.

Evaluación de endpoints para producción: qué verificar

Si estás decidiendo entre endpoints públicos y gestionados, o entre múltiples proveedores, usa esta tabla para estructurar tu evaluación.

CriterioQué verificarPor qué importa
Límites de tasa¿Cuál es el límite documentado de solicitudes por segundo o por mes?Un límite que parece generoso el primer día puede limitar tu aplicación durante un pico de usuarios.
Integridad de datos¿El endpoint sirve estado de archivo, eth_getLogs y métodos de rastreo?Los análisis, indexadores y herramientas de soporte dependen de estos métodos.
Soporte WebSocket¿Puedes suscribirte a newHeads y logs a través de wss://?Las dApps en tiempo real no deberían hacer polling; necesitan notificaciones push.
Latencia regional¿Dónde está alojado el nodo? ¿Hay equilibrio de carga entre regiones?La alta latencia hace que cada lectura y confirmación de transacción sea más lenta.
Conmutación por error¿El proveedor ofrece múltiples URLs o lógica de reintento automático?Un solo endpoint es un punto único de falla.
Modelo de precios¿Cómo se facturan las solicitudes? ¿Hay niveles gratuitos y costos por exceso?Sorpresas inesperadas en la facturación pueden romper el presupuesto de una aplicación.
Soporte y operaciones¿Hay una página de estado, SLA o canal de soporte directo?Necesitas reaccionar rápidamente cuando el endpoint se cae.

El endpoint "correcto" es el que coincide con tu carga de trabajo. Un frontend DeFi, un indexador de datos y un bot de trading tienen diferentes requisitos de latencia, historial y transmisión.

Depuración de fallos comunes en endpoints de BNB Smart Chain

Incluso con un endpoint correcto, los desarrolladores encuentran problemas. Aquí están los más comunes y cómo solucionarlos.

  • ID de cadena incorrecto. Tu URL RPC apunta a BSC, pero la billetera o SDK está configurado para otra cadena. Siempre establece chainId en 56 en el código de tu aplicación y en la configuración de la billetera. Para testnet, usa 97.
  • eth_chainId devuelve 0x1 u otro valor inesperado. Puede que estés golpeando un endpoint de Ethereum o un proxy que reescribe las solicitudes. Cambia a un endpoint BSC conocido y vuelve a ejecutar la verificación.
  • Errores 429 o "límite excedido". Has alcanzado el límite de tasa de un endpoint público. Agrega retroceso y caché, o muévete a un endpoint gestionado con límites más altos.
  • eth_getLogs no es compatible. Usa una conexión WebSocket para suscribirte a logs, o elige un proveedor gestionado que soporte el método.
  • Bloque no encontrado después de enviar una transacción. BSC tiene tiempos de bloque de 3 segundos, pero tu nodo puede necesitar unos segundos para sincronizar el último bloque. Vuelve a consultar y considera esperar algunos bloques de confirmación antes de mostrar éxito al usuario.
  • La conexión WebSocket se cae. Algunos endpoints WebSocket de la comunidad son menos confiables que HTTP. Para transmisión en producción, usa un proveedor con infraestructura WebSocket dedicada.

Cuándo usar un nodo dedicado de BNB Smart Chain

Un nodo dedicado es un nodo de BNB Smart Chain de un solo inquilino aprovisionado para tu proyecto. Te brinda:

  • Rendimiento aislado. Tus solicitudes no compiten con un grupo compartido de tráfico.
  • Configuración RPC flexible. Puedes habilitar o deshabilitar módulos específicos, configurar el almacenamiento de bloques en modo archivo y ajustar la configuración de sincronización.
  • Mayor volumen de solicitudes. Puedes ajustar maxpeers y otros parámetros del nodo para que coincidan con tu carga de trabajo.
  • Privacidad. Las solicitudes no son registradas por un servicio público compartido.

Los nodos dedicados son útiles cuando:

  • Tu dApp tiene una gran audiencia o patrones de lectura/escritura de alta frecuencia.
  • Ejecutas pipelines de análisis que necesitan datos de archivo y consultas de logs repetidas.
  • Quieres un endpoint privado para tu backend sin exponer tu patrón de uso.

En OnFinality, puedes lanzar un nodo dedicado de BNB Smart Chain en mainnet o testnet, y también puedes usar el servicio de API RPC si prefieres un endpoint compartido pero escalable. Para una descripción general de todas las redes compatibles, consulta redes RPC compatibles.

Conclusiones clave

  • El endpoint de mainnet para BNB Smart Chain es https://bsc-dataseed.bnbchain.org con ID de cadena 56.
  • El endpoint de testnet usa el ID de cadena 97 y el token tBNB.
  • Los endpoints públicos son adecuados para desarrollo pero tienen límites de tasa y pueden deshabilitar eth_getLogs.
  • Siempre verifica un endpoint con eth_chainId antes de conectarlo a una aplicación.
  • Las aplicaciones de producción deben evaluar límites de tasa, datos de archivo, soporte WebSocket, latencia y conmutación por error.
  • Una API RPC gestionada o un nodo dedicado es una opción más predecible cuando tu dApp crece más allá de la etapa de prototipo.

Preguntas frecuentes

¿Cuál es el endpoint RPC oficial de BNB Smart Chain?

El endpoint oficial de mainnet es https://bsc-dataseed.bnbchain.org. El equipo de BNB Chain también ejecuta URLs adicionales de semillas de datos como bsc-dataseed1.bnbchain.org y bsc-dataseed2.bnbchain.org. Para la lista oficial actual, consulta la documentación de BNB Chain.

¿Cuál es el endpoint de testnet de BNB Smart Chain?

La testnet de BNB Smart Chain (Chapel) usa el ID de cadena 97 y se puede acceder a través de URLs como https://data-seed-prebsc-1-s1.bnbchain.org:8545. Los faucets de testnet están disponibles a través de las herramientas oficiales para desarrolladores de BNB Chain.

¿Por qué eth_getLogs está deshabilitado en algunos endpoints públicos de BSC?

Las consultas de logs son costosas para los operadores de nodos porque fuerzan un escaneo extenso. Los endpoints públicos deshabilitan o limitan severamente eth_getLogs para mantener estable la infraestructura compartida. Los proveedores gestionados pueden soportarlo con indexación y caché adecuadas.

¿Qué ID de cadena debo usar para BNB Smart Chain?

Usa 56 para mainnet y 97 para testnet. En código que toma un valor hexadecimal, 56 es 0x38 y 97 es 0x61.

¿Puedo usar WebSockets con un endpoint de BNB Smart Chain?

Sí. Varios proveedores exponen endpoints wss:// para suscripciones en tiempo real. OnFinality y otros servicios RPC gestionados soportan conexiones WebSocket en sus endpoints de BNB Smart Chain, lo cual es útil para transmitir nuevos bloques y logs de transacciones.

Base de conocimiento RPC

Detalles RPC relacionados

Nunca te preocupes por la infraestructura nuevamente

OnFinality elimina la carga pesada de DevOps para que puedas construir de forma más inteligente y rápida.

Comenzar