Crean prototipo de exchange de bitcoin con «dark pools» privados

• El código del prototipo aún no fue publicado ni auditado de forma independiente.
• Las órdenes se emparejan de forma directa entre usuarios mediante identidades de Nostr.

Un desarrollador identificado como ian (@januszg_ en X) presentó el 21 de julio de 2026, un prototipo de exchange de bitcoin (BTC) pensado para funcionar como un <>: un mercado donde los montos y las direcciones de los participantes quedan ocultos durante toda la operación.

El objetivo es mover bitcoin de una persona a otra sin dejar rastro en la red y, al mismo tiempo, sin que ninguna de las partes (comprador y vendedor) tenga que confiar ciegamente en la otra.

Para lograrlo, se combinan dos piezas que operan en paralelo y se conectan mediante un hash. Del lado de Bitcoin, el prototipo usa statechains ---una técnica que permite reasignar la llave de gasto de un UTXO sin necesidad de una transacción en la cadena--- y se apoya, según el autor, en el protocolo Latch de Mercury Layer.

El vendedor bloquea su posición dentro de una orden y esa orden genera un hash único, que funciona como el hilo conductor de todo el intercambio. Ese mismo hash es el que entra en juego del otro lado del sistema: la red de stablecoins.

Por su parte, el comprador deposita sus stablecoins (o <>, en palabras del propio autor) en un contrato de garantía dentro de una red con circuitos de prueba conocimiento cero (zk), un método criptográfico que permite a una parte (el probador) demostrar a otra (el verificador) que una afirmación es verdadera, sin revelar ninguna información adicional sobre la afirmación en sí.

Ese contrato solo libera los fondos si alguien revela la clave que corresponde al hash generado por la orden del vendedor, o los devuelve automáticamente al comprador si vence un plazo determinado sin que eso ocurra.

Aquí es donde entra el tercer elemento del diseño: un cofirmante que no participa en la negociación ni firma nada por iniciativa propia, sino que actúa únicamente cuando ambas partes se lo indican.

Una vez que el vendedor verifica que las stablecoins quedaron depositadas en el contrato, autoriza al cofirmante a completar el traspaso del bitcoin; el comprador hace lo mismo del otro lado.

Con ambas confirmaciones, el cofirmante reasigna la llave de gasto del statechain al comprador y borra la copia que compartía con el vendedor.

Solo después de ese borrado se revela la clave que permite al vendedor reclamar las stablecoins. Ahí se completa el swap.

Ese último paso deja una condición de confianza que el propio autor reconoce: el comprador debe confiar en que el cofirmante efectivamente eliminó su llave una vez terminada la operación.

Todo ese mecanismo de intercambio resuelve el problema de mover los activos sin rastro, pero no dice nada todavía sobre cómo dos personas llegan a acordar una operación. Para eso, el desarrollador construyó encima un protocolo de cotizaciones (RFQ) basado en identidades de Nostr.

Cada usuario crea una identidad (npub) y publica órdenes de compra o venta mostrando únicamente esa identidad y el monto de la orden, sin revelar su dirección de bitcoin ni otros datos personales.

Vale aclarar que, a diferencia de los montos y las direcciones, el npub del usuario sí queda visible para el resto de participantes del libro de órdenes: lo que el diseño oculta es la dirección de bitcoin y la información personal, no la identidad pseudónima en Nostr.

Cuando alguien encuentra una oferta que le conviene, envía una cotización cifrada con el monto y el precio exactos, que solo puede leer la contraparte de esa operación específica.

El resultado, de acuerdo con la descripción del autor, es que del lado de Bitcoin no existe ninguna transacción en la cadena, mientras que del lado de la red zk lo único que queda a la vista son los hashes de las entradas y salidas, sin que pueda determinarse siquiera qué activo se intercambió.

El propio ian calificó el diseño, en su valoración personal, como extremadamente preservador de la privacidad y adelantó que trabajará en versiones más optimizadas del protocolo y que planea publicar el código en el futuro, sin precisar una fecha.