Wallets hot, warm y cold: exposición frente a velocidad

Es viernes a las 18:40. Un cliente institucional pide retirar 180 000 USDC y la wallet que firma sola, sin intervención humana, tiene 60 000. El resto está en una wallet que exige dos aprobadores, y la mayor parte del saldo vive en una wallet cuyas llaves no tocan internet. Nadie hizo nada mal: el sistema está diseñado para que ese retiro tarde. La pregunta de este capítulo es si tarda lo que el negocio aceptó, o lo que salió por casualidad.

La respuesta no es técnica, es una política: cuánto saldo puede estar expuesto en cada nivel, cuándo se mueve dinero entre niveles y cuántas personas aprueban según el monto. Aquí la construimos paso a paso, apoyándonos en lo que ya vimos sobre llaves y tipos de firma.

Qué mide la temperatura de una wallet

Una wallet es el conjunto de direcciones que controla una misma llave o un mismo esquema de firma. Su temperatura describe cuánto esfuerzo cuesta producir una firma válida. No es una marca de producto ni un tipo de criptografía: es una propiedad operativa.

• Una wallet hot (caliente) firma con la llave accesible desde sistemas conectados a la red. Puede firmar en segundos y sin una persona en el circuito. Es la que paga los retiros cotidianos.
• Una wallet warm (templada) también firma en línea, pero solo después de una o más aprobaciones humanas o de un control adicional. Funciona como colchón entre la operación y la reserva.
• Una wallet cold (fría) guarda la llave fuera de línea. Firmar exige un procedimiento físico o un tercero, y eso cuesta horas.

Los proveedores usan esta misma escala, aunque con nombres distintos. Fireblocks distingue workspaces "hot" (en línea) y "cold" (fuera de línea) dentro del mismo dominio de cliente. [1] BitGo declara que todas sus wallets de custodia son frías y que sus wallets de autocustodia son más flexibles, pero menos seguras que las frías. [2]

La temperatura tampoco se confunde con el tipo de firma del capítulo anterior. Una wallet multifirma puede ser hot si sus llaves están en servidores, y una wallet MPC puede ser cold si un fragmento solo se usa en un equipo aislado. Lo que cambia la temperatura es dónde vive cada llave o fragmento, y cuántos pasos humanos hay antes de firmar.

Exposición frente a velocidad: cuánto saldo en cada nivel

La regla de diseño es sencilla de enunciar: en la wallet hot debe haber lo justo para atender los retiros que llegan antes de que alguien pueda reponerla. Todo lo demás es exposición innecesaria. Si un atacante obtiene la llave hot, el radio de impacto (cuánto puede perderse de una vez) es el saldo de esa wallet, no el total de la tesorería.

Para dimensionar cada nivel conviene pensar en tiempos, no en porcentajes. Tres datos bastan para un primer cálculo:

1. El flujo neto de salida esperado por hora en el peor día normal (retiros menos depósitos).
2. El tiempo de reposición desde el nivel siguiente: cuánto tarda conseguir las aprobaciones y firmar desde warm hacia hot.
3. Un margen para picos que el negocio acepta cubrir sin esperar.

Con esos datos, el máximo hot es aproximadamente el flujo neto por hora multiplicado por las horas de reposición, más el margen. El mismo razonamiento, con días en lugar de horas, da el máximo warm. Lo que exceda ambos va a cold. Es una aproximación ilustrativa: cada red y cada activo tienen su propio patrón, y la cifra se revisa con datos reales cada trimestre.

BitGo propone exactamente esta estructura en su arquitectura de referencia para custodia: tres wallets por moneda. Una wallet de custodia fría con la mayor parte de los activos, una wallet "standby" de autocustodia con un saldo intermedio, y una wallet de depósito y retiro con el saldo más pequeño, que permite retiros pequeños sin aprobaciones. [3] En la escala de este capítulo, la standby es la wallet warm.

El otro lado del compromiso es la velocidad de la reserva. BitGo indica un acuerdo de nivel de servicio de 24 horas para completar retiros en cadena desde sus wallets de custodia. [2] Ese número es el que debe aparecer en el contrato con los clientes si un retiro grande depende de la reserva fría.

Barridos y reposición: el circuito entre temperaturas

Un cliente deposita 5 000 USDC en una dirección que le asignamos. Ese depósito llega a la wallet hot o a una dirección intermedia. Si nadie lo mueve, el saldo hot crece con cada depósito y la regla del apartado anterior deja de cumplirse. Por eso existe el barrido (sweep): una transacción que consolida saldos hacia el nivel siguiente.

Figura 1

Circuito de barrido y reposición entre temperaturas

Fuentes:

[3]

Cómo leer esta figura

Cuatro cajas en fila: Exterior, con clientes y contrapartes; Hot, con llave en línea y saldo de horas; Warm, con firma con aprobación y saldo de días; Cold, con llave fuera de línea y la mayor parte del saldo. Flechas azules: 1, depósito del exterior a hot, y 4, retiro de hot al exterior. Flechas verdes por arriba: 2, barrido de hot a warm cuando el saldo supera el máximo hot, y 3, barrido del excedente de warm a cold. Flechas ocres por abajo: 5, reposición de warm a hot cuando el saldo cae bajo el mínimo, y 6, reposición mayor de cold a warm con quórum. Debajo, una tabla: aprobaciones de 0 a 1 automática en hot, 1 a 2 personas en warm y quórum m de n en cold; tiempo de salida de segundos a minutos, de minutos a horas y de horas a un día. Una flecha roja de cold hacia hot indica más exposición en línea y más velocidad.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

El circuito tiene seis movimientos y cada uno necesita una regla escrita: depósito, barrido a warm, barrido a cold, retiro, reposición menor y reposición mayor. BitGo describe el mismo flujo: acumular en la wallet de depósito, subir excedentes a standby y de ahí a custodia, y reponer en sentido inverso cuando cada nivel se queda corto. [3]

Cuándo barrer. Fireblocks documenta tres estrategias válidas: barrer justo después de cada depósito, barrer al acumular cierto saldo o número de depósitos, o barrer solo cuando la comisión de red baja de un umbral. [4] La elección depende de cuánto cuesta cada transacción en esa red y de cuánto tiempo aceptamos tener saldo en direcciones intermedias.

Quién paga la comisión. Barrer un token ERC-20 desde una dirección de depósito exige que esa dirección tenga el activo nativo de la red para pagar gas. Fireblocks resuelve esto con Gas Station, que transfiere el activo nativo desde una cuenta "tanque" del propio workspace hacia las cuentas con auto-fueling activado. [5] BitGo usa "gas tanks", wallets de comisión por empresa que pagan el gas en redes EVM. [6] En los dos casos, el tanque es una wallet hot más que hay que vigilar y limitar.

Barrido automático y firma automática. Un barrido automatizado necesita también una firma automatizada. Fireblocks recomienda un API Co-Signer para firmar los barridos según la lógica de la organización. [4] Eso significa que la regla de barrido debe restringir el destino: un barrido solo puede ir a una wallet propia de la temperatura siguiente. BitGo lo plantea con listas blancas entre las tres wallets, para que los fondos solo se muevan entre destinos designados. [3]

Depósitos sin llave privada. No hace falta que el servidor que genera direcciones de depósito tenga una llave privada. BIP-32 describe cómo un servidor no confiable puede generar direcciones de recepción con una clave pública extendida: si alguien lo compromete, ve los pagos entrantes pero no puede gastarlos. [7] La contrapartida, que vimos en cuentas, claves y direcciones, es que esa clave pública extendida no debe circular junto a ninguna llave privada hija no endurecida.

Direcciones de depósito, consolidación y gas según el tipo de red

Un cliente envía 5 000 USDC por Ethereum y otro 2 000 ATOM por Cosmos. En Ethereum, su dirección de depósito luego hay que vaciarla hacia la wallet que paga retiros; en Cosmos basta un identificador en el mensaje. Esta sección aplica sobre todo al Middleware Blockchain, que asigna direcciones de depósito por cliente.

Forwarders de BitGo y redes con memo

En redes de cuentas, BitGo solo puede retirar desde la dirección base de cada wallet: si la wallet tiene varias direcciones de recepción, hay que consolidar periódicamente sus saldos hacia la base. Para la mayoría de las redes EVM, que no soportan varias direcciones de recepción de forma nativa, BitGo usa un contrato forwarder por dirección. Esas direcciones son de una sola firma, la controla la llave BitGo, y solo pueden enviar a la dirección base de su wallet; esa firma única es lo que permite la consolidación automática. [14]

Dos matices de la misma página afectan al diseño. Primero, la consolidación automática de tokens se puede desactivar con flushForwardersManually, pero las monedas nativas se siguen consolidando solas. Segundo, varias redes (Cosmos, Hedera, EOS y otras) usan memo IDs o destination tags junto a la dirección base: no hay consolidación y lo depositado queda disponible de inmediato en el saldo gastable. [14] La contrapartida es que la atribución al cliente depende por completo del memo y del libro interno; ese libro se trata en el módulo 8.

Quién paga el gas del barrido

Barrer USDC en Ethereum exige ETH en la cuenta de origen: Fireblocks lo dice con ese mismo ejemplo y recuerda que, al ser una transferencia en la cadena, el barrido paga comisión. Ofrece dos mecanismos. Gas Station empuja ETH a cada cuenta intermedia antes del barrido, así que esas cuentas guardan y gastan gas. Universal Gasless (EVM Gasless) usa un relay que patrocina el gas durante la transacción, de modo que las cuentas intermedias nunca necesitan ETH; cubre tokens ERC-20, ERC-721 y ERC-1155, pero no transferencias de ETH nativo, para las que sigue haciendo falta Gas Station. El relay puede ser una bóveda de este workspace, otro workspace o el propio Fireblocks. [16]

BitGo centraliza el gas en gas tanks: wallets de comisión a nivel de empresa que pagan el gas en redes EVM; cualquier activo en una red EVM, nativo o token, requiere uno. TRON es la excepción documentada: un gas tank en TRX financia las direcciones de recepción para consolidar tokens TRC-20. [6] Con cualquiera de las tres opciones, el saldo de gas es una wallet hot más: necesita máximo, mínimo y alerta.

Límites de las reglas de automatización de Fireblocks

Las reglas de automatización de barrido de Fireblocks hacen un barrido por depósito: se ejecutan cuando llega un depósito y barren desde esa cuenta. No agrupan depósitos, no corren por calendario y no miran la comisión de red; para esas estrategias hay que crear los barridos por API. [4] En la práctica: si el disparador elegido arriba es "por saldo acumulado" o "por comisión", el equipo escribe y opera ese servicio; la regla nativa solo cubre "inmediato".

Límites y aprobaciones por monto

Un retiro de 900 USDC y uno de 900 000 USDC no deben seguir el mismo camino. La política asigna un nivel de aprobación según el monto, el destino y la ventana de tiempo. Un límite por transacción acota cada movimiento; un límite por periodo (o de velocidad) acota la suma en una ventana, por ejemplo 24 horas.

El límite por periodo es el que protege contra el ataque paciente: muchos retiros pequeños, cada uno bajo el umbral, que juntos vacían la wallet. Sin un límite de velocidad, un umbral por transacción solo obliga al atacante a fraccionar.

Fireblocks describe tres formas de operar según el valor. Un proceso manual para montos grandes, con inicio en consola, aprobación en el móvil de personas designadas y firma por la misma persona u otra. Un proceso semiautomático para montos intermedios que aún requieren verificación humana. Y un proceso totalmente automático para movimientos internos o retiros pequeños. [8] Esos tres procesos encajan con cold, warm y hot.

BitGo ofrece tipos de regla que cubren cada dimensión del límite: por destino, por iniciador, por porcentaje del saldo de la wallet, por umbral de monto y por límite de velocidad en una ventana de tiempo. [9] Cada regla se define como un alcance, un evento que la dispara, una condición y una acción, que puede ser exigir una aprobación o aprobar o rechazar automáticamente. [10]

Una advertencia que pocas políticas recogen: en BitGo, las transacciones de recuperación que usan la llave de usuario y la llave de respaldo no pasan por las políticas configuradas en la plataforma. [9] El procedimiento de recuperación del capítulo de llaves necesita, por tanto, su propio control fuera del motor de políticas.

Hay un segundo tipo de exposición que la temperatura no ve. En Ethereum, approve de ERC-20 autoriza a un tercero a retirar varias veces hasta el monto aprobado. [11] Con permit, esa autorización se concede con un mensaje firmado en lugar de una transacción. [12] Una wallet hot que firma aprobaciones amplias deja abierto un permiso que sobrevive a la sesión; el análisis completo está en approvals, permit y phishing de firmas. La política de la wallet hot debe limitar qué contratos pueden recibir aprobaciones y por cuánto.

Cómo lo resuelven Fireblocks, BitGo y Kaleido

Los tres proveedores permiten montar las tres temperaturas, pero cada uno parte de un lugar distinto. La tabla compara criterios, no calidad; cada fila sin fuente explícita queda marcada para validar con el proveedor y con el contrato.

Fuentes por columna. Fireblocks: estructura de workspaces, [1] barridos y reglas de automatización, [4] gestión de tesorería en wallets hot y cold con reglas de autorización [13] y procesos por valor. [8] BitGo: arquitectura de tres wallets, [3] consolidaciones [14] y tipos de regla. [9] Kaleido: su página de producto afirma soporte para wallets hot, warm, cold y air-gapped, reglas de barrido, umbrales y políticas que evalúan monto, velocidad, contraparte o resultado de screening antes de firmar. [15] La documentación técnica de Kaleido requiere acceso, así que el detalle de cómo se configura cada regla queda a validar con el proveedor.

Un criterio práctico para elegir: si la reserva fría debe estar con un custodio regulado, la arquitectura de BitGo ya separa custodia de autocustodia por wallet. Si la prioridad es automatizar barridos y comisiones en muchas cuentas de depósito, la combinación de reglas de automatización y Gas Station de Fireblocks reduce código propio. Si las llaves deben quedarse en el HSM de la organización, Kaleido declara que no genera ni guarda las llaves. [15] Las tres afirmaciones se confirman en la prueba de concepto, no en la propuesta comercial.

Decisiones que el equipo debe cerrar

Entregable: política de tesorería por temperatura

La política cabe en una tabla por activo y red. Las cifras de ejemplo son ilustrativas; las reales salen del cálculo de saldo descrito arriba.

Si el equipo prefiere guardar la política como datos versionados, este esquema ilustrativo muestra la forma mínima. No es la sintaxis de ningún proveedor; cada uno tiene su propio formato de reglas.

# Boceto ilustrativo: política de tesorería por temperatura (no es sintaxis de proveedor)
asset: USDC
network: ethereum
tiers:
  hot:
    max_balance: 60000
    min_balance: 20000
    per_tx_limit: 10000
    daily_limit: 80000
    approvals: 0
    allowed_destinations: [verified_customers, warm]
  warm:
    max_balance: 600000
    min_balance: 150000
    per_tx_limit: 250000
    approvals: 2
    allowed_destinations: [hot, cold]
  cold:
    approvals: "3-of-5"
    allowed_destinations: [warm]
sweeps:
  hot_to_warm: { when: "balance > max_balance", target: "max_balance * 0.6" }
  warm_to_cold: { when: "balance > max_balance", target: "max_balance * 0.7" }

Con la política escrita, la siguiente pregunta es quién responde por cada wallet y quién puede cambiar estas cifras. Eso es custodia, el módulo 5.