Ark, la cuenta mancomunada masiva sobre Bitcoin: ¿qué es y cómo funciona? 

1 ¿Cuál es el propósito y qué problema resuelve Ark? 

Ark nació de una frustración concreta. Hasta 2023, en Lightning, para recibir un pago no basta con tener una wallet: necesitabas un canal de pago abierto con alguien que tuviera bitcoin disponible de su lado del canal para que fluyera hacia ti. Eso se llama liquidez entrante y conseguirla costaba dinero: o abrías un canal con una transacción en la contabilidad de Bitcoin (generando comisiones a los mineros), o le pagabas una comisión a un proveedor para que te la cediera. 

El desarrollador Burak Keceli, que presentó Ark en mayo de 2023, consideraba esa exigencia un sinsentido: un sistema de pagos donde hace falta dinero para poder recibir dinero. Su idea de una wallet de Lightning terminó convirtiéndose, casi por accidente, en un protocolo distinto que no necesita canales. El nombre alude al Arca de Noé: la idea de poner a salvo a los usuarios comunes de tener que depender de custodios. 

Ahora bien, si la liquidez entrante fue la chispa que encendió a Ark en 2023, hoy Lightning ya no sufre ese problema como antes. Existen las aperturas colaborativas de canales (dual funding), incorporadas a la especificación del protocolo, que permiten que ambas partes aporten fondos y que el canal nazca con liquidez en los dos sentidos. A eso se suman los proveedores de servicios Lightning (LSP) que abren canales en el momento justo de recibir (just-in-time) y los canales de confirmación cero, que dejan recibir al instante. En la práctica, recibir sin liquidez previa ya es un problema resuelto en Lightning. 

Si Ark se agotara ahí, sería un protocolo sin propósito. Pero la liquidez entrante nunca fue la enfermedad: era el síntoma. La enfermedad es que la arquitectura de canales no escala en número de usuarios. Cada usuario autocustodiado de Lightning necesita al menos un canal, y cada canal es al menos una transacción propia en la contabilidad de Bitcoin. El propio Burak hizo la cuenta en su propuesta original: llevar a toda la población mundial a Lightning de forma no custodiada, asumiendo cuatro canales por persona, tomaría más de un siglo, porque no hay suficiente espacio de bloques para abrir tantos canales.  

Ese es el propósito vigente de Ark: escalar el número de usuarios con autocustodia. Una sola transacción en la contabilidad de Bitcoin puede respaldar a cientos o miles de personas, y la liquidez del servidor es un fondo común que se asigna sobre la marcha a quien la necesita, sin apuestas por usuario.  

Lightning escala magníficamente en volumen de pagos, pero mal en cantidad de wallets; Ark es exactamente lo contrario. Por eso, más que rivales, son complementos, incluso se comunican entre sí. A eso se suma un propósito secundario que ya está dando frutos: como Ark replica el modelo de propiedad de Bitcoin en lugar del modelo de canales, construir lógica financiera compleja sobre él (préstamos, intercambios, emisión de activos) resulta más sencillo que sobre Lightning. 

Ark no es un Lightning mejorado: es un conjunto distinto de concesiones, otra alternativa más de escalabilidad que aumenta el universo de Bitcoin y que permite interactuar con Lightning. 

2 ¿Cómo funciona Ark? 

Para entender Ark hay que recordar que en Bitcoin, en rigor, no existen las monedas. Lo que existe es una contabilidad, un libro público donde se anotan asientos que dicen cuánto valor hay y quién tiene derecho a gastarlo. Esos asientos se llaman UTXO (unspent transaction outputs, salidas de transacción no gastadas).  

Cuando pagas, no «mueves una moneda»: tu transacción destruye el asiento que estaba a tu nombre y crea asientos nuevos a nombre de otros. Lo que llamamos una moneda de Bitcoin es, en realidad, una cadena de propiedad: el asiento nació en la minería con la transacción coinbase, su dueño lo gastó creando otro asiento, ese otro asiento se gastó creando el siguiente, y así hasta hoy. No es el mismo registro viajando de mano en mano; es un registro nuevo cada vez, encadenado al anterior. Por eso se dice que las monedas «se destruyen y se crean» en cada pago. 

En ese sentido, Ark es un protocolo para que un solo asiento de la contabilidad de Bitcoin tenga cientos o miles de dueños a la vez. A ese registro compartido lo llamaremos asiento mancomunado. 

A todo el esquema lo coordina un servidor, conocido como ASP (Ark Service Provider, o proveedor de servicio de Ark). Aquí aparece la diferencia arquitectónica más importante frente a Lightning: mientras Bitcoin y Lightning son protocolos entre pares (peer-to-peer), donde tú y yo podemos interactuar sin que medie un servidor, Ark es un protocolo de cliente-servidor. Todos los usuarios de un Ark hablan con el mismo servidor y solo con ese servidor. Es como una red social: no puedes conectarte a los servidores de Instagram desde TikTok. Si tus transacciones están en un servidor de Ark, para casi cualquier operación tienes que dialogar con ese servidor. 

La porción que cada usuario posee dentro del asiento mancomunado se llama VTXO (virtual UTXO,). Siguiendo la analogía: si el UTXO es un asiento del libro público de Bitcoin, el VTXO es el asiento que demuestra que tú eres dueño de una parte del asiento mancomunado. Con él transas igual que con bitcoin on-chain: puedes darle a otro usuario una parte o el total de tu VTXO, y esa porción representará propiedad sobre un valor exacto. 

Ahora, tu VTXO no es una anotación en la base de datos del servidor. Es un paquete de transacciones de Bitcoin reales, ya firmadas por todas las partes, que tu wallet guarda localmente. Hay una relación 1:1 entre una UTXO y una VTXO. El servidor lleva su propio registro de qué VTXO existen y cuáles se gastaron —una especie de mempool virtual—, pero la copia que importa es la tuya. Mientras no se publiquen, esas transacciones no se escriben en la contabilidad. 

Distintos servidores de Ark son como bancos con su propia contabilidad interna, que no se hablan directamente entre sí. No puedes mandar monedas de un servidor de Ark a otro de forma nativa; una wallet basada en Bark (la implementación de la empresa Second) y otra basada en Arkade (la implementación de la empresa Ark Labs) no se envían fondos entre ellas por Ark. La forma de tender un puente entre ambas es, precisamente, Lightning, que funciona como la red interbancaria que todas entienden. 

3 ¿Cómo se usa Ark en la práctica? 

Antes de bajar al mecanismo, vale la pena aclarar cómo se siente Ark de cara al usuario, porque toda la complejidad que sigue está abstraída. En la práctica, usar Ark es tan sencillo como usar cualquier wallet de Lightning.  

Puedes descargar una wallet como Noah (basada en Bark, de Second) o Arkade Money (de Ark Labs), y fondearla de dos maneras: con una transacción en la red Bitcoin, o con una transacción de Lightning. Para recibir por Lightning, tu wallet genera una factura en la que debes precisar el monto que quieres recibir; para pagar, escaneas una factura como lo harías en cualquier wallet de Lightning.  

En tanto que la arquitectura es similar a la de UTXO, los pagos en Ark también son similares a los de la contabilidad base de Bitcoin: tengo un asiento contable a mi favor, lo uso para generar asientos de pago y de vuelto que son respectivamente acreditados a los nuevos dueños, todo en el ecosistema de mi servidor. 

Ninguno de los conceptos que explicaremos —árboles, rondas, VTXO— aparece frente al usuario: la wallet los gestiona sola. Eso sí, conviene tener presente dos cosas. La primera es que estas wallets son todavía experimentales y su software está en etapas tempranas; no conviene poner en ellas más de lo que estarías dispuesto a perder. La segunda ya la mencionamos: no todas las wallets de Ark se comunican entre sí. No puedes enviar dinero de Noah a Arkade Money a través de Ark; para eso tendrían que usar Lightning como red interbancaria. 

4 ¿Cómo funciona en detalle? El árbol de transacciones 

Aquí es donde la cuenta mancomunada masiva se vuelve concreta. Antes, un recordatorio de anatomía: una transacción de Bitcoin tiene entradas —los asientos que destruye, es decir, el dinero que gasta— y salidas —los asientos nuevos que crea, con sus nuevos dueños—. 

Supongamos que Alice tiene un asiento propio de 1.000.000 de sats en la contabilidad de Bitcoin y quiere entrar a Ark junto con otros siete usuarios. A este evento coordinado en el que un grupo de usuarios y el servidor arman juntos un asiento mancomunado se le llama una ronda. Esto ocurre de forma periódica y es lo que ancla a Ark en la contabilidad de Bitcoin.  

El servidor construye entonces una transacción llamada de compromiso (commitment transaction). Sus entradas son los fondos que se están subiendo a Ark —los de los propios usuarios cuando ingresan, o la liquidez que adelanta el servidor cuando se trata de renovaciones—. Su salida principal es una sola: el asiento mancomunado, cuyo valor es la suma de lo que corresponde a los ocho participantes. La transacción incluye además una salida diminuta llamada conector, que sirve para amarrar de forma atómica ciertas operaciones, y el vuelto que regresa al servidor. 

¿Cómo sabe Alice que dentro de ese asiento gigante le corresponde exactamente 1.000.000 de sats y ni uno menos? Aquí entra el árbol de transacciones. El orden en que se construye es el siguiente: 

Primero, el borrador. Antes de publicar nada, el servidor arma toda la serie de transacciones que subdividirá el asiento mancomunado. Con ocho usuarios, la primera transacción del borrador toma el asiento mancomunado y lo parte en dos asientos: uno con la suma de lo que les corresponde a los usuarios 1 al 4, y otro con la suma de los usuarios 5 al 8. No son mitades iguales de valor: son mitades del grupo. La segunda capa parte cada uno de esos asientos en dos (el grupo 1-2 y el 3-4 por un lado; el 5-6 y el 7-8 por el otro). La tercera capa hace la última división y sus salidas son las hojas: un asiento por usuario, con su monto exacto. Si Alice es la usuaria 8, la última transacción de su lado crea dos asientos: el del usuario 7, con lo suyo, y el de Alice, con exactamente 1.000.000 de sats bajo su control. 

Segundo, la verificación. La wallet de Alice recorre el borrador y comprueba que el árbol, seguido desde la raíz, desemboca en un asiento de 1.000.000 de sats que solo ella puede gastar. No necesita revisar las ramas ajenas: solo la suya, la secuencia de transacciones que va de la raíz a su hoja. 

Tercero, las firmas. Se firma de las hojas hacia la raíz: primero las transacciones finales, luego las ramas intermedias, y al final la que gasta el asiento mancomunado. Cada usuario firma únicamente las transacciones de su propia rama; el servidor firma todas, siempre. 

Cuarto, la publicación. Solo cuando el árbol entero está firmado, el servidor transmite la transacción de compromiso a la red Bitcoin. Es la única que se escribe en la contabilidad. El resto —todo el árbol— queda guardado en las wallets: válido, listo, pero inédito. La rama de Alice, de la raíz a su hoja, es su VTXO. 

En este ejemplo el árbol se parte en dos por nivel (un árbol binario), lo más simple de explicar. En la práctica, las implementaciones pueden usar otras formas: la de Second, por ejemplo, parte cada rama en cuatro, precisamente para que las salidas de emergencia requieran menos transacciones. 

Cada transacción del árbol está firmada por los usuarios de esa rama más el servidor, usando multifirmas construidas con la tecnología de Taproot y el esquema MuSig. Gracias a ello, una multifirma de muchos participantes aparece en la cadena de bloques como si fuera una firma sencilla de Taproot, lo que ahorra muchísimo en comisiones y, de paso, mejora la privacidad.  

La seguridad viene de que Alice tuvo que participar en la firma de su propia rama; nadie puede reescribir el árbol para quitarle su parte sin que todos vuelvan a firmar, y ella no puede tocar las hojas ajenas porque no posee las transacciones que las mueven. El servidor también firma siempre, para que los usuarios no se confabulen contra él. 

5 ¿Cómo se paga dentro de Ark? 

Una vez que Alice tiene su VTXO, pagar es sencillo y prácticamente instantáneo. Las rondas —esos eventos periódicos en los que se arma o renueva un asiento mancomunado— ocurren aproximadamente cada hora, según lo configure el servidor, y cada una es una transacción en la contabilidad. Los pagos entre usuarios no esperan a esas rondas. Ocurren «fuera de ronda» (out of round), con una técnica que las implementaciones llaman arkoor (contracción de «Ark out of round»). Así no hace falta aguardar a que el servidor haga una transacción on-chain para pagarle a alguien. 

Supongamos que Alice, que tiene un VTXO de 1.000.000 de sats, le compra a Bob un artículo de 400.000 sats. Alice y el servidor firman una transacción que gasta el VTXO de Alice y crea dos nuevos: uno de 400.000 sats para Bob y otro de 600.000 sats de cambio que vuelve a Alice. Es la misma lógica contable de Bitcoin —se destruye un asiento, se crean dos—, solo que sin publicar nada. En términos del árbol, la hoja de Alice se extendió: ahora hay una nueva rama que cuelga de ella, con una hoja para Bob y otra para el vuelto de Alice.  

Como este pago no toca la cadena, no tiene costo de liquidez y se liquida casi al instante. No toca la red bitcoin, no espera por confirmación de mineros ni gasta en sus comisiones. Se asienta a la velocidad de internet, pero no se liquida del todo porque no está en la contabilidad de Bitcoin, que es la única capa de liquidación de este dinero digital. 

Refrescar significa volver a participar en una ronda para convertir ese VTXO preconfirmado en un VTXO con el modelo de seguridad completo. En ese momento, Bob deja de depender de la honestidad de Alice y recupera la salida unilateral sin condiciones. Y como los pagos se pueden encadenar —Bob gasta a su vez ese VTXO con Carol antes de refrescarlo—, cada eslabón añade una transacción más a la rama y encarece una eventual salida unilateral; por eso las wallets suelen refrescar en segundo plano sin que el usuario lo note. 

6 ¿Por qué caducan los fondos en Ark? 

Este es el sacrificio que más sorprende a quien viene de Bitcoin on-chain. En la capa base, recibes una moneda y puede pasar un siglo sin que hagas nada: ahí estará. En Ark, en cambio, cada VTXO nace con una fecha de caducidad, que en las implementaciones actuales ronda los 30 días. No es una exageración retórica: en un explorador de Ark, cada transacción muestra literalmente su campo «Created» y su campo «Expires», con unos 30 días de diferencia. 

La razón es económica, y es la clave de todo el modelo. El servidor tuvo que adelantar su propia liquidez para crear esos VTXO, y solo recupera ese bitcoin cuando el asiento mancomunado expira y puede «barrerlo» (sweep) con una sola transacción on-chain. Sin caducidad, un usuario podría mantener bloqueada esa liquidez del servidor para siempre. Por eso, pasado el plazo, si el usuario no actuó, el servidor puede reclamar ese bitcoin. 

¿Y qué significa, en concreto, que el servidor «reclame» el dinero al vencer los 30 días? El script del asiento mancomunado, al cumplirse el plazo establecido en el timelock, deja de bloquear uno de los caminos de gasto de la transacción. A partir de ese instante, ese bitcoin puede gastarlo tanto el usuario como el servidor: no es que tú pierdas la salida y él se quede con todo, sino que la salida deja de ser exclusivamente tuya. Lo que pierdes, entonces, es la exclusividad de tu salida unilateral. 

Y si el servidor sale con los fondos antes que tú, ¿te quedaste sin nada? No necesariamente. Implementaciones como Arkade emiten en ese caso una nota (una arknote) canjeable por un VTXO nuevo, para no dañar su reputación con una pérdida percibida como injusta. Pero ojo con el cambio de naturaleza: mientras tu VTXO estuvo vigente, recuperar tu bitcoin era un derecho que ejercías solo; una vez barrido, pasa a depender de que el servidor te entregue esa nota. 

En la práctica, no deberías llegar ahí. Antes del vencimiento, tu wallet debería refrescar el VTXO automáticamente, firmando un nuevo árbol que te asigna una moneda fresca con 30 días más por delante. Esa renovación sí produce una transacción de compromiso nueva en la cadena. Mientras renueves a tiempo, tu vía unilateral nunca se apaga. 

Este juego puede durar para siempre: mientras el usuario siga renovando ronda tras ronda, el servidor nunca recupera ese capital y simplemente sigue financiándolo, cobrando su comisión por el servicio. El servidor no pierde —le pagan por esperar—, y el usuario conserva sus fondos y su vía de salida. 

Como esa exigencia de estar presente cada cierto tiempo es incómoda, algunas implementaciones crearon la figura del delegado. En Arkade, por ejemplo, el usuario puede autorizar a un tercero a refrescar sus VTXO por él, sin cederle la custodia: firma una prueba de propiedad y una transacción de renuncia parcial que el delegado no puede modificar, solo enviar en el momento autorizado.  

El usuario conserva el control unilateral, y hasta puede correr su propia infraestructura de delegado si prefiere no confiar en nadie. La contrapartida es que un VTXO renovado por un delegado se mantiene en estado preconfirmado —con el modelo de confianza más blando— y no obtiene finalidad plena de Bitcoin hasta que el propio usuario participe en una ronda. 

7 ¿Cómo entro y salgo de Ark? 

Para entrar desde la red Bitcoin a Ark, un usuario firma con el servidor una transacción de ingreso que bloquea sus fondos y, tras algunas confirmaciones, obtiene su VTXO. Los usuarios nuevos ni siquiera necesitan esto: pueden empezar a recibir VTXO al instalar la wallet, sin transacción on-chain previa. Y cuando entras recibiendo por Lightning, el servidor te entrega tu VTXO conectándolo a un árbol existente; por eso puedes fondear una wallet con un pago de Lightning y días después retirar esos mismos fondos on-chain, sin haber firmado nunca una ronda desde cero.  

Para salir otra vez a la contabilidad de Bitcoin hay dos caminos. El cooperativo, llamado offboarding, es el normal: el usuario renuncia a su VTXO a favor del servidor y este paga en la contabilidad de la red Bitcoin con su propia liquidez a la dirección que el usuario elija, de forma atómica —es decir, o se completa entera o no ocurre, sin que ninguna parte quede expuesta—. Suele ser más barato que una transacción on-chain común, porque el costo se reparte. 

El otro camino es la salida unilateral reservada para cuando el servidor no responde o se niega a cooperar. Aquí el usuario transmite él mismo, en orden, todas las transacciones de su rama del árbol. ¿Cuántas son? La cuenta es la del árbol: si cada nivel parte el grupo en dos, con siete niveles se llega a 128 hojas (2, 4, 8, 16, 32, 64, 128). Salir significa publicar tu rama completa: una transacción por nivel —siete, en un árbol de 128 usuarios— más una final que lleva el dinero a una dirección enteramente tuya. Unas ocho transacciones en total. En árboles que se parten en cuatro por nivel, como los de Second, los niveles son menos y la salida es más corta. 

8 ¿Cómo se conecta Ark con Lightning y con el resto de Bitcoin? 

Como los servidores de Ark son jardines cerrados que no se hablan entre sí, Lightning cumple el papel de puente. Un servidor de Ark opera su propia pasarela de Lightning (Lightning gateway): mantiene sus propios canales y nodos, y actúa de intermediario. Así, un usuario de Ark puede pagar una factura de Lightning de cualquiera en la red —o recibir un pago de Lightning como un nuevo VTXO— sin tener que gestionar canales, liquidez entrante ni enrutamiento.  

¿Y por qué pueden entenderse dos sistemas tan distintos? Porque hablan el mismo idioma criptográfico: los HTLC (contratos con bloqueo de tiempo y de hash), los mismos contratos con los que Lightning encadena sus pagos.  

Un HTLC dice, en esencia: «este dinero se libera para quien revele un secreto antes de cierta fecha; si no, vuelve a su dueño». Como los VTXO son transacciones de Bitcoin comunes, pueden incorporar exactamente ese contrato. El servidor arma entonces dos HTLC amarrados al mismo secreto: uno del lado de Ark y otro del lado de Lightning.  

Cuando el pago llega a destino y el secreto se revela, ambos se desbloquean a la vez; si algo falla, ninguno. Ese amarre es el intercambio atómico, y es también lo que permite mover fondos entre dos servidores de Ark distintos usando Lightning como puente. 

9 ¿Quién opera un ASP y cómo gana dinero? 

El Ark Service Provider (ASP) es el coordinador central de un Ark, análogo a un proveedor de servicios Lightning (LSP): construye las transacciones de las rondas, administra el árbol del fondo compartido y aporta la liquidez que hace posibles las transferencias. Pero, a diferencia de un custodio, no puede apropiarse de los fondos que ya están en un VTXO; a lo sumo puede negarse a incluir a un usuario en futuras rondas (censura). 

El modelo de negocio son las comisiones. Un ASP cobra por las operaciones que le cuestan liquidez —renovaciones, pagos de Lightning, offboards—, más las comisiones on-chain y de enrutamiento que debe cubrir.  

Aquí hay una particularidad: renovar un VTXO recién creado cuesta más que renovar uno a punto de expirar. La clave es entender qué se cobra. Cuando renuevas, el servidor debe poner bitcoin fresco para tu VTXO nuevo, pero el bitcoin viejo al que renunciaste no lo recupera hasta que aquel viejo asiento venza. Lo que pagas es el costo de oportunidad de ese capital inmovilizado, y es proporcional al tiempo que queda inmovilizado.  

Si renuevas un VTXO que aún tenía 29 días de vida, el servidor tiene su capital atado 29 días más: caro. Si renuevas uno al que le quedaba un día, lo tiene atado un día: barato. Por eso las wallets renuevan lo más tarde posible, y por eso el sistema empuja a gastar siempre los saldos más viejos primero. Cada servidor fija su política de comisiones; no está codificada en el protocolo. Y si el negocio no le rinde, la salida no es apropiarse de fondos ajenos —no puede—, sino subir comisiones o dejar de aceptar ingresos. 

10 ¿Miles de usuarios comparten una sola moneda? ¿Cuál es el límite? 

Conviene separar la teoría de la realidad presente, porque el potencial de Ark y su uso actual están en puntos muy distintos de la curva. 

En teoría, el número de usuarios que pueden compartir una misma salida a la contabilidad de Bitcoin es muy alto, porque el árbol crece de forma logarítmica: cada nivel multiplica la cantidad de hojas, de modo que la profundidad —y por tanto el costo de una salida unilateral— aumenta despacio, aunque los usuarios se cuenten por cientos.  

Second ha hecho pruebas con alrededor de 100 participantes por ronda, y estima que el modelo actual, sin cambios en Bitcoin, podría sostener del orden de unos pocos miles de VTXO por ronda. Como un usuario solo necesita participar en una ronda cada 30 días para refrescar, ese ritmo se traduce en una capacidad potencial de decenas o cientos de miles de usuarios por servidor. Con covenants como CTV, esos límites subirían drásticamente, porque un emisor podría crear miles de VTXO en una sola transacción sin que cada usuario tenga que estar presente. 

En la práctica, hoy las cifras son modestas. Ambas implementaciones llevan pocos meses en la red Bitcoin, en fase experimental, y manejan cantidades pequeñas mientras la tecnología se prueba. Así que la afirmación honesta es esta: que miles de usuarios compartan una moneda es real como diseño y ya demostrado a pequeña escala, pero todavía no es un fenómeno masivo. Ark está en el punto en que la arquitectura ya existe y funciona, y falta ver cuánta gente termina usándola y para qué. 

Hay, además, un matiz de fondo sobre el rendimiento. A diferencia de Lightning, que escala extraordinariamente bien en volumen de pagos, pero mal en número de wallets, Ark hace justo lo contrario: escala muy bien en número de usuarios, pero su capacidad de mover volumen está más atada al ritmo de la cadena base, porque cada ronda es una transacción on-chain y el servidor debe financiar liquidez. Por eso las dos tecnologías se ven menos como rivales y más como complementarias: Lightning como tejido conectivo entre sistemas, Ark como una de las formas de dar a un usuario individual una wallet autocustodiada barata e instantánea. 

11 ¿Qué se puede hacer hoy con Ark, y con qué wallets? 

Ark ya funciona en versión beta en la red principal de Bitcoin, y las dos implementaciones que lo llevan allí tienen filosofías distintas. Second, el laboratorio fundado por Steven Roose y otros ex-Blockstream, lanzó Bark en mainnet el 9 de junio de 2026, con una apuesta austera y enfocada en una sola cosa: pagos autocustodiados en Bitcoin tan simples como usar una wallet normal. Sobre Bark corren wallets como Noah.  

Ark Labs, fundada por el ex-BTCPay Server Mr. Kukks, sacó Arkade en beta pública en mainnet el 20 de octubre de 2025, con una wallet propia (Arkade Money) y una ambición más amplia. 

Y es que Arkade no se plantea solo como un sistema de pagos, sino como una capa de ejecución programable: además de enviar y recibir bitcoin, permite emitir activos sobre Ark —lo que llama Arkade Assets—, con soporte de stablecoins como el USDT de Tether en camino. La idea es traer de vuelta a Bitcoin la actividad de stablecoins que hoy ocurre mayormente en otras cadenas, aprovechando la programabilidad que dan las monedas virtuales. Es una diferencia de fondo con Second, que deliberadamente se concentra solo en pagos. 

Lo más revelador no es lo que prometen, sino que ya haya gente construyendo sobre ellas. El equipo de HodlHodl, por ejemplo, que durante años peleó con las limitaciones de Lightning para ofrecer préstamos colateralizados con Bitcoin, usó Arkade para crear una herramienta de intercambios atómicos entre bitcoin y stablecoins en otras cadenas, sin tomar custodia de los fondos del usuario. No es adopción masiva. Es algo más temprano y más interesante: constructores tanteando el terreno, en el punto donde Lightning estaba al principio de su propia curva.