Billetera cripto no custodial: propiedad de claves, dependencias RPC y flujo de verificación

Respuesta directa y alcance

Una billetera cripto no custodial es una billetera en la que las claves privadas se generan y almacenan bajo el control del usuario, y ninguna empresa puede mover fondos sin una firma producida por esas claves. El término describe la custodia, no la conectividad: una billetera no custodial sigue leyendo saldos, estimando comisiones y difundiendo transacciones a través de endpoints RPC operados por terceros, a menos que ejecutes tu propio nodo.

Esta guía cubre el modelo operativo que hay detrás de las billeteras de autocustodia: cómo se relacionan las claves, las direcciones y las firmas; cómo depende una billetera de la infraestructura RPC; y cómo verificar su comportamiento con comandos reproducibles. No clasifica marcas de billeteras ni recomienda un endpoint concreto. Para la selección concreta de endpoints y proveedores, usa los recursos del RPC Assistant enlazados más adelante.

• Dentro del alcance: propiedad de claves, flujo de firma, dependencias RPC, verificación, resolución de problemas y supuestos de recuperación.
• Fuera del alcance: comentarios sobre el precio de tokens, clasificaciones de marcas de billeteras y asesoramiento legal o fiscal.
• Supuesto: dispones de una billetera de prueba sin fondos reales y acceso a un terminal con curl y Node.js o Python.

Custodial frente a no custodial: la frontera que importa

La diferencia decisiva es quién puede producir una firma válida. En un esquema custodial, una plataforma guarda las claves o partes de ellas y autoriza retiros tras sus propios controles, como el inicio de sesión, el KYC o la revisión de retiros. En un esquema no custodial, el material de firma permanece con el usuario, y la aplicación de billetera es una herramienta, no una autoridad.

Esta frontera tiene consecuencias prácticas. Una billetera no custodial no puede congelar tus fondos a nivel de protocolo, pero tampoco puede restablecer tu contraseña ni restaurar una frase semilla perdida. A la inversa, una plataforma custodial puede ofrecer recuperación de cuenta y atención al cliente, pero también puede restringir retiros o quebrar como negocio. Muchos usuarios operan ambos modelos con fines distintos, lo que es una elección legítima de asignación de riesgo y no una contradicción.

• No custodial: claves en poder del usuario, transacciones firmadas por el usuario, sin recuperación por parte de la plataforma.
• Custodial: claves en poder de la plataforma, retiros autorizados por la plataforma, recuperación por la plataforma y riesgo de la plataforma.
• Existen patrones híbridos, como configuraciones multifirma o MPC, pero la cuestión de la custodia sigue siendo quién controla suficiente material de clave para firmar.

Cómo encajan claves, direcciones y firmas

Una billetera genera una clave privada, deriva una clave pública y luego deriva una o más direcciones a partir de esa clave pública. La clave privada firma un digest de transacción; la red verifica la firma contra la clave pública y comprueba que la dirección tenga saldo suficiente y un nonce válido. La frase semilla es una codificación de entropía a partir de la cual se deriva la clave privada, por lo que cualquiera que tenga la frase puede reconstruir la capacidad de firma.

La aplicación de billetera no necesita custodiar fondos. Guarda o accede al material de firma y construye transacciones. El estado de la cadena, como saldos, nonces, precios de gas y resultados de contratos, proviene de llamadas RPC. Esta separación es útil para depurar: si un saldo parece incorrecto, el problema suele ser el endpoint RPC o la red seleccionada, no la clave en sí.

// Derive an address from a private key using ethers v6
// npm install ethers
import { Wallet } from "ethers";

const privateKey = process.env.PRIVATE_KEY; // test key only
const wallet = new Wallet(privateKey);
console.log("address:", wallet.address);
console.log("publicKey:", wallet.signingKey.publicKey);

Por qué una billetera no custodial sigue dependiendo de RPC

Toda lectura y escritura contra una blockchain pasa por una interfaz de nodo, normalmente JSON-RPC. La billetera llama a métodos como eth_chainId, eth_getBalance, eth_getTransactionCount, eth_estimateGas y eth_sendRawTransaction. El nodo no necesita tu clave privada; recibe transacciones ya firmadas. Por eso un endpoint RPC comprometido puede informar mal del estado o censurar transacciones, pero no puede robar fondos directamente sin una firma.

Esta distinción importa al solucionar problemas. Una billetera que muestra un saldo cero en una red y un saldo correcto en otra probablemente apunta a una cadena distinta o a un endpoint desactualizado. Una transacción firmada que nunca se confirma puede haber sido rechazada por el endpoint, descartada del mempool o enviada con un nonce ya usado. Separar los fallos de firma de los fallos de transporte acorta el diagnóstico.

• Custodia de claves: local a la billetera, independiente del RPC.
• Estado de la cadena: suministrado por RPC, por lo que la calidad del endpoint afecta a la precisión y la latencia.
• Difusión: realizada por RPC, por lo que la política del endpoint afecta a la inclusión y los reintentos.
• Privacidad: el operador RPC puede ver tu dirección IP y las transacciones que consultas o difundes.

Requisitos previos para una comprobación reproducible de la billetera

Usa una billetera de prueba desechable y una red de prueba o una cuenta con poco valor. Necesitas una RPC_URL para la red que estás probando, una PRIVATE_KEY para la billetera de prueba y un terminal con curl más Node.js o Python. Nunca pegues una frase semilla o clave privada de producción en el historial de un shell, un entorno compartido o un sitio web de terceros.

Las comprobaciones siguientes son deliberadamente neutrales respecto al proveedor. Verifican que el endpoint informa de la cadena esperada, que la dirección derivada por la billetera coincide con la dirección financiada y que una transacción firmada puede difundirse y observarse. Si necesitas un endpoint gestionado en lugar de un nodo local, compara opciones mediante la guía de endpoints del RPC Assistant y el directorio de redes de OnFinality antes de decidir.

• RPC_URL: un endpoint HTTP JSON-RPC para la cadena de destino.
• PRIVATE_KEY: una clave solo para pruebas, cargada desde una variable de entorno.
• Un explorador de bloques o un segundo endpoint RPC para contrastar resultados.
• Una nota del chain ID esperado y de la dirección de billetera que esperas controlar.

Paso 1: Verificar el endpoint y la identidad de la cadena

Antes de firmar nada, confirma que el endpoint está en la cadena que esperas. El método eth_chainId devuelve un identificador de cadena hexadecimal. Compáralo con el chain ID documentado de la red y con el chain ID que muestra tu billetera. Una discrepancia es una causa habitual de comportamientos confusos de saldo y nonce, especialmente cuando una billetera tiene redes personalizadas configuradas.

El comando curl siguiente se puede ejecutar contra cualquier endpoint JSON-RPC compatible con EVM. Sustituye RPC_URL por tu endpoint. El resultado esperado es un objeto JSON con un campo result que contiene el chain ID en hexadecimal.

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}'

# Example response shape (value depends on the network):
# {"jsonrpc":"2.0","id":1,"result":"0x1"}

Paso 2: Confirmar la propiedad de la dirección y el estado del nonce

Deriva la dirección localmente a partir de la clave privada de prueba y luego consulta en el endpoint el saldo y el recuento de transacciones de esa dirección. El recuento de transacciones, o nonce, es el número de transacciones que la red ha aceptado de la dirección. Una billetera que muestra un nonce distinto del que informa el endpoint puede estar almacenando en caché el estado o consultando un endpoint diferente.

Ejecuta el fragmento de JavaScript siguiente con la misma RPC_URL y PRIVATE_KEY usadas en la comprobación con curl. El resultado de verificación esperado es que la dirección impresa coincida con la dirección que financiaste y que el nonce sea un entero no negativo coherente con el número de transacciones que has enviado desde esa dirección.

// npm install ethers
import { JsonRpcProvider, Wallet, formatEther } from "ethers";

const provider = new JsonRpcProvider(process.env.RPC_URL);
const wallet = new Wallet(process.env.PRIVATE_KEY, provider);

const [network, balance, nonce] = await Promise.all([
  provider.getNetwork(),
  provider.getBalance(wallet.address),
  provider.getTransactionCount(wallet.address)
]);

console.log("chainId:", network.chainId.toString());
console.log("address:", wallet.address);
console.log("balance:", formatEther(balance));
console.log("nonce:", nonce);

Paso 3: Firmar localmente, difundir por RPC y observar

El paso de firma debe ocurrir localmente. El paso de difusión envía la transacción sin procesar firmada al endpoint. Si el endpoint rechaza la transacción, el error suele identificar la causa: fondos insuficientes, nonce demasiado bajo, reemplazo con precio insuficiente o discrepancia de chain ID. Si el endpoint acepta la transacción, registra el hash de la transacción y consulta periódicamente el recibo.

El ejemplo de Python siguiente usa web3.py y una clave de prueba. Firma una transferencia de valor simple, envía la transacción sin procesar y espera un recibo. Sustituye el destinatario por una dirección que controles en la red de prueba. No ejecutes esto contra la red principal con una clave que contenga fondos reales.

# pip install web3
import os
from web3 import Web3

w3 = Web3(Web3.HTTPProvider(os.environ["RPC_URL"]))
account = w3.eth.account.from_key(os.environ["PRIVATE_KEY"])
recipient = os.environ["RECIPIENT_ADDRESS"]

nonce = w3.eth.get_transaction_count(account.address)
tx = {
    "to": recipient,
    "value": w3.to_wei(0.0001, "ether"),
    "gas": 21000,
    "maxFeePerGas": w3.to_wei(2, "gwei"),
    "maxPriorityFeePerGas": w3.to_wei(1, "gwei"),
    "nonce": nonce,
    "chainId": w3.eth.chain_id,
}

signed = account.sign_transaction(tx)
tx_hash = w3.eth.send_raw_transaction(signed.raw_transaction)
print("tx hash:", tx_hash.hex())
receipt = w3.eth.wait_for_transaction_receipt(tx_hash, timeout=120)
print("status:", receipt.status, "block:", receipt.blockNumber)

Resultados de verificación esperados y procedimiento con tabla de resultados

Una comprobación correcta produce un conjunto coherente de observaciones: el chain ID del endpoint coincide con la red esperada, la dirección derivada localmente coincide con la dirección financiada, el nonce es plausible, la transacción firmada se acepta y el estado del recibo es 1. Si alguno de estos valores no coincide, registra los valores antes de cambiar nada para poder comparar endpoints o reintentar con una configuración corregida.

Usa la tabla siguiente como plantilla. Rellénala con los valores que observes; no copies números de ejemplo. Ejecuta las mismas comprobaciones contra un segundo endpoint para distinguir errores de la billetera del comportamiento del endpoint.

• | Comprobación | Endpoint A | Endpoint B | Esperado |
• | eth_chainId | registrar el valor observado | registrar el valor observado | coincide con la documentación de la red |
• | Dirección derivada | registrar el valor observado | registrar el valor observado | coincide con la dirección financiada |
• | Nonce | registrar el valor observado | registrar el valor observado | coherente con las transacciones enviadas |
• | Resultado de la difusión | registrar el hash o el error | registrar el hash o el error | aceptada con un hash |
• | Estado del recibo | registrar el estado | registrar el estado | 1 para éxito |

Solución de fallos habituales en billeteras no custodiales

La mayoría de los fallos de billeteras se agrupan en unas pocas categorías. Un chain ID incorrecto o una configuración de red personalizada producen saldos ausentes y difusiones fallidas. Un nonce obsoleto produce errores de reemplazo o de precio insuficiente cuando una transacción anterior sigue pendiente. Un límite de tasa o una caída del endpoint producen tiempos de espera y lecturas incoherentes. Una frase semilla perdida o un keystore dañado son un problema de recuperación, no un problema de RPC, y ningún endpoint puede solucionarlo.

Diagnostica en ese orden: confirma la identidad de la cadena, confirma la derivación de la dirección, confirma el nonce y el saldo, y luego confirma la difusión y el recibo. Si la interfaz de la billetera no coincide con las llamadas RPC directas, puede que la billetera esté almacenando datos en caché o usando un endpoint distinto del que supones. Revisa la configuración de red de la billetera y cualquier RPC personalizado antes de concluir que faltan fondos.

• Discrepancia de chain ID: compara eth_chainId con el ID documentado de la red.
• Nonce demasiado bajo: una transacción anterior se minó; actualiza el nonce desde el endpoint.
• Reemplazo con precio insuficiente: aumenta la comisión solo si pretendes reemplazar una transacción pendiente.
• Fondos insuficientes: ten en cuenta los costes de gas, no solo el valor de la transferencia.
• Tiempos de espera o respuestas 429: el endpoint está limitando la tasa o no está disponible; reintenta con retroceso exponencial o usa otro endpoint.
• Frase semilla perdida: la autocustodia no tiene autoridad de recuperación; es una limitación permanente, no un error.

Limitaciones, compromisos y supuestos de recuperación

La autocustodia elimina el riesgo de contraparte de la plataforma, pero concentra el riesgo operativo en el usuario. La pérdida de la frase semilla, el compromiso del dispositivo, el phishing y la manipulación de firmas son modos de fallo reales. Una billetera no custodial no puede revertir una transacción firmada, y ningún servicio de soporte puede restaurar una clave perdida. Las billeteras hardware y las configuraciones multifirma o MPC pueden reducir el riesgo de punto único, pero añaden complejidad de configuración y sus propios procedimientos de recuperación.

La dependencia de RPC es un compromiso aparte. Un endpoint público puede tener límites de tasa, ser incoherente o invadir la privacidad. Un nodo dedicado o un servicio RPC gestionado puede mejorar la fiabilidad y la previsibilidad, pero no cambia la custodia de claves. Al evaluar infraestructura, separa la cuestión de quién guarda las claves de la cuestión de quién sirve los datos de la cadena. Para orientación sobre endpoints según la carga de trabajo, consulta las notas del RPC Assistant sobre endpoints fiables de Ethereum y selección de endpoints multicadena.

• Riesgo de clave: pérdida, robo o coacción relacionados con el material de firma.
• Riesgo de transporte: estado inexacto, censura o caídas en la capa RPC.
• Riesgo de recuperación: ninguna autoridad central para restablecer credenciales o restaurar fondos.
• Riesgo de privacidad: el operador RPC puede correlacionar direcciones, direcciones IP y tiempos.

Próximos pasos: reforzar la configuración y elegir la infraestructura con criterio

Una vez superadas las comprobaciones de verificación, pasa de una billetera de prueba a una configuración reforzada: un firmante hardware para saldos significativos, una copia de seguridad de la semilla documentada y almacenada sin conexión, y un procedimiento de recuperación escrito que hayas probado con una cantidad pequeña. Mantén separadas las responsabilidades de firma y de RPC en tu modelo mental y en tus herramientas.

En cuanto a infraestructura, empieza por el directorio de redes de OnFinality para identificar las cadenas compatibles y luego revisa los precios de RPC y las opciones de nodo dedicado si necesitas un rendimiento predecible. Si eliges un proveedor para una cadena concreta, usa la guía del RPC Assistant en lugar de adivinar a partir de páginas de marketing. El objetivo es una configuración en la que la custodia de claves sea verificable y el comportamiento del endpoint sea medible.

• Vuelve a ejecutar las comprobaciones de chain ID, dirección, nonce y difusión tras cualquier cambio de billetera o de red.
• Registra el comportamiento del endpoint a lo largo del tiempo en lugar de confiar en una sola prueba.
• Mantén las claves de prueba y de producción en entornos separados.
• Revisa las guías de endpoints del RPC Assistant para recomendaciones específicas de cada cadena.