Resumen
BNB Smart Chain Testnet (chain ID 97) es donde validas contratos, billeteras e indexadores antes de tocar mainnet. Esta página te proporciona la configuración exacta de la red, un endpoint público funcional, orientación sobre el faucet y los modos de fallo que más tiempo hacen perder a los desarrolladores. También encontrarás una breve lista de verificación para decidir cuándo un endpoint público compartido es suficiente y cuándo un nodo dedicado es la mejor opción.
BNB Smart Chain Testnet es el entorno de ensayo para cualquier cosa que planees lanzar en BNB Chain. Ejecuta las mismas herramientas EVM que mainnet, pero con chain ID 97, un estado separado y tBNB en lugar de BNB. Si estás aquí, probablemente necesites una de tres cosas: una URL RPC funcional, la configuración exacta de la red en la billetera o una forma de depurar por qué una solicitud que funciona en mainnet falla en testnet.
Esta página responde directamente a esas preguntas y luego cubre las cuestiones operativas que surgen una vez que tu implementación en testnet empieza a parecerse a una carga de trabajo real.
Configuración de la cadena de un vistazo
Copia estos valores en tu billetera, configuración de Hardhat, configuración de Foundry o entorno de backend. Coinciden con la definición de red de BNB Chain Testnet utilizada por OnFinality.
| Configuración | Valor |
|---|---|
| Nombre de la red | BNB Smart Chain Testnet |
| Chain ID | 97 |
| Moneda nativa | tBNB (18 decimales) |
| Explorador de bloques | https://testnet.bscscan.com |
| RPC público (HTTP) | https://bnb-testnet.api.onfinality.io/public |
Una verificación rápida antes de conectar cualquier cosa:
curl -s https://bnb-testnet.api.onfinality.io/public \
-H 'content-type: application/json' \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
Deberías recibir "0x61", que es 97 en hexadecimal. Si obtienes un chain ID diferente, estás apuntando a la red incorrecta, una causa muy común de la confusión "mi contrato se implementó pero no puedo encontrarlo".
¿Es suficiente el endpoint público de testnet para tu carga de trabajo?
La mayoría de los desarrolladores pueden comenzar en un endpoint público compartido y permanecer allí más tiempo de lo que esperan. El tráfico de testnet suele ser irregular: una implementación aquí, una ejecución de script allá, un trabajo de CI durante la noche. La decisión no se trata tanto del rendimiento bruto sino de qué sucede cuando algo sale mal.
Usa esto como un filtro rápido:
| Tu situación | Punto de partida razonable |
|---|---|
| Pruebas manuales, configuración de billetera, scripts pequeños | Endpoint público compartido |
| Canalizaciones de CI que implementan y verifican contratos en cada push | Endpoint compartido, con una URL de respaldo configurada |
| Indexadores, herramientas con muchos logs o bots de larga duración | Nodo dedicado o un plan de RPC de pago |
| Necesitas un comportamiento predecible bajo solicitudes paralelas | Nodo dedicado |
| Estás depurando un problema específico del proveedor | Prueba un segundo endpoint para aislar la causa |
Si no estás seguro, comienza con el público y mide. En el momento en que te encuentres reintentando solicitudes fallidas o preguntándote si un timeout fue culpa de tu código o del endpoint, esa es la señal para consultar Precios de RPC y comparar opciones compartidas versus dedicadas.
Agregar BNB Smart Chain Testnet a una billetera
En MetaMask, abre el selector de red, elige Agregar red → Agregar una red manualmente e ingresa los valores de la tabla anterior. Los dos campos que la gente suele equivocar son el chain ID (debe ser 97, no 56) y el símbolo de la moneda (tBNB).
Si prefieres agregarla programáticamente, esta es la llamada estándar wallet_addEthereumChain:
await window.ethereum.request({
method: 'wallet_addEthereumChain',
params: [{
chainId: '0x61', // 97
chainName: 'BNB Smart Chain Testnet',
nativeCurrency: { name: 'tBNB', symbol: 'tBNB', decimals: 18 },
rpcUrls: ['https://bnb-testnet.api.onfinality.io/public'],
blockExplorerUrls: ['https://testnet.bscscan.com'],
}],
});
Ten en cuenta que chainId está en hexadecimal aquí, mientras que la mayoría de los archivos de configuración usan decimal. Mezclar los dos es una fuente frecuente de configuración incorrecta silenciosa.
Obtener tBNB del faucet
El faucet es el primer obstáculo real para la mayoría de las personas. El BNB de testnet es gratuito, pero los faucets suelen restringirlo con un captcha, un saldo mínimo en mainnet o un límite diario por dirección.
Algunas notas prácticas:
- La disponibilidad del faucet cambia con el tiempo. Si uno está seco o limitado, prueba otro en lugar de asumir que testnet está caído.
- Financia la dirección desde la que realmente vas a implementar. Mover tBNB entre cuentas después cuesta gas que quizás aún no tengas.
- Mantén un pequeño colchón. La implementación de contratos más unas cuantas transacciones de verificación e interacción se acumulan más rápido que una sola transferencia.
- Si un faucet solicita un saldo en mainnet, eso es una medida antiabuso, no un error.
Una vez que tengas tBNB, confirma el saldo con eth_getBalance antes de empezar a depurar cualquier otra cosa. Elimina toda una categoría de falsas alarmas.
Conectar el endpoint a tus herramientas
Hardhat y Foundry leen una URL RPC simple, por lo que el mismo endpoint funciona en todo tu stack.
// hardhat.config.js
module.exports = {
networks: {
bscTestnet: {
url: 'https://bnb-testnet.api.onfinality.io/public',
chainId: 97,
accounts: [process.env.DEPLOYER_KEY],
},
},
};
Para viem o ethers, define la cadena una vez y reutilízala:
import { createPublicClient, http } from 'viem';
const bscTestnet = {
id: 97,
name: 'BNB Smart Chain Testnet',
nativeCurrency: { name: 'tBNB', symbol: 'tBNB', decimals: 18 },
rpcUrls: {
default: { http: ['https://bnb-testnet.api.onfinality.io/public'] },
},
};
const client = createPublicClient({
chain: bscTestnet,
transport: http(),
});
Mantén la URL en una variable de entorno en lugar de codificarla directamente. Cuando más adelante pases a un endpoint dedicado o agregues un respaldo, cambias un solo valor en lugar de buscar en todo el código.
Depurar los fallos que realmente encontrarás
Los problemas de testnet rara vez son exóticos. Se agrupan en torno a un puñado de causas, y la mayoría son de configuración, no de infraestructura.
| Síntoma | Causa probable | Lo primero que debes verificar |
|---|---|---|
eth_chainId devuelve 0x38 | Apunta a mainnet | Cambia la URL RPC al endpoint de testnet |
| Transacciones atascadas como pendientes | Precio de gas demasiado bajo para las condiciones actuales de testnet | Vuelve a estimar el gas; las tarifas base de testnet se mueven |
insufficient funds for gas | Sin tBNB o cuenta incorrecta | Verifica eth_getBalance en la dirección del implementador |
| Contrato no encontrado después de la implementación | Se implementó en mainnet o cadena incorrecta en el explorador | Confirma el chain ID y busca en testnet.bscscan.com |
| Timeouts intermitentes bajo carga | Endpoint compartido bajo tráfico irregular | Agrega una URL de respaldo o pasa a un nodo dedicado |
eth_getLogs no devuelve nada | Rango de bloques demasiado amplio o filtro de dirección/tema incorrecto | Reduce el rango y vuelve a verificar el filtro |
| Errores de nonce después de una transacción fallida | Caché de nonce local desincronizada | Restablece la cuenta en tu billetera o consulta eth_getTransactionCount con pending |
Dos hábitos previenen la mayoría de estos. Primero, registra el chain ID al que tu cliente realmente se conecta al inicio; detecta configuraciones incorrectas de inmediato. Segundo, cuando una solicitud falla, reintenta una vez contra un endpoint diferente antes de cambiar tu código. Ese único paso te dice si el problema es tu aplicación o la conexión.
Testnet versus mainnet: qué se mantiene
Testnet es similar a mainnet, pero no idéntico, y las diferencias importan para la planificación.
- El estado es desechable. Testnet puede reiniciarse o reorganizarse de formas que mainnet no puede. No trates los datos de testnet como duraderos.
- El comportamiento del gas difiere. Las tarifas suelen ser más bajas y más volátiles. Una estrategia de gas ajustada en testnet necesitará revisión antes de mainnet.
- La disponibilidad de archive y trace varía. Si tus herramientas dependen del estado histórico o métodos de trace, confirma el soporte en el endpoint que planeas usar en lugar de asumir paridad con mainnet.
- Los patrones de congestión difieren. Testnet es más tranquilo, por lo que un endpoint compartido puede funcionar bien allí y tener dificultades bajo la carga real de mainnet.
Ese último punto es el que pilla a los equipos. Una configuración de testnet que funciona perfectamente aún puede necesitar reelaboración cuando llega el tráfico de mainnet. Si estás planificando esa transición, la página de BNB Chain mainnet RPC cubre la configuración del lado de producción, y cómo elegir un proveedor de RPC detalla los criterios de evaluación.
Cuándo dejar el endpoint compartido
Los endpoints públicos compartidos son genuinamente útiles, y OnFinality opera uno para BNB Chain Testnet para que puedas comenzar sin una cuenta. Sin embargo, no son el hogar adecuado a largo plazo para todas las cargas de trabajo.
Considera un nodo dedicado cuando:
- Tu entorno de CI o staging genera tráfico constante y paralelo.
- Dependes de consultas de logs, métodos de trace o datos de archive que los endpoints compartidos pueden limitar.
- Necesitas un comportamiento consistente para una demo, una auditoría o una integración con socios.
- Quieres aislamiento de los patrones de tráfico de otros usuarios.
OnFinality proporciona tanto acceso a la API RPC como infraestructura de nodos dedicados, para que puedas comenzar en el endpoint compartido y pasar a un nodo dedicado sin cambiar el código de tu aplicación, solo la URL. Puedes revisar el conjunto completo de redes RPC compatibles para ver dónde encaja BNB Chain Testnet junto a las otras cadenas que ejecutas.
Puntos clave
- BNB Smart Chain Testnet usa el chain ID 97 y el token nativo tBNB.
- Un endpoint público funcional es
https://bnb-testnet.api.onfinality.io/public; verifícalo coneth_chainIdque devuelva0x61. - La mayoría de los fallos en testnet son problemas de configuración (chain ID incorrecto, falta de fondos del faucet o un nonce obsoleto), no caídas de infraestructura.
- Mantén tu URL RPC en una variable de entorno y configura un respaldo antes de necesitarlo.
- Los endpoints compartidos son adecuados para pruebas manuales y CI ligero; los nodos dedicados para cargas de trabajo sostenidas, paralelas o con muchos logs.
- El comportamiento de testnet no predice completamente el de mainnet, especialmente en lo que respecta al gas y la congestión.
Preguntas frecuentes
¿Cuál es el chain ID de BNB Smart Chain Testnet?
97, que es 0x61 en hexadecimal. Si tu cliente informa 56, estás conectado a BNB Chain mainnet.
¿Cuál es la URL RPC de BNB Smart Chain Testnet?
El endpoint público de OnFinality es https://bnb-testnet.api.onfinality.io/public. También puedes usar un endpoint dedicado si necesitas aislamiento o mayor rendimiento sostenido.
¿Cómo obtengo BNB de testnet?
Usa un faucet de BNB Chain testnet. La disponibilidad y los límites de tasa cambian, así que si un faucet no está disponible, prueba otro. Financia la dirección desde la que vas a implementar y mantén un pequeño colchón para gas.
¿Por qué mi transacción sigue fallando en testnet?
Verifica tres cosas en orden: el chain ID al que está conectado tu cliente, tu saldo de tBNB y tu nonce. Estos explican la gran mayoría de los fallos de transacciones en testnet.
¿Puedo usar el mismo código en mainnet y testnet?
Sí, si mantienes la URL RPC y el chain ID en la configuración en lugar de codificarlos directamente. Revisa las suposiciones de gas y cualquier dependencia de archive o trace antes de cambiar a mainnet.
¿OnFinality admite BNB Chain Testnet?
Sí. Consulta la página de red de BNB Chain Testnet para detalles del endpoint y Precios de RPC para opciones de planes.