Chain ID de Solana: por qué es el hash génesis, no 101

La respuesta corta: no existe un chain ID numérico de Solana

Si buscas el chain ID de Solana, la respuesta honesta es que Solana no tiene uno en el sentido que esperan los desarrolladores de Ethereum. No hay un campo chainId en una transacción de Solana, no hay un método eth_chainId en un endpoint de Solana y no hay un entero que el protocolo mezcle en las firmas. El identificador que distingue un clúster de Solana de otro es el hash génesis: el hash codificado en Base58 del bloque cero, devuelto por getGenesisHash.

Ese hash tiene 44 caracteres. El estándar agnóstico de cadena que usan las billeteras y dApps multicadena, CAIP-2, no lo usa literalmente. Toma los primeros 32 caracteres como referencia de cadena y le antepone el espacio de nombres, produciendo valores como solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp para mainnet-beta. El perfil del espacio de nombres CAIP-2 de Solana define esto como truncate(genesisHash, 32) y lo resuelve llamando a getGenesisHash, y la especificación CAIP-2 define el formato general de cadena namespace:reference en el que encaja el resultado.

Así que los dos valores que realmente verás en la configuración son el moniker del clúster (mainnet-beta, devnet, testnet) y el chain ID CAIP-2 (solana: más los primeros 32 caracteres del hash génesis). Si un tutorial o un registro te dice que el chain ID de Solana es un número, ese número se está reutilizando de una convención EVM.

Por qué Solana no necesita un chain ID numérico

Ethereum necesitaba un chain ID para la protección contra repetición. Antes de EIP-155, los campos firmados eran (nonce, gasprice, startgas, to, value, data) — nada identificaba la cadena, por lo que una transacción firmada para una red EVM podía reproducirse en otra. EIP-155 incluyó CHAIN_ID en el hash de firma y lo codificó en v como CHAIN_ID * 2 + 35 o CHAIN_ID * 2 + 36, haciendo que el chain ID formara parte de la propia firma.

El formato de transacción de Solana resuelve el mismo problema de manera diferente. Una transacción de Solana es un mensaje de instrucciones compiladas más firmas, firmado sobre ese mensaje exacto en el formato de cable propio de Solana. No es una estructura RLP con un valor v y no tiene un campo para un identificador de cadena numérico. La separación de clústeres proviene del envío: la transacción va a un endpoint que participa en un clúster y solo es válida si su blockhash reciente existe en el ledger de ese clúster.

La consecuencia es práctica más que filosófica. Lo que obtienes es un identificador a nivel de conexión: el hash génesis del clúster que tu endpoint está sirviendo realmente. Es una afirmación más fuerte que una constante configurada, porque se mide desde el nodo en lugar de declararse en un archivo de configuración.

Los tres clústeres y sus hashes génesis

Solana publica actualmente tres clústeres públicos, cada uno con su propio hash génesis, su propio endpoint de API y un propósito distinto. La siguiente tabla se generó llamando a getGenesisHash contra cada endpoint público el 2026-10-19 y truncando el resultado a 32 caracteres para derivar la referencia CAIP-2.

Fíjate en la nomenclatura. El clúster de producción se llama mainnet-beta, no mainnet, y el moniker aparece en el nombre de host api.mainnet-beta.solana.com. Trata mainnet solo como ambiguo en tu propia configuración, porque una billetera o biblioteca puede mapearlo a una cadena diferente de la que reporta el clúster.

• mainnet-beta — 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d → solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp. Producción, SOL real, valor real.
• devnet — EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG → solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1. Pruebas de aplicaciones, financiado por faucet, puede reiniciarse.
• testnet — 4uhcVJyU9pJkvQyS88uRDiswHXSCkY3zQawwpjk2NsNY → solana:4uhcVJyU9pJkvQyS88uRDiswHXSCkY3z. Pruebas de estrés de validadores y versiones del núcleo, puede reiniciarse.
• Las tres referencias de 32 caracteres anteriores coinciden con los casos de prueba del perfil del espacio de nombres CAIP-2 de Solana — una verificación cruzada útil: si tus herramientas producen algo diferente para estos clústeres, el paso de truncamiento o codificación es incorrecto.

De dónde viene el número 101 y por qué es incorrecto

Busca un chain ID de Solana y encontrarás afirmaciones de que es 101, a veces 900, ocasionalmente 501. Los tres son chain IDs EVM que pertenecen a redes no relacionadas. El 2026-10-19, el registro público de chain IDs de Ethereum listaba 2.818 cadenas: 101 es EtherInc, 900 es Garizon Testnet Stage0, 501 es Columbus Test Network. Ninguna se llama Solana, porque Solana no es una cadena EVM y nunca registra un chain ID eip155.

La confusión tiene un origen predecible. Algunas billeteras y SDK aceptan un chainId numérico para redes EVM y una cadena CAIP-2 para redes no EVM, por lo que algunas herramientas asignaron números de marcador de posición a los clústeres de Solana para llenar un único campo numérico. Esos marcadores de posición son detalles de implementación: no son identificadores de consenso, no son estables entre proveedores y dos herramientas pueden discrepar legítimamente sobre qué número mapea a qué clúster.

Por eso nunca debes validar un destino de Solana comparando un número. La comprobación correcta es la referencia CAIP-2 de 32 caracteres, o el hash génesis completo de 44 caracteres, obtenido del endpoint que vas a usar.

Resolver cualquier endpoint a su chain ID

El siguiente script toma cualquier URL RPC de Solana, le pide al endpoint su hash génesis, deriva el chain ID CAIP-2 y devuelve un veredicto contra un clúster esperado opcional. También dispara dos controles negativos, eth_chainId y getChainId, para mostrar que la superficie JSON-RPC de Solana no implementa ninguno de los dos.

// solana-chain-id.mjs — Node.js 18+
// Usage: node solana-chain-id.mjs <RPC_URL> [mainnet-beta|devnet|testnet]
const [rpcUrl, expected] = process.argv.slice(2);
if (!rpcUrl) { console.error("usage: node solana-chain-id.mjs <RPC_URL> [cluster]"); process.exit(2); }

// Authoritative references: ChainAgnostic/namespaces solana caip2 => truncate(genesisHash, 32)
const KNOWN = {
  "5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp": "mainnet-beta",
  "EtWTRABZaYq6iMfeYKouRu166VU2xqa1": "devnet",
  "4uhcVJyU9pJkvQyS88uRDiswHXSCkY3z": "testnet",
};

async function rpc(method, params = []) {
  const started = Date.now();
  const res = await fetch(rpcUrl, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({ jsonrpc: "2.0", id: 1, method, params }),
    signal: AbortSignal.timeout(15000),
  });
  return { http: res.status, ms: Date.now() - started, body: await res.json() };
}

const genesis = await rpc("getGenesisHash");
if (genesis.body.error) {
  console.error(JSON.stringify({ rpcUrl, error: genesis.body.error }, null, 2));
  process.exit(1);
}
const fullHash = genesis.body.result;      // 44 Base58 characters
const chainRef = fullHash.slice(0, 32);    // CAIP-2 reference = first 32 characters
const cluster = KNOWN[chainRef] ?? "unknown";

// Negative controls: neither method exists in Solana's JSON-RPC surface.
const ethChainId = await rpc("eth_chainId");
const getChainId = await rpc("getChainId");

console.log(JSON.stringify({
  rpcUrl,
  httpStatus: genesis.http,
  latencyMs: genesis.ms,
  genesisHash: fullHash,
  genesisHashLength: fullHash.length,
  caip2ChainId: `solana:${chainRef}`,
  cluster,
  expectedCluster: expected ?? null,
  verdict: !expected ? "observed" : expected === cluster ? "match" : "MISMATCH",
  eth_chainId_error: ethChainId.body.error ?? null,
  getChainId_error: getChainId.body.error ?? null,
}, null, 2));

Salida medida de tres clústeres públicos

Estas son las ejecuciones reales capturadas el 2026-10-19 contra los endpoints públicos de solana.com. Cada valor regresó del nodo durante la ejecución; las latencias son muestras únicas, así que trátalas como indicativas y no como un benchmark.

$ node solana-chain-id.mjs https://api.mainnet-beta.solana.com mainnet-beta
{
  "rpcUrl": "https://api.mainnet-beta.solana.com",
  "httpStatus": 200,
  "latencyMs": 83,
  "genesisHash": "5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d",
  "genesisHashLength": 44,
  "caip2ChainId": "solana:5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp",
  "cluster": "mainnet-beta",
  "verdict": "match",
  "eth_chainId_error": { "code": -32601, "message": "Method not found" },
  "getChainId_error": { "code": -32601, "message": "Method not found" }
}

$ node solana-chain-id.mjs https://api.devnet.solana.com mainnet-beta
{
  "rpcUrl": "https://api.devnet.solana.com",
  "caip2ChainId": "solana:EtWTRABZaYq6iMfeYKouRu166VU2xqa1",
  "cluster": "devnet",
  "expectedCluster": "mainnet-beta",
  "verdict": "MISMATCH"
}

Interpretar los resultados: coincidencia, discrepancia y clúster desconocido

La segunda ejecución es la que importa. Un endpoint de devnet al que se le pide demostrar que es mainnet-beta devuelve un hash génesis válido, una cadena CAIP-2 válida, HTTP 200 y ningún error; todas las comprobaciones excepto la comparación pasan. Solo el veredicto MISMATCH detecta el problema, por lo que una comprobación de estado que se detiene en getHealth no es suficiente: un nodo de devnet está perfectamente sano, solo que en el ledger equivocado.

Un veredicto de clúster unknown es una señal diferente: el endpoint respondió a getGenesisHash pero devolvió una referencia que no es uno de los tres clústeres públicos. Eso puede ser legítimo, ya que las instancias locales de solana-test-validator, los clústeres privados y las bifurcaciones tienen su propio hash génesis. Trata unknown como entrada no confiable y decide deliberadamente si aceptarlo.

Las dos respuestas -32601 Method not found son la respuesta empírica. eth_chainId es un método EVM y getChainId no forma parte de la interfaz JSON-RPC de Solana, por lo que un nodo de Solana no puede producir un chain ID numérico a partir de ellos. Una herramienta que reporta uno de todos modos está leyendo una constante local o traduciendo a través de un mapeo CAIP-2.

Verificar un entorno completo antes de confiar en él

En producción rara vez verificas un solo endpoint; verificas un grupo o los endpoints integrados en una compilación móvil. Recopila el conjunto de referencias CAIP-2 distintas en todos los endpoints y afirma que el conjunto tiene exactamente un miembro. Cualquier otra cosa es un defecto de configuración que eventualmente enviará una transacción firmada al clúster equivocado.

En el lado del cliente, compara la referencia completa de 32 caracteres devuelta por la billetera o el endpoint RPC con la que esperas. Nunca compares un prefijo corto: solana:5ey y solana:5ez son cadenas diferentes, y la coincidencia de prefijos es cómo una acción solo para mainnet termina ofreciéndose en un clúster de prueba.

• Recopila getGenesisHash de cada endpoint de la lista, no solo del primero que responda.
• Reduce cada resultado a la referencia de 32 caracteres y agrupa por referencia, no por nombre de host ni por etiqueta en la configuración.
• Falla el despliegue si el tamaño del conjunto es mayor que uno, y nombra cada endpoint que discrepe.
• Registra la referencia junto al endpoint en tu catálogo de servicios, porque los nombres DNS y los balanceadores de carga pueden reasignarse sin aviso.
• Vuelve a ejecutar la comprobación periódicamente. Devnet y testnet pueden reiniciarse, y un reinicio cambia el ledger sin cambiar el nombre de host.

Reglas de integración de billeteras y dApps para cadenas no EVM

CAIP-2 existe porque un único campo numérico no puede describir todos los ecosistemas. Su sintaxis es namespace:reference, y cada espacio de nombres define cómo se resuelve la referencia: para eip155 es el chain ID decimal de eth_chainId, para solana el hash génesis truncado de getGenesisHash. Una billetera multicadena que solo almacena números no puede representar Solana correctamente.

En la práctica, lleva la cadena CAIP-2 como clave primaria de una red y deriva cualquier campo numérico heredado solo como etiqueta de visualización. Los cambios de red se convierten en comparaciones de cadenas sobre la referencia; los registros deben incluirla; las cachés deben tenerla como clave para que las respuestas de mainnet y devnet no colisionen.

Adopta un hábito más: almacena el hash génesis completo de 44 caracteres para reconciliación y analítica, y la referencia de 32 caracteres para identificación en el formato de cable. La referencia es un truncamiento, por lo que es una convención de identificación, no un compromiso criptográfico, y conservar el hash completo significa que un futuro esquema de truncamiento no puede colapsar silenciosamente dos cadenas en una sola clave.

Qué hacer cuando un endpoint no puede responder

Si getGenesisHash falla, no recurras a un número configurado ni a una etiqueta de clúster codificada. Distingue los modos de fallo, porque significan cosas diferentes para tu aplicación.

Si necesitas un endpoint verificado en lugar de uno público, la guía de endpoints RPC de Solana cubre la selección y el aprovisionamiento, y la página de la red Solana describe la red a un nivel superior. Este artículo deliberadamente no recomienda proveedores: qué endpoint usar es una decisión de servicio, mientras que cómo probar qué cadena sirve es una cuestión de protocolo.

• Conexión rechazada o tiempo de espera agotado — el endpoint está caído o la ruta de red está bloqueada. Prueba el siguiente endpoint del grupo, pero verifica igualmente su hash génesis antes de usarlo.
• HTTP 429 o 403 — estás limitado o bloqueado. Es un problema de acceso, no de identidad; el clúster del endpoint sigue siendo desconocido para ti hasta que una solicitud tenga éxito. Consulta Límites de velocidad y errores 429 en RPC de Solana para el comportamiento de reintento.
• -32601 Method not found — el endpoint no es un nodo JSON-RPC de Solana en absoluto, o es un proxy que solo reenvía un subconjunto de métodos. No asumas su clúster.
• Resultado válido con una referencia inesperada — el endpoint responde, pero para un clúster diferente al que esperabas. Trátalo como un MISMATCH y detente.

Limitaciones y supuestos

El perfil del espacio de nombres CAIP-2 de Solana está marcado como borrador, actualizado por última vez en marzo de 2023, por lo que la regla de truncamiento es una convención de facto en lugar de un estándar finalizado. Las implementaciones coinciden en ella hoy y las tres referencias aquí coinciden con los propios casos de prueba del perfil, pero vuelve a consultar la especificación en lugar de tratarla como congelada.

Las latencias anteriores son muestras únicas de una máquina. Muestran que la llamada es barata, no que un endpoint sea rápido; los endpoints públicos están limitados en velocidad y cambian sin aviso, por lo que producción necesita verificación más un endpoint privado.

Los reinicios de clúster también son reales. Devnet y testnet están documentados como sujetos a reinicios del ledger, y un reinicio puede cambiar el hash génesis. Trata cualquier hash no productivo codificado como caché con caducidad, actualizado desde el endpoint, nunca como una constante permanente.

Lecturas relacionadas y próximos pasos

Si tu trabajo abarca cadenas EVM y no EVM, el complemento es Identidad de nodo EVM: chainId, net_version y clientVersion, que cubre el lado numérico del mismo problema. Para redes de billetera configuradas manualmente, Configuración de MetaMask para RPC de Base: campos de chain ID muestra el conjunto de campos EVM.

Una vez confirmada la cadena, las siguientes preguntas son sobre cuándo se puede confiar en un resultado. Niveles de compromiso de Solana: processed, confirmed, finalized explica los estados de confirmación, y Transacciones versionadas de Solana y análisis de getBlock cubre la decodificación de lo que regresa. Vale la pena leer ambos antes de construir lógica de reconciliación sobre la comprobación del chain ID.

Para planificación de capacidad en torno al acceso verificado, consulta Precios de RPC y la descripción general del servicio de API, y explora el centro de aprendizaje de OnFinality para el conjunto más amplio de guías de protocolo y operaciones.