<\/p>\n
Wallets custodiales versus no custodiales: la arquitectura que lo explica todo<\/h2>\n
Una wallet custodial, como las ofrecidas por intercambios centralizados, funciona bajo un modelo de servicio tradicional. El proveedor controla las claves privadas en sus servidores. El usuario accede a trav\u00e9s de una contrase\u00f1a, se autentica en una p\u00e1gina web y sus operaciones se ejecutan en la infraestructura del servicio. Esa arquitectura permite f\u00e1cilmente una interfaz web: el navegador solo necesita comunicarse con los servidores del proveedor, que custodian realmente los fondos. El usuario nunca maneja directamente las claves. Es conveniente, familiar, y compatible con cualquier dispositivo con navegador. Tambi\u00e9n es precisamente lo que Cake Wallet rechaza deliberadamente.<\/p>\n
Un wallet no custodial<\/strong> invierte esa relaci\u00f3n. El usuario controla las claves privadas. La aplicaci\u00f3n es solo una interfaz que ayuda a construir, firmar y transmitir transacciones. Las claves nunca salen del dispositivo. Si el proveedor de la wallet desapareciera, el usuario podr\u00eda recuperar sus fondos con la frase semilla (seed phrase) usando otra aplicaci\u00f3n compatible. Esta es la raz\u00f3n por la que Cake Wallet lanzado en 2018 enfatiza desde el inicio que no requiere registro de cuenta, creaci\u00f3n de usuario ni recopilaci\u00f3n de datos. Sin cuentas, no hay base de datos centralizada de clientes. Sin contrase\u00f1as en servidores, no hay “olvid\u00e9 mi contrase\u00f1a”.<\/p>\n Cuando una wallet no custodial intenta convertirse en versi\u00f3n web, enfrenta un dilema t\u00e9cnico irresoluible sin comprometer la seguridad. Si la clave privada se almacena en el servidor web, deja de ser no custodial: el proveedor ahora custod\u00eda los fondos. Si la clave se almacena en el navegador del cliente, debe transmitirse cada vez que el usuario accede desde una m\u00e1quina diferente, o copiarse entre dispositivos, o exponerse a trav\u00e9s de almacenamiento temporal del navegador. Ninguna de esas opciones es aceptable para un proyecto que promete que los fondos est\u00e1n bajo control exclusivo del usuario.<\/p>\n La alternativa te\u00f3rica de usar WebAssembly y almacenamiento local del navegador resuelve parcialmente el problema: las claves podr\u00edan generarse y almacenarse localmente en el navegador sin transmitirse a servidores. Pero esa soluci\u00f3n crea nuevas vulnerabilidades. El almacenamiento local del navegador es mucho menos seguro que el almacenamiento criptografiado del sistema operativo en una aplicaci\u00f3n nativa. Los navegadores tienen extensiones, scripts injected, malware que puede acceder al almacenamiento, historial de sesiones borrado de forma imperfecta y cach\u00e9 que persiste. Una clave privada en almacenamiento local del navegador est\u00e1 expuesta a vectores de ataque que no existen en una aplicaci\u00f3n de escritorio o m\u00f3vil moderna.<\/p>\n Las aplicaciones nativas instaladas en Android, iOS, macOS, Linux o Windows pueden aprovechar caracter\u00edsticas de seguridad del sistema operativo que un navegador no puede usar. Android ofrece Secure Enclave, encriptaci\u00f3n basada en el hardware, y aislamiento de procesos. iOS tiene un nivel de aislamiento a\u00fan m\u00e1s estricto. Incluso en Windows y macOS, una aplicaci\u00f3n puede usar APIs del sistema operativo para proteger datos sensibles, autenticar biom\u00e9tricamente a trav\u00e9s del TPM, y almacenar claves fuera del acceso directo de procesos no autorizados.<\/p>\n Un navegador web, por dise\u00f1o, necesita ser un entorno m\u00e1s permisivo. Debe ejecutar JavaScript de m\u00faltiples or\u00edgenes, permitir la instalaci\u00f3n de extensiones, acceder a almacenamiento local, e interactuar con servicios remotos. Esa flexibilidad es la fortaleza de la web. Es tambi\u00e9n su debilidad para la custodia de claves. Una extensi\u00f3n maliciosa puede monitorear el almacenamiento local. Un sitio web comprometido o un ataque man-in-the-middle puede inyectar c\u00f3digo. El navegador, hist\u00f3ricamente, no ha sido dise\u00f1ado como contenedor de b\u00f3vedas criptogr\u00e1ficas.<\/p>\n Cake Wallet est\u00e1 disponible en Android, iOS, macOS, Linux y Windows precisamente porque cada plataforma ofrece herramientas diferentes para que la aplicaci\u00f3n proteja las claves privadas de manera nativa. En dispositivos m\u00f3viles modernos, las claves pueden estar vinculadas a hardware criptogr\u00e1fico. En computadoras de escritorio, pueden protegerse mediante encriptaci\u00f3n del sistema de archivos. La aplicaci\u00f3n puede verificar que no ha sido modificada inspeccionando firmas digitales, como Cake Labs hace a trav\u00e9s del repositorio de GitHub cake-tech\/cake_wallet, permitiendo que usuarios t\u00e9cnicos validen la autenticidad descargando directamente desde cakewallet.com.<\/p>\n La regulaci\u00f3n financiera moderna ha comenzado a reconocer que las wallets no custodiales y custodiales son categor\u00edas diferentes con implicaciones legales distintas. FinCEN ha orientado que las wallets no custodiales en poder del usuario final no caen bajo los requisitos de AML\/KYC que aplican a los custodios centralizados<\/a>. La l\u00f3gica es que si el proveedor no tiene acceso a los fondos, no puede monitorear, bloquear ni reportar transacciones de la forma que un intercambio regulado debe hacer.<\/p>\n Sin embargo, el momento en que una wallet proporciona una interfaz web centralizada, introduce ambig\u00fcedad regulatoria. \u00bfEs el proveedor responsable de las transacciones facilitadas a trav\u00e9s de su servidor? \u00bfDebe monitorear la actividad aunque las claves residan t\u00e9cnicamente en el dispositivo del cliente? Diferentes jurisdicciones tendr\u00e1n respuestas diferentes. El Banco Central Europeo y los reguladores europeos han comenzado a establecer que los proveedores de servicios de custodia de criptomonedas enfrentan requisitos sustanciales de licencia y supervisi\u00f3n<\/a>. Una wallet web que facilita transacciones podr\u00eda ser capturada por esa definici\u00f3n.<\/p>\n Cake Labs ha elegido mantener su posici\u00f3n legal clara evitando cualquier versi\u00f3n que introduzca ambig\u00fcedad. No custodiar fondos significa no tener responsabilidad regulatoria de custodio. Eso es parte de por qu\u00e9 el proyecto documenta que no recopila datos de usuarios, no requiere registro, y que cada dispositivo ejecuta la aplicaci\u00f3n de forma completamente independiente. Una wallet web centralizada, incluso si t\u00e9cnicamente mantuviera claves en el cliente, crear\u00eda la apariencia de un servicio centralizado. Eso abrir\u00eda un frente regulatorio que Cake Wallet ha evitado deliberadamente.<\/p>\n Los usuarios que buscan acceso m\u00e1s flexible a Cake Wallet tienen opciones que mantienen la integridad no custodial. La aplicaci\u00f3n ya funciona en iOS, Android, macOS, Linux y Windows. En la pr\u00e1ctica, eso cubre pr\u00e1cticamente cualquier escenario: escritorio en el trabajo, laptop en viaje, tel\u00e9fono m\u00f3vil en la calle. Cada instalaci\u00f3n mantiene sus propias claves privadas encriptadas localmente. Si un usuario necesita acceso desde m\u00faltiples dispositivos, puede crear m\u00faltiples wallets independientes o usar la frase semilla para importar la misma wallet en varios aparatos, manteniendo control total de cu\u00e1ndo y c\u00f3mo se sincroniza.<\/p>\n Para transacciones simples, Cake Wallet tambi\u00e9n ofrece Cake Pay, que integra pagos dentro de la aplicaci\u00f3n sin necesidad de un navegador web separado. La interfaz de Cake Wallet web mencionada en cake wallet web<\/a> como recurso auxiliar no proporciona custodia remota de claves ni acceso centralizado a fondos. Es solo informaci\u00f3n de referencia. La aplicaci\u00f3n oficial sigue siendo descargada desde Google Play Store (100,000+ descargas), Apple App Store (calificaci\u00f3n 4.8\/5), o directamente como APK desde cakewallet.com para usuarios de Android que prefieren verificar la autenticidad del c\u00f3digo descargado.<\/p>\n La verificaci\u00f3n de autenticidad es una pr\u00e1ctica especialmente importante para usuarios preocupados por la seguridad. El c\u00f3digo fuente de Cake Wallet se publica bajo licencia MIT en GitHub, permitiendo que cualquiera lea el c\u00f3digo, lo audite de forma independiente, y verifique que las construcciones binarias descargadas correspondan realmente al c\u00f3digo publicado. El Open Source Initiative reconoce la licencia MIT como una de las m\u00e1s permisivas y confiables<\/a>. Eso significa que expertos en seguridad pueden inspeccionar cada funci\u00f3n de la wallet, incluido c\u00f3mo maneja las claves privadas, c\u00f3mo transmite transacciones, y c\u00f3mo protege datos sensibles.<\/p>\n El protocolo de Monero, documentado completamente por el proyecto oficial, usa criptograf\u00eda de curva el\u00edptica que depende de la integridad del generador de n\u00fameros aleatorios<\/a>. Si ese generador es d\u00e9bil o predecible, las claves privadas pueden ser recuperadas. En una aplicaci\u00f3n nativa, el dispositivo provee una fuente de aleatoriedad criptogr\u00e1ficamente segura respaldada por hardware o el sistema operativo. En un navegador web, la \u00fanica fuente es la API crypto est\u00e1ndar del navegador, que te\u00f3ricamente es segura pero que atraviesa capas adicionales de c\u00f3digo que podr\u00edan comprometer la entrop\u00eda.<\/p>\nEl est\u00e1ndar de seguridad diferente: aplicaciones nativas versus navegador<\/h2>\n
Regulaci\u00f3n, responsabilidad legal y por qu\u00e9 cake wallet web no es viable sin cambiar el modelo<\/h2>\n
Alternativas pr\u00e1cticas para acceso m\u00f3vil y verificaci\u00f3n de transacciones<\/h2>\n
Criptograf\u00eda de la cadena de bloques: por qu\u00e9 no se puede transpolar desde mobile a web sin riesgo<\/h2>\n