BSC Testnet: configuración de la cadena, faucet y configuración del endpoint RPC

Configuración de la cadena BSC Testnet de un vistazo

Estos son los valores que necesitas para agregar BSC Testnet a una billetera o apuntar un cliente a ella. El ID de cadena 97 es el campo que realmente distingue esta red de la mainnet de BNB Smart Chain (ID de cadena 56), así que verifícalo en cada archivo de configuración y pantalla de billetera.

Si una herramienta solicita un nombre de red, "BNB Smart Chain Testnet" y "BSC Testnet" son aceptados en la práctica; el nombre es cosmético, el ID de cadena no.

Agrega BSC Testnet a MetaMask sin romper mainnet

El error más común en billeteras es editar la entrada existente de la mainnet de BNB Smart Chain en lugar de agregar una nueva red. Agrega BSC Testnet como una red separada para que mainnet permanezca intacta y tu billetera muestre claramente en qué cadena estás.

En MetaMask, abre el selector de red, elige Agregar red, luego Agregar una red manualmente, y completa la configuración de la cadena de la tabla anterior. Guarda, cambia a la nueva red y confirma que el ID de cadena muestre 97 en los detalles de la red. Si usas otra billetera, los nombres de los campos varían pero los valores son los mismos.

• No sobrescribas la entrada de mainnet de BNB Smart Chain — agrega una nueva red en su lugar.
• Después de guardar, cambia de red y vuelve a verificar el ID de cadena; algunas billeteras almacenan en caché la cadena anterior.
• Si la billetera muestra un saldo de 0 tBNB, eso es esperado hasta que reclames del faucet.
• Mantén una cuenta separada para trabajo en testnet para que las transacciones de prueba nunca se mezclen con el historial de mainnet.

Obtén tBNB del faucet

El gas de BSC Testnet se paga en tBNB, que obtienes del faucet oficial de testnet de BNB Chain. El faucet tiene límite de frecuencia y puede requerir un pequeño saldo de BNB en mainnet o una conexión de billetera para disuadir el abuso, así que planifica las solicitudes al faucet antes de una ejecución de CI en lugar de durante ella.

tBNB no tiene valor real. No lo compres, no puentees activos reales a testnet esperando recuperarlos, y no trates los saldos de testnet como datos de producción. Si necesitas cantidades mayores para pruebas de carga, solicítalas a través de los canales documentados del faucet en lugar de programar solicitudes repetidas.

• Reclama tBNB a la misma dirección que usan tus scripts de implementación.
• Financia primero la cuenta del implementador; las llamadas a contratos fallan sin gas.
• Los límites del faucet se restablecen según un horario — consulta la página del faucet para las reglas actuales.
• Mantén un pequeño colchón de tBNB para gas de transacciones fallidas y reintentos de nonce.

Apunta Hardhat, Foundry, viem o ethers a un RPC de BSC Testnet

Una vez configurada la billetera, el siguiente paso es conectar tus herramientas a un endpoint JSON-RPC. El patrón es el mismo en todos los frameworks: almacena la URL RPC en una variable de entorno, establece el ID de cadena 97 explícitamente y mantén una configuración de mainnet separada para que un error de copiar y pegar falle ruidosamente en lugar de implementar silenciosamente en mainnet.

Los fragmentos a continuación usan marcadores de posición para la URL RPC. Reemplázalos con el endpoint de tu proveedor — para OnFinality, el endpoint actual de BSC Testnet se encuentra en la página de la red BNB Testnet.

• Hardhat: agrega una entrada de red bscTestnet con url y chainId: 97.
• Foundry: establece [rpc_endpoints] bsc_testnet = "${BSC_TESTNET_RPC_URL}" en foundry.toml.
• viem: crea un objeto de cadena con id: 97 y pasa la URL de transporte.
• ethers: usa new JsonRpcProvider(url, 97) para que el ID de cadena se verifique al conectar.

Ruta de depuración: cuando falla una solicitud a BSC Testnet

Los fallos en testnet generalmente se deben a un pequeño conjunto de causas. Revísalas en orden — la mayoría se resuelven en el primer o segundo paso, y el orden te evita perseguir problemas de endpoint cuando el problema real es una billetera vacía.

Comienza confirmando el ID de cadena que reporta el endpoint, luego confirma que el remitente tiene tBNB, y después revisa la transacción en sí. Si todo en la cadena parece correcto pero las llamadas siguen fallando, el endpoint es el siguiente sospechoso.

Cuando un endpoint público no es suficiente

Los endpoints públicos de BSC Testnet son suficientes para un solo desarrollador navegando por una dApp. Se convierten en un problema cuando varios trabajos de CI, un frontend de staging y un indexador comparten la misma URL limitada. Los síntomas parecen pruebas inestables y tiempos de espera intermitentes en lugar de un error claro, lo que los hace costosos de depurar.

Un endpoint RPC gestionado te brinda una URL con límites predecibles y una vía de soporte cuando algo falla. Un nodo dedicado va más allá: capacidad aislada para consultas de archivo, depuración intensiva en registros y suscripciones WebSocket que un endpoint compartido puede no soportar de manera confiable. OnFinality ofrece ambos — comienza en la página de la red BNB Testnet para detalles del endpoint, y consulta redes RPC compatibles para la lista completa.

• Desarrollador único, implementaciones ocasionales: un endpoint público suele ser suficiente.
• CI de equipo con trabajos paralelos: un endpoint gestionado evita la limitación compartida.
• Lecturas de archivo, llamadas de traza o eth_getLogs intensivo: verifica el soporte de métodos antes de comprometerte.
• Suscripciones WebSocket de larga duración: confirma el soporte de transporte en el plan elegido.

Lista de verificación de preparación de testnet a mainnet

BSC Testnet refleja de cerca mainnet, pero una ejecución exitosa en testnet no es prueba de estar listo para mainnet. Antes de promover un contrato o servicio, verifica los elementos a continuación — cada uno detecta una clase de error que testnet por sí solo no revelará.

El objetivo no es volver a probar todo, sino confirmar que las diferencias entre el ID de cadena 97 y el ID de cadena 56 se manejan explícitamente en tu configuración, tus suposiciones de gas y tu monitoreo.

• El ID de cadena se lee desde la configuración, no está codificado en un solo lugar fácil de pasar por alto.
• Las estimaciones de gas y las tarifas prioritarias se vuelven a medir en mainnet; las condiciones de testnet difieren.
• Las direcciones de contrato son específicas del entorno y no se comparten entre testnet y mainnet.
• Los enlaces del explorador y los paneles de monitoreo apuntan a la red correcta.
• Los scripts que dependen del faucet se eliminan o se condicionan antes de la implementación en producción.
• El endpoint RPC y el plan están dimensionados para el tráfico esperado en mainnet, no para el tráfico de testnet.

Preguntas frecuentes