Tu billetera no guarda una copia de la cadena. Le pregunta a un nodo, y la dirección a la que pregunta es el endpoint que está en tus ajustes de red. Cambiar esa dirección lleva unos segundos y cambia quién responde cada pregunta que haces sobre tu propio saldo. Por eso conviene hacerlo a conciencia y no por reflejo.
Qué es el endpoint de tus ajustes de red
Un endpoint de llamada a procedimiento remoto es una dirección web a la que tu billetera envía preguntas. Hay fondos en esta dirección, cuánto cuesta una transacción ahora mismo, se ha incluido ya esta otra, pasa por favor este objeto firmado a la red. El endpoint responde, y su respuesta es lo que muestra tu pantalla.
La máquina detrás de esa dirección es un nodo RPC, un nodo que además expone una interfaz pública para que las billeteras y las aplicaciones no tengan que ejecutar el suyo. De aquí en adelante ese ajuste se abrevia como el endpoint.
De esa disposición se siguen dos cosas, y tiran en direcciones opuestas. El endpoint no forma parte de la cadena, así que sustituirlo no cambia nada de tus claves, de tu dirección ni del saldo anotado en ella. El endpoint es también lo único a través de lo cual ves la cadena, así que sustituirlo cambia todo lo que se te muestra.
Por qué querrías cambiar uno
La razón corriente es que el actual ha dejado de responder bien. Un nodo caído, que te limita las peticiones o que va por detrás de la punta de la cadena no anuncia nada de eso. Produce saldos desactualizados, una transacción confirmada que sigue apareciendo como pendiente, o un envío que falla en la conexión mientras nada va mal en tu cuenta.
La segunda razón es la cobertura. Una billetera viene con una lista corta de redes, y una cadena fuera de esa lista hay que añadirla a mano, endpoint incluido. Añadir una red y añadir un endpoint son la misma acción hecha en el mismo cuadro de diálogo.
La tercera razón es la privacidad. Cada petición que haces pasa por un operador, así que ese operador puede asociar tus direcciones entre sí y con una dirección IP. Pasarte a otro proveedor traslada esa visibilidad en lugar de eliminarla, así que trata la elección como elegir quién mira, no como esconderte.
Qué puede cambiar un endpoint y qué no
El límite es la firma. Tu billetera construye la transacción en local y la firma con una clave que nunca sale del dispositivo, así que el endpoint recibe un objeto terminado que no puede editar sin invalidarlo. Puede negarse a reenviarlo, retrasarlo o mandarlo a otra parte, pero no puede alterar el importe ni el destinatario que lleva dentro.
Lo que sí puede hacer es dar forma a los datos con los que decides. Saldos, listas de tokens, estimaciones de comisión y estado de confirmación llegan todos por el endpoint, y uno hostil es libre de informar cifras sencillamente inventadas. Ahí está el peligro real: no una clave robada, sino una decisión tomada sobre una imagen falsa.
| Qué estás mirando | Puede falsearlo un endpoint hostil | Qué lo zanja |
|---|---|---|
| Saldo y lista de tokens | Sí | Leer la misma dirección en una segunda fuente |
| Estimación de comisión | Sí | Comprobar la comisión que muestra la billetera antes de firmar |
| Historial de transacciones | Sí | Un explorador que opera su propia infraestructura |
| Estado de confirmación | Sí | Volver a comprobarlo por un endpoint distinto |
| El contenido de lo que firmaste | No | La firma cubre la carga útil |
| Tu clave privada | No | Nunca se envía a ningún sitio |
La consecuencia práctica es que un endpoint merece el mismo escrutinio que un sitio al que conectarías una billetera. Una dirección pegada en un chat de soporte o servida por un anuncio de búsqueda va al mismo cajón que una web de cripto falsa, y por la misma razón.
El identificador de cadena es la comprobación que atrapa la red equivocada
Cada red lleva un identificador que vive dentro de la propia transacción firmada. EIP-155 lo introdujo para impedir que una transacción firmada para una cadena sea válida en otra, y funciona plegando el identificador de cadena dentro de los datos que se convierten en hash y se firman. Una firma hecha bajo un identificador de cadena no significa nada en una cadena que usa otro distinto.
Eso te da una comprobación que no depende de confiar en nadie. El método eth_chainId devuelve el identificador de cadena que se usa para firmar transacciones con protección contra repetición, así que se le puede preguntar directamente a un endpoint qué red cree estar sirviendo. Si esa respuesta discrepa del identificador de cadena que tu billetera guarda para esa entrada de red, las dos no están describiendo la misma cadena.
EIP-3085, la interfaz propuesta para añadir una cadena de forma programática, integra la misma comparación en la billetera. Exige rechazar la petición cuando el identificador de cadena declarado no coincide con lo que informan los endpoints suministrados, y afirma que no se puede dar por supuesto que esos endpoints sean honestos, correctos ni que apunten siquiera a la misma cadena. En el lado de la firma su instrucción es aún más estrecha: usar solo el identificador de cadena que la billetera ya tiene, nunca uno recibido de un endpoint.
Comprueba un endpoint antes de enrutar nada por él
Cuatro comprobaciones, en el orden que menos cuesta. Confirma primero el identificador de cadena, porque es la única respuesta que no es cuestión de grado. Después compara la altura de bloque que informa con una fuente independiente. Un nodo muy por detrás de la punta no es hostil, está desactualizado, y desactualizado basta para que todo lo demás que te diga esté mal.
Compara luego algo que ya sabes. Abre una dirección cuyo saldo puedas verificar en otro sitio y mira si las dos vistas coinciden. Una discrepancia en este punto te dice que pares antes de firmar nada, sin decirte todavía si la causa es el retraso o la mala fe.
Por último, cuando el endpoint es nuevo para ti y los importes no lo son, envía primero una transacción pequeña y mírala confirmarse. Lo importante no es lo poco que arriesgas; es que un viaje completo de ida y vuelta ejercita el envío y la lectura de vuelta, que son las dos mitades que un endpoint malo rompe por separado.
Añadir uno a mano sin romper la billetera
Añade en vez de sobrescribir. Donde la billetera te deja conservar varias entradas para la misma cadena, quedarte con la que funcionaba significa que un cambio malo se deshace seleccionando la entrada anterior y no volviendo a teclear una URL que ya no tienes. Nombra cada entrada según quien la opera, para que el selector se lea como una lista de partes y no como una lista de nombres de cadena idénticos.
Rellena el resto de la entrada con la documentación de la propia red, no con la de quien te pasó el endpoint. El identificador de cadena, el símbolo de la moneda y el explorador de bloques forman parte de lo que la billetera mostrará después, y una entrada con el endpoint correcto y el símbolo equivocado etiquetará mal, en silencio, cada importe que mires.
Comprueba después la entrada ya guardada, no antes. El cuadro de diálogo valida lo que tecleaste; lo que importa es lo que hace la entrada guardada. Cámbiate a ella, deja que carguen los saldos y confirma que coinciden con lo que mostraba la entrada anterior. Una entrada de red que discrepa de su predecesora sobre tu propio saldo te está diciendo algo, y el momento de enterarse es antes de firmar.
Cuándo cambiar no es la solución
Un endpoint nuevo cambia lo que puedes ver, así que repara problemas hechos de información ausente o desactualizada. No alcanza hacia atrás lo que ya ha ocurrido en la cadena. Una vez emitida, una transacción se queda en el mempool de cada nodo que la recibió, y cambiar el nodo con el que habla tu billetera no la retira.
El mismo límite se aplica a un fallo que la cadena ya ha registrado. Una transacción que se ejecutó y fue revertida es reverted, y ese resultado queda escrito en un recibo que cualquier endpoint honesto informa igual. Verlo desde dos endpoints independientes significa que la respuesta no es ir a buscar un tercero.
Entre esos dos casos hay una clase de error que un cambio sí despeja, porque viene de una vista en caché y no de la cadena. Una billetera que informa nonce demasiado alto tras un cambio de red o una reinstalación está comparando su propio recuento con lo que le dijo un endpoint, y reconectarse por un nodo sano le permite releer ese recuento desde una fuente que sí está al día.
En resumen
Un endpoint no forma parte de la cadena ni de la seguridad de las claves de tu billetera, pero es todo lo que puedes ver, y una decisión tomada sobre cifras inventadas cuesta tanto como una tomada tras una clave robada. Cambiar de endpoint es una reparación rutinaria para una red desactualizada o que no responde, y la disciplina que lo vuelve seguro es pequeña: saber quién opera el que estás añadiendo, confirmar el identificador de cadena y conservar la entrada que ya funcionaba.
La comprobación del identificador de cadena es la más barata de las cuatro, y es la primera que hay que hacer. Pregunta al endpoint qué cadena sirve y compáralo con lo que tu billetera ya tiene, porque esa única comparación atrapa tanto el error honesto de añadir la red equivocada como el caso deshonesto de un endpoint que quiere hacerte creer que estás en otro sitio. Para seguir aprendiendo los fundamentos, sigue leyendo Bitbase Academy.
Lecturas relacionadas
Otros artículos de Bitbase sobre este tema:
- Comisión máxima de transacción superada: qué significa ese aviso de la billetera
- Límite de solicitudes RPC excedido y cómo evitarlo
- ¿Qué es un código QR de cripto?
- Fill or kill, immediate or cancel y all or none, explicados
- ¿Está Bitcoin correlacionado con las acciones, el oro o el apetito por el riesgo?
Aviso legal: Este artículo es contenido educativo de Bitbase Academy y se ofrece solo con fines informativos. No constituye asesoramiento de inversión, negociación, fiscal ni financiero. Los criptoactivos son volátiles; evalúa tu propio riesgo. Redactado en septiembre de 2026; consulta la información oficial más reciente.
Fuentes
[1] Ethereum Improvement Proposals, EIP-155: Simple replay attack protection, estado Final eips.ethereum.org
[2] Ethereum Improvement Proposals, EIP-3085: wallet_addEthereumChain RPC Method, estado Stagnant eips.ethereum.org
[3] Documentación para desarrolladores de ethereum.org, JSON-RPC API, método eth_chainId ethereum.org
