Monedero cripto no custodial: gestión de claves, dependencias RPC y flujos de verificación

Respuesta directa y alcance

Un monedero no custodial es un monedero cripto en el que las claves privadas se generan y almacenan en infraestructura que controla el usuario, normalmente un dispositivo móvil, una extensión de navegador o un dispositivo hardware. El monedero firma las transacciones localmente y solo envía cargas firmadas a la red. Ninguna empresa posee el material de claves, por lo que ninguna empresa puede mover, congelar o recuperar fondos en nombre del usuario.

Este artículo cubre los mecanismos técnicos que importan cuando se construye, integra o audita flujos de monederos no custodiales: derivación de claves, firma local, dependencias RPC y procedimientos de verificación. No clasifica marcas de monederos. Si necesitas una recomendación concreta de endpoint RPC para una cadena específica, utiliza el Asistente RPC en lugar de tratar esta página como una lista de proveedores.

• En alcance: modelo de custodia de claves, flujo de firma, llamadas RPC que realiza un monedero, comprobaciones reproducibles.
• Fuera de alcance: comparativas de marcas, comentarios sobre precios de tokens y asesoramiento legal sobre autocustodia.
• Suposición: dispones de una dirección de monedero, acceso a un endpoint RPC y herramientas básicas de línea de comandos.

Modelo de custodia custodial frente a no custodial

La línea divisoria es quién controla la clave privada. En un modelo custodial, un exchange o una aplicación posee la clave y firma en tu nombre; tu saldo es un asiento en el libro contable de ese proveedor hasta que retiras on-chain. En un modelo no custodial, la clave existe solo en tu dispositivo o módulo hardware, y el proveedor nunca la ve.

Esta diferencia tiene consecuencias operativas. Un proveedor custodial puede restablecer tu contraseña, congelar retiros o perder fondos en un fallo de la plataforma. Un monedero no custodial no puede hacer nada de eso, pero tampoco puede restaurar el acceso si pierdes tu frase de recuperación. El intercambio es comodidad y un servicio de soporte frente a la responsabilidad exclusiva de la copia de seguridad.

• Custodial: el proveedor posee las claves, firma transacciones y controla el momento de los retiros.
• No custodial: el usuario posee las claves, firma localmente y controla la copia de seguridad y la recuperación.
• Híbrido: los monederos MPC o de cuenta inteligente dividen la autoridad de firma, pero el material de claves sigue sin estar en manos exclusivas de una plataforma.

Cómo un monedero no custodial deriva y almacena claves

La mayoría de los monederos no custodiales siguen una jerarquía determinista. Una frase de recuperación, normalmente de 12 o 24 palabras, codifica una semilla. A partir de esa semilla, el monedero deriva una clave maestra y luego claves por cuenta a lo largo de una ruta de derivación. Para cadenas EVM la ruta común es m/44'/60'/0'/0/0; Bitcoin y Solana usan tipos de moneda y convenciones de ruta diferentes.

La clave privada nunca sale del entorno de firma. En un monedero software se cifra en reposo en el dispositivo y solo se descifra para firmar. En un monedero hardware permanece dentro de un elemento seguro, y el ordenador anfitrión envía una carga sin firmar para que el dispositivo la firme tras la confirmación física. La frase de recuperación es la copia de seguridad de la semilla, no una contraseña, y cualquiera que la obtenga puede reconstruir todas las claves derivadas.

• Frase semilla → clave maestra → ruta de derivación → clave privada de cuenta → dirección pública.
• Los monederos software cifran las claves localmente; los monederos hardware aíslan las claves en un chip seguro.
• La frase de recuperación equivale a todas las claves privadas derivadas y nunca debe introducirse en un sitio web.

Qué le pide el monedero a un endpoint RPC

Un monedero no custodial no es un nodo. Lee el estado de la cadena y difunde transacciones a través de un endpoint RPC. El endpoint ve tu dirección pública y las transacciones firmadas, pero nunca ve tu clave privada. Esa separación es lo que hace que el RPC remoto sea compatible con la autocustodia.

Las llamadas típicas incluyen consultas de saldo, búsquedas de nonce, estimación de comisiones, comprobaciones de chain ID y envío de transacciones. Si el endpoint está desactualizado o limitado en tasa, el monedero puede mostrar un saldo incorrecto, reutilizar un nonce o no difundir la transacción. Elegir un endpoint fiable es, por tanto, parte de la fiabilidad del monedero, no una ocurrencia tardía. Consulta la guía de endpoints RPC multicadena para el modelo general y la guía de endpoints RPC para patrones de configuración.

• Llamadas de lectura: saldo, nonce, chain ID, historial de comisiones, estado de contratos.
• Ruta de escritura: transacción sin procesar firmada localmente y enviada mediante eth_sendRawTransaction o el equivalente de la cadena.
• Modos de fallo: nonce obsoleto, chain ID incorrecto, limitación de tasa y transacciones descartadas.

Requisitos previos para el procedimiento de verificación

Las comprobaciones siguientes suponen una cadena compatible con EVM y un endpoint JSON-RPC. Sustituye RPC_URL por un endpoint que controles o un endpoint de proveedor que estés evaluando. Nunca pegues una clave privada real en el historial de un shell compartido; usa una variable de entorno y una clave de prueba desechable para los experimentos de firma.

Necesitas curl para las llamadas de lectura y Node.js con ethers o Python con web3.py para la firma. Los procedimientos son de solo lectura hasta la sección de firma, que usa una clave de prueba y no difunde nada.

export RPC_URL="https://your-endpoint.example"
export WALLET_ADDRESS="0xYourPublicAddress"
export PRIVATE_KEY="0xYourThrowawayTestKey"

Comprobación de la identidad de la cadena y el saldo mediante RPC

Antes de confiar en cualquier visualización de saldo, confirma que el endpoint está en la cadena que esperas. Un monedero apuntado a un chain ID incorrecto puede mostrar un saldo cero o enviar una transacción que otra red rechace. Las dos llamadas siguientes devuelven el chain ID y el saldo de la cuenta en wei.

Registra las salidas en una tabla de resultados junto con el endpoint, la marca de tiempo y el número de bloque. No asumas valores; mide. Una tabla sencilla con columnas para endpoint, chain ID, número de bloque, saldo en wei y latencia observada hace que las comparaciones de endpoints sean reproducibles.

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

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

Verificación del estado del nonce antes de firmar

El nonce de la cuenta es el recuento de transacciones enviadas desde una dirección. Un monedero que firma con un nonce obsoleto producirá una transacción que no podrá incluirse hasta que se mine el nonce anterior. Consulta tanto el nonce más reciente como el pendiente para ver si el endpoint tiene visibilidad de las transacciones en cola.

Si pending es igual a latest, no hay transacciones en cola desde esa dirección en la vista del mempool del endpoint. Si pending es mayor, una transacción anterior sigue pendiente. Esta distinción importa cuando un usuario reintenta una transacción atascada; reemplazarla requiere el mismo nonce con una comisión mayor, no un nonce nuevo.

curl -s -X POST "$RPC_URL" \
  -H "Content-Type: application/json" \
  -d "{\"jsonrpc\":\"2.0\",\"id\":3,\"method\":\"eth_getTransactionCount\",\"params\":[\"$WALLET_ADDRESS\",\"latest\"]}"

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

Demostración de firma local sin difusión

La propiedad central de un monedero no custodial es que la firma ocurre localmente. Puedes demostrarlo construyendo y firmando una transacción en tu propio proceso, y luego inspeccionando la carga sin procesar firmada. Ningún material de claves se envía al endpoint RPC; solo se difundiría la cadena hexadecimal resultante.

El ejemplo de Node.js siguiente usa ethers para firmar una transacción sin conexión. Ejecútalo con una clave desechable y un chain ID que coincida con tu endpoint. La salida es una transacción sin procesar firmada que puedes decodificar o descartar. El ejemplo de Python realiza la misma operación con web3.py.

// npm install ethers
const { Wallet } = require("ethers");

async function main() {
  const wallet = new Wallet(process.env.PRIVATE_KEY);
  const tx = {
    to: process.env.WALLET_ADDRESS,
    value: 0n,
    nonce: 0,
    gasLimit: 21000n,
    maxFeePerGas: 1000000000n,
    maxPriorityFeePerGas: 1000000000n,
    chainId: 1,
    type: 2
  };
  const signed = await wallet.signTransaction(tx);
  console.log("from:", wallet.address);
  console.log("signed raw tx:", signed);
}

main().catch(console.error);

Resultados esperados de la verificación

Una configuración no custodial correctamente configurada debería producir resultados coherentes en todas las comprobaciones. Usa la tabla siguiente como plantilla y rellénala con tus propias mediciones en lugar de valores supuestos.

Si la carga firmada se produce localmente y el endpoint solo recibe la transacción sin procesar, el flujo del monedero es no custodial con respecto al material de claves. Si cualquier paso requiere enviar la clave privada o la semilla a un servidor, el flujo es custodial independientemente del lenguaje de marketing.

Solución de problemas comunes de monederos no custodiales

La mayoría de los fallos de monederos son problemas de infraestructura o de estado, no de claves. Un saldo que no se actualiza suele significar que el endpoint está limitado en tasa o retrasado respecto a la cabeza de la cadena. Una transacción que nunca se confirma suele significar que el nonce está obsoleto o que la comisión está por debajo de la comisión base actual. Un monedero que muestra la red incorrecta suele tener un desajuste de chain ID entre la configuración de la aplicación y el endpoint.

Para transacciones atascadas, consulta el nonce pendiente y reenvía con el mismo nonce y una comisión de prioridad mayor. Para discrepancias de saldo, compara dos endpoints independientes a la misma altura de bloque. Para errores de firma, confirma la ruta de derivación y que la clave corresponde a la dirección que esperas. Si operas tu propio nodo, la guía de alojamiento de nodos blockchain cubre la sincronización y las comprobaciones de estado que afectan a la fiabilidad del monedero.

• Saldo obsoleto: compara endpoints a un número de bloque fijo.
• Transacción atascada: reutiliza el nonce con comisiones más altas.
• Red incorrecta: verifica el chain ID tanto en la configuración del monedero como en la respuesta del endpoint.
• Fallo de firma: comprueba la ruta de derivación y la correspondencia clave-dirección.

Limitaciones, compensaciones y próximos pasos

Los monederos no custodiales eliminan el riesgo de contraparte pero concentran el riesgo operativo en el usuario. Las frases de recuperación perdidas son irrecuperables, los sitios de phishing se dirigen a la introducción de semillas y las aprobaciones maliciosas de tokens pueden vaciar fondos incluso cuando las claves permanecen locales. Los monederos hardware y la simulación de transacciones reducen estos riesgos, pero no los eliminan.

La dependencia de RPC es la otra compensación. Un monedero de autocustodia sigue confiando en un endpoint para datos de la cadena y propagación. Para integraciones en producción, evalúa la fiabilidad del endpoint, los límites de tasa y la cobertura de cadenas antes de comprometerte. Puedes comparar planes en la página de precios de RPC, revisar las redes compatibles o explorar opciones de nodos dedicados para cargas de trabajo que necesitan un rendimiento constante. Para una elección concreta de endpoint por cadena, consulta el Asistente RPC.

• Haz una copia de seguridad de la frase de recuperación sin conexión y verifícala antes de depositar fondos.
• Simula o decodifica las transacciones antes de firmar contratos desconocidos.
• Prueba la conmutación por error de endpoints para que la caída de un solo proveedor no bloquee la firma y la difusión.
• Revisa /en/learn para fundamentos relacionados de monederos y RPC antes del despliegue en producción.