Custodia: quién responde por los activos y quién cambia las reglas

Una auditora externa revisa la operación y hace dos preguntas. La primera: si mañana el proveedor de wallets cerrara, ¿de quién serían los 3 millones de USDC que hoy aparecen en el panel? La segunda: el martes alguien subió el límite diario de la wallet hot de 80 000 a 200 000 USDC; ¿quién lo propuso, quién lo aprobó y dónde está la evidencia?

Si el equipo no puede contestar las dos con documentos, el problema no es de tecnología. Es de custodia: quién controla las llaves, a nombre de quién están los activos y quién gobierna las reglas que deciden cada movimiento. Este capítulo parte de la política de tesorería por temperatura y de los esquemas de firma para responder a esas preguntas.

Tres modelos de custodia y qué responsabilidad mueve cada uno

Custodiar un activo digital es tener la capacidad de firmar las transacciones que lo mueven y responder por él ante su dueño. En la práctica hay tres modelos, y la diferencia entre ellos es quién controla las llaves y quién asume la responsabilidad legal.

En autocustodia, la organización controla las llaves o los fragmentos de llave, aunque use la infraestructura de un proveedor. Fireblocks describe su modelo como custodia directa, una forma de autocustodia en la que el cliente es dueño y controlador de sus activos. [1] Los fragmentos MPC se generan y cifran en entornos aislados y la organización puede obtener una copia de respaldo de sus llaves de firma. [2] Kaleido declara que no genera ni guarda llaves por el cliente: se crean dentro del keystore que el cliente elige, por ejemplo su HSM. [3]

En custodia de terceros, una entidad regulada guarda las llaves y firma por cuenta del cliente. BitGo describe sus wallets de custodia como frías, con material de llave repartido en bóvedas físicas y dividido entre distintos responsables de BitGo Bank & Trust, de modo que nadie controla más de una llave de una wallet. El cliente inicia la transacción, pero no firma: firma BitGo tras una verificación por video. [4]

En el modelo mixto, la firma requiere a las dos partes o el saldo se reparte entre modelos. En las wallets hot de autocustodia de BitGo, el cliente guarda la llave de cliente y la de respaldo, y BitGo guarda la llave de plataforma. [5] La arquitectura de tres wallets del módulo anterior también es mixta: reserva fría en custodia de terceros y operación diaria en autocustodia. [6]

La pregunta de la auditora sobre el cierre del proveedor tiene respuestas distintas en cada modelo. En custodia calificada, BitGo afirma que los activos de clientes se mantienen dentro de entidades reguladas, segregados del balance corporativo. [7] En autocustodia, la respuesta depende de que la organización tenga una copia de respaldo y un procedimiento probado para firmar sin el proveedor, como vimos en el ciclo de vida de llaves. Las condiciones exactas en cada jurisdicción se validan con el área legal y con el contrato, no con la página de producto.

Tipos de wallet en BitGo: quién genera cada llave y quién firma

Escenario: el equipo del Middleware Blockchain tiene que decidir en qué tipo de wallet de BitGo vive la reserva de USDC y en cuál la operación diaria. El nombre comercial no basta; lo que define la custodia es quién genera cada una de las tres llaves y quién firma. Todas las wallets en cadena de BitGo usan llave de usuario, de respaldo y de BitGo, con firma 2 de 3. [4]

Fuentes de la tabla: la página de tipos de wallet de BitGo para las cuatro primeras filas, incluido que el SLA de 24 horas puede relajarse con políticas que eliminan la verificación por video en condiciones definidas por el cliente. [4] Para Advanced Wallets, BitGo indica que usan dos instancias de servidores Express para gestionar las llaves de usuario y de respaldo en la región o jurisdicción del cliente con su propio HSM o KMS, y que BitGo no provee la integración con ese proveedor de llaves: hay que implementarla. [17] Dónde corren esos servidores se trata en el módulo 6, firma operativa.

Una contradicción a resolver: ¿la Go Account tiene una llave o tres?

La página de tipos de wallet dice que las Go Accounts son el único tipo de wallet de BitGo que usa un libro fuera de la cadena y una sola llave en lugar de tres. [4] La página de retiros, en cambio, dice que las Go Accounts son un tipo de wallet de custodia multifirma con un flujo de transacción propio. [18] Las dos frases no pueden ser ciertas a la vez para el mismo objeto. Para la auditora importa: el número de llaves cambia quién puede mover el saldo agregado. Queda a validar con el proveedor, por escrito.

Quién es el custodio: entidades de BitGo y el modelo de Circle

"BitGo custodia" no identifica a una persona jurídica. La página de licencias de BitGo lista, entre otras, a BitGo Bank & Trust, National Association, autorizada por la Office of the Comptroller of the Currency (OCC) de Estados Unidos para ejercer facultades fiduciarias y de custodia, y a BitGo Europe GmbH, que recibió de BaFin una licencia MiCAR para custodia, transferencia y negociación de criptoactivos en la Unión Europea. [19] Qué entidad firma nuestro contrato decide el regulador, el derecho aplicable y la protección ante quiebra; es un dato a validar con el proveedor y con el área legal.

Circle aporta un tercer punto de referencia útil para el proyecto que usa stablecoins. En el modelo que llama Direct End-User Custody, Circle custodia las stablecoins directamente por cuenta del cliente final, y el distribuidor actúa como integrador tecnológico que aporta la interfaz pero no custodia ni controla los fondos. [20] Con los tres puntos el mapa queda completo: en Fireblocks custodiamos nosotros con infraestructura del proveedor; en una wallet de custodia de BitGo custodia una entidad regulada de BitGo; en ese modelo de Circle custodia el emisor y nosotros solo integramos.

Cuentas segregadas y ómnibus: dónde vive el saldo de cada cliente

La palabra "segregado" tiene dos sentidos que conviene no mezclar. El sentido legal separa los activos de los clientes del patrimonio del custodio. El sentido operativo decide si cada cliente tiene su propia wallet en la cadena o si los saldos de muchos clientes comparten una.

En una cuenta segregada (operativa), cada cliente tiene su wallet o cuenta de bóveda, y su saldo en la cadena es su saldo. En una cuenta ómnibus, los fondos de muchos clientes se agrupan en una wallet común y el saldo de cada uno solo existe en el libro interno de la organización.

Fireblocks documenta las dos estructuras. En la segregada, cada cliente tiene su propia cuenta de bóveda y los fondos se guardan e invierten desde ella. En la ómnibus, los depósitos llegan a cuentas intermedias por cliente o a una cuenta de depósitos y se barren a una cuenta central. La elección es independiente de que el workspace sea hot o cold, y un mismo workspace puede combinar ambas. [8]

Técnicamente, Fireblocks usa una llave maestra por workspace, dividida en tres fragmentos, y deriva cada cuenta de bóveda usando su identificador como nivel account de la ruta de derivación. [9] Segregar por cliente no multiplica las llaves maestras: multiplica las ramas del mismo árbol. Para la auditora, eso significa que la segregación operativa es una separación de direcciones, no de material criptográfico.

BitGo permite crear wallets segregadas ilimitadas por activo, y su Go Account es, en sus propias palabras, una wallet de custodia ómnibus y fría que usa un libro fuera de la cadena. [4]

El modelo ómnibus es más barato y simple en la cadena, pero traslada la verdad al libro interno. Cada depósito debe acreditarse una sola vez, cada retiro debe descontarse antes de firmarse y el total del libro debe coincidir con el saldo en la cadena. Esos patrones de idempotencia, nonce único y finalidad están explicados en arquitectura de una dApp en producción. Sin ellos, la cuenta ómnibus es una fuente de descuadres.

Este capítulo se queda en la decisión de custodia. Cómo se atribuye cada depósito según el tipo de red, qué construcciones ofrece cada proveedor para las subcuentas que el equipo llama "sintéticas", la invariante entre libro y cadena y la diferencia entre el modelo ómnibus en Estados Unidos y la segregación que exige MiCA se desarrollan en el módulo 8, ómnibus y libro interno.

Gobierno de aprobaciones: mover fondos frente a cambiar las reglas

Volvamos al límite que subió el martes. Mover 200 000 USDC requiere aprobaciones. Pero cambiar la regla que permite mover 200 000 USDC sin aprobaciones es más peligroso, porque afecta a todos los movimientos futuros. Un gobierno sano separa dos planos y protege el segundo al menos tanto como el primero.

Figura 1

Plano de transacción y plano de gobierno

Fuentes:

[12][10]

Cómo leer esta figura

Dos franjas separadas por una línea discontinua. Franja superior, plano de transacción: Iniciador, operación o servicio por API, solicita al Motor de políticas, que encuentra la regla que coincide y bloquea si no coincide; el motor exige Aprobadores, con quórum según monto y destino; los aprobadores autorizan al Firmante, que puede ser MPC, multifirma o custodio; el firmante firma hacia la Red. Franja inferior, plano de gobierno: el Dueño de la política propone un borrador al Quórum de administración, que publica una Política versionada; una flecha verde sube de la política versionada al motor de políticas con el rótulo se aplica. Auditoría, que lee registros y no aprueba, recibe flechas discontinuas de registro desde el firmante y desde la red.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

El plano de transacción. Una política de aprobación es un conjunto de reglas que decide, para cada transacción, si se permite, si necesita aprobaciones y de quién. En Fireblocks, las políticas controlan quién inicia, desde qué origen, hacia qué destino y bajo qué condiciones, y las reglas se evalúan en orden: las más restrictivas deben ir primero. [10] En BitGo, cada regla combina alcance, evento, condición y acción. [11]

El plano de gobierno. Fireblocks exige la aprobación de un quórum de administradores para cambios de políticas, para añadir direcciones a listas blancas, para incorporar usuarios y para otras modificaciones de configuración; cualquier administrador puede rechazar la solicitud antes de alcanzar el umbral. [12] Además, la API permite trabajar con borradores de política antes de publicarlos. [10] Kaleido declara que cualquier versión nueva de una política necesita aprobación antes de aplicarse. [3]

Los caminos que esquivan la política. Todo motor de políticas tiene al menos una puerta lateral: la recuperación. BitGo advierte que las transacciones de recuperación con la llave de usuario y la de respaldo no pasan por las políticas configuradas en BitGo. [13] El modelo de custodia debe nombrar esa puerta, decir quién tiene acceso a ella y cómo se registra su uso.

El valor de cada aprobación depende de que sea atribuible. Una firma digital asocia una acción a una llave concreta, y eso permite castigar o investigar a quien la produjo; el mecanismo se explica en castigo financiero y slashing. En custodia, la misma idea pide que cada aprobación use una credencial personal, nunca una cuenta compartida.

Separación de funciones y matriz RACI

La separación de funciones reparte un proceso entre personas distintas para que ninguna pueda completarlo sola. NIST la define como dividir funciones de negocio y de soporte entre distintas personas o roles para reducir el riesgo de actividad maliciosa sin colusión, y pide que quien administra el control de acceso no administre también la auditoría. [14]

Fireblocks plantea la pregunta en tres verbos: quién inicia, quién aprueba y quién firma. Su tabla de roles de API muestra que un rol Approver puede aprobar pero no iniciar, que un Editor puede iniciar pero no firmar, y que un Signer, normalmente emparejado con un API Co-Signer, firma lo que la política permite. [15] BitGo asigna permisos por wallet: Admin gestiona políticas, usuarios y aprobaciones pendientes; Spend inicia retiros; Freeze congela la wallet; View solo consulta. [16]

Una matriz RACI escribe ese reparto en una tabla. Para cada actividad indica quién la Realiza (Responsible), quién Aprueba y responde por el resultado (Accountable), a quién se Consulta y a quién se Informa. La regla de oro para custodia es que quien inicia una acción no sea quien la aprueba; por eso iniciar y aprobar se escriben como filas separadas.

Tres conflictos aparecen en casi todas las primeras versiones. El primero: el equipo de desarrollo administra la plataforma y también opera retiros. El segundo: el mismo administrador propone y aprueba cambios de política porque el quórum es de uno. El tercero: el servicio que inicia retiros por API usa la misma credencial que el que firma. Los tres se detectan leyendo la RACI fila por fila.

Cómo lo resuelven Fireblocks, BitGo y Kaleido

Fuentes. Fireblocks: autocustodia, [2] estructuras [8] y quórums. [12] BitGo: tipos de wallet [4] y permisos. [16] Kaleido: su página de producto describe wallets ómnibus, pools de depósito y retiro, aprobación de versiones de política, control de acceso por rol y los tres modos de despliegue. [3] Las celdas marcadas "a validar" no aparecen en la documentación pública que pudimos consultar.

Si el negocio necesita protección legal de los activos de clientes frente a la quiebra del proveedor, el criterio decisivo es la figura de custodio regulado y su contrato. Si necesita velocidad y control de llaves propio, el criterio es la calidad del motor de políticas y del procedimiento de recuperación. La mayoría de las organizaciones terminan en un modelo mixto, y entonces el riesgo está en la costura entre las dos plataformas.

Decisiones que el equipo debe cerrar

Entregable: modelo de custodia con matriz RACI

El entregable tiene dos partes. La primera es una ficha por producto: modelo de custodia, estructura de cuentas, proveedor y procedimiento ante el cierre del proveedor. La segunda es la matriz RACI. Los roles de ejemplo son ilustrativos; cada organización usa los suyos.

Leída por columnas, la matriz confirma la separación: Administración de plataforma realiza altas y cambios pero nunca aprueba un retiro; Auditoría interna revisa registros pero no aprueba ningún movimiento. Leída por pares de filas, quien inicia no aprueba: Operaciones inicia retiros que aprueba Tesorería, y Tesorería propone cambios de política que aprueba un quórum de Riesgos y Administración de plataforma.

Con la custodia definida, el siguiente paso es decidir qué corre en nuestra red para firmar: BitGo Express, signers externos y co-signers. Eso es firma operativa, el módulo 6. Después viene AML y KYT, el módulo 7.