Rabby Wallet para programadores: Cómo integrar tu dApp o smart contract con Rabby usando proveedores EIP-1193

Un desarrollador de dApps necesita que su aplicación funcione con la mayor cantidad de billeteras posible. Si tu protocolo solo soporta un proveedor específico, pierdes usuarios que prefieren otras herramientas. Rabby Wallet, creada por el equipo detrás de DeBank, se ha convertido en una opción estándar para usuarios multi-cadena que necesitan interactuar con Ethereum, Arbitrum, Polygon, Optimism, Avalanche y más de 100 blockchains EVM adicionales. Pero integrar Rabby en tu dApp requiere entender cómo funciona el estándar EIP-1193 y qué métodos específicos el wallet proporciona para transacciones seguras.

La buena noticia es que Rabby implementa el estándar Ethereum Provider API de forma completa y predecible. No necesitas código especial solo para Rabby; necesitas código que siga el estándar web3 correcto, con algunas optimizaciones para aprovechar características avanzadas como la simulación de transacciones antes de firmar o la gestión automática de redes. Esta guía cubre cómo hacer que tu aplicación sea totalmente compatible con Rabby desde el lado del desarrollador, qué errores evitar y cómo probar la integración sin exponer claves privadas.

El estándar EIP-1193 y cómo Rabby lo implementa

EIP-1193 define la especificación que debe cumplir cualquier billetera Ethereum o compatible con EVM para comunicarse con aplicaciones descentralizadas. El estándar establece que el objeto window.ethereum debe estar disponible en el navegador cuando Rabby esté instalado, y este objeto debe exponer métodos JSON-RPC que permitan solicitar acciones específicas. Los métodos principales incluyen eth_accounts para obtener direcciones del usuario, eth_chainId para saber en qué red está conectado, eth_sendTransaction para enviar transacciones firmadas, personal_sign para firmar mensajes, y otros RPC estándar de Ethereum.

Rabby cumple con EIP-1193 de manera completa, lo que significa que si tu dApp funciona con MetaMask usando los métodos estándar, probablemente funcionará con Rabby sin cambios. Sin embargo, Rabby añade extensiones útiles por encima del estándar. Por ejemplo, expone un evento de cambio de cadena que notifica a tu aplicación cuando el usuario cambia de red, permite acceso a múltiples cuentas simultáneamente, y proporciona métodos para sugerir nuevas redes sin que el usuario deba configurarlas manualmente. Estas características hacen que la experiencia de usuario sea más fluida, especialmente en un ecosistema multi-cadena donde los usuarios cambian constantemente entre Arbitrum, Polygon y otras redes.

Para verificar que Rabby está disponible, tu código debe ejecutar una comprobación simple: revisar si window.ethereum existe y tiene la propiedad isRabby establecida en true. De esta forma evitas conflictos con otros wallets que puedan estar instalados en el mismo navegador. El orden importa: si el usuario tiene MetaMask y Rabby simultáneamente, window.ethereum podría apuntar a cualquiera de ellos, dependiendo del orden en que se cargaron las extensiones. La mejor práctica es permitir que el usuario seleccione explícitamente qué wallet desea usar en lugar de asumir que siempre es el primero disponible.

La inicialización correcta comienza llamando a eth_requestAccounts, que solicita permiso al usuario para conectar su billetera. Este método es importante porque implementa la seguridad necesaria: el usuario debe aprobar explícitamente que tu aplicación acceda a sus cuentas. Una vez aprobado, Rabby mantiene esa sesión, pero el usuario puede revocar acceso en cualquier momento desde la interfaz del wallet. El contrato entre tu dApp y Rabby es que nunca solicites o intentes acceder a claves privadas directamente; siempre debes usar los métodos RPC que Rabby expone como intermediario.

Detección y conexión inicial con Rabby Wallet

El primer paso en cualquier integración es detectar si Rabby está disponible. A diferencia de una aplicación que asume que Ethereum está siempre presente, una dApp debe seguir un flujo de detección robusto. El código debe buscar window.ethereum, verificar que isRabby sea true, y solo entonces permitir que el usuario conecte. Si Rabby no está instalado, tu aplicación debe mostrar un mensaje claro indicando dónde descargar Rabby Wallet, con un enlace a través del cual el usuario pueda obtener la rabby wallet descarga en su navegador preferido.

Una vez confirmado que Rabby está disponible, el siguiente paso es solicitar acceso a las cuentas del usuario. Esto se realiza llamando a eth_requestAccounts, que devuelve una promesa que se resuelve con un array de direcciones de Ethereum. Si el usuario rechaza la solicitud, la promesa es rechazada. Es crucial manejar ambos casos: el éxito y el error. En caso de éxito, almacena la primera dirección del array como la cuenta activa. En caso de rechazo, muestra un mensaje explicando que la aplicación necesita acceso a la billetera para funcionar.

Después de obtener las cuentas, tu código debe consultar la red actual usando eth_chainId. Este método devuelve un string hexadecimal que representa el identificador de la cadena. Por ejemplo, “0x1” representa Ethereum Mainnet, “0xa4b1” es Arbitrum, y “0x89” es Polygon. Tu aplicación debe comparar este valor contra las redes que soporta. Si el usuario está en una cadena no soportada, debes sugerirle que cambie de red o mostrar un mensaje indicando que tu dApp funciona solo en ciertas blockchains.

Para cambiar de red automáticamente, usa el método wallet_switchEthereumChain pasando el chainId destino. Rabby intentará cambiar a esa red. Si la red no existe en el wallet del usuario, puedes registrarla usando wallet_addEthereumChain, proporcionando detalles como el nombre de la red, RPC URLs, símbolo nativo y parámetros de explorador de bloques. Este flujo automático mejora significativamente la experiencia de usuario en aplicaciones multi-cadena, eliminando la necesidad de que el usuario busque manualmente cómo conectar a Optimism o Avalanche.

Construcción y firma de transacciones con seguridad

Cuando un usuario desea interactuar con un smart contract a través de tu dApp, necesitas construir una transacción y enviarla a Rabby para firma. El proceso comienza creando un objeto de transacción con los campos estándar: to (dirección del contrato), from (dirección del usuario, obtenida previamente), value (cantidad de wei a enviar si es un pago de ETH), data (encoded function call del contrato), gas (límite de gas estimado) y gasPrice o maxFeePerGas/maxPriorityFeePerGas para transacciones EIP-1559.

Aquí es donde Rabby destaca entre otros wallets: implementa simulación de transacciones antes de que el usuario firme. Esto significa que antes de presentar la transacción para firma, Rabby ejecuta la llamada de contrato localmente contra el estado actual de la blockchain para determinar si tendrá éxito o fallará. Si la simulación detecta un error —por ejemplo, fondos insuficientes, allowance no configurado, o una lógica de contrato que revierte— Rabby muestra un mensaje de advertencia claro al usuario. Este mecanismo previene que usuarios firmen transacciones que van a fallar, ahorrando gas y frustración.

Para aprovechar esta característica, asegúrate de que tu construcción de transacciones sea precisa. Usa librerías como ethers.js o web3.js para encoding de data. Un error común es calcular incorrectamente el gas requerido; siempre usa eth_estimateGas antes de firmar para obtener una estimación del costo real. Rabby reconocerá si tu estimación es completamente inexacta y te alertará. Otro error frecuente es incluir valores numéricos incorrectos; siempre convierte montos a wei usando las herramientas apropiadas de la librería, nunca hardcodees conversiones manuales.

Una vez que la transacción está construida correctamente, envíala usando eth_sendTransaction. Rabby mostrará una ventana popup con los detalles de la transacción, permitiendo que el usuario revise antes de firmar. Tu aplicación debe manejar la promesa devuelta: si se resuelve, contiene el hash de transacción; si se rechaza, el usuario canceló la firma. Nunca asumas que porque llamaste a eth_sendTransaction la transacción fue aceptada; siempre espera la promesa y maneja ambos casos.

Manejo de eventos y cambios de red

Rabby emite eventos que tu aplicación debe escuchar para mantenerse sincronizada con el estado del wallet. El evento chainChanged se dispara cuando el usuario cambia de red. El evento accountsChanged se dispara cuando el usuario cambia de cuenta o desconecta el wallet. Estos eventos son críticos porque tu UI debe reflejar el estado actual; si el usuario estaba en Ethereum pero cambió a Arbitrum, tu aplicación debe actualizarse automáticamente sin que el usuario tenga que recargar la página.

Para escuchar chainChanged, usa window.ethereum.on(‘chainChanged’, callback). En el callback, consulta la nueva cadena usando eth_chainId y actualiza el estado de tu aplicación. Si la nueva cadena no es soportada, muestra un mensaje o deshabilita ciertas características. Para accountsChanged, el callback recibe un array de direcciones; si está vacío, significa que el usuario desconectó el wallet; si contiene nuevas direcciones, significa que el usuario cambió de cuenta.

Un patrón recomendado es que tu aplicación chequee periódicamente si aún tiene permisos para acceder a accounts. Algunos usuarios pueden revocar acceso manualmente desde Rabby. Si intentas usar eth_accounts después de que el usuario revocó permisos, recibirás un array vacío. Manejar esto elegantemente significa mostrar un botón “Conectar” nuevamente en lugar de fallar silenciosamente.

Gestión avanzada de aprobaciones y contratos inteligentes

En aplicaciones DeFi es frecuente que los usuarios deban aprobar contratos para gastar tokens en su nombre. Esto requiere una transacción separada que llama a la función approve del contrato ERC-20. Rabby gestiona estas aprobaciones de forma visual intuitiva, mostrando al usuario exactamente cuántos tokens está aprobando y a cuál dirección. Sin embargo, como desarrollador, debes ser consciente de algunos patrones inseguros.

El patrón incorrecto es solicitar un approve con una cantidad gigante (tipo uint256.max) para que “nunca expire”. Aunque es conveniente, representa un riesgo de seguridad: si el contrato que recibe la aprobación es comprometido, puede gastar todos los tokens del usuario. Rabby ahora advierte sobre aprobaciones excesivas en su interfaz. El patrón seguro es solicitar el monto exacto que el usuario necesita gastar, o máximo un poco más para múltiples transacciones, pero nunca cantidades ilimitadas.

Cuando construyas transacciones de approve, recuerda que debes esperar confirmación. El flujo correcto es: 1) usuario aprueba, 2) promesa se resuelve con hash de tx, 3) esperas confirmación del bloque, 4) luego ejecutas la transacción que realmente usa el allowance. No intentes usar el allowance en el mismo bloque donde fue aprobado; la mayoría de redes requieren confirmación de bloques anteriores. Rabby no puede firmar transacciones simultáneamente, por lo que el usuario debe completar la aprobación antes de que tu aplicación solicite la transacción posterior.

Manejo robusto de errores y reintentabilidad

Las transacciones en blockchain fallan por muchas razones: gas insuficiente, nonce incorrecto, smart contract revierte, red congestionada, o el usuario rechaza la firma. Tu código debe manejar cada escenario. Si eth_sendTransaction rechaza con un mensaje que mencionada “User rejected”, simplemente muestra un mensaje amable diciendo que la transacción fue cancelada. Si rechaza con “Insufficient funds”, el usuario necesita más saldo. Si es “contract execution reverted”, significa que la lógica de contrato falló; muestra el mensaje de error al usuario si es disponible.

Nunca reintentes automáticamente una transacción rechazada sin intervención del usuario. El motivo del fallo usualmente no se resuelve solos. Si el contrato falló una vez, fallará de nuevo a menos que cambie el estado de la blockchain. Lo que sí puedes hacer es permitir que el usuario intente de nuevo manualmente después de revisar el error y potencialmente ajustar parámetros.

Para transacciones pendientes, debes monitorear el estado. Después de obtener el hash de transacción de eth_sendTransaction, consulta regularmente eth_getTransactionReceipt pasando el hash. Si devuelve null, la transacción aún está pendiente. Si devuelve un objeto con status, verifica que sea 0x1 (éxito) o 0x0 (fallo). Algunos desarrolladores usan event emitters o websockets para ser notificados cuando una transacción se confirma, pero el polling simple también funciona bien para la mayoría de casos de uso.

Testing y debugging con Rabby en desarrollo local

Para probar tu integración, instala Rabby en modo desarrollo. Descárgalo desde GitHub, descomprimelo, y cárgalo como extensión no empaquetada en Chrome. Abre las DevTools (F12) de tu aplicación local y verifica que window.ethereum.isRabby sea true. Usa la consola para llamar manualmente a window.ethereum.request({ method: ‘eth_accounts’ }) y confirma que devuelve un array con direcciones.

Configura una red de prueba como Sepolia en Rabby y asegúrate de que tu dApp puede cambiar a ella. Prueba eth_chainId y confirm que devuelve el hexadecimal correcto para Sepolia. Construye una transacción de prueba —incluso una simple transferencia de ETH— y envíala. Abre la ventana de firma en Rabby y verifica que muestra los detalles correctos. Si Rabby simula y muestra un error, investiga por qué; el bug está en tu construcción de transacción.

Para contratos inteligentes, compila y deploya un ERC-20 simple en tu red de prueba. Escribe código en tu dApp que intente interactuar con este contrato. El ciclo de feedback es: 1) tu dApp construye tx, 2) Rabby simula, 3) Rabby muestra advertencias si hay problemas, 4) tú arreglas tu código. Este flujo es mucho más seguro que lanzar directamente a producción. Cuando estés seguro de que todo funciona en testnet, solo entonces deploya el contrato real en mainnet.

Buenas prácticas de seguridad para desarrolladores

La seguridad en integraciones de wallet no es solo responsabilidad de Rabby; también depende de cómo construyas tu aplicación. Nunca solicites información sensible que Rabby no debería exponer, como mnemónicos o claves privadas; si alguien te dice que lo hagas, es una bandera roja. Rabby está diseñado específicamente para que jamás debas tener acceso a esos datos.

Valida siempre que window.ethereum.isRabby sea true, no solo que window.ethereum exista. Múltiples wallets pueden estar instalados y podrían interferir. Usa mecanismos de consenso si tu dApp interactúa con contratos críticos; considera requerir múltiples signatarios o firmas oracle para transacciones de alto valor. Implementa rate limiting en tu backend para prevenir que un actor malicioso abuse de tu API enviando miles de requests.

Cifra datos sensibles en tránsito usando HTTPS. Nunca stores claves API de blockchain en el frontend; mueve ese código al backend. Si usas RPC pública, considera usar un servicio de RPC privado como Alchemy o Infura para evitar race conditions en high-frequency applications. Audita tu código de interacción con contratos; un error en la construcción de data puede llevar a que usuarios aprueben algo diferente a lo que vieron.

Integración con librerías y frameworks modernos

Si utilizas ethers.js, la integración es directa. Crea un BrowserProvider usando window.ethereum y Rabby lo proporcionará como backend. Con wagmi o ethers hooks, la conexión es casi automática; estas librerías detectan y conectan wallets compatibles con EIP-1193. Web3.js también funciona, aunque tiene una API ligeramente diferente. Para React, hay useAccount, useChainId y useContractWrite de wagmi que hacen que la integración sea mucho más simple que conectar directamente a window.ethereum.

Un patrón moderno es usar una librería como “connectkit” o “rainbowkit” que abstractiza la lógica de conexión de múltiples wallets. Estos toolkits automáticamente soportan Rabby sin que hagas nada especial, porque Rabby es compatible con EIP-1193. Lo importante es que eligas una librería mantenida activamente que siga siendo compatible con especificaciones web3 emergentes.

Para aplicaciones de servidor, considera usar ethers.js JsonRpcProvider directamente contra un nodo. Los wallets como Rabby son para el frontend; en el backend usas RPC nodes directamente. Si necesitas firmar transacciones desde el servidor, usa una solución de gestión de claves como AWS KMS o un hardware security module, nunca hardcodees claves privadas en código.