¿Cómo acota una pasarela el riesgo de la billetera caliente?

Un procesador custodial guarda una clave capaz de mover tu saldo. Nada de lo que viene abajo cambia eso. Lo que cambian los controles es de cuántas maneras se puede fabricar una transferencia que esa clave acepte firmar, y cada uno cierra una vía dejando otras abiertas. Un control nombrado sin su límite vale menos que uno nombrado con él: el límite es donde hay que poner a una persona.

La clave está caliente por una razón de lo más corriente. Un comercio pulsa enviar a las dos de la madrugada en un huso donde no hay nadie despierto en el proveedor, y la transferencia hay que construirla, firmarla y difundirla igual. El almacenamiento en frío es justo la ausencia de eso: una clave que necesita a un humano delante no puede contestar a una petición de retiro. Cualquiera que pague a demanda opera una billetera caliente, la llame como la llame.

Así que la pregunta nunca fue si la clave está en línea. Es qué tiene que sobrevivir una petición antes de que la clave llegue a verla.

El robo más grande no rompió ninguna clave

Porque la transacción la firmó justo quien tenía que firmarla.

El 21 de febrero de 2025 o en torno a esa fecha salieron de Bybit unos 1.500 millones de dólares en activos virtuales, y cinco días después el FBI atribuyó el robo a Corea del Norte.

Una semana después del robo, la Safe Ecosystem Foundation describió la vía en su propio comunicado: el ataque al Safe de Bybit «was achieved through a compromised Safe{Wallet} developer machine», y de ahí salió «the proposal of a disguised malicious transaction».

Varias personas la aprobaron. La multifirma hizo su trabajo sobre la transacción equivocada, y el número de firmas no fue nunca la variable. Ese es el examen que conviene pasarle a todo lo que viene abajo: ¿qué hace este control cuando la petición ya parece legítima?

Antes de la clave: qué credencial puede pedir un retiro

Una de las dos, y solo una.

Un comercio tiene una credencial de cobro y una de retiro por entorno. La Payment cubre facturas y canales de pago; la Payout, los retiros. Ninguna alcanza el terreno de la otra, así que una clave de cobro que se escapa por un plugin, por un log o por un portátil no puede crear un retiro: no tiene ese acceso que abusar. El alcance se comprueba en el servidor en cada petición, no en la pantalla.

Al lado van dos condiciones que se olvidan el primer día. Una clave Payout tiene que llevar una lista de IP, y autenticar con la lista vacía se rechaza en vez de leerse como «sin restricción»; una clave Payment no puede llevar lista ninguna, porque el tráfico de cobro está pensado para llamarse desde donde estén tus clientes.

Y no hay una clave por servicio ni por tienda que emitir. Hay una clave activa de cada tipo por entorno, cuatro en total, sin nombre y sin caducidad, y anular una es definitivo. Eso pertenece a un plan de incidentes antes que a un folleto: una fuga no se contiene anulando la integración por la que se fue, porque todas las integraciones de ese entorno llevan la misma clave.

La lista blanca carga con casi todo

Acota hacia dónde puede ir el dinero. Ni cuánto, ni quién lo pidió, ni si la dirección sigue siendo tuya.

La mecánica se lee entera de una sentada:

• Con la lista vacía no sale nada. No se interpreta como «sin restricción»: apaga los retiros.
• Una entrada va por dirección y familia de redes. Aprobar una dirección EVM cubre de un plumazo Ethereum, BSC, Polygon, Arbitrum, Optimism, Base, Avalanche y Plasma; Tron, TON y Solana son familias propias.
• Solo cuatro familias admiten lista blanca, y por eso NEAR y Sui aceptan pagos y no pueden recibir un retiro.
• Quitar una entrada la revoca en lugar de borrarla, así que el rastro de a quién se podía pagar, y desde cuándo, queda entero.
• Una aprobación admite hasta 1.000 direcciones, un archivo CSV hasta 1.000 líneas, y una cuenta guarda como mucho 5.000 entradas activas.
• Nada de esto tiene ruta de API. La lista se gestiona en el panel.

La última línea merece una pausa. La credencial que mueve dinero no puede ensanchar el conjunto de sitios a los que moverlo, y esa separación sobrevive a una configuración mal hecha, porque la ruta para hacerlo por API no llegó a construirse nunca.

Ahora los límites. Una lista blanca afirma algo sobre la dirección del dinero y nada sobre su propiedad: un comercio puede aprobar a propósito la dirección de un cliente o de un jugador y pagarle, que es como funcionan aquí los pagos a usuarios finales. Una dirección aprobada en marzo para la billetera de un colaborador que ya se fue sigue aprobada en septiembre.

Del tamaño tampoco dice nada. Dos límites de cuenta sí se aplican a un retiro —cuánto cabe en uno solo y cuántos hay en vuelo al mismo tiempo— y lo que te queda libre se ve en el formulario antes de escribir nada, en lugar de llegar después como un rechazo. Esos acotan un movimiento; la lista acota una dirección. Un retiro puede caber holgado en los dos y aun así ir a un sitio que esta mañana no habrías elegido.

Quién aprueba un destino y quién manda el dinero

Menos gente de la que puede enviarle dinero, y es a propósito.

Gestionar la lista blanca es de serie cosa del rol Propietario. El rol Finanzas ejecuta retiros hacia los destinos que aprobó el Propietario y no puede aprobar ninguno; el rol Administrador no tiene de serie ningún permiso de retiro. El glosario del NIST resume el principio con una nómina: nadie debe tener privilegios suficientes para abusar del sistema por su cuenta, y quien autoriza una nómina no es quien la prepara.

Los valores de serie son una posición de partida, eso sí, y a un miembro concreto se le pueden conceder permisos extra. La separación aguanta mientras nadie la regale y se olvide, lo que convierte la pantalla de permisos en parte de este control.

La segunda capa de ese instante es una verificación reforzada, y no es incondicional. A un usuario del comercio que no tiene ni TOTP ni passkey no se le pregunta nunca, porque una verificación refuerza un factor que ya existe y no puede exigir uno que no está. Leída como una defensa que la cuenta ya tiene, no lo es. Lo que aguanta en los dos casos es la lista: un retiro solo puede nombrar una dirección que esté en ella, añadir una es una acción registrada por derecho propio, y una lista vacía significa cero retiros.

Donde sí salta, la verificación va atada a la acción que aprueba y se gasta al usarla, en lugar de quedarse abierta sobre la cuenta. Fíjate dónde está puesta. El retiro no pide verificación; el cambio en la lista sí. Se vigila la puerta y no cada salida por ella, que es el argumento entero para tener esa lista corta.

¿Qué aísla exactamente la infraestructura de firma?

Al firmante de las superficies que un comercio o quien paga pueden alcanzar.

Las transacciones de salida de Paymos se firman lejos del camino web público, y un retiro solo puede nombrar un destino que el comercio aprobó antes. El aislamiento es una propiedad de alcance: acorta la lista de cosas capaces de poner una petición delante de la clave. Es trabajo de verdad, y es menos de lo que sugiere la palabra, porque no hace nada contra una petición que entra por la puerta principal con una firma válida.

Tampoco reparte la potestad de firmar, y nada de esto hay que leerlo como si lo hiciera. Esto es custodia gestionada: el comercio autoriza, el proveedor opera la firma y la difusión, y si ese canje le conviene a tu negocio es una decisión sobre el modelo de custodia que se toma antes de que ninguno de estos controles valga la pena leerlo.

La pregunta siguiente de cualquier tesorero tiene respuesta corta. Un saldo en Paymos no se presta ni le renta nada a Paymos mientras está ahí quieto, y se lleva por separado en el libro de Paymos, por partida doble.

¿Qué detiene un retiro que ya va en camino?

Cada vez menos cosas, y conviene saber la forma de esa cuesta antes que el día que toque.

Cancelar es una ventana del principio, no una recuperación. Un retiro se puede cancelar mientras siga en created y la ejecución no haya arrancado; repetir la cancelación sobre uno ya cancelado responde 200 y no hace nada. Pasado ese punto la transferencia es de la cadena, y la lista blanca resulta ser lo único que hubo entre la petición y una transacción irreversible.

Las congelaciones trabajan por encima del retiro individual. Hay una congelación general de salidas y otra para un par concreto de activo y red, y esta última se levanta sola: cuando el libro y la billetera se separan más allá de una tolerancia configurada, ese par se detiene sin esperar a que nadie se dé cuenta. Es un mecanismo de seguridad haciendo su trabajo: un desacuerdo contable detiene aquello sobre lo que discrepa, antes de que nadie haya averiguado qué lado se equivoca.

Aparte de eso, una ruta de salida de un activo en una red puede quedarse no disponible durante un rato. Se rechaza en la puerta en lugar de encolarse: el par no aparece en el selector, una petición que lo nombre se rechaza al crearla y el saldo no se toca. Los rechazos salen baratos aquí por construcción: crear un retiro aparta el importe más su comisión de red en una retención, y el que termina sin llegar a la cadena la devuelve entera, comisión de red incluida. Repetir también sale barato, porque external_order_id es único por comercio y repetir la creación devuelve el retiro que ya existe en vez de mandar un segundo.

¿Por qué un retiro fallido dice tan poco?

Porque la alternativa es una cadena de texto interna aterrizando en la pantalla de un comercio.

El motivo por el que falló un retiro no se le muestra al comercio. Lo que se muestra sale del estado —un conjunto cerrado de resultados— y dice que el retiro no salió, que la retención se ha soltado y adónde preguntar. Un estado cerrado en el punto de pintado y nunca una cadena que venga de más abajo: ese es el patrón.

El coste cae del lado del comercio, y el motivo no es lo único que falta. Un retiro que no sale no manda correo ni pone nada en la campana, así que de un fallo te enteras por el webhook o no te enteras. Cuánto tarda el resto de un retiro es asunto de otra página.

Las preguntas que hay que hacerle a un custodio

Empieza por el saldo que está parado y sigue por las personas.

¿Se presta, se bloquea en staking o le renta algo al proveedor mientras está ahí? Luego: qué rol aprueba un destino, si ese mismo rol puede además enviarle dinero, y qué hace la verificación cuando cambia la lista en una cuenta donde nadie activó un segundo factor. Una buena respuesta nombra un rol y una verificación, no un equipo. Y por último, qué te cuentan cuando un retiro no sale y por qué canal: quien conteste «te avisamos por correo en cada paso» o ha construido algo que nosotros no tenemos, o no ha leído su propio código de notificaciones.

Un control carga más peso que los demás, y es la lista de direcciones aprobadas. Funciona en proporción a lo corta que sea, y el momento que hay que vigilar es aquel en que cambia. Por eso en Paymos ese cambio de serie solo lo hace el Propietario, queda registrado, no tiene ruta de API y es el que pide un segundo factor, mientras que el retiro que autoriza después no pide ninguno.