Resumen
Arbitrum One es la cadena mainnet (chain ID 42161). La testnet a la que los desarrolladores suelen referirse cuando dicen "Arbitrum One testnet" es Arbitrum Sepolia (chain ID 421614), que utiliza Sepolia ETH para gas. Esta página explica la configuración de la cadena, cómo agregar la red a una billetera, cómo solicitar ETH de testnet y cómo depurar los errores que aparecen cuando un endpoint de testnet está mal configurado. También cubre cuándo un endpoint público compartido es suficiente y cuándo un nodo dedicado o una API RPC gestionada es la mejor opción para pipelines de CI, indexadores y entornos de staging.
Si buscaste un "Arbitrum One testnet RPC", lo primero que hay que aclarar es el nombre. Arbitrum One es la cadena mainnet (chain ID 42161). No existe una "Arbitrum One testnet" separada con ese nombre. La testnet a la que los desarrolladores casi siempre se refieren es Arbitrum Sepolia (chain ID 421614), que funciona con Sepolia ETH y replica el entorno de ejecución de Arbitrum Nitro lo suficientemente bien para pruebas de contratos, flujos de billetera y CI.
Esta página te proporciona el endpoint, la configuración exacta de la cadena, un fragmento de configuración de billetera, pasos para el faucet y una ruta de depuración para los errores que aparecen cuando un endpoint de testnet está mal configurado. También te ayuda a decidir si un endpoint público compartido es suficiente o si tu flujo de trabajo necesita una API RPC gestionada o un nodo dedicado.
¿Qué endpoint se adapta a tu flujo de trabajo?
Antes de copiar un endpoint, relaciónalo con lo que realmente estás haciendo. Los patrones de tráfico de testnet son muy diferentes a los de mainnet: ráfagas durante ejecuciones de CI, largos períodos de inactividad y escaneos ocasionales pesados de eth_getLogs desde indexadores.
| Tu flujo de trabajo | Lo que necesitas | Punto de partida sensato |
|---|---|---|
| Pruebas manuales en una billetera o Remix | Un endpoint HTTPS accesible, sin fricción de autenticación | Endpoint público compartido |
| Desarrollo local con Hardhat/Foundry | Endpoint estable, comportamiento de tasa predecible | Clave de API RPC gestionada |
| Pipeline de CI ejecutando pruebas de contratos | Margen de concurrencia, sin limitación compartida | API RPC gestionada o nodo dedicado |
| Indexador o escaneo de logs estilo subgraph | Rangos amplios de eth_getLogs, acceso a archivo | Nodo dedicado con datos de archivo |
| Entorno de staging que imita producción | Mismo proveedor y transporte que producción | Misma configuración gestionada/dedicada que mainnet |
Si solo estás verificando que un contrato se despliega, un endpoint público compartido está bien. Si tu suite de pruebas genera docenas de solicitudes paralelas, o escaneas logs en rangos de bloques grandes, planifica una configuración gestionada o dedicada desde el principio para no estar depurando límites de tasa en lugar de tu código.
Configuración de la cadena Arbitrum Sepolia de un vistazo
Estos son los valores que pegas en una billetera, una configuración de framework o un archivo .env. Mantenlos consistentes en tu equipo para evitar confusión de "red incorrecta".
| Configuración | Valor |
|---|---|
| Nombre de la red | Arbitrum Sepolia |
| Chain ID | 421614 |
| Símbolo de moneda | ETH (Sepolia ETH) |
| Explorador de bloques | https://sepolia.arbiscan.io |
| RPC (HTTPS) | https://arbitrum-sepolia.api.onfinality.io/public |
| Transporte | HTTP (WebSocket disponible en planes gestionados/dedicados) |
Para comparar, Arbitrum One mainnet usa chain ID 42161 y el explorador https://arbiscan.io. Confundir estos dos es la fuente más común de confusión por "transacción fallida" durante las pruebas.
Agregar la red a una billetera
La mayoría de las billeteras aceptan una red personalizada. En MetaMask puedes agregarla manualmente, o activar el mensaje desde una dapp con wallet_addEthereumChain:
await window.ethereum.request({
method: "wallet_addEthereumChain",
params: [{
chainId: "0x66eee", // 421614 en hexadecimal
chainName: "Arbitrum Sepolia",
nativeCurrency: { name: "Sepolia Ether", symbol: "ETH", decimals: 18 },
rpcUrls: ["https://arbitrum-sepolia.api.onfinality.io/public"],
blockExplorerUrls: ["https://sepolia.arbiscan.io"]
}]
});
Ten en cuenta que chainId debe estar codificado en hexadecimal. 421614 en decimal es 0x66eee. Si pasas la cadena decimal, algunas billeteras rechazan la solicitud silenciosamente.
Verificar el endpoint con curl y viem
Antes de conectar cualquier cosa a una aplicación, confirma que el endpoint responde y reporta la cadena que esperas.
curl -s https://arbitrum-sepolia.api.onfinality.io/public \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'
Una respuesta correcta devuelve "result":"0x66eee". Si obtienes un chain ID diferente, estás apuntando a la red incorrecta. Una verificación rápida del número de bloque confirma que el nodo está sincronizado:
import { createPublicClient, http } from "viem";
import { arbitrumSepolia } from "viem/chains";
const client = createPublicClient({
chain: arbitrumSepolia,
transport: http("https://arbitrum-sepolia.api.onfinality.io/public")
});
const block = await client.getBlockNumber();
console.log("Arbitrum Sepolia head:", block);
Si eth_chainId funciona pero getBlockNumber se estanca, el nodo puede estar retrasado o la solicitud está siendo limitada. Esa distinción importa para la sección de depuración a continuación.
Obtener ETH de testnet de un faucet
El gas de Arbitrum Sepolia se paga en Sepolia ETH. No puedes transferir ETH de mainnet a una testnet, así que necesitas un faucet. Opciones típicas:
- El faucet de Arbitrum Sepolia enlazado desde los documentos para desarrolladores de Arbitrum.
- Alchemy y otros faucets de infraestructura que dispensan Sepolia ETH para Arbitrum Sepolia.
- Transferir Sepolia ETH desde Ethereum Sepolia a Arbitrum Sepolia si ya tienes algo.
Los faucets generalmente requieren un saldo mínimo en mainnet o un inicio de sesión social para prevenir abuso, y dispensan pequeñas cantidades. Si un faucet dice que tu dirección no es elegible, casi siempre es una regla antiabuso, no un problema con tu endpoint RPC.
Depurar los errores que realmente encontrarás
La mayoría de los problemas de "testnet RPC" son errores de configuración, no caídas de nodos. Revisa estos en orden.
| Síntoma | Causa probable | Solución |
|---|---|---|
Desajuste de chainId / aviso de red incorrecta | Billetera configurada en Arbitrum One (42161) en lugar de Sepolia (421614) | Vuelve a agregar la red con chain ID 421614 |
insufficient funds for gas | No hay Sepolia ETH en la billetera de prueba | Solicita de un faucet |
nonce too low o transacción pendiente atascada | Nonce reutilizado después de una transacción descartada | Restablece la cuenta en la billetera o envía una transacción de reemplazo |
429 o tiempos de espera bajo carga | Limitación de tasa del endpoint compartido | Cambia a una clave de API RPC gestionada o nodo dedicado |
eth_getLogs devuelve error de rango | Rango de bloques demasiado amplio para el endpoint | Reduce el rango o usa un nodo dedicado con capacidad de archivo |
| La llamada al contrato se revierte solo en testnet | Direcciones o estado desplegados diferentes | Vuelve a verificar direcciones y argumentos del constructor para Sepolia |
Un hábito útil es registrar el chain ID que tu aplicación resuelve al inicio. Muchos "errores de testnet" son en realidad la aplicación hablando silenciosamente con mainnet porque una variable de entorno no se sobrescribió.
Cuándo un endpoint compartido no es suficiente
Los endpoints públicos son convenientes, pero son compartidos. En una testnet eso suele estar bien para un solo desarrollador. Se convierte en un problema cuando:
- Tu CI ejecuta muchos trabajos de prueba en paralelo y alcanza los límites de tasa.
- Un indexador escanea logs en rangos amplios y necesita datos de archivo.
- Quieres suscripciones WebSocket para pruebas basadas en eventos.
- Necesitas el mismo proveedor en staging y producción para que el comportamiento coincida.
En ese punto, una API RPC gestionada con una clave de API, o un nodo dedicado que controlas, elimina la variable de limitación compartida. OnFinality proporciona ambos: un servicio de API RPC gestionado en redes compatibles, y nodos dedicados cuando necesitas capacidad aislada, datos de archivo o transporte WebSocket. Para el trabajo en testnet, la razón práctica para subir de nivel es la reproducibilidad: quieres que las fallas de prueba reflejen tu código, no el tráfico de otra persona.
Testnet versus mainnet: qué difiere realmente
Ayuda saber qué se traslada de Arbitrum Sepolia a Arbitrum One, y qué no.
- Entorno de ejecución: Basado en Nitro, por lo que el comportamiento de EVM y la mayoría de los opcodes coinciden estrechamente con mainnet.
- Gas: Sepolia ETH, no ETH real. Los precios del gas suelen ser bajos y menos representativos de las condiciones de mainnet.
- Estado: Completamente separado. Los contratos deben redesplegarse; las direcciones diferirán.
- Oráculos y puentes: Existen versiones de testnet pero pueden estar limitadas o tener feeds diferentes.
- Comportamiento del secuenciador: Similar, pero no asumas características de latencia o rendimiento de mainnet.
Debido a que el gas es barato y el estado es desechable, la testnet es el lugar correcto para probar el manejo de nonces, suscripciones a eventos y lógica de escaneo de logs antes de apuntar el mismo código a mainnet.
Puntos clave
- "Arbitrum One testnet" casi siempre significa Arbitrum Sepolia, chain ID
421614. - Arbitrum One en sí es mainnet, chain ID
42161— no apuntes código de prueba a ella. - El endpoint HTTPS público es
https://arbitrum-sepolia.api.onfinality.io/public; verifícalo coneth_chainIdantes de usarlo. - Necesitas Sepolia ETH de un faucet; no puedes transferir ETH de mainnet a una testnet.
- La mayoría de los errores son problemas de configuración (chain ID incorrecto, sin gas, nonce reutilizado), no fallas de nodo.
- Cambia a una API RPC gestionada o nodo dedicado cuando la concurrencia de CI, los escaneos de logs o las necesidades de WebSocket superen un endpoint compartido.
Preguntas frecuentes
¿Arbitrum One es una testnet?
No. Arbitrum One es la cadena mainnet (chain ID 42161). La testnet es Arbitrum Sepolia (chain ID 421614).
¿Cuál es la URL RPC de Arbitrum Sepolia?
El endpoint HTTPS público es https://arbitrum-sepolia.api.onfinality.io/public. Para configuraciones de prueba similares a producción, usa un endpoint gestionado o dedicado.
¿Qué chain ID debo usar para la testnet de Arbitrum?
421614, que es 0x66eee en hexadecimal.
¿Cómo obtengo ETH de testnet? Usa un faucet de Arbitrum Sepolia, o transfiere Sepolia ETH desde Ethereum Sepolia si ya tienes algo. El ETH de mainnet no se puede transferir a una testnet.
¿Por qué falla mi transacción con fondos insuficientes? Tu billetera no tiene Sepolia ETH. Solicita de un faucet y vuelve a intentarlo.
¿Puedo usar WebSockets en la testnet? El transporte WebSocket está disponible en planes gestionados y dedicados. Consulta la página de red de Arbitrum y los precios de RPC para opciones actuales.
¿Debería usar el mismo proveedor para testnet y mainnet? Es una buena práctica. Coincidir proveedores y transportes reduce la posibilidad de que staging se comporte de manera diferente a producción por razones no relacionadas con tu código.