MWMovingWallet
← Back
2026-02-08 · explanation · Applies to: v1

Mover activos no es un clic: entender el riesgo antes de actuar

What This Covers

Este documento descompone los riesgos de mover activos cripto en tres fases temporales (antes, durante, después) y documenta cómo los componentes de simulación de MovingWallet abordan cada fase. No cubre ejecución real — en v0.x solo hay simulación.


B1 — Fase ANTES: lo que no ves te puede costar

Objetivo: Documentar los riesgos que existen antes de iniciar cualquier transferencia de activos.

La mayoría de errores al mover activos ocurren antes de la primera transacción. Los riesgos de la fase previa son:

Riesgo 1: Inventario incompleto. El usuario no sabe exactamente qué tiene ni dónde. La detección de activos en MovingWallet consulta cuatro redes (Ethereum, Polygon, Optimism, Arbitrum) y tres tipos de activos (nativos, ERC-20, NFTs). Pero la detección de ERC-20 requiere direcciones de contrato conocidas — si un token no está en el conjunto de consulta, no aparece. El resultado es un inventario útil pero no exhaustivo.

Código de referencia: src/app/api/assets/route.ts — consulta eth_getBalance para nativos y balanceOf para ERC-20 en cada red soportada.

Riesgo 2: Destino no verificado. MovingWallet valida que la dirección de destino tenga formato EVM correcto (checksum, longitud de 42 caracteres). No valida que la dirección pertenezca al usuario, que sea una wallet activa, o que no sea un contrato que rechace transfers. El PanicFlow muestra errores de validación de formato pero no puede verificar propiedad.

Riesgo 3: Condiciones de red desconocidas. El gas estimado por PlanEstimate es una aproximación mock en v0.x. Las condiciones reales de la red (congestión, base fee, priority fee) cambian constantemente. Un plan estimado a las 10:00 puede ser inviable a las 10:05 si el gas sube.

Cómo aborda MovingWallet esta fase:

  • PlanEstimate muestra batches, gas estimado y nivel de riesgo antes de cualquier acción.
  • SimulationWarnings genera el warning empty_plan (riesgo alto) si no se detectan activos: "No hay activos. Verifica que la wallet tiene fondos."
  • SimulationWarnings genera limited_provider (riesgo medio) si no hay provider indexado: "Solo ETH detectado. Configura Alchemy para ver tokens."

TL;DR: Antes de mover nada, hay tres riesgos: no ver todos los activos, no verificar el destino, y no conocer las condiciones de red. MovingWallet hace visibles los dos primeros mediante inventario y warnings. El tercero es inherente a la blockchain.

Mini-post: El mayor riesgo al mover activos no es la transacción en sí — es lo que no sabes antes de hacerla. Inventario incompleto, destino sin verificar, gas impredecible. MovingWallet muestra estos riesgos antes de que actúes.

Checklist técnica:

  • [ ] Ejecutar inventario y comparar con explorador de bloques por red
  • [ ] Verificar que PlanEstimate muestra el número esperado de activos
  • [ ] Revisar si aparece warning limited_provider (indica detección parcial)
  • [ ] Confirmar dirección de destino carácter por carácter fuera de MovingWallet

B2 — Fase DURANTE: donde los errores se vuelven irreversibles

Objetivo: Documentar los riesgos que existen durante la ejecución de transferencias (y cómo la simulación los anticipa).

En v0.x, MovingWallet no ejecuta transacciones reales. Pero la simulación modela los escenarios que ocurrirían durante la ejecución. Los riesgos de esta fase son:

Riesgo 4: Ejecución parcial. Si un plan tiene 8 activos en 3 redes y la ejecución se interrumpe después del activo 5, quedan 3 activos en la wallet original. No hay mecanismo de rollback en blockchain — cada transacción es independiente e irreversible.

SimulationWarnings clasifica este escenario con el warning partial_success (riesgo medio): "Algunos activos fallaron. Revisa errores abajo." La función buildSimulationWarnings() lo genera cuando partialSuccess === true y totalBatches > 0.

Riesgo 5: Fallo completo. La simulación puede fallar completamente si, por ejemplo, el RPC no responde o los contratos rechazan las llamadas. Este escenario genera el warning failed (riesgo alto) con el detalle del primer error encontrado.

La prioridad de warnings está definida en el código:

  1. failed (prioridad 1 — más crítico)
  2. empty_plan (prioridad 2)
  3. partial_success (prioridad 3)
  4. limited_provider (prioridad 4)
  5. conversion_not_implemented (prioridad 5)
  6. simulation_only (prioridad 6 — contexto, no error)

Riesgo 6: Conversión no disponible. Si el usuario selecciona un modo de conversión (to_eth, to_usdc), la simulación degrada automáticamente a none en v0.x y genera el warning conversion_not_implemented (riesgo bajo): "Conversión a ETH/USDC no disponible en v0.x."

Cómo aborda MovingWallet esta fase:

  • SimulationWarnings muestra todos los warnings ordenados por prioridad (más crítico primero) usando sortWarningsByPriority().
  • calculateRiskLevel() determina el nivel máximo: si hay algún warning de riesgo alto, el nivel global es alto.
  • El componente NextStepsGuide aparece opcionalmente con instrucciones post-simulación, incluyendo un aviso especial si el riesgo es alto.

TL;DR: Durante la ejecución, los errores son irreversibles. No hay rollback. La simulación de MovingWallet modela escenarios de fallo parcial, fallo completo y degradación de funcionalidades, con warnings priorizados por criticidad.

Mini-post: En blockchain no hay "deshacer". Si 5 de 8 activos se mueven y los otros 3 fallan, quedan distribuidos entre dos wallets. La simulación de MovingWallet te muestra este escenario antes de que ocurra.

Checklist técnica:

  • [ ] Ejecutar simulación completa y verificar que todos los warnings aparecen
  • [ ] Confirmar que warnings están ordenados por prioridad (failed > empty_plan > partial_success > ...)
  • [ ] Si aparece partial_success, revisar qué activos fallaron y por qué
  • [ ] Si aparece failed, revisar el error específico antes de reintentar

B3 — Fase DESPUÉS: verificar lo que ocurrió

Objetivo: Documentar los riesgos y tareas que existen después de que una operación (o simulación) ha finalizado.

La fase posterior es la que menos atención recibe, pero es donde se confirma si la operación fue exitosa:

Riesgo 7: Asumir éxito sin verificar. Que una transacción haya sido enviada no significa que haya sido confirmada. Que una simulación muestre éxito no significa que la ejecución real tendrá el mismo resultado. Las condiciones cambian entre la simulación y la ejecución.

Riesgo 8: No registrar lo que ocurrió. Sin un registro del plan ejecutado (o simulado), es imposible auditar qué se hizo, qué falló y qué quedó pendiente. Esto es especialmente relevante cuando se opera bajo presión (el "modo pánico" de MovingWallet es explícito sobre este escenario).

Cómo aborda MovingWallet esta fase:

  • PortfolioView (src/features/portfolio/components/PortfolioView.tsx) mantiene un historial de simulaciones con:

    • Fecha y timestamp
    • Direcciones de origen y destino
    • Conteo de activos movibles y no movibles
    • Estado: éxito, parcial o fallida
    • Nivel de riesgo (badges: Alto, Medio, Bajo, OK)
    • Gas estimado y tarifa placeholder
    • Tipo de conversión
    • Lista de errores específicos
  • Exportación de snapshot. PanicFlow permite copiar el plan al portapapeles o descargar como archivo JSON. Este snapshot es la evidencia del estado de la simulación en ese momento.

  • Detalle expandible. Cada simulación en PortfolioView se puede expandir para ver metadatos completos: ID, chain, balances, errores, gas, fee.

  • Banner de modo simulación. PortfolioView muestra permanentemente: "MODO SIMULACIÓN (v0.x): Las simulaciones guardadas aquí son solo planes calculados. No representan fondos movidos."

Limitación: El historial se almacena en localStorage del navegador. No persiste entre dispositivos, ni sobrevive a una limpieza de datos del navegador.

TL;DR: Después de operar (o simular), hay que verificar y registrar. PortfolioView guarda un historial de simulaciones con estado, riesgo y errores. Los snapshots JSON son exportables. Pero el historial es local — no hay respaldo en servidor.

Mini-post: La simulación terminó. Ahora hay que verificar: qué se movió, qué falló, qué quedó atrás. PortfolioView guarda cada simulación con su estado y nivel de riesgo. Exporta el JSON antes de cerrar el navegador.

Checklist técnica:

  • [ ] Después de cada simulación, verificar que aparece en PortfolioView
  • [ ] Expandir el detalle y confirmar activos movibles, estado y errores
  • [ ] Exportar snapshot JSON del plan
  • [ ] Verificar balances directamente en exploradores de bloque (no confiar solo en MovingWallet)

B4 — El principio de no-ejecución-sin-revisión

Objetivo: Documentar el modelo de operación de MovingWallet y por qué no ejecuta acciones automáticamente.

MovingWallet se diseñó con un principio explícito: no ejecutar sin revisión del usuario.

Esto se manifiesta en:

  1. Lectura primero. El flujo comienza con la detección de activos — no con una acción. El usuario ve qué tiene antes de decidir qué hacer.

  2. Simulación antes de ejecución. PanicFlow construye un plan (buildExecutionPlan()) y lo simula. El resultado incluye warnings, estimaciones y el plan completo en JSON. Todo esto ocurre antes de que exista cualquier opción de firmar.

  3. Warnings explícitos y clasificados. El sistema no oculta problemas. SimulationWarnings muestra seis tipos de advertencias, ordenadas por criticidad, con niveles de riesgo calculados programáticamente. Un warning de failed siempre aparece antes que uno de simulation_only.

  4. Preview completo. PreviewPlan muestra el JSON crudo del plan. No hay resumen que oculte detalles — el usuario puede inspeccionar cada batch, cada activo, cada dirección.

  5. v0.x = solo simulación. La versión actual no tiene capacidad de firma ni ejecución. El warning simulation_only ("SIMULACIÓN v0.x: No mueve fondos reales.") aparece en toda simulación. Esto no es una limitación accidental — es una decisión de diseño.

  6. Historial auditable. Cada simulación se guarda en PortfolioView con metadatos completos. El usuario puede revisar simulaciones pasadas, comparar resultados y detectar patrones de error.

Este modelo tiene un coste: es más lento que una ejecución automática. Requiere que el usuario lea, entienda y decida. Pero en un sistema donde los errores son irreversibles y potencialmente costosos, la velocidad de ejecución no es la métrica correcta.

TL;DR: MovingWallet no ejecuta sin revisión. El flujo es: inventario → simulación → warnings → preview → decisión del usuario. En v0.x, la cadena termina en preview — no hay ejecución disponible. Esto es una decisión de diseño, no una limitación temporal.

Mini-post: Inventario. Simulación. Warnings. Preview. Decisión. En MovingWallet, cada paso requiere revisión antes de avanzar. En v0.x, el flujo termina en preview — la ejecución no está disponible aún. Esto es intencional.

Checklist técnica:

  • [ ] Verificar que el flujo PanicFlow sigue la secuencia: assets → estimate → preview → export
  • [ ] Confirmar que warnings aparecen antes de cualquier acción
  • [ ] Verificar que PreviewPlan muestra el JSON completo (no un resumen)
  • [ ] Confirmar que no hay botón de ejecución en v0.x

B5 — Resumen: las tres fases y sus controles

Objetivo: Tabla resumen de riesgos por fase y qué componente de MovingWallet los aborda.

| Fase | Riesgo | Componente | Warning type | |------|--------|-----------|-------------| | ANTES | Inventario incompleto | AssetTable + /api/assets | empty_plan, limited_provider | | ANTES | Destino no verificado | PanicFlow (validación de formato) | — | | ANTES | Gas desconocido | PlanEstimate | — | | DURANTE | Ejecución parcial | SimulationWarnings | partial_success | | DURANTE | Fallo completo | SimulationWarnings | failed | | DURANTE | Conversión no disponible | SimulationWarnings | conversion_not_implemented | | DESPUÉS | No verificar resultado | PortfolioView | — | | DESPUÉS | No registrar lo ocurrido | Export snapshot (JSON) | — | | SIEMPRE | Simulación ≠ ejecución real | SimulationWarnings | simulation_only |

TL;DR: Cada fase de la operación tiene riesgos específicos. MovingWallet no elimina ninguno — los hace visibles antes de que el usuario actúe.

Mini-post: Antes: ¿ves todos tus activos? Durante: ¿qué pasa si falla a mitad? Después: ¿verificaste el resultado? MovingWallet estructura estas tres fases con inventario, simulación y registro.


Known Limitations

  • La simulación modela escenarios pero no garantiza que la ejecución real producirá los mismos resultados.
  • Los niveles de riesgo (alto, medio, bajo) son calculados por heurísticas basadas en el tipo de warning, no en análisis de mercado.
  • El gas estimado en v0.x es mock — no consulta condiciones de red en tiempo real.
  • La validación de dirección es solo de formato (checksum EVM). No verifica propiedad, actividad ni tipo de contrato.
  • El historial en PortfolioView es local (localStorage). No se sincroniza ni respalda.

Risks

  • Un usuario puede confundir simulación exitosa con garantía de ejecución exitosa. No es así.
  • Las estimaciones de gas mock pueden diferir sustancialmente del coste real.
  • La priorización de warnings es fija (codificada). No se adapta al contexto específico del usuario.
  • Exportar un snapshot no constituye prueba de ejecución — solo documenta el estado de la simulación en ese momento.
  • Operar bajo presión temporal (escenario "pánico") aumenta el riesgo de errores incluso con visibilidad mejorada.

Disclaimer: This is technical documentation, not financial advice. MovingWallet does not guarantee asset completeness, transaction success, or protection against loss. Users are responsible for verifying all operations independently.