¿Qué es una billetera no custodial? Control de claves, firma y verificación

Definición y alcance de una billetera no custodial

Una billetera no custodial, también llamada billetera de autocustodia, es software o hardware en el que las claves privadas que controlan una dirección se crean y almacenan bajo el control del usuario. La billetera no contiene monedas; contiene la capacidad de autorizar cambios de estado en una blockchain. Quien pueda producir una firma válida para una dirección controla los activos en esa dirección.

Este artículo cubre la mecánica técnica de ese control: generación de claves, derivación de direcciones, firma de transacciones, transmisión a través de un endpoint RPC y recuperación a partir de una frase semilla. No recomienda una marca específica de billetera. El objetivo es darte un modelo mental que puedas probar, además de un procedimiento que puedas ejecutar contra cualquier cadena compatible con EVM y proveedor RPC.

• No custodial significa claves en manos del usuario, no tokens en manos del usuario.
• La billetera es un cliente; la blockchain es la fuente de verdad.
• Un endpoint RPC retransmite transacciones firmadas, pero nunca debería necesitar tu clave privada.

Supuestos y requisitos previos para el procedimiento de verificación

Los ejemplos a continuación asumen una red compatible con EVM, Node.js 18 o posterior y una cuenta de prueba financiada en una testnet. Necesitas una RPC_URL para la cadena de destino; obtén una desde el panel de tu proveedor o desde el servicio API de OnFinality. Nunca uses una clave privada de mainnet en un script de tutorial.

También necesitas una comprensión básica de cómo se estructuran las transacciones. Si los conceptos de nonce, gas y chain ID no te resultan familiares, lee la explicación de nonce en blockchain y la guía de endpoints RPC antes de continuar.

• Node.js 18+ y npm para el ejemplo de firma.
• curl para las comprobaciones JSON-RPC sin procesar.
• Una cuenta de testnet con un saldo pequeño y su clave privada almacenada en una variable de entorno, no en el código fuente.

En qué se diferencia el control de claves del acceso a cuentas custodiales

En un modelo custodial, una plataforma posee las claves y tú posees un inicio de sesión. Cuando solicitas un retiro, la plataforma firma con su propia clave. Tu acceso puede suspenderse, limitarse en frecuencia o perderse si la plataforma falla. En un modelo no custodial, tú posees la clave y la plataforma, si existe, solo proporciona conectividad.

La diferencia práctica aparece en el momento de la firma. Una billetera no custodial construye la carga útil de la transacción localmente, la firma con la clave privada y envía solo los bytes firmados a un endpoint RPC. El endpoint puede ver la transacción y puede registrarla, pero no puede alterar la firma ni mover fondos sin la clave.

• Custodial: la plataforma firma; tú te autenticas.
• No custodial: tú firmas; la red verifica.
• Los proveedores RPC en un flujo no custodial son transporte, no custodios.

El proceso de firma desde la frase semilla hasta la transmisión

Una billetera no custodial sigue un proceso determinista. Una frase semilla se expande en una clave maestra, a partir de la cual se derivan las claves de cuenta y las direcciones. La billetera construye una transacción con el nonce, chain ID, parámetros de gas, destinatario y valor correctos. Hashea y firma esa carga útil localmente, luego llama a eth_sendRawTransaction en un endpoint RPC.

El endpoint valida el formato de la transacción, la reenvía a la red y devuelve un hash de transacción. La confirmación es un paso separado: la billetera consulta eth_getTransactionReceipt hasta que un bloque incluya la transacción. En ningún momento el endpoint recibe la clave privada.

const { ethers } = require("ethers");

async function signAndBroadcast() {
  const provider = new ethers.JsonRpcProvider(process.env.RPC_URL);
  const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);

  const tx = {
    to: process.env.RECIPIENT,
    value: ethers.parseEther("0.001"),
    chainId: Number(process.env.CHAIN_ID)
  };

  const signed = await wallet.signTransaction(tx);
  console.log("Signed locally. First 20 bytes:", signed.slice(0, 42));

  const response = await provider.broadcastTransaction(signed);
  console.log("Broadcast hash:", response.hash);

  const receipt = await response.wait();
  console.log("Included in block:", receipt.blockNumber);
}

signAndBroadcast().catch(console.error);

Comprobación ejecutable de que el endpoint RPC nunca recibe tu clave

Puedes confirmar la separación de funciones con dos llamadas curl. La primera solicita al endpoint el nonce actual de tu dirección; la segunda envía una transacción sin procesar previamente firmada. Ninguna llamada incluye una clave privada. Si un proveedor alguna vez solicita una clave privada para enviar una transacción, eso es un patrón custodial y debe tratarse como una señal de alerta.

Ejecuta primero la consulta de nonce, luego firma sin conexión con el script anterior y después envía la transacción sin procesar. Reemplaza los marcadores de posición con tus propios valores.

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

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

Resultados esperados de la verificación y cómo interpretarlos

Un flujo no custodial correcto produce tres resultados observables. La consulta de nonce devuelve un recuento hexadecimal para tu dirección. El script de firma imprime una carga útil firmada sin contactar la red para obtener material de claves. La llamada de transmisión devuelve un hash de transacción, y una consulta de recibo posterior devuelve un número de bloque y un estado.

Registra cada resultado en una tabla para poder comparar proveedores o reintentar tras un fallo. No rellenes valores que no hayas observado; la tabla es una plantilla de medición, no una afirmación sobre ningún proveedor.

• Resultado del nonce: cadena hexadecimal de eth_getTransactionCount.
• Carga útil firmada: salida local de signTransaction, sin dependencia de red.
• Resultado de transmisión: hash de transacción de eth_sendRawTransaction.
• Resultado del recibo: número de bloque y estado de eth_getTransactionReceipt.

Procedimiento de tabla de resultados para comparar el comportamiento de RPC

Cuando pruebes más de un endpoint RPC, mantén la transacción firmada constante y cambia solo RPC_URL. Esto aísla el comportamiento del transporte del comportamiento de firma. Rellena la tabla solo con valores observados.

Si una transmisión tiene éxito pero el recibo nunca aparece, la transacción puede estar pendiente, descartada o rechazada por la red. Verifica el hash en un explorador de bloques antes de asumir que el endpoint está defectuoso. Para cargas de trabajo en producción, compara opciones de nodos dedicados y revisa los precios de RPC para que los límites de frecuencia no se confundan con fallos de la billetera.

Solución de problemas comunes de billeteras no custodiales

La mayoría de los problemas de billeteras no custodiales se dividen en cuatro categorías: manejo de claves, construcción de transacciones, conectividad del endpoint y estado de la red. Sepáralos antes de cambiar nada.

Si la firma falla, la clave o la ruta de derivación es incorrecta. Si la transmisión falla con un error de nonce, hay otra transacción de la misma dirección pendiente. Si el endpoint se agota, la billetera no puede alcanzar la red pero tus claves no se ven afectadas. Si falta el recibo, la transacción puede tener fondos insuficientes para el gas o haber sido descartada del mempool.

• Nonce demasiado bajo: espera la transacción pendiente o reemplázala.
• Fondos insuficientes: verifica el saldo y el precio del gas por separado.
• Chain ID incorrecto: confirma que la red de la billetera coincide con RPC_URL.
• Frase semilla rechazada: verifica el orden de las palabras y el idioma antes de reintentar.

Límites de recuperación y el equilibrio de responsabilidad

Una frase semilla es una copia de seguridad del material de claves, no un servicio de recuperación de cuentas. Si se pierde la frase y el dispositivo falla, los fondos son irrecuperables. Si la frase se expone, cualquiera puede firmar. Este es el equilibrio central de la autocustodia: eliminas el riesgo de la plataforma y aceptas el riesgo operativo.

Las billeteras no custodiales también dependen de la infraestructura. Una billetera puede firmar sin conexión, pero necesita un endpoint RPC para leer saldos y transmitir. Elegir un endpoint confiable es, por lo tanto, parte de las operaciones de autocustodia, no una preocupación separada. Revisa la cobertura de red y las opciones de nodos dedicados cuando pases de las pruebas a producción.

Próximos pasos para operaciones de autocustodia seguras

Comienza en una testnet, ejecuta el procedimiento de firma y transmisión, y registra la tabla de resultados. Luego pasa a cantidades pequeñas en mainnet con un firmante de hardware si es posible. Mantén la clave privada fuera del historial del shell y del control de código fuente, y rota las claves de prueba después de cada ejercicio.

Para la selección de endpoints, utiliza la guía del RPC Assistant sobre los mejores proveedores RPC para proyectos Web3 y la guía de endpoints RPC multicadena. Si necesitas un rendimiento predecible, compara las ofertas de nodos dedicados y los precios antes de comprometer un flujo de billetera en producción.

• Prueba la firma y la transmisión en una testnet primero.
• Almacena las frases semilla sin conexión y nunca las introduzcas en un sitio web.
• Monitorea la salud del endpoint por separado del software de la billetera.