Liquidez y liquidación con contrapartes: qué hay detrás de «BitGo market maker»

La tesorería necesita vender 2 millones de USDC y recibir dólares antes del cierre del día. Alguien propone "usar el market maker de BitGo". Antes de escribir una línea de integración, el equipo tiene que responder tres preguntas: con quién se cierra la operación, dónde están los USDC y los dólares mientras tanto, y en qué momento la operación ya no se puede deshacer. Este capítulo responde esas preguntas con lo que BitGo documenta, y termina con una plantilla de flujo con límites y conciliación.

Tres términos se usan en todo el capítulo. La contraparte es la entidad con la que se cierra la operación y que nos debe la otra pata. La liquidación es el momento en que los activos cambian de dueño de verdad, después de acordar precio y cantidad. La entrega contra pago (DvP, delivery versus payment) es una liquidación en la que las dos patas se entregan juntas, o no se entrega ninguna. Una operación OTC (over the counter) se negocia de forma bilateral con una mesa, fuera del libro de órdenes de un exchange.

«BitGo market maker»: qué existe con ese nombre y qué no

El equipo usa la expresión "BitGo market maker", pero BitGo no documenta ningún producto con ese nombre en las páginas consultadas. Un market maker es una firma que cotiza a la vez precio de compra y de venta y gana con la diferencia; BitGo lo menciona como un tipo de contraparte, no como un producto propio. Su oferta para firmas de trading se agrupa bajo BitGo Global Markets, cuya capa de liquidez conecta con "exchanges, market makers y contrapartes OTC". [1] La equivalencia entre el nombre informal y los productos documentados es nuestra y queda a validar con el proveedor.

Global Markets agrupa cuatro piezas. El trading electrónico se opera por web, REST, FIX, WebSocket o integraciones con sistemas de gestión de órdenes (OEMS). [1] [2] La mesa OTC ejecuta operaciones en bloque y transacciones complejas con traders asignados. [3] Prime Financing da financiamiento contra activos elegibles sin venderlos, y la gestión de colateral lo acompaña. [1] La liquidación se hace sobre Go Network, con DvP entre clientes de la red. [1] BitGo resume el conjunto como servicios de prime brokerage: custodia, liquidez, financiamiento y liquidación en una sola plataforma. [4]

En la documentación para desarrolladores, la pieza que se integra por API se llama Trading API. Opera desde la Go Account, la cuenta ómnibus de BitGo con un libro fuera de la cadena, y admite trading con fondos propios (funded) y con margen. [5] En el trading con fondos propios, BitGo es la única contraparte. [6] Por eso "market maker" no describe bien la relación: para nuestro sistema, quien nos vende o compra es BitGo, aunque BitGo obtenga la liquidez de varios exchanges.

Con esa base, "usar el market maker de BitGo" puede significar tres cosas, y cada una cambia el diseño:

1. Somos clientes que compran o venden, por ejemplo USDC contra dólares, por la Trading API o por la mesa OTC.
2. Liquidamos con nuestras propias contrapartes (un market maker, otra institución) sobre Go Network, con DvP.
3. Somos una plataforma socia de Off-Exchange Settlement (OES): nuestros usuarios asignan activos custodiados en BitGo para operar en nuestra plataforma. Este papel exige firmar una licencia de BitGo Network y operar BitGo Express. [7]

El caso 1 aplica a los dos proyectos: al Middleware Blockchain, que ya custodia con BitGo, y al proyecto de stablecoins, que necesita convertir USDC. Los casos 2 y 3 aplican sobre todo al Middleware. Cuál es el caso real queda a validar con el arquitecto y con BitGo.

Quién es la contraparte en cada canal

Un ejemplo aclara la diferencia. Si vendemos USDC por la Trading API, la deuda abierta hasta liquidar es de BitGo con nosotros. Si liquidamos con un market maker por Go Network, la deuda es del market maker, y BitGo es el custodio de ambos. Si asignamos activos a un exchange por OES, operamos contra los participantes de ese exchange, que liquida con nosotros a través de BitGo. El riesgo de contraparte, la posibilidad de que quien nos debe la otra pata no la entregue, cambia de dueño en cada caso.

La Go Network solo liquida entre partes que se conectaron antes. BitGo mantiene un directorio público de Go Accounts y cada conexión es una relación uno a uno entre dos cuentas. [11] Para el equipo, eso significa que el alta de una contraparte es un proceso con aprobación, igual que dar de alta una dirección en una lista blanca. La revisión AML de la contraparte sigue el capítulo AML y KYT.

Dónde están los fondos durante la operación

En los tres canales de BitGo, los fondos viven en la Go Account. BitGo la define como una wallet ómnibus de custodia que puede guardar varios activos, fiat incluido, y como el único tipo de wallet que usa un libro fuera de la cadena y una sola llave en vez de tres. [12] Cada enterprise tiene una sola Go Account. [12] Ómnibus quiere decir que un mismo saldo agrupado respalda muchas posiciones, y que la posición de cada uno existe solo como registro. El capítulo Ómnibus y libro interno explica qué obliga eso a nuestro libro.

La documentación de BitGo se contradice en un punto. La página de retiros llama a la Go Account "un tipo de wallet de custodia multifirma". [13] La de tipos de wallet dice "una sola llave". [12] Para el análisis de riesgo importa cuál es cierta; queda a validar con el proveedor.

Los activos de una Go Account se nombran con el prefijo ofc, que indica que el activo tokenizado está fuera de la cadena. [14] Un saldo ofc de USDC no es USDC en una dirección de Ethereum: es un registro en el libro de BitGo que BitGo respalda. Nuestro libro debe guardar ese identificador tal cual y no mezclarlo con el USDC en cadena de los capítulos USDC y Circle Mint y USDT y Tether.

Durante la operación, el saldo pasa por estados. Con la Trading API, los activos "nunca salen de la custodia de BitGo" y la liquidación ocurre después. [6] En OES, BitGo bloquea los activos asignados y los pone a disposición del socio; la asignación es síncrona, y el saldo asignado se ve en BitGo y en la plataforma del socio. [15] En el trading con margen, el colateral admitido es USD, USDT, USDC y BTC. [16] Ese colateral es saldo comprometido, no libre, y el libro debe marcarlo así.

BitGo describe OES diciendo que los activos permanecen en su custodia, "a tu nombre y bajo tu control", lo que reduce el riesgo de contraparte y de mezcla de fondos. [17] Es una afirmación comercial. Qué entidad legal guarda los activos, con qué protección ante quiebra y en qué jurisdicción depende del contrato y queda a validar con el proveedor.

Cuándo la liquidación es final: fuera y dentro de la cadena

En la cadena, una transferencia es final cuando revertirla exigiría romper las reglas de consenso; el capítulo Web3 para el equipo explica las confirmaciones. Una liquidación fuera de la cadena no tiene bloques: es un asiento en el libro del custodio. Es final cuando el custodio la registra como completada y el contrato dice que ya no se revierte. Para el ingeniero, la evidencia de finalidad deja de ser un hash y un número de confirmaciones, y pasa a ser un estado en la API del proveedor más una cláusula contractual.

Cada canal fija su momento. En la Trading API, BitGo liquida fuera de la cadena "los días hábiles a las 12:00 PM Eastern Standard Time (EST)". [6] Entre la ejecución y ese corte, la operación está cerrada pero no liquidada. Además, Nueva York usa horario de verano parte del año: si el corte sigue la hora local o la hora estándar queda a validar con el proveedor, porque mueve una hora la ventana de exposición.

En Go Network, cualquiera de las partes puede iniciar la liquidación, pero las dos deben confirmarla antes de que finalice y los activos pasen de una Go Account a otra. [9] Quien envía activos debe además firmar la liquidación; quien solo recibe, no. [9] Ese es el DvP de BitGo: las dos patas se completan juntas para reducir el riesgo de liquidación. [1] En OES existe una ventana de disputa antes de que BitGo liquide con el socio; no todos los socios la admiten y su duración llega en el campo clientDisputeWindowMinutes. [18]

Figura 1

Flujo de una operación con contraparte: de la orden a la conciliación

Fuentes:

[6][9][15][18]

Cómo leer esta figura

Fila superior con seis cajas unidas por flechas: 1 orden, con límites pre-trade y saldo libre; 2 ejecución, precio y cantidad con la contraparte; 3 bloqueo, saldo reservado o asignado en OES; 4 liquidación DvP con las dos patas juntas; 5 libro, asiento por id de liquidación; 6 conciliación, libro contra saldo informado. Una línea vertical separa los pasos 1 a 4, en el proveedor (Go Account, BitGo Go Network), de los pasos 5 y 6, en nuestros sistemas. Banda dónde están los fondos: Go Account saldo libre; Go Account comprometido; bloqueado en la Go Account o en el socio; pasan de una Go Account a otra con tickers ofc; el libro refleja y no mueve fondos; dos fuentes que deben coincidir. Banda es final: no cancelable; no deuda abierta; no aún reversible; sí al confirmarse; registra el estado; lo comprueba. Banda control y evidencia: límite por orden, activo y contraparte; confirmación de ejecución guardada; ventana de disputa si el socio la ofrece; firma y aprobación de ambas partes; externalId único sin asientos dobles; ante diferencia congelar el límite y abrir caso. Abajo, fuera del ciclo: el retiro on-chain de la Go Account a una wallet propia es otra operación con su red, sus confirmaciones y su firma.

Descargar SVGDescargar .tex

Código TikZ

Abrir `.tex` en otra pestaña

La figura separa lo que hace el proveedor de lo que hacemos nosotros. Hasta el paso 4, la operación vive en BitGo y nuestro sistema solo observa estados. Los pasos 5 y 6 son nuestros: el libro registra lo que BitGo informa, y la conciliación comprueba que ambos digan lo mismo. Sacar los fondos a la cadena es otra operación, con su red, sus confirmaciones y su política de firma.

Liquidar dentro o fuera de la cadena: cómo elegir

Liquidar fuera de la cadena no es mejor ni peor que hacerlo en la cadena: cambia qué riesgo se asume. BitGo destaca que sus liquidaciones entre Go Accounts son más rápidas y baratas que las transacciones en cadena y que los activos no salen de su almacenamiento en frío. [14] El precio es la concentración: el custodio, el libro y la liquidación son la misma entidad.

Una liquidación en cadena con dos transferencias independientes no es DvP: si enviamos primero, asumimos el riesgo completo de la contraparte hasta que llegue su pata. Para obtener DvP en la cadena hace falta un contrato que retenga ambas patas, como el escrow de Circle StableFX o los HTLC de Kaleido que se describen más abajo.

Riesgos, límites y conciliación con nuestro libro

Los riesgos son de tres clases. El riesgo de contraparte existe entre la ejecución y la liquidación: con la Trading API puede durar hasta el siguiente corte diario. El riesgo de custodia es el del custodio que guarda los fondos de todos los canales: su solvencia, su entidad legal y sus controles. El riesgo operativo incluye límites técnicos como las 10 solicitudes por segundo de la Trading API. [6] También incluye que el trading en producción se habilita contactando a BitGo, lo que conviene planificar en el calendario del proyecto. [19]

Los límites responden a la decisión del módulo sobre qué saldo puede estar fuera de la cadena y por cuánto tiempo. Se definen al menos cuatro: monto máximo por orden; exposición abierta por contraparte (operado y no liquidado); saldo máximo en la Go Account como proporción de la tesorería; y tiempo máximo que un saldo puede permanecer comprometido o asignado. Si una liquidación supera ese tiempo, el sistema deja de enviar órdenes a esa contraparte hasta que alguien revise el caso.

La conciliación compara tres fuentes: nuestro libro, lo que informa BitGo y lo que confirmó la contraparte. La API de liquidaciones de Go Network acepta un externalId propio. [9] Usarlo como clave única en nuestro libro evita asientos duplicados cuando un webhook llega dos veces o una llamada se reintenta. La invariante es la del capítulo Ómnibus y libro interno: la suma de las posiciones del libro por activo ofc debe igualar el saldo que BitGo informa para la Go Account.

El libro distingue cuatro estados por operación: comprometido (ejecutado, sin liquidar), bloqueado (asignado o en colateral), liquidado y en disputa. Solo el estado liquidado cuenta como saldo propio y disponible. Si la conciliación encuentra una diferencia, el sistema congela el límite de esa contraparte, abre un caso y conserva toda la evidencia: ids de orden, ids de liquidación, firmas y respuestas de la API.

Esa evidencia es lo que sostiene una disputa. El capítulo El castigo financiero (slashing) explica por qué una falta solo se puede sancionar si deja evidencia atribuible a quien la cometió. Aquí no hay protocolo que castigue, pero el principio es el mismo: sin mensajes firmados y registros con identificador, una diferencia con la contraparte se discute con la palabra de cada parte.

Fireblocks, BitGo, Kaleido y Circle frente a la misma necesidad

BitGo. Liquidez por Global Markets y liquidación fuera de la cadena entre Go Accounts, con DvP y OES, como se describió arriba. [20] Su punto distintivo es que custodia, contraparte del trading y liquidación están en el mismo proveedor.

Fireblocks. Documenta la Fireblocks Network, una red de proveedores de liquidez, mesas de préstamo y contrapartes; una nueva conexión exige la aprobación del Admin Quorum de ambas partes, y las direcciones de depósito se autentican de forma automática. [21] Su Trading API crea órdenes con dos tipos de liquidación: DVP, en la que el proveedor espera el depósito antes de ejecutar, y prefondeada, que usa saldo ya depositado en el proveedor. [22] Ofrece también una solución Off Exchange para operar en exchanges conectados sin ceder el control de los activos. [23] Qué exchanges y qué plazos de liquidación aplican a nuestro workspace queda a validar con el proveedor.

Kaleido. No documenta, en lo consultado, una mesa de liquidez ni una red de liquidación con terceros. Sí ofrece un servicio de intercambio de tokens entre miembros de una red con contratos HTLC (hashed time lock contracts): los tokens se bloquean con un hash, se liberan con el secreto correcto y vuelven a su dueño si vence el plazo, de modo que ambas partes cumplen o ninguna. [24] Sirve para DvP en cadena dentro de una red propia o de un consorcio; su uso con stablecoins en redes públicas queda a validar con el proveedor.

Circle. Agrupa sus servicios de liquidez en Circle Mint, StableFX y Digital Asset Accounts. [25] StableFX cotiza por RFQ (request for quote), ejecuta fuera de la cadena y liquida en la cadena de Arc con un escrow en el que ambas patas se liquidan o ninguna. [26] Es una plataforma con permisos para instituciones; aplica al proyecto de stablecoins si necesita cambiar USDC por EURC u otras stablecoins. Su disponibilidad para nosotros queda a validar con el proveedor.

Entregable: flujo de operación y liquidación con límites y conciliación

La plantilla describe cada paso de la figura. El equipo completa responsable, evidencia y límite para cada canal que vaya a usar; las celdas marcadas "a validar" se cierran con el contrato.

La política de límites, como pseudopolítica ilustrativa (no es la sintaxis de ningún proveedor):

# Ilustrativo: límites y conciliación para operaciones con contrapartes
contrapartes:
  - id: mm-01
    canal: go_network_settlement   # trading_api | otc | go_network_settlement | oes
    exposicion_abierta_max_usd: 500000
    tiempo_sin_liquidar_max: 24h
saldo_fuera_de_cadena:
  go_account_max_pct_tesoreria: 20
orden:
  monto_max_usd: 250000
  rechazar_si:
    - exposicion_abierta[contraparte] + monto > exposicion_abierta_max_usd
    - activo no comienza con "ofc"   # solo saldos de la Go Account
conciliacion:
  clave: externalId
  invariante: suma(libro[activo]) == saldo_go_account[activo]
  frecuencia: cada_liquidacion_y_diaria
  si_difiere: [congelar_limite_contraparte, abrir_caso]

El capítulo anterior, USDT y Tether, y el de USDC y Circle Mint describen las stablecoins que suelen ser una de las patas de estas operaciones. El siguiente, Arquitectura de referencia, ubica la Go Account, Go Network y la conciliación en el mapa de capacidades por proveedor.