Lista de cadenas: cómo encontrar chain IDs, endpoints RPC y redes confiables para tu aplicación

Qué contiene realmente una lista de cadenas

Una lista de cadenas es un directorio estructurado de redes blockchain. Para las cadenas EVM, cada entrada suele incluir el nombre de la cadena, el chain ID (decimal y hexadecimal), el nombre corto, el símbolo y los decimales de la moneda nativa, las URL del explorador de bloques y uno o más endpoints RPC. Las cadenas no EVM aparecen en listas más amplias, pero usan metadatos diferentes porque no comparten la interfaz JSON-RPC de EVM.

La fuente más referenciada es el repositorio ethereum-lists/chains. Cada cadena tiene su propio archivo JSON nombrado con su identificador CAIP-2, y directorios como Chainlist convierten esos datos en una interfaz de búsqueda. Cuando ves un chain ID en una wallet o en una dApp, normalmente se remonta a este repositorio o a una copia suya.

La distinción importante: una lista de cadenas te dice cómo identificar una red, no cómo operar contra ella. El chain ID es metadato de protocolo estable. La URL RPC es una decisión operativa que cambia con tu carga de trabajo, y los endpoints públicos de un directorio los comparten todos los que leen esa página.

• Chain ID: el identificador numérico usado en transacciones y configuraciones de wallet.
• Moneda nativa: símbolo y decimales usados para mostrar valores y calcular gas.
• URLs RPC: uno o más endpoints, a menudo públicos y con límite de tasa.
• URLs del explorador: enlaces al explorador de bloques para verificación y depuración.
• Identificador CAIP-2: el formato namespace:reference usado en el repositorio upstream.

Recomendación rápida: consulta en directorio vs endpoint de producción

Usa una lista de cadenas cuando necesites configurar una wallet, verificar un chain ID o añadir un testnet a un entorno de desarrollo. Usa un proveedor RPC gestionado cuando necesites un endpoint que soporte tráfico de aplicaciones, consultas de archive o suscripciones WebSocket sin competir con usuarios anónimos.

La tabla siguiente relaciona tareas comunes con la fuente adecuada. Si tu tarea está en la columna de la derecha, una entrada de directorio no es la respuesta final.

Los campos que causan más errores de configuración

La mayoría de los errores en listas de cadenas provienen de tres campos: chain ID, URL RPC y decimales de la moneda. Un chain ID incorrecto envía una transacción a la red equivocada o hace que una wallet rechace una firma. Una URL RPC obsoleta produce timeouts que parecen errores de la aplicación. Unos decimales incorrectos muestran los saldos mal sin romper las transacciones, lo que hace que el error sea más difícil de detectar.

El chain ID merece especial atención porque aparece en dos formatos. Las wallets y JSON-RPC esperan una cantidad hexadecimal como 0x1 para Ethereum mainnet, mientras que muchas listas muestran la forma decimal 1. Convertir entre ambos es trivial pero fácil de omitir, y una discrepancia entre el chain ID configurado y la red real del endpoint se manifestará como un error de chain ID inválido.

Para las URL RPC, trata cualquier endpoint público de un directorio como una comodidad para desarrollo. Comprueba si el endpoint soporta los métodos que necesitas, si es archive o podado, y si acepta conexiones WebSocket antes de construir sobre él.

• Verifica el chain ID tanto en decimal como en hexadecimal antes de configurar una wallet.
• Confirma la red del endpoint RPC llamando a eth_chainId, no confiando en la etiqueta.
• Comprueba los decimales de la moneda nativa; no asumas 18 para todas las cadenas.
• Prefiere endpoints HTTPS; evita fallos de contenido mixto en dApps de navegador.
• Registra la fuente y la fecha de cualquier metadato de cadena que codifiques de forma fija.

Verificar una entrada de cadena con una sola solicitud

Antes de conectar una cadena a una aplicación, confirma que el endpoint realmente sirve la red que esperas. El método eth_chainId devuelve el chain ID como cantidad hexadecimal, que puedes comparar con el valor decimal de la lista de cadenas.

El ejemplo siguiente usa un endpoint de marcador de posición. Sustitúyelo por el endpoint de tu proveedor o por la documentación oficial de la cadena; no asumas que una URL de directorio público está lista para producción.

• curl -X POST https://your-rpc-endpoint.example \
• -H "Content-Type: application/json" \
• -d '{"jsonrpc":"2.0","method":"eth_chainId","params":[],"id":1}'
• Forma de respuesta esperada: {"jsonrpc":"2.0","id":1,"result":"0x1"} para Ethereum mainnet.

De la lista de cadenas al RPC de producción: qué evaluar

Una vez que dejas atrás las consultas en directorios, la decisión pasa de los metadatos a las operaciones. El valor de un proveedor está en cómo gestiona tu carga de trabajo específica: volumen de solicitudes, mezcla de métodos, profundidad de archive y tipo de conexión. La evaluación siguiente es una lista de comprobación inicial, no una clasificación.

OnFinality ofrece acceso a la API RPC gestionada e infraestructura de nodos dedicados en una variedad de redes compatibles. Para una vista cadena por cadena, consulta las redes RPC compatibles; para planificar la carga de trabajo, consulta los precios de RPC. Si necesitas capacidad aislada, los nodos dedicados son la opción relevante.

Leer entradas no EVM en una lista de cadenas

No todas las cadenas de una lista hablan JSON-RPC de EVM. Solana, Polkadot y otros ecosistemas tienen sus propias interfaces RPC y sus propias convenciones de metadatos. Una lista de cadenas genérica puede incluirlas, pero los campos no se corresponderán uno a uno con la configuración de una wallet EVM.

Para redes no EVM, los campos útiles son el identificador de red, el endpoint RPC y la documentación de la API específica de la cadena. Las páginas de red de OnFinality para cada cadena compatible son una referencia mejor que un directorio genérico, porque reflejan el endpoint y el soporte de métodos que el proveedor ofrece realmente.

Si estás construyendo multicadena, mantén una configuración por ecosistema en lugar de forzarlo todo en un único esquema con forma de EVM. Eso evita fallos silenciosos cuando una cadena no soporta un método que tu código EVM da por hecho.

• Cadenas EVM: chain ID, moneda, explorador, endpoint JSON-RPC.
• Solana: nombre del clúster, endpoint RPC, endpoint WebSocket.
• Polkadot y Substrate: nombre de la red, endpoint RPC, métodos específicos de la cadena.
• Mantén objetos de configuración separados por ecosistema para evitar desajustes de métodos.

Un flujo de trabajo práctico para añadir una nueva cadena

Cuando una nueva cadena aparece en tu hoja de ruta, la secuencia siguiente mantiene separadas las decisiones de metadatos y de infraestructura. También te deja un registro de qué verificaste y cuándo.

Empieza por el repositorio upstream o la documentación oficial de la cadena, no por una copia de terceros. Confirma el chain ID con una llamada eth_chainId en vivo. Después decide si la cadena es un testnet o un objetivo de producción, y elige un endpoint en consecuencia. Para producción, prefiere un proveedor gestionado con límites documentados antes que una URL de directorio público.

• 1. Encuentra la cadena en el repositorio upstream o en la documentación oficial.
• 2. Registra el chain ID, los decimales de la moneda y la URL del explorador.
• 3. Verifica el endpoint con eth_chainId antes de configurar la aplicación.
• 4. Decide testnet vs producción y elige una clase de endpoint.
• 5. Añade failover y monitorización antes del lanzamiento.
• 6. Vuelve a comprobar los metadatos cuando la cadena anuncie actualizaciones.

Preguntas frecuentes