Cuentas ómnibus, segregadas y subcuentas: el libro interno

Son las nueve de la mañana y el informe de conciliación muestra una diferencia: el vault ómnibus de USDC en Ethereum tiene 4 812 300 USDC y la suma de los saldos de clientes en nuestro libro dice 4 817 300. Faltan 5 000 USDC en la cadena, o sobran 5 000 en el libro. Nadie ha robado nada todavía, pero hasta que el equipo sepa qué asiento no tiene respaldo, cualquier retiro puede estar pagándose con el dinero de otro cliente.

Ese es el problema central del modelo que el equipo llama "Modelo Omnibus / Synthetic Account": muchos clientes comparten una wallet en la cadena y la propiedad de cada unidad vive en un registro nuestro. Este capítulo profundiza la sección corta de custodia sobre cuentas segregadas y ómnibus, usa los barridos y tanques de gas de wallets hot, warm y cold y apoya la atribución por cliente que exige AML y KYT. Aplica sobre todo al proyecto "Middleware Blockchain" (Fireblocks y BitGo); las subcuentas de Circle aplican al proyecto que usa USDC.

Una wallet, muchos dueños: tres formas de repartir la propiedad

Un cliente deposita 5 000 USDC. La pregunta no es si el dinero llegó, sino a nombre de quién quedó. Hay tres respuestas posibles, y cada una pone la verdad en un lugar distinto.

Una cuenta segregada (en sentido operativo) es una wallet o un vault por cliente: su saldo en la cadena es su saldo, y cualquiera con un explorador puede comprobarlo. Una cuenta ómnibus junta en una o pocas wallets los fondos de muchos clientes; la cadena solo muestra el total, y el reparto existe únicamente en un libro interno (ledger): una base de datos de asientos que dice cuánto de ese total pertenece a cada cliente. Una subcuenta en libro es una cuenta por cliente que existe solo como registro de ese libro, nuestro o del proveedor, encima de fondos agrupados.

Esa tercera forma es lo que el equipo llama "cuenta sintética". Ningún proveedor la documenta con ese nombre: en la documentación de Circle, Fireblocks y BitGo que revisamos no aparece el término "synthetic account" ni "cuenta sintética". Lo que sí existe son construcciones equivalentes con otros nombres, que mapeamos en la sección siguiente. Ese mapeo es nuestro y queda a validar con el proveedor y con el arquitecto, que debe confirmar qué entiende el diseño del Middleware por "sintética".

Conviene recordar la distinción del módulo 5: segregar en la cadena no es lo mismo que segregar legalmente. Una cuenta ómnibus puede estar legalmente separada del patrimonio del custodio, y una wallet por cliente no protege nada si el contrato no lo dice. Este capítulo trata la parte operativa y deja la legal para el final.

"Cuenta sintética" en cada proveedor: qué existe de verdad

Fireblocks. Su estructura ómnibus tiene, en sus palabras, "a central vault account, deposits vault account for UTXO and Tag/Memo based assets and vault accounts for each end-client for account based assets", y los fondos depositados se barren a la cuenta central. [1] Lo que el equipo llama sintético es la combinación de esos vaults por cliente con un libro propio, porque Fireblocks aclara que no lo provee: "Fireblocks does not provide a built-in component or feature for this specific need". La misma guía orienta la estructura segregada a negocios B2B y la ómnibus a negocios B2C. [2] La referencia de su API nombra los tres tipos de vault: intermedios por cliente, "Omnibus deposits" y "Withdrawal pool". [3]

BitGo. La Go Account es "an omnibus custody wallet that enables you to hold multiple assets, including fiat", y es el único tipo de wallet de BitGo que usa "an off-chain ledger and a single key, instead of three"; cada empresa (enterprise) tiene solo una. [4] Para tener una por cliente, el modelo Crypto-as-a-Service crea empresas hijas: "you can create enterprises for your end users, each with their own Go Account". [5] En ese libro los activos llevan el prefijo ofc, que indica que el activo tokenizado está fuera de la cadena. [6]

Circle. En la Institutional API de Circle Mint, cada entidad aceptada recibe una wallet de tipo end_user_wallet que es propiedad de la cuenta del distribuidor pero está "segregated to that entity, so balances and money movement remain attributable per counterparty". [7] En Digital Asset Accounts, la custodia puede usar "omnibus wallet structures", pero "account records ensure that each customer's entitlements are clearly defined and auditable". [8] Su campo custodyType toma literalmente el valor omnibus para las cuentas custodiadas y self para las no custodiadas. [9] Y en CPN Managed Payments, "A Managed Payments subaccount is a separate ledger for a merchant or segment". [10]

La lectura práctica: en Fireblocks el libro es nuestro; en BitGo y en Circle el proveedor lleva un libro por cliente y nosotros llevamos otro encima. En los dos casos hay un libro que conciliar.

Atribuir cada depósito: dirección única o memo

La atribución es la regla que convierte "llegaron 5 000 USDC a esta dirección" en "son de la clienta 4711". Solo hay dos señales fiables en la cadena: la dirección de destino o un campo adicional de la transacción (memo o tag). Todo lo demás, como el importe o la dirección de origen, sirve para investigar pero no para atribuir.

Figura 1

Del depósito a la conciliación en un modelo ómnibus

Fuentes:

[1][17]

Cómo leer esta figura

Dos franjas separadas por una línea discontinua. Franja superior, en la cadena: 1, Depósito, el cliente envía a su dirección o memo; flecha llega a Dirección intermedia, vault por cliente o dirección compartida más memo; flecha 3, barrido en cadena, hacia Vault ómnibus con fondos de todos los clientes. Sobre el barrido, una caja ocre Tanque de gas o relayer con una flecha que paga la comisión. Una flecha discontinua, evento de depósito, baja de la dirección intermedia a la franja inferior. Franja inferior, en el libro interno: 2, Atribución, de dirección o memo a id de cliente; flecha a Compuerta de finalidad y KYT; desde la compuerta, una flecha verde acredita lleva a 4, Crédito en libro, asiento idempotente por transacción y cliente, y una flecha roja hacia abajo indica retiene, no acredita. A la derecha, entre las dos franjas, una caja 5, Conciliación: suma del libro igual a saldo en cadena, diaria y por bloque; recibe el saldo del vault ómnibus desde arriba y los saldos del libro desde abajo.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

Redes UTXO y redes con memo. En Bitcoin cada depósito puede ir a una dirección nueva del mismo wallet, y en redes como XRP o Stellar se usa una dirección compartida con un memo por cliente. Fireblocks las agrupa en un vault de depósitos común. [1] El precio del memo lo dice la misma documentación: "you must manage internal credits and balances based solely on transactions, because there is no on-chain balance to validate. Your internal system becomes the source of truth". [2] Un memo olvidado por el cliente es un depósito sin dueño: hace falta un procedimiento para esos casos.

Redes de cuentas (EVM). En Ethereum y similares, Fireblocks indica que un activo sin memo "can only generate one deposit address" por wallet, y que en EVM esa dirección se comparte entre todos los tokens del vault. [1] Por eso la dirección única por cliente exige un vault intermedio por cliente. BitGo resuelve lo mismo con contratos forwarder: direcciones de recepción de una sola firma que solo pueden enviar a la dirección base de la wallet. [11]

Circle Mint. Una cuenta Mint tiene una wallet principal (masterWalletId) y Circle genera "one deposit address per blockchain for your account". [12] Esa dirección, sola, se comporta como una ómnibus: no distingue a nuestros clientes. La atribución por cliente pasa por las wallets por entidad de la Institutional API, que usan "a per-entity deposit address". [7] Si nuestra cuenta tiene ese acceso es algo a validar con Circle; el detalle se desarrolla en el módulo 9.

Barrido y gas: consolidar sin perder la atribución

En el modelo ómnibus de cuentas EVM, los fondos no se quedan en el vault del cliente: se barren al vault central. Fireblocks lo dice sin rodeos: el barrido es "an on-chain transfer, fees apply", y barrer un ERC-20 exige el activo nativo: "sweeping USDC on Ethereum requires ETH". [13] La alternativa documentada es Universal Gasless, donde un relayer patrocina el gas y los vaults intermedios "never need to hold ETH". [13]

Las reglas de automatización de Fireblocks tienen un límite que conviene conocer antes de diseñar: "One sweep per deposit. [...] Rules don't batch deposits, run on a schedule, or check network fees." [14] Con muchos depósitos pequeños, barrer cada uno puede costar más que lo depositado; un barrido por saldo acumulado o por comisión de red, como se discutió en el módulo 4, se implementa por API.

En BitGo, los activos de cuenta "can withdraw only from the base address of a wallet", así que las direcciones de recepción deben consolidarse periódicamente. [15] En redes con memo no hace falta: los depósitos quedan "immediately available in the spendable balance". [11] El gas de EVM lo pagan sus gas tanks, wallets de comisión por empresa. [16]

Dos reglas para el libro. Primera: el barrido es un movimiento entre wallets nuestras y no cambia el saldo de ningún cliente; si el libro lo registra, es como traspaso interno con importe neto cero por cliente. Segunda: la comisión del barrido es un gasto de la operación, no del cliente, salvo que el contrato diga otra cosa; necesita su propia cuenta de gastos para que la conciliación cuadre.

Acreditar solo lo final y conciliar cada día

Acreditar es crear el asiento que hace disponible un saldo para el cliente. La regla es la misma de indexadores, eventos y reorgs: solo se acredita lo que ya no puede revertirse, y cada depósito se acredita una sola vez aunque el evento llegue dos veces. La arquitectura de una dApp en producción explica cómo hacer el asiento idempotente con una clave única por transacción.

Fireblocks documenta un procedimiento concreto para su modelo: esperar el webhook de transacción COMPLETED y anotar su blockHeight, esperar un evento de saldo del mismo vault a esa altura o mayor, y comparar con la cadena. "If they don't match, don't credit the end user until you investigate and resolve the difference." [17] La misma página aclara que cada evento de saldo trae el saldo completo, no una diferencia, y que hay que ignorar eventos con una altura menor. Es un buen modelo aunque el proveedor sea otro.

La invariante del libro es la regla que sostiene todo el modelo: para cada activo y cada red, la suma de los saldos de clientes, más las cuentas propias de la operación (comisiones, fondos propios, depósitos sin atribuir), es igual al saldo en la cadena de todas nuestras wallets, medido a una misma altura de bloque. Si se rompe, el libro está prometiendo dinero que no existe o la cadena tiene dinero que el libro no reconoce.

La conciliación es el proceso que comprueba la invariante. Conviene hacerla en dos ritmos: por depósito, antes de acreditar, como propone Fireblocks; y diaria, por activo, red y wallet, con un informe firmado por tesorería. En el escenario inicial, la conciliación diaria encontró 5 000 USDC de diferencia. Las causas típicas son un depósito acreditado dos veces, un retiro registrado pero no emitido o una comisión no contabilizada. La regla operativa: mientras la diferencia no esté explicada, se congelan los retiros del activo afectado por encima de un umbral.

AML, regla de viaje y segregación legal sobre una ómnibus

Una wallet ómnibus mezcla en la cadena el dinero de muchos clientes, y el proveedor de análisis de cadena ve una sola dirección. El módulo 7 exige screening por depósito y por retiro; en un modelo ómnibus, esa decisión solo sirve si cada alerta se puede atribuir a un cliente concreto.

Fireblocks resuelve esa atribución con metadatos del vault intermedio: "Both the name of the vault account and the AML customerRefId fields are propagated to every transaction". [3] La misma guía pide no guardar datos personales en esos campos. [2] Además permite registrar un LEI y asociar vaults a entidades legales. [18] Circle hace un screening síncrono de sanciones al dar de alta cada entidad, y su wallet no se puede usar hasta que el estado es ACCEPTED. [7]

La regla de viaje (aplicación de la Recomendación 16 del GAFI a los proveedores de servicios de activos virtuales) pide datos del ordenante y del beneficiario por transferencia. Una dirección ómnibus no los contiene: los aporta el libro, que sabe qué cliente pidió cada retiro. En BitGo Crypto-as-a-Service, registrar un destino en la lista blanca de una Go Account "runs travel rule compliance checks and exchanges counterparty information with the receiving Virtual Asset Service Provider (VASP)". [19] Umbrales y alcance dependen de la jurisdicción y los fija el área legal.

Segregación legal. La misma estructura técnica recibe tratamientos legales distintos. En el modelo de custodia de Digital Asset Accounts, Circle declara que "the beneficial ownership is tracked at the individual account level" aunque los activos estén agrupados. [8] Para el Espacio Económico Europeo, en cambio, escribe: "MiCA requires that customer assets be physically segregated onchain rather than pooled in omnibus wallets". [20] Esa frase describe cómo opera Circle; si la misma exigencia aplica a nuestros vaults ómnibus en Fireblocks o BitGo es una pregunta legal que estos documentos no responden.

Cómo lo resuelven Fireblocks, BitGo, Kaleido y Circle

Fuentes. Fireblocks: estructuras, [1] libro, [2] barrido [13] y validación de saldos. [17] BitGo: tipos de wallet, [4] empresas hijas [5] y consolidaciones. [11] Kaleido: su página de producto menciona "omnibus wallets and deposit and withdrawal pools". [21] Circle: Institutional API, [7] estructura de cuentas DAA [9] y transferencias internas "with no blockchain fees". [22]

Una advertencia sobre BitGo: su página de tipos de wallet describe la Go Account con "a single key", pero la de retiros dice que "Go Accounts are a type of custody multisignature wallet". [23] Las dos frases no encajan; qué modelo de llaves tiene la Go Account de nuestro contrato queda a validar con BitGo.

Un criterio para elegir: si el Middleware necesita controlar su propio libro y su modelo de datos, Fireblocks deja el libro en nuestras manos a cambio de construirlo. Si se prefiere que el proveedor lleve el libro por cliente, la Go Account de BitGo y las subcuentas de Circle lo ofrecen, a cambio de conciliar dos libros y de aceptar su modelo.

Decisiones que el equipo debe cerrar

Entregable: modelo de cuentas, libro y conciliación

El entregable tiene tres partes. La primera es el modelo de cuentas: una fila por producto que diga estructura, proveedor, regla de atribución y momento del crédito. Las filas son un ejemplo ilustrativo.

La segunda es el esquema del libro. Es un boceto ilustrativo de los campos mínimos de un asiento, no un diseño de base de datos. Cada movimiento son dos o más líneas con el mismo entry_id que suman cero (partida doble), y la clave de idempotencia impide acreditar dos veces el mismo evento.

La tercera es la regla de conciliación. Para cada activo y red, a una misma altura de bloque, el saldo de las cuentas de tipo wallet del libro debe igualar el saldo en la cadena de esas wallets. Por la partida doble, ese saldo es a su vez la suma de clientes (en estado disponible, pendiente o retenido), comisiones y depósitos sin atribuir; si la suma de todas las líneas no da cero, el error está dentro del libro y no en la cadena. El boceto siguiente es ilustrativo.

-- Ilustrativo: diferencia por activo y red al cierre del día
SELECT l.asset, l.network,
       SUM(l.amount)                          AS total_libro,
       c.onchain_balance                      AS total_cadena,
       c.onchain_balance - SUM(l.amount)      AS diferencia
FROM ledger_lines l
JOIN onchain_snapshot c
  ON c.asset = l.asset AND c.network = l.network
 AND c.block_height = :altura_de_cierre
WHERE l.account_type = 'wallet'
  AND l.block_height <= :altura_de_cierre
GROUP BY l.asset, l.network, c.onchain_balance
HAVING c.onchain_balance - SUM(l.amount) <> 0;

Cada fila que devuelva esa consulta abre un incidente con dueño, plazo y, mientras siga abierto, retiros congelados por encima del umbral del activo. El informe diario, aunque salga vacío, lo firma tesorería y queda como evidencia para auditoría.

Con el libro definido, el siguiente paso es conectar la cuenta con el emisor de USDC. Eso es Stablecoins I: USDC y Circle Mint, el módulo 9, que parte de la dirección única por red de Circle Mint y de sus subcuentas por entidad.