👛 Wallets desde cero: uso, seguridad y recuperación

Nivel: Inicial · ⏱️ Duración estimada: 120 min · Fuente: BIP-32/39/44, documentación oficial de Ethereum (ethereum.org), EIP-1193/6963/712/2612 y ERC-4337 ⬅️ Volver al programa · 📚 Currículo · 📚 Bibliografía 🧭 Guía complementaria — reúne en un solo lugar el contenido de wallets integrado en las clases 4, 9–11, 16, 53–54 y 59–60. No es una clase, subclase ni etapa adicional. 📖 Glosario de términos · 🌱 ¿Nuevo en esto? Empieza aquí

🎯 Para quién es esta unidad y qué necesitas antes

Esta unidad es la puerta de entrada práctica al uso de una wallet (billetera o cartera digital) para una persona sin experiencia. Enseña qué es, cómo se usa con seguridad y qué hacer cuando algo sale mal: perder el teléfono, exponer una credencial o firmar algo que no debías.

Prerrequisitos: haber leído Clases 3–4 · Criptografía (qué es una clave y una firma) y Clases 9–10 · Bitcoin (qué es una transacción y una dirección). No hace falta conocer Ethereum: esta unidad se puede recorrer completa antes de las clases 11–12.

⚠️ Regla innegociable de toda la unidad: ningún ejercicio usa fondos reales, ninguna actividad te pedirá una seed phrase real ni una clave privada, y ningún material de este repositorio debe contener secretos. Una testnet reduce el riesgo económico, pero no es un entorno libre de riesgos: el phishing, el malware y los malos hábitos funcionan igual en red de prueba.

🎯 Objetivos

• Explicar qué administra realmente una wallet (claves, cuentas y autorizaciones) y por qué los activos no "están dentro".
• Distinguir clave privada, clave pública, dirección, cuenta, seed phrase (frase semilla) y ruta de derivación.
• Comparar tipos de wallet (custodial, autocustodia; caliente, templada, fría; software, hardware, watch-only, multisig, MPC, cuenta inteligente) y elegir según el uso.
• Ejecutar el ciclo completo: crear, respaldar, verificar la recuperación, recibir, enviar, conectar con una dApp, revisar una firma, desconectar y revocar permisos.
• Diferenciar conectar, iniciar sesión con firma, firmar un mensaje, firmar datos estructurados (EIP-712), aprobar tokens (approve/permit) y enviar una transacción.
• Detectar las estafas y errores más comunes (phishing, drainers, blind signing, approvals ilimitados, address poisoning) y aplicar prevención, detección y respuesta.
• Diseñar un respaldo y un procedimiento de recuperación, y ensayarlo como simulación de escritorio.
• Explicar las diferencias básicas entre una wallet Bitcoin y una wallet EVM.

✅ Resultados de aprendizaje

Al terminar puedes, con evidencia:

1. Dibujar el flujo usuario → wallet → firma → nodo/RPC → blockchain y explicar qué viaja en cada tramo.
2. Ejecutar pnpm lab:wallet-segura y justificar el veredicto de cada escenario, control por control.
3. Redactar tu propia matriz de emergencia (¿perdí el teléfono?, ¿revelé la seed?) con acciones concretas.
4. Superar la autoevaluación de la unidad con al menos un 80 %.

🧠 Modelo mental: la wallet es un llavero, no un monedero

Una wallet no guarda monedas. Los activos son anotaciones en el registro compartido (la blockchain); lo que la wallet guarda y administra son las claves que autorizan moverlos. La analogía útil no es un monedero: es un llavero con un dispositivo de firma.

• La blockchain es el registro de la propiedad (como el conservador de bienes raíces).
• La dirección es tu identificador en ese registro (como el rol de la propiedad).
• La clave privada es la llave que autoriza cambios en tu asiento del registro.
• La wallet es el llavero que guarda las llaves, te muestra el registro y construye y firma las órdenes.

Límites de la analogía: un llavero perdido se repone en una cerrajería; una clave privada perdida sin respaldo no se repone, y una llave copiada por un tercero le da control total sin que la cerradura "se dé cuenta". Además, la wallet también muestra información (saldos, historial) que obtiene preguntando a un nodo: si el nodo miente o la interfaz está comprometida, lo que ves puede no ser lo que firmas.

🧩 Esquema visual: qué pasa cuando "envías"

flowchart LR
    U["👤 Usuario<br>decide: a quién, cuánto"] --> W["👛 Wallet<br>construye la transacción<br>y muestra qué se firmará"]
    W --> F["✍️ Firma<br>con la clave privada<br>(local: la clave no sale)"]
    F --> N["📡 Nodo / RPC<br>recibe la transacción firmada<br>y la propaga"]
    N --> B["⛓️ Blockchain<br>la incluye en un bloque:<br>el registro cambia"]
    B -.->|"saldos e historial"| W

La clave privada nunca viaja: lo que viaja es la transacción firmada. Y el punto donde el usuario puede evitar casi todos los desastres es uno solo: la pantalla de revisión antes de firmar. A entrenar esa revisión se dedica el laboratorio.

🔬 Anatomía de una wallet

⚖️ Custodia frente a autocustodia

• Custodial: un tercero (por ejemplo, un exchange) guarda las claves; tú tienes una cuenta de usuario y un derecho contractual contra ese tercero. Recuperar la contraseña es fácil; el riesgo es la insolvencia, el bloqueo o el fraude del custodio (caso real: FTX y la custodia).
• Autocustodia: tú guardas las claves. Nadie puede bloquearte ni "prestarse" tus fondos, y nadie puede rescatarte si pierdes el respaldo. La responsabilidad operacional completa es tuya.

Ninguna es "la buena": son perfiles de riesgo distintos. La versión institucional de esta decisión (multisig, MPC, HSM, segregación, gobierno de claves) es el clases 53–54.

🌡️ Caliente, templada y fría

🗂️ Tabla comparativa de tipos de wallet

Sin marcas: lo que importa es el modelo de control de la clave. Si algún material externo usa productos concretos, son solo ejemplos; verifica su documentación oficial.

Nota: no todas las wallets usan una seed phrase tradicional. Las MPC y varias cuentas inteligentes se respaldan con otros mecanismos (fragmentos, guardianes, passkeys). Antes de usar una, entiende cuál es su respaldo real.

🔶 Wallet Bitcoin frente a wallet EVM

La consecuencia práctica: en Bitcoin el error típico es de comisiones o de formato de dirección; en EVM se suman los errores de red equivocada, token falso y aprobaciones, porque la wallet firma cosas más expresivas.

🔁 Ciclo completo de utilización

El orden importa: el respaldo se verifica antes de recibir nada.

1. Elegir el tipo según la tabla anterior y el monto en juego. Para este programa: una wallet de navegador solo para testnet.
2. Crear la wallet en el dispositivo, sin nadie mirando la pantalla (tampoco en videollamada).
3. Respaldar la seed phrase en papel o metal, a mano. Nunca: foto, captura, correo, nube, gestor de notas, chat.
4. Verificar la recuperación: restaura la wallet desde el respaldo en un entorno limpio antes de que custodie nada. Un respaldo no verificado es una esperanza, no un respaldo.
5. Recibir: comparte tu dirección, verifica con una cantidad pequeña, confirma que llegó.
6. Enviar: aplica el prevuelo completo antes de firmar.
7. Conectar una dApp: conectar ≠ autorizar movimientos; revisa qué cuenta y qué red expones. El detalle técnico (EIP-1193, EIP-6963, viem) está en las clases 15–16.
8. Revisar cada firma: qué tipo de solicitud es (sección siguiente) y qué efecto puede tener.
9. Desconectar la dApp al terminar la sesión.
10. Revocar permisos periódicamente: las aprobaciones de tokens sobreviven a la desconexión y siguen vigentes hasta que las revocas con otra transacción.
11. Rotar o retirar una wallet: si sospechas exposición, crea una nueva y migra los fondos; una seed comprometida no "se limpia".

⛽ Gas, comisiones y redes

• Toda transacción paga una comisión al procesador (minero/validador): en Bitcoin proporcional al tamaño en bytes; en EVM, gas usado × precio del gas.
• La comisión se paga siempre en el activo nativo de la red. Es el motivo por el que puedes "tener tokens" y aun así no poder moverlos.
• El nonce (EVM) ordena tus transacciones: una atascada por comisión baja bloquea a las siguientes; se reemplaza reenviando el mismo nonce con más comisión.
• La red es parte de la dirección en la práctica: la misma 0x… en otra red EVM es otra cuenta a efectos de saldo. Enviar por la red equivocada puede ser recuperable (si controlas la clave en la otra red) o no serlo (si el destino es un contrato o un custodio que no opera esa red).

✍️ Firmas y autorizaciones: qué te puede pedir una dApp

De menor a mayor capacidad de hacer daño:

La trampa recurrente: una "simple firma" puede tener efectos económicos. Si la wallet no puede mostrarte en claro qué autoriza una firma (blind signing), la respuesta segura es no firmar.

💾 Respaldo y recuperación

• El respaldo maestro (seed phrase o equivalente) va fuera de línea, en al menos dos ubicaciones físicas separadas, protegido de agua y fuego.
• Nadie legítimo te pedirá jamás la seed: ni "soporte técnico", ni una dApp, ni este programa, ni una IA. Quien la pide, roba.
• Verifica la recuperación con un ensayo real (restaurar en limpio) mientras la wallet aún no custodia nada, y ensaya en seco (tabletop) los escenarios de la matriz de emergencia: qué harías, en qué orden, con qué a mano.
• Al heredar o compartir custodia, considera multisig antes que fotocopiar semillas.

🧭 Separación recomendada de wallets

Una firma comprometida en la wallet de aprendizaje no debe poder tocar el ahorro: eso solo se cumple si son claves distintas, no cuentas de la misma semilla.

🛡️ Matriz de amenazas y controles

Para cada amenaza: cómo se previene, cómo se detecta, cómo se responde.

🚨 Matriz de emergencia

Qué hacer en los primeros minutos. Honestidad primero: hay casos sin recuperación posible; prometer otra cosa sería engañar.

🧪 Laboratorio guiado: prevuelo de una transacción

Como un piloto antes de despegar, no firmas nada sin recorrer la lista completa. El laboratorio te entrega tres solicitudes de firma simuladas (datos deterministas, direcciones ficticias, cero red) y las contrasta contra lo que el usuario esperaba firmar:

pnpm lab:wallet-segura

La lista de controles que ejecuta —y que debes poder aplicar a mano— es:

1. Red — ¿es la red en la que crees estar?
2. Origen — ¿firma la cuenta que corresponde (la de aprendizaje, no la de ahorro)?
3. Destino — ¿coincide la dirección completa con la verificada?
4. Contrato — ¿es el contrato oficial del protocolo/token?
5. Función y argumentos — ¿transfer? ¿approve? ¿a quién y cuánto?
6. Token, monto y decimales — ¿el monto humano coincide, con los decimales correctos?
7. Gas / comisión — ¿la comisión máxima está dentro de tu tope?
8. Aprobación — si la hay, ¿es acotada al monto necesario o ilimitada?
9. Efecto esperado — ¿puedes describir en una frase qué pasará si firmas?

• Escenario 1 es una transferencia legítima: todos los controles en verde → FIRMAR.
• Escenario 2 es un approve ilimitado hacia un contrato desconocido → NO FIRMAR.
• Escenario 3 es una dirección envenenada (mismo principio y final, otro cuerpo) → NO FIRMAR.

Criterio de aceptación: las pruebas automatizadas pasan (node --test labs/00-wallets/prevuelo-transaccion.test.mjs) y puedes explicar, para los escenarios 2 y 3, qué control falló y qué ataque representa. La resolución explicada está en el cuaderno de laboratorios.

Ejercicio de recuperación (simulación de escritorio)

Sin wallet real y sin secretos: es un tabletop exercise. Toma la matriz de emergencia y, para dos escenarios que elijas, escribe tu procedimiento personal: qué harías en los primeros 10 minutos, qué necesitas tener preparado desde antes (respaldo verificado, lista de aprobaciones, dirección de la wallet nueva) y qué es irrecuperable en tu plan actual. Si necesitas material de ejemplo, usa exclusivamente los vectores de prueba oficiales de BIP-39 (trezor/python-mnemonic), que son públicos y no custodian nada — jamás una semilla tuya.

🏁 Reto verificable

Extiende labs/00-wallets/prevuelo-transaccion.mjs con un cuarto escenario: una firma permit (EIP-2612) donde el spender no es el contrato que el usuario cree y el plazo (deadline) es de años. Añade el control que lo detecte y su prueba en prevuelo-transaccion.test.mjs.

Criterio de aceptación: pnpm test sigue en verde con tu prueba nueva incluida, y el escenario 4 termina en NO FIRMAR con un detalle que explique el riesgo.

⚠️ Errores frecuentes

🛡️ Seguridad y ética

• Nunca pidas, aceptes ni custodies la seed o clave de otra persona "para ayudar".
• No atribuyas identidad real a una dirección: una dirección no es una persona.
• Los ejercicios ofensivos de este programa (phishing, drainers) se estudian para defender, en material propio y simulado; probarlos contra terceros es delito.
• Esta unidad no es asesoría financiera y no recomienda productos ni proveedores.

🧠 Autoevaluación

Aprobación: 80 % (12 de 15). Cada respuesta está plegada con su explicación: puntúa 1 por acierto, 0 por fallo; multiplica tu total por 100/15 para la nota 0–100. Las preguntas 12–15 son escenarios: valen igual, pero si fallas una, vuelve a la matriz de amenazas antes de seguir.

1. ¿Qué guarda realmente una wallet?
   Respuesta

   Claves (y los metadatos para usarlas: cuentas, direcciones, historial). Los activos viven en el registro de la blockchain; la wallet administra la capacidad de autorizarlos. Si respondiste "las monedas", relee el modelo mental.
2. ¿Cuál es la diferencia entre dirección y clave pública?
   Respuesta

   La dirección se deriva de la clave pública (por hash o codificación) y es el identificador que compartes; la clave pública verifica firmas. Ninguna de las dos permite gastar.
3. ¿Qué diferencia a una wallet custodial de una de autocustodia?
   Respuesta

   Quién controla la clave. En la custodial tienes un derecho contra un tercero (y su riesgo de contraparte); en autocustodia tienes la clave y toda la responsabilidad del respaldo.
4. ¿Toda wallet tiene una seed phrase?
   Respuesta

   No. MPC reparte fragmentos sin que la clave completa exista; varias cuentas inteligentes usan passkeys o guardianes. Antes de usar una wallet, identifica cuál es su mecanismo real de respaldo.
5. ¿Por qué la comisión se paga en el activo nativo aunque muevas un token?
   Respuesta

   Porque la comisión remunera a quien procesa el bloque en la unidad de la red (gas en EVM, sat/vB en Bitcoin). Tener tokens sin saldo nativo te deja sin poder moverlos.
6. Conectar la wallet a una dApp, ¿autoriza mover fondos?
   Respuesta

   No: expone tu dirección y permite a la dApp proponerte firmas. Mover fondos exige una firma posterior (transacción, approve o permit). Pero conectar sí filtra información: qué dirección eres.
7. ¿Qué hace approve y por qué un valor ilimitado es un riesgo?
   Respuesta

   Autoriza a un contrato a gastar hasta X de tus tokens sin nuevas firmas. Ilimitado significa que si ese contrato es (o se vuelve) malicioso o vulnerable, puede vaciar el token completo, hoy o en un año.
8. ¿Por qué un permit "gratis y sin gas" puede ser más peligroso que una transacción?
   Respuesta

   Porque es una firma off-chain: no ves gas, no ves transacción, y aun así cede una autorización de gasto que el atacante ejecutará después. Toda firma EIP-712 se revisa como si fuera una transacción.
9. ¿Qué es el address poisoning y cuál es la defensa?
   Respuesta

   Sembrar en tu historial direcciones que imitan el principio y el final de las tuyas habituales, esperando que copies la impostora. Defensa: nunca copiar del historial y verificar la dirección completa, no la abreviatura.
10. ¿Qué diferencia práctica hay entre una wallet Bitcoin y una EVM al recibir?
    Respuesta

    En Bitcoin se recomienda una dirección nueva por cobro (privacidad, modelo UTXO); en EVM se reutiliza la misma `0x…`, que además existe en todas las redes EVM: verificar la red pasa a ser parte de verificar el destino.
11. ¿Cuándo se verifica un respaldo?
    Respuesta

    Antes de que la wallet custodie nada: restaurando desde el respaldo en un entorno limpio. Después, cada escenario de emergencia se ensaya en seco. Un respaldo sin ensayo de restauración no está verificado.
12. Escenario: una dApp de intercambio te pide approve ilimitado "para ahorrar gas en el futuro". ¿Qué haces?
    Respuesta

    Editar la aprobación al monto de la operación (o rechazarla si la interfaz no lo permite y no confías). El ahorro de gas futuro no compensa ceder el token completo a un contrato. Si ya aprobaste sin límite antes, revócalo.
13. Escenario: perdiste el teléfono, pero tienes un respaldo verificado en papel. ¿Orden correcto?
    Respuesta

    Restaurar en un dispositivo limpio desde el respaldo → evaluar si el acceso del teléfono era débil (sin PIN de app, por ejemplo) → si lo era, crear semilla nueva y migrar fondos → revocar aprobaciones de la cuenta antigua si migras. Bloquear la SIM y las cuentas asociadas en paralelo.
14. Escenario: "soporte técnico" del proyecto te escribe por privado y pide tu seed para "resincronizar el nodo". ¿Qué es esto?
    Respuesta

    Un robo en curso. Ningún soporte legítimo pide la seed, jamás, bajo ningún pretexto técnico. Se corta el contacto y se reporta por el canal oficial. Si la diste: migración inmediata de todo a una semilla nueva.
15. Escenario: pegaste una dirección y, antes de firmar, notas que el centro no coincide con la que copiaste. ¿Qué pasó y qué haces?
    Respuesta

    Probable malware de portapapeles (o copiaste una envenenada del historial). No firmas, verificas la fuente de la dirección, y no vuelves a operar desde ese equipo hasta limpiarlo: el reemplazo se repetirá.

Checkpoint práctico: enseña a alguien (o grábate) el prevuelo completo sobre el escenario 2 del laboratorio, explicando cada control. Si no puedes explicarlo sin leer, la unidad no está cerrada.

📖 Glosario de la unidad

• Wallet (billetera/cartera digital): software o hardware que administra claves y firma; no contiene los activos.
• Seed phrase (frase semilla): palabras BIP-39 de las que se derivan todas las claves; el respaldo maestro.
• Derivación HD: generación jerárquica y determinista de claves desde una semilla (BIP-32/44).
• Aprobación (approval/allowance): permiso a un contrato para gastar hasta X de un token tuyo.
• Blind signing (firma a ciegas): firmar datos que la wallet no puede mostrar en claro.
• Wallet drainer: contrato o dApp maliciosa diseñada para obtener firmas que vacían una wallet.
• Address poisoning (envenenamiento de direcciones): sembrar direcciones parecidas a las tuyas para que copies la impostora.
• Watch-only (solo lectura): wallet sin clave privada; observa, no firma.
• Cuenta inteligente: cuenta implementada como contrato (ERC-4337) con reglas programables de firma y recuperación.

El resto del vocabulario, en el glosario general.

📚 Referencias

Fuentes primarias, consultadas el 2026-08-24:

• BIP-32 — Hierarchical Deterministic Wallets
• BIP-39 — Mnemonic code for generating deterministic keys
• BIP-44 — Multi-Account Hierarchy for Deterministic Wallets
• Bitcoin Core — documentación
• ethereum.org — Wallets y Security
• EIP-1193 — Ethereum Provider JavaScript API
• EIP-6963 — Multi Injected Provider Discovery
• EIP-712 — Typed structured data hashing and signing
• EIP-2612 — Permit: firma de aprobaciones ERC-20
• ERC-4337 — Account Abstraction
• viem — documentación oficial
• OWASP Smart Contract Top 10 y OWASP Key Management Cheat Sheet

🧭 Navegación

Vienes de: ⬅️ Clases 9–10 · Bitcoin · Sigue con: ➡️ Clases 11–12 · Ethereum y EVM

Profundiza después: Clases 15–16 · dApps (conexión wallet-dApp con viem) · Clases 19–20 · Seguridad (cómo piensa un atacante) · Clases 53–54 · Custodia institucional e identidad (multisig, MPC, HSM, ERC-4337)

📚 Índice del currículo · 🧪 Catálogo de prácticas · 🏠 Programa