Rabby Wallet para instituciones: Configuración multi-usuario, firmas compartidas y auditoría

Una cooperativa de criptomonedas en Buenos Aires mantiene fondos en Ethereum, Arbitrum y Polygon, pero sus cinco administradores no pueden usar la misma cartera de escritorio. Cada uno necesita autoridad limitada, visibilidad completa del estado de los activos, y un registro auditable de quién movió qué y cuándo. Las billeteras tradicionales de auto-custodia ofrecen seguridad individual, pero no fueron diseñadas para gobernanza compartida. Las soluciones custodiales sacrifican el control privado por la conveniencia administrativa. Existe un espacio intermedio donde una billetera Web3 puede ser adaptada para múltiples usuarios sin renunciar a la responsabilidad de las claves privadas.

Rabby Wallet, desarrollada por el equipo detrás de DeBank, presenta capacidades que pueden soportar esta estructura cuando se configuran deliberadamente. Su arquitectura no custodial, compatibilidad con hardware wallets, simulación de transacciones antes de firmar, y gestión granular de aprobaciones crean una base técnica viable. Sin embargo, una configuración institucional requiere más que instalar la Rabby Wallet app en múltiples computadoras. Demanda decisiones explícitas sobre segregación de claves, permisos operacionales, procesos de autorización, y qué hechos se registran y cómo se conservan.

La diferencia entre multi-usuario y multi-firma en una billetera Web3

Muchas instituciones confunden dos modelos distintos. El primero es acceso múltiple donde varios usuarios comparten una sola billetera compartida, todos con acceso a las mismas claves y capaces de gastar sin restricción. El segundo es multi-firma donde un gasto requiere consentimiento de N de M participantes, cada uno controlando una clave separada. Rabby Wallet en su forma estándar soporta el primer modelo de manera directa: múltiples dispositivos pueden importar la misma frase semilla de recuperación, con cada usuario viendo la cartera completa en su extensión o aplicación desktop.

Esta configuración de acceso compartido es viable para estructuras pequeñas de alto grado de confianza. Los cinco administradores de la cooperativa podrían todos importar la misma frase semilla en sus máquinas, ejecutar nodos propios o usar endpoints públicos, y autorizar transacciones de forma independiente. El beneficio es que Rabby maneja automáticamente el cambio de red, simula transacciones antes de que se firmen para mostrar los riesgos reales, y puede alertar sobre aprobaciones de tokens peligrosas. Si un administrador está a punto de autorizar un contrato malicioso, la simulación puede evidenciar tokens siendo robados; entonces ese usuario puede rechazar la transacción sin necesidad de una capa de gobernanza externa.

Sin embargo, el acceso compartido tiene límites. Si uno de los cinco administradores es comprometido, todos son comprometidos. No existe segregación de permisos: cada usuario puede gastar el 100% del fondo sin consentimiento de los otros. Para estructuras donde los fondos son significativos y la confianza no es absoluta, una verdadera solución multi-firma es más apropiada. Algunos proyectos usan carteras multi-firma basadas en contratos inteligentes, como Safe (anteriormente Gnosis Safe), que despliega un contrato en la blockchain que requiere múltiples firmas para mover fondos. Rabby Wallet puede firmar transacciones que se envían a Safe, pero Safe es el contrato de gobernanza, no Rabby.

La decisión operacional entonces es: ¿cuán baja debe ser la fricción de administración, y cuán alta debe ser la barrera de gasto no autorizado? El acceso compartido a Rabby es más fluido pero menos resistente. Multi-firma es más lento pero más robusto. Muchas instituciones implementan un modelo híbrido: dinero de operación diaria en una configuración de acceso compartido con límites bajos de transacción, y fondos de reserva o tesorería en un contrato multi-firma donde cada movimiento requiere acuerdo explícito de múltiples partes.

Segregación de claves y contextos de riesgo

Una cooperativa que maneja transacciones frecuentes en Ethereum, Arbitrum y Polygon enfrenta una pregunta básica: ¿debe existir una única frase semilla para todas las cadenas y activos, o múltiples frases con propósitos segregados? Rabby Wallet soporta ambos enfoques porque es una billetera determinística HD: de una única frase semilla, puede derivar direcciones infinitas en múltiples blockchains. Un administrador puede importar la misma semilla en su máquina, y acceder a todas las direcciones derivadas del estándar BIP-44 sin tomar notas de múltiples secretos.

La conveniencia de una semilla única viene con un costo de seguridad que debe ser explícito. Si la semilla es comprometida, cada dirección en cada blockchain derivada de esa semilla puede ser gastada. La alternativa es crear múltiples semillas: una para fondos de operación en Ethereum, otra para tokens en Arbitrum, otra para NFTs en Polygon. Cada una se almacena separadamente, y cada una se distribuye a un subconjunto diferente de administradores. Esto aumenta el trabajo operacional, pero reduce el daño de una exposición. Si la semilla de Arbitrum es robada, los fondos en Ethereum y Polygon permanecen intactos.

La elección también depende de cómo se generan y almacenan las semillas. Si las frases se escriben en papel y se cierren en cajas fuertes separadas, la segregación es práctica. Si se almacenan en un archivo cifrado compartido o en un gestor de contraseñas corporativo, el costo de segregación se reduce porque la administración del acceso es el punto débil de todos modos. Para una cooperativa sin infraestructura de seguridad físca robusta, una semilla única con permisos de acceso muy restringidos puede ser más segura que múltiples semillas mal custodiadas.

El uso de hardware wallets como Ledger, Trezor, o Keystone amplifica la segregación sin complejidad operacional adicional. Cada administrador puede tener un dispositivo hardware que mantiene su copia de la clave privada, nunca revelada al software en su computadora. Rabby Wallet se integra directamente con estos dispositivos: la extensión o la aplicación desktop solicita la firma, el hardware wallet la realiza localmente y devuelve la firma de transacción firmada. Si el software de alguien está comprometido, solo puede ver las direcciones públicas y solicitar firmas; no puede extraer claves privadas del dispositivo hardware.

Gestión granular de aprobaciones y riesgos de token

Una fuente persistente de pérdida institucional en DeFi es la autorización de tokens mal calibrada. Un usuario conecta su billetera a una plataforma de trading, autoriza el token A con un límite de mil unidades, ejecuta una transacción legítima, pero luego esa plataforma o un atacante que compromete la plataforma gasta el límite completo. Rabby Wallet aborda este riesgo con controles de aprobación que permiten ver exactamente cuál es el limite autorizado a qué contrato, y modificarlo o revocarlo después de que sea seguro hacerlo.

Para una institución, la gestión de aprobaciones debe ser parte de un proceso. Cuando un administrador necesita interactuar con un protocolo de préstamo nuevo, la transacción de autorización de token debe ser explícitamente revisada por un segundo administrador, simulada para confirmar que no autoriza más de lo necesario, y registrada. Rabby Wallet proporciona la herramienta: su simulación de transacciones muestra exactamente qué sucederá si la transacción se ejecuta. Si la autorización es de 10 000 tokens pero la transacción solo usa 50, la simulación lo hace evidente. Un segundo par de ojos viendo esa simulación antes de firmar puede prevenir riesgos significativos.

El paso más concreto es establecer una política institucional que exija límites de autorización bajos para plataformas nuevas o de riesgo medio. En lugar de autorizar la cantidad máxima que Ethereum permite (2^256), autorizar solo lo necesario para la próxima transacción. Después de que el riesgo sea evaluado durante varias semanas, se puede autorizar más. Para proyectos de alto riesgo, Rabby también permite autorizar a direcciones específicas en lugar de a contratos abiertos. Esto reduce la superficie de ataque si esa dirección es comprometida, porque otros contratos no pueden usar la autorización.

La simulación de transacciones es donde Rabby demuestra valor operacional sustancial. Antes de que un administrador firme, ve una vista previa clara: “Envías 1 ETH, recibes 2000 USDC aproximadamente, el precio actual es X.” Si ve “Envías 1 ETH, PIERDES 2000 USDC,” la transacción está invertida o es un ataque. Una institución puede entrenar a sus administradores para nunca firmar sin revisar la simulación de transacciones. Este es un control de bajo costo que ha prevenido pérdidas significativas en equipos pequeños.

Auditoría, registro y responsabilidad

Un fondo o cooperativa que maneja capital de terceros requiere documentación de quién autorizó qué y cuándo. Rabby Wallet en su configuración estándar no es un sistema de auditoría: no registra automáticamente quién firmó una transacción, no crea un log inmutable, y no genera reportes automáticos para enviar a auditores externos. Sin embargo, sus características se alinean con procesos de auditoría cuando se estructuran deliberadamente.

El primer paso es que cada administrador tenga un dispositivo o cuenta de computadora identificable. Si el administrador Alice usa siempre la computadora A con la extensión Rabby de su cuenta de correo corporativo, y el administrador Bob usa siempre la computadora B, los registros de red de esas máquinas pueden reconstruir quién firmó qué. La blockchain misma proporciona un segundo registro: la transacción incluye una firma criptográfica que fue creada por una clave privada específica. Si solo Alice tiene la clave privada asociada a la dirección de su administrador, esa firma matemáticamente solo puede haber venido de ella.

Sin embargo, reconstruir este registro después del hecho es trabajo manual. Una institución que planea estar sujeta a auditoría debe implementar un proceso paralelo desde el principio: cuando un administrador está a punto de aprobar una transacción, envía primero un borrador a un segundo administrador a través de correo corporativo o un sistema de mensajes seguro. El segundo administrador revisa la simulación de transacciones en su propia instancia de Rabby Wallet, confirma que es segura, y responde por correo con un “APROBADO” firmado. Solo entonces el primer administrador firma la transacción en la blockchain. Esos correos electrónicos corporativos proporcionan un rastro de auditoría, y los sellos de tiempo del correo asociado con los números de bloque de la transacción cierren la cadena de custodia.

Para volúmenes altos de transacciones, este proceso manual es tedioso. Algunas instituciones optan por escribir scripts que exportan datos de transacción de la blockchain (dirección del remitente, receptor, cantidad, hash de transacción, timestamp) e importarlos en una hoja de cálculo con autorización previa documentada. El punto es que Rabby Wallet proporciona la interfaz segura para ejecutar transacciones y simularlas; el registro de auditoría se debe construir alrededor de él, no dentro de él.

Configuración técnica para múltiples blockchains

Una ventaja específica de Rabby Wallet es su soporte para más de 100 blockchains EVM. Ethereum, Arbitrum, Polygon, Optimism y Avalanche aparecen preconfigurados, pero la institución puede además agregar redes personalizadas. Para una cooperativa que opera en Ethereum, Arbitrum y Polygon, esto significa una sola extensión o aplicación desktop gestiona tokens en todas las cadenas sin cambiar entre aplicaciones.

El cambio automático de red es crucial operacionalmente. Un administrador conecta su billetera a un protocolo en Arbitrum, Rabby detecta que el sitio espera la red Arbitrum y pregunta si cambiar. Si el administrador aprueba, la extensión cambia la red sin requerir que manualmente busque la cadena en un menú. Esto es seguridad a través del flujo: reduce la confusión en la que alguien aprueba una transacción en Ethereum cuando pensaba que estaba en Arbitrum. El error resultante sería una pérdida total de los fondos si el contrato no existe en esa cadena.

Para instituciones, el cambio automático de red también significa que la configuración de nodos es centralizada. En lugar de que cada administrador maneje sus propios endpoints de RPC, la cooperativa puede configurar una sola instancia de Rabby para usar un nodo privado (ejecutado por ellos mismos o arrendado a un proveedor confiable) y distribuir esa configuración a todos los administradores. Algunos proveedores como Infura o Alchemy ofrecen endpoints compartidos de alto rendimiento; otros permiten nodos dedicados. La decisión es un compromiso entre conveniencia y exposición de datos: un nodo compartido público es rápido pero puede revelar información de transacción preliminar; un nodo privado es más lento de configurar pero no expone actividad a terceros.

Compatibilidad con hardware wallets y segregación de responsabilidad

La integración de Rabby Wallet con Ledger, Trezor y Keystone tiene implicaciones de gobernanza que van más allá de seguridad de claves. Cuando una institución requiere que todas las transacciones de tesorería sean firmadas por un hardware wallet, está implementando un requisito que al menos dos dispositivos físicos deben estar presentes: la computadora con Rabby Wallet y el hardware wallet. Un atacante que compromete una máquina individual no puede crear una transacción sin acceso físico a la segunda máquina.

Además, los hardware wallets permiten “multi-sig compartido.” Un Ledger puede mantener una semilla privada y una aplicación independiente en el dispositivo confirma o rechaza transacciones basándose en restricciones que el administrador ha configurado. Aunque Rabby Wallet maneja las operaciones de alto nivel, la decisión final de firmar ocurre en un dispositivo que el usuario controla directamente y puede ver en su mano. Esto elimina ciertos vectores de ataque: un software malicioso en la computadora no puede interceptar la transacción entre Rabby Wallet y el dispositivo hardware; el dispositivo verifica directamente qué está siendo firmado.

En una cooperativa de cinco administradores, la política puede ser: transacciones de menos de 10 ETH pueden ser firmadas por un solo administrador con su hardware wallet después de simulación. Transacciones de más de 10 ETH requieren que dos administradores diferentes firmen con sus propios hardware wallets. Esto se implementa a través de un contrato multi-firma en la blockchain, o a través de un procedimiento: el primer administrador crea la transacción y la deja en el mempool, el segundo administrador la aprueba enviando una segunda transacción que la autoriza, o usa una herramienta de escrow temporal. Rabby Wallet no impone esta lógica automáticamente, pero proporciona las primitivas para construirla: compatibilidad con múltiples hardware wallets, simulación, cambio de red automático, y aprobación granular.

Gestión de tokens y vista unificada del portfolio

Una cooperativa que opera en múltiples cadenas enfrenta un problema de visibilidad: el saldo real está distribuido entre Ethereum, Arbitrum y Polygon, en diferentes tokens, y parte puede estar en liquidity pools o contratos de préstamo. Rabby Wallet resuelve esto con una vista unificada de portfolio que agrega saldos de token y NFTs en todas las redes soportadas en una sola pantalla. Un administrador ve inmediatamente cuánto USDC existe en Ethereum, cuánto en Arbitrum, cuánto está en un farm de liquidity en Polygon, y cuántos activos digitales únicos maneja la billetera.

Esta visibilidad es crítica para gobernanza porque previene la sobreapropiación accidental. Si la cooperativa tiene un límite de 50 000 USDC total en tesorería, y eso está distribuido entre tres cadenas, Rabby Wallet muestra el total de 50 000 USDC en una mirada. Sin esta vista unificada, un administrador podría ver 20 000 USDC en Ethereum, asumir que ese es el total disponible, y autorizar un gasto pensando que hay margen. El panorama de múltiples cadenas hace que la falta de visibilidad sea un riesgo real.

La gestión de tokens también permite que los administradores reconozcan activos spam o fraudulentos. Si un atacante envía un token falso llamado “USDC-Fake” a la dirección de la cooperativa esperando que alguien lo devuelva y así revele de quién es la billetera, Rabby puede marcar ese token como oculto o sospechoso. La cooperativa no necesita pensar en él, y no puede ser confundido con USDC real. Esta característica es particularmente importante en operaciones institucionales donde el volumen de actividad es alto y un token fraudulento entre cientos legítimos puede pasar desapercibido.

Limitaciones del modelo y cuándo usar alternativas

Rabby Wallet es una herramienta de firmas no custodial, no una plataforma de gobernanza completa. Si una institución requiere que cada transacción sea votada en un DAO, que se apruebe a través de un sistema de votación en cadena, o que se ejecute solo dentro de una ventana de tiempo específica, esas lógicas deben vivir en un contrato inteligente separado. Safe (Gnosis Safe) es una alternativa que sí implementa estos controles dentro de la blockchain misma. Con Safe, estableces que se requieren 3 de 5 firmas para gastar, y el contrato mismo refuerza esa regla. Nadie puede eludirla desde el software.

Rabby Wallet confía en la disciplina del procedimiento humano. Los controles son fuertes pero opcionales: es responsabilidad de los administradores revisar, simular y coordinar. Esto funciona bien para equipos pequeños, altamente coordinados y de alta confianza. Para operaciones donde los fondos son muy grandes o los administradores están distribuidos globalmente sin relaciones previas, un contrato multi-firma que refuerza los controles en código es más robusto.

Otra limitación es que Rabby Wallet, como cualquier extensión de navegador, es tan segura como el navegador que lo ejecuta. Si la máquina de un administrador está comprometida por un malware avanzado, ese software podría interceptar firmas o acceder a claves privadas incluso si están almacenadas de forma encriptada localmente. El uso de hardware wallets mitiga esto porque la clave privada nunca sale del dispositivo. El aislamiento de aire también mitiga: ejecutar Rabby Wallet solo en una computadora dedicada que no se conecta a internet excepto para firma (usando una segunda máquina para construir transacciones), o ejecutarlo en una máquina virtual aislada, proporciona una barrera adicional contra malware.

Proceso de implementación para una institución

El primer paso es inventariar qué blockchains, tokens y direcciones contiene actualmente la institución. Esto debería tomar la forma de una hoja de cálculo o una base de datos: blockchain, dirección pública, saldo actual, propósito (tesorería, operación diaria, fondos congelados). A partir de ahí, decida si usando una sola frase semilla compartida para todas las direcciones es acceptable o si múltiples semillas segregadas por propósito o riesgo son necesarias. Luego, adquiera hardware wallets para cada administrador si la política lo requiere.

Configure una instancia de Rabby Wallet en una máquina de prueba con la frase semilla (o múltiples frases si está segregando). Importe la frase, verifique que todas las direcciones esperadas deriven correctamente, y confirme que el saldo total concuerda con la hoja de cálculo. Luego, establezca un procedimiento documentado: cómo se solicita una transacción, quién puede aprobarla, cuál es el mínimo de revisores, cómo se simula, y cómo se registra después de la firma. Entregue este documento a todos los administradores y ejecute al menos una transacción de prueba con fondos reales de bajo valor antes de un volumen completo.

Una vez en operación, la responsabilidad principal es la gestión segura de la frase semilla y el acceso a las máquinas que ejecutan Rabby Wallet. La frase debe ser almacenada offline, preferiblemente en una caja fuerte física o un compartimento seguro, accesible solo a los administradores o a un depositario designado. Las computadoras que ejecutan Rabby Wallet deben ser mantenidas actualizadas, ejecutar software antimalware, y estar separadas de máquinas de uso general. El registro de auditoría debe ser revisado periódicamente, posiblemente mensualmente, para verificar que no ha habido actividad no autorizada.