Paso 1: lee lo que la transacción hace realmente
Antes de que cualquier clave toque una transacción multifirma, lee su contenido en lenguaje llano: a qué contrato llama, qué método ejecuta y qué hacen los argumentos. Una pantalla que muestra hexadecimal en bruto no es una lectura, es una suposición, y toda la rutina que sigue existe porque esa suposición es donde empiezan las pérdidas.
Toda transacción dirigida a un contrato lleva un payload: la dirección de destino, la función que va a llamar y los parámetros. En bruto es hexadecimal, y la pequeña pantalla de un dispositivo de firma suele mostrar exactamente eso. Leerlo significa conseguir que el payload se traduzca a palabras, de modo que lo que apruebas sea una frase y no un borrón.
Safe{Wallet} Monitor hace esta traducción como su primera tarea: toma el contenido de la transacción y lo traduce en explicaciones claras y legibles para las personas sobre lo que hará la llamada. El sentido del paso no es la herramienta; es el estándar. Una transacción cuyo efecto no puedes enunciar en una frase no está lista para tu firma.
La razón por la que este paso va primero está escrita en la mayor pérdida de 2025. En el incidente de Bybit de febrero de 2025, cerca de 1.500 millones de dólares salieron del exchange después de que la interfaz presentara una transferencia mientras la transacción realizaba en realidad una actualización de contrato. El atacante había desplegado y probado el contrato malicioso dos días antes. Las claves hicieron su trabajo. La lectura nunca ocurrió. La Cybersecurity and Infrastructure Security Agency documenta este tipo de engaño en la cadena de suministro y en la interfaz en sus avisos.
Paso 2: prueba la transacción antes de firmar
La lectura te dice lo que la transacción dice que hará; una ejecución de prueba muestra lo que hará realmente. Ejecuta la transacción en un sandbox que la aplique sobre una copia del estado de la cadena e informe de los resultados: qué saldos se mueven, qué permisos cambian, qué contratos acaban siendo distintos. Después compara ese informe con lo que pretendías.
Un payload puede tener un aspecto honesto y aun así ser incorrecto, porque el efecto real de una llamada a un contrato solo aparece cuando se ejecuta. La prueba no publica nada; ejecuta la transacción sobre una copia de la cadena en sandbox y devuelve las consecuencias. Si creías que estabas aprobando una retirada rutinaria y el informe muestra un delegatecall a un contrato recién creado, tienes la respuesta antes de firmar y no después.
Safe{Wallet} Monitor incluye esto como su paso de comprobación de riesgos y prueba de transacciones: comprueba las transacciones frente a reglas de riesgo y ejecuta la acción para mostrar lo que ocurriría. Para la rutina, lo que importa es el orden: primero leer, después probar, y tratar cualquier discrepancia entre ambos como una señal de parada, no como una curiosidad.
Paso 3: incorpora a alguien que no firme
La tercera comprobación corresponde a una persona que no sea uno de los firmantes. Envía la traducción y el resultado de la prueba a alguien que no firme y obtén su lectura antes de que llegue la firma final. El fallo que esto evita es social, no técnico: el segundo firmante confía en el primero, el tercero confía en el segundo y nadie en la cadena ha mirado de verdad.
La multifirma concentra un riesgo sutil: la propia secuencia de firmas invita a la deferencia. Si la rutina es firmar, firmar, listo, entonces la M de M de N es decoración, y el monedero es en la práctica de firma única con pasos extra. Alguien que no firma, que recibe la transacción decodificada y el resultado de la prueba y que responde con su conformidad, rompe esa cadena de confianza justo a un paso de distancia.
Por eso Safe{Wallet} Monitor envía sus alertas por varios canales a la vez, dirigidas tanto a firmantes como a no firmantes. Un mensaje a un teléfono, un mensaje a una estación de trabajo, entregados por vías que un atacante tendría que controlar todas a la vez para silenciarlas. El supuesto de diseño es directo y correcto: en un ataque dirigido, un dispositivo comprometido no debería bastar para completar una aprobación a ciegas.
Paso 4: establece salvaguardas para las operaciones rutinarias
La última capa son reglas permanentes que actúan sin esperar a nadie. Una lista blanca limita con qué contratos puede interactuar tu monedero, y cualquier cambio genera una alerta. Las reglas de respuesta automática pueden transferir fondos a cuentas de respaldo o pausar contratos cuando la comprobación de riesgos detecta un daño. Juntas convierten la rutina de leerlo todo, cada vez, en revisar las excepciones.
Una lista blanca es la versión aburrida de la seguridad: el pequeño conjunto de contratos que usas realmente, registrado, con cada intento de añadir o sustituir uno marcado para revisión. La mayoría de las semanas, nadie llama a la puerta. La semana en que alguien lo hace, la alerta lo es todo. Los marcos del National Institute of Standards and Technology tratan este enfoque por capas, defensa en profundidad con respuestas automáticas, como la forma básica de una configuración de controles seria.
La capa de avisos permanece activa en todo momento, en la ventana que importa. Una alerta puede llegar después de detectarse un riesgo pero antes de que termine la firma y antes de que la transacción llegue a la cadena. Esa es la única ventana en la que todavía es posible detenerla. Las salvaguardas no sustituyen a la lectura ni a la prueba; atrapan lo que se les escapa a personas cansadas a las 2 de la madrugada.
Un ejemplo práctico: firmar una actualización
Recorre las cuatro comprobaciones con una actualización de contrato. Lee la traducción y observa el destino. Prueba la ejecución y mira cómo cambian los permisos. Envía ambas cosas a alguien que no firme y espera su respuesta. Comprueba la lista blanca para el nuevo contrato y después firma. Minutos extra en total: unos pocos. Lo que habría detectado: el mayor robo de cripto hasta la fecha.
| Comprobación | Qué detecta | En el ejemplo de la actualización |
|---|---|---|
| Leer la traducción | Un destino o método que no es el que se describió | La llamada muestra una actualización, no una transferencia |
| Probar la ejecución | Efectos que solo aparecen al ejecutarse | Cambian los permisos del contrato |
| Revisión por alguien que no firma | Deferencia a lo largo de la cadena de firmas | Un segundo lector cuestiona el cambio |
| Salvaguardas | Contratos fuera de la lista blanca | El nuevo contrato no está en la lista |
Las actualizaciones son el escenario que vale la pena ensayar porque son legítimas, son poco frecuentes y concentran poder: la transacción que actualiza un contrato puede cambiar todo lo que ese contrato haga a continuación. También es exactamente la forma del caso Bybit, donde una actualización disfrazada pasó por una transferencia. La escala tampoco es hipotética: en marzo de 2025, Safe sumaba más de 39,14 millones de monederos creados que custodiaban alrededor de 54.900 millones de dólares (según BlockSec), así que la rutina protege mucho valor real.
El cierre honesto es el mismo que esta familia no deja de repetir. Estas cuatro comprobaciones reducen el riesgo en el lado de la operación: lo que firmas, leído, probado y confirmado. La seguridad de tus dispositivos, tu configuración de firma y tus copias de seguridad sigue siendo un trabajo aparte. ¿Qué es la firma a ciegas en cripto? y Monederos multifirma cubren ese terreno. La herramienta detrás de la rutina está en la página de Safe{Wallet} Monitor, y el hub de riesgo de monederos traza el mapa de toda la familia.