Saltar al contenido principal

51 publicaciones etiquetados con "Blockchain"

Ver Todas las Etiquetas

Gráfico Acíclico Dirigido (DAG) en Blockchain

· 51 min de lectura
Dora Noda
Software Engineer

¿Qué es un DAG y en qué se diferencia de una blockchain?

Un gráfico acíclico dirigido (Directed Acyclic Graph, DAG) es un tipo de estructura de datos formada por vértices (nodos) conectados por aristas dirigidas que nunca forman un ciclo. En el contexto de los libros mayores distribuidos, un ledger basado en DAG organiza transacciones o eventos en una red tipo telaraña en lugar de en una cadena secuencial única. Esto significa que, a diferencia de una blockchain tradicional donde cada nuevo bloque referencia solo a un predecesor (formando una cadena lineal), un nodo en un DAG puede referenciar múltiples transacciones o bloques anteriores. Como resultado, muchas transacciones pueden confirmarse en paralelo, en vez de estrictamente una por una en bloques cronológicos.

Para ilustrar la diferencia, si una blockchain se parece a una larga cadena de bloques (cada bloque contiene muchas transacciones), un ledger basado en DAG se asemeja más a un árbol o red de transacciones individuales. Cada nueva transacción en un DAG puede anexarse a (y por tanto validar) una o más transacciones anteriores, en lugar de esperar a ser empaquetada en el siguiente bloque único. Esta diferencia estructural genera varias distinciones clave:

  • Validación paralela: En las blockchains, los mineros/validadores añaden un bloque a la vez a la cadena, por lo que las transacciones se confirman en lotes por cada nuevo bloque. En los DAG, múltiples transacciones (o pequeños “bloques” de transacciones) pueden añadirse de forma concurrente, ya que cada una puede adjuntarse a diferentes partes del grafo. Esta paralelización implica que las redes DAG no tienen que esperar a que una cadena larga crezca bloque a bloque.
  • Sin orden secuencial global: Una blockchain crea inherentemente un orden total de las transacciones (cada bloque ocupa un lugar definido en una única secuencia). Un ledger DAG, en cambio, forma un orden parcial de las transacciones. No existe un único “último bloque” en el que todas las transacciones hagan fila; en su lugar, muchos extremos del grafo pueden coexistir y ampliarse simultáneamente. Luego se necesitan protocolos de consenso para ordenar o acordar el orden o la validez de las transacciones en el DAG.
  • Confirmación de transacciones: En una blockchain, las transacciones se confirman cuando se incluyen en un bloque minado/validado y ese bloque pasa a formar parte de la cadena aceptada (a menudo tras añadirse más bloques encima). En los sistemas DAG, una nueva transacción ayuda por sí misma a confirmar transacciones previas al referenciarlas. Por ejemplo, en el Tangle de IOTA (un DAG), cada transacción debe aprobar dos transacciones anteriores, logrando que los usuarios validen colaborativamente las transacciones de los demás. Esto elimina la división estricta entre “creadores de transacciones” y “validadores” que existe en la minería blockchain: cada participante que emite una transacción también realiza parte del trabajo de validación.

Es importante destacar que una blockchain es en realidad un caso especial de DAG: un DAG restringido a una sola cadena de bloques. Ambos son formas de tecnología de registro distribuido (DLT) y comparten objetivos como la inmutabilidad y la descentralización. Sin embargo, los ledgers basados en DAG son “sin bloques” o multiparentales en su estructura, lo que les da propiedades diferentes en la práctica. Las blockchains tradicionales como Bitcoin y Ethereum usan bloques secuenciales y suelen descartar los bloques competidores (forks), mientras que los ledgers DAG intentan incorporar y ordenar todas las transacciones sin descartar ninguna, siempre que no entren en conflicto. Esta diferencia fundamental sienta las bases de los contrastes de rendimiento y diseño detallados a continuación.

Comparación técnica: arquitectura DAG vs. blockchain

Para entender mejor los DAG frente a las blockchains, podemos comparar sus arquitecturas y procesos de validación:

  • Estructura de datos: Las blockchains almacenan datos en bloques enlazados en una secuencia lineal (cada bloque contiene muchas transacciones y apunta a un único bloque previo, formando una larga cadena). Los ledgers DAG usan una estructura de grafo: cada nodo del grafo representa una transacción o un bloque de eventos, y puede enlazarse a múltiples nodos anteriores. Este grafo dirigido no tiene ciclos, lo que significa que si sigues los enlaces “hacia atrás” nunca volverás a la transacción de la que partiste. La ausencia de ciclos permite un orden topológico de las transacciones (una forma de ordenarlas de modo que cada referencia aparezca después de la transacción referenciada). En resumen, blockchains = cadena unidimensional, DAG = grafo multidimensional.
  • Rendimiento y concurrencia: Debido a las diferencias estructurales, las blockchains y los DAG manejan el rendimiento de manera distinta. Una blockchain, incluso en condiciones óptimas, añade bloques uno por uno (a menudo esperando a que cada bloque se valide y propague por toda la red antes de crear el siguiente). Esto limita inherentemente el rendimiento de transacciones: por ejemplo, Bitcoin promedia 5–7 transacciones por segundo (TPS) y Ethereum alrededor de 15–30 TPS bajo el diseño clásico de proof-of-work. Los sistemas basados en DAG, en cambio, permiten que muchas nuevas transacciones/bloques entren en el ledger simultáneamente. Múltiples ramas de transacciones pueden crecer a la vez y luego entrelazarse, incrementando drásticamente el rendimiento potencial. Algunas redes DAG modernas afirman alcanzar miles de TPS, acercándose o superando la capacidad de las redes de pago tradicionales.
  • Proceso de validación de transacciones: En las redes blockchain, las transacciones esperan en el mempool y se validan cuando un minero o validador las empaqueta en un nuevo bloque, que luego es verificado por otros nodos frente al historial. En las redes DAG, la validación suele ser más continua y descentralizada: cada transacción nueva realiza una acción de validación al referenciar (aprobar) transacciones anteriores. Por ejemplo, cada transacción en el Tangle de IOTA debe confirmar dos transacciones previas comprobando su validez y ejecutando una pequeña prueba de trabajo, “votando” por esas transacciones. En el DAG block-lattice de Nano, las transacciones de cada cuenta forman su propia cadena y se validan mediante votos de nodos representantes (lo explicamos más adelante). El resultado neto es que los DAG distribuyen el trabajo de validación: en lugar de que un único productor de bloques valide un lote de transacciones, cada participante o muchos validadores validan distintas transacciones en paralelo.
  • Mecanismo de consenso: Tanto las blockchains como los DAG necesitan un modo de que la red esté de acuerdo sobre el estado del ledger (qué transacciones están confirmadas y en qué orden). En las blockchains, el consenso suele provenir de la Prueba de Trabajo o la Prueba de Participación generando el siguiente bloque y la regla de “la cadena más larga (o más pesada) gana”. En los ledgers DAG, el consenso puede ser más complejo porque no existe una única cadena. Diferentes proyectos DAG usan distintos enfoques: algunos emplean protocolos gossip y votación virtual (como Hedera Hashgraph) para acordar el orden de las transacciones, otros usan selección de puntas con cadenas de Markov Monte Carlo (el enfoque inicial de IOTA) u otros esquemas de votación para decidir qué ramas del grafo se prefieren. Más adelante detallamos métodos de consenso específicos. En general, alcanzar un acuerdo en toda la red en un DAG puede ser más rápido en términos de rendimiento, pero requiere un diseño cuidadoso para manejar conflictos (como intentos de doble gasto), dado que múltiples transacciones pueden existir en paralelo antes de ordenarse definitivamente.
  • Gestión de forks: En una blockchain, un “fork” (dos bloques minados casi al mismo tiempo) provoca que una rama termine ganando (la cadena más larga) y la otra sea huérfana (descartada), desperdiciando el trabajo realizado en el bloque huérfano. En un DAG, la filosofía es aceptar los forks como ramas adicionales del grafo en lugar de desaprovecharlos. El DAG incorpora ambos forks; el algoritmo de consenso determina qué transacciones se confirman (o cómo se resuelven las que entran en conflicto) sin desechar toda una rama. Esto significa que no se desperdicia energía de minado ni esfuerzo en bloques obsoletos, contribuyendo a la eficiencia. Por ejemplo, el Tree-Graph de Conflux (un DAG de PoW) intenta incluir todos los bloques en el ledger y ordenarlos, en lugar de huérfanar alguno, utilizando así el 100% de los bloques producidos.

En resumen, las blockchains ofrecen una estructura más simple y estrictamente ordenada donde la validación es bloque a bloque, mientras que los DAG proporcionan una estructura de grafo más compleja que permite un procesamiento asíncrono y paralelo de las transacciones. Los ledgers basados en DAG deben emplear lógica de consenso adicional para gestionar esta complejidad, pero prometen una mayor capacidad y eficiencia al utilizar todo el potencial de la red en lugar de obligarla a avanzar en fila india bloque a bloque.

Beneficios de los sistemas blockchain basados en DAG

Las arquitecturas DAG se introdujeron principalmente para superar las limitaciones de las blockchains tradicionales en escalabilidad, velocidad y coste. Estos son los beneficios clave de los ledgers distribuidos basados en DAG:

  • Alta escalabilidad y rendimiento: Las redes DAG pueden lograr altos volúmenes de transacciones porque gestionan muchas operaciones en paralelo. Al no existir un cuello de botella de cadena única, las TPS (transacciones por segundo) pueden escalar con la actividad de la red. De hecho, algunos protocolos DAG han demostrado rendimientos del orden de miles de TPS. Por ejemplo, Hedera Hashgraph tiene capacidad para procesar más de 10.000 transacciones por segundo en la capa base, superando con creces a Bitcoin o Ethereum. En la práctica, Hedera ha demostrado finalizar transacciones en unos 3–5 segundos, frente a los minutos o más que tardan las blockchains PoW. Incluso plataformas de contratos inteligentes basadas en DAG como Fantom han logrado finalidades casi instantáneas (~1–2 segundos) bajo cargas normales. Esta escalabilidad hace que los DAG sean atractivos para aplicaciones que requieren un alto volumen, como microtransacciones IoT o flujos de datos en tiempo real.
  • Costes de transacción bajos (sin comisiones o mínimas): Muchos ledgers DAG presumen de comisiones insignificantes o incluso transacciones sin coste. Por diseño, suelen no depender de mineros que esperen recompensas de bloque o comisiones; por ejemplo, en IOTA y Nano no existen tarifas obligatorias, lo que es crucial para micropagos en IoT y usos cotidianos. Cuando sí hay tarifas (p. ej., en Hedera o Fantom), suelen ser muy bajas y predecibles, ya que la red puede manejar la carga sin guerras de pujas por espacio limitado en bloques. Las transacciones en Hedera cuestan alrededor de 0,0001 dólares (una diezmilésima parte de un dólar), una fracción mínima respecto a las comisiones típicas en blockchain. Este coste reducido abre la puerta a casos de uso como transacciones de alta frecuencia o pagos diminutos inviables en cadenas con tarifas elevadas. Además, como los DAG incluyen todas las transacciones válidas en lugar de descartar algunas en caso de forks, se desperdicia menos trabajo, lo que indirectamente ayuda a mantener bajos los costes aprovechando los recursos con eficiencia.
  • Confirmación rápida y baja latencia: En los ledgers DAG, las transacciones no tienen que esperar a ser incluidas en un bloque global, por lo que la confirmación puede ser más rápida. Muchos sistemas DAG logran finalidad rápida, el punto en el que una transacción se considera permanentemente confirmada. Por ejemplo, el consenso de Hedera Hashgraph suele finalizar transacciones en pocos segundos con certeza del 100% (finalidad ABFT). La red de Nano suele ver transacciones confirmadas en <1 segundo gracias a su proceso de votación ligero. Esta baja latencia mejora la experiencia del usuario, haciendo que las operaciones parezcan casi instantáneas, algo importante para pagos reales y aplicaciones interactivas.
  • Eficiencia energética: Las redes basadas en DAG a menudo no requieren la minería intensiva en pruebas de trabajo que usan muchas blockchains, lo que las hace mucho más eficientes energéticamente. Incluso comparadas con blockchains proof-of-stake, algunas redes DAG consumen energía mínima por transacción. Por ejemplo, una sola transacción en Hedera Hashgraph consume alrededor de 0,0001 kWh (kilovatios-hora). Esto es varios órdenes de magnitud menor que Bitcoin (que puede consumir cientos de kWh por transacción) o incluso que muchas cadenas PoS. La eficiencia proviene de eliminar cálculos desperdiciados (no hay carrera de minado) y de no descartar intentos de transacción. Si las redes blockchain adoptaran modelos basados en DAG de forma generalizada, el ahorro energético sería monumental. La huella de carbono de redes DAG como Hedera es tan baja que el conjunto de la red es carbono-negativa cuando se consideran las compensaciones. Esta eficiencia energética es cada vez más crucial para una infraestructura Web3 sostenible.
  • Sin minería y validación democratizada: En muchos modelos DAG no existe un rol de minero/validador distinto que los usuarios corrientes no puedan desempeñar. Por ejemplo, cada usuario de IOTA que emite una transacción también ayuda a validar otras dos, descentralizando el trabajo de validación hacia los extremos de la red. Esto puede reducir la necesidad de hardware de minería potente o de apostar grandes cantidades de capital para participar en el consenso, lo que potencialmente hace la red más accesible. (Sin embargo, algunas redes DAG siguen usando validadores o coordinadores; más adelante abordamos el consenso y la descentralización).
  • Gestión fluida del alto tráfico: Las blockchains suelen sufrir atascos en el mempool y picos de comisiones bajo alta carga (ya que solo puede añadirse un bloque a la vez). Las redes DAG, debido a su naturaleza paralela, generalmente manejan mejor los picos de tráfico. A medida que más transacciones inundan la red, simplemente crean más ramas paralelas en el DAG, que el sistema puede procesar de forma concurrente. Hay menos un límite rígido de rendimiento (la escalabilidad es más “horizontal”). Esto se traduce en una mejor escalabilidad bajo carga, con menos retrasos y solo incrementos moderados en los tiempos de confirmación o en las tarifas, hasta el límite de la capacidad de red y procesamiento de los nodos. En esencia, un DAG puede absorber ráfagas de transacciones sin congestionar tan rápido, lo que lo hace adecuado para casos de uso con picos de actividad (por ejemplo, dispositivos IoT enviando datos simultáneamente o un evento viral de una DApp).

En resumen, los ledgers basados en DAG prometen transacciones más rápidas, baratas y escalables que el enfoque blockchain clásico. Pretenden soportar escenarios de adopción masiva (micropagos, IoT, trading de alta frecuencia, etc.) con los que las blockchains principales actuales tienen dificultades debido a limitaciones de rendimiento y coste. Sin embargo, estos beneficios vienen acompañados de ciertos compromisos y desafíos de implementación, que abordamos en secciones posteriores.

Mecanismos de consenso en plataformas basadas en DAG

Como los ledgers DAG no producen naturalmente una única cadena de bloques, requieren mecanismos de consenso innovadores para validar transacciones y asegurar que todos acuerdan el estado del ledger. Diferentes proyectos han desarrollado soluciones adaptadas a su arquitectura DAG. Aquí resumimos algunos enfoques notables utilizados por plataformas basadas en DAG:

  • Tangle de IOTA – selección de puntas y votación ponderada: El Tangle de IOTA es un DAG de transacciones diseñado para el Internet de las Cosas (IoT). En el modelo original de IOTA no hay mineros; en su lugar, cada nueva transacción debe realizar una pequeña prueba de trabajo y aprobar dos transacciones previas (las “puntas” del grafo). Esta selección de puntas suele hacerse mediante un algoritmo de Markov Chain Monte Carlo (MCMC) que elige probabilísticamente qué puntas aprobar, favoreciendo el subtangle más pesado para evitar la fragmentación. El consenso en la primera versión de IOTA se lograba en parte por este peso acumulado de aprobaciones: cuantas más transacciones futuras aprueban indirectamente la tuya, más “confirmada” se vuelve. No obstante, para asegurar la red en sus inicios, IOTA dependía de un nodo centralizado temporal, el Coordinator, que emitía transacciones de hito para finalizar el Tangle. Esta centralización recibió críticas y está siendo eliminada en la actualización conocida como “Coordicide” (IOTA 2.0). En IOTA 2.0, un nuevo modelo de consenso aplica un consenso tipo Nakamoto sin líderes sobre un DAG. En esencia, los nodos realizan votación en el propio Tangle: cuando un nodo adjunta un nuevo bloque, ese bloque vota implícitamente sobre la validez de las transacciones que referencia. Un comité de validadores (elegidos mediante un mecanismo de staking) emite bloques de validación como votos, y una transacción se confirma cuando acumula suficientes aprobaciones ponderadas (concepto denominado approval weight). Este enfoque combina la idea del DAG más pesado (similar a la cadena más larga) con una votación explícita para lograr consenso sin un coordinador. En resumen, el consenso de IOTA evolucionó de la selección de puntas + Coordinador a una votación descentralizada sobre las ramas del DAG, buscando seguridad y acuerdos rápidos sobre el estado del ledger.
  • Hedera Hashgraph – gossip y votación virtual (aBFT): Hedera Hashgraph usa un DAG de eventos junto con un algoritmo de consenso asíncrono tolerante a fallas bizantinas (aBFT). La idea central es “gossip about gossip”: cada nodo difunde rápidamente información firmada sobre las transacciones y sobre su historial de gossip a otros nodos. Esto crea un Hashgraph (el DAG de eventos) donde cada nodo termina sabiendo qué ha difundido cada otro nodo, incluyendo la estructura de quién oyó qué y cuándo. A partir de este DAG de eventos, Hedera implementa votación virtual. En lugar de enviar mensajes de voto reales para ordenar las transacciones, los nodos simulan localmente un algoritmo de votación analizando el grafo de conexiones de gossip. El algoritmo Hashgraph de Leemon Baird puede calcular de forma determinista cómo se desarrollaría una ronda teórica de votos sobre el orden de las transacciones, examinando la “red de gossip” registrada en el DAG. Esto produce una marca de tiempo de consenso y un orden total de transacciones que es justo y definitivo (las transacciones se ordenan por la mediana del momento en que la red las recibió). El consenso de Hashgraph es sin líderes y logra aBFT, lo que significa que puede tolerar hasta 1/3 de nodos maliciosos sin comprometerse. En la práctica, la red de Hedera está gobernada por un conjunto de 39 nodos operados por organizaciones conocidas (el Consejo de Hedera), por lo que es permisionada pero geográficamente distribuida. El beneficio es un consenso extremadamente rápido y seguro: Hedera alcanza la finalidad en segundos con consistencia garantizada. El mecanismo de consenso Hashgraph es patentado pero fue abierto en 2024, y muestra cómo un DAG sumado a un consenso innovador (gossip y votación virtual) puede reemplazar un protocolo blockchain tradicional.
  • Lachesis de Fantom – PoS aBFT sin líderes: Fantom es una plataforma de contratos inteligentes que usa un consenso basado en DAG llamado Lachesis. Lachesis es un protocolo PoS aBFT inspirado en Hashgraph. En Fantom, cada validador agrupa las transacciones recibidas en un bloque de eventos y lo añade a su propio DAG local de eventos. Estos bloques contienen transacciones y referencias a eventos anteriores. Los validadores difunden estos bloques de eventos entre sí de forma asíncrona: no hay una secuencia única en la que deban producirse o acordarse los bloques. Conforme los bloques se propagan, los validadores identifican periódicamente ciertos eventos como hitos (o “bloques raíz”) cuando una supermayoría de nodos los ha visto. Lachesis ordena estos eventos finalizados y los compromete en una Opera Chain final (una estructura de blockchain tradicional) que actúa como ledger de bloques confirmados. En esencia, el DAG de bloques de eventos permite a Fantom lograr consenso de forma asíncrona y muy rápida, y luego el resultado final se linealiza para compatibilidad. Esto brinda una finalidad de ~1–2 segundos por transacción en Fantom. Lachesis no tiene mineros ni líderes que propongan bloques; todos los validadores aportan bloques de eventos y el protocolo los ordena determinísticamente. El consenso está asegurado por un modelo PoS (los validadores deben hacer staking de tokens FTM y están ponderados por su stake). Lachesis también es aBFT, tolerando hasta 1/3 de nodos defectuosos. Al combinar la concurrencia del DAG con una salida en cadena final, Fantom logra un alto rendimiento (varios miles de TPS en pruebas) mientras sigue siendo compatible con la EVM para contratos inteligentes. Es un buen ejemplo de usar un DAG internamente para aumentar el rendimiento sin exponer su complejidad a la capa de aplicación (los desarrolladores siguen viendo una cadena normal de transacciones).
  • Votación de Representantes Abiertos (ORV) de Nano: Nano es una criptomoneda orientada a pagos que emplea una estructura DAG única llamada block-lattice. En Nano, cada cuenta tiene su propia blockchain (account-chain) que solo su propietario puede actualizar. Todas esas cadenas individuales forman un DAG, ya que las transacciones de distintas cuentas se enlazan de forma asíncrona (un envío en la cadena de una cuenta referencia una recepción en otra, etc.). El consenso en Nano se logra mediante un mecanismo llamado Open Representative Voting (ORV). Los usuarios designan un nodo representante para su cuenta (una delegación de peso, sin bloquear fondos) y estos representantes votan sobre la validez de las transacciones. Cada transacción se liquida individualmente (no hay bloques que agrupen múltiples tx) y se considera confirmada cuando una supermayoría (por ejemplo, >67%) del peso de voto (de los representantes) está de acuerdo. Dado que los titulares honestos no intentarán gastar dos veces sus propios fondos, los forks son raros y suelen deberse a intentos maliciosos, que los representantes pueden rechazar rápidamente. La finalidad suele alcanzarse en menos de un segundo por transacción. ORV es similar a la Prueba de Participación en que el peso del voto se basa en los saldos (stake), pero no hay recompensas de staking ni comisiones: los representantes son nodos voluntarios. La ausencia de minería y producción de bloques permite a Nano operar sin comisiones y con eficiencia. Sin embargo, depende de que un conjunto de representantes confiables esté en línea para votar, y existe una centralización implícita en los nodos que acumulan gran peso de voto (aunque los usuarios pueden cambiar de representante en cualquier momento, manteniendo el control de la descentralización en manos de la comunidad). El consenso de Nano es liviano y optimizado para la velocidad y eficiencia energética, en línea con su objetivo de ser un dinero digital rápido y sin comisiones.
  • Otros enfoques destacados: Existen otros protocolos de consenso basados en DAG. Además de Hedera Hashgraph y Fantom Lachesis:
    • Consenso Avalanche (Avalanche/X-Chain): Avalanche emplea un consenso basado en DAG donde los validadores se muestrean repetidamente entre sí de forma aleatoria para decidir qué transacciones o bloques preferir. La X-Chain de Avalanche (cadena de intercambio) es un DAG de transacciones (UTXO) y alcanza consenso mediante este muestreo de red. El protocolo de Avalanche es probabilístico pero extremadamente rápido y escalable: puede finalizar transacciones en ~1 segundo y, según se informa, manejar hasta 4.500 TPS por subred. Su enfoque es único al combinar estructuras DAG con un consenso metastable (protocolo Snowball), y está asegurado por Proof-of-Stake (cualquiera puede ser validador con stake suficiente).
    • Tree-Graph de Conflux: Conflux es una plataforma que extendió el PoW de Bitcoin a un DAG de bloques. Utiliza una estructura Tree-Graph donde los bloques referencian no solo a un padre sino a todos los bloques previos conocidos (sin huerfanar). Esto permite a Conflux usar minería PoW pero mantener todos los forks como parte del ledger, logrando mucho mayor rendimiento que una cadena típica. Así, Conflux puede alcanzar teóricamente entre 3.000 y 6.000 TPS usando PoW, permitiendo que los mineros produzcan bloques continuamente sin esperar a una sola cadena. Su consenso ordena estos bloques y resuelve conflictos mediante una regla de subárbol más pesado. Es un ejemplo de DAG híbrido con PoW.
    • Variantes de Hashgraph y protocolos académicos: Hay numerosos protocolos DAG académicos (algunos implementados en proyectos recientes): SPECTRE y PHANTOM (protocolos blockDAG orientados a alto rendimiento y confirmación rápida, de DAGlabs), Aleph Zero (un consenso DAG aBFT usado en la blockchain Aleph Zero), Parallel Chains / Prism (proyectos de investigación que separan la confirmación en subcadenas paralelas y DAGs), y avances recientes como Narwhal & Bullshark de Sui, que usan un mempool en DAG para alto rendimiento y un consenso separado para la finalidad. Aunque no todos tienen despliegues a gran escala, indican un campo de investigación vibrante. Muchos de estos protocolos distinguen entre disponibilidad (escribir datos rápidamente en un DAG) y consistencia (ponerse de acuerdo en una historia), buscando obtener lo mejor de ambas.

Cada plataforma DAG adapta su consenso a sus necesidades —ya sean micropagos sin comisiones, ejecución de contratos inteligentes o interoperabilidad—. Un tema común, sin embargo, es evitar un cuello de botella serial único: los mecanismos de consenso basados en DAG buscan permitir mucha actividad concurrente y luego usan algoritmos ingeniosos (gossip, votación, muestreo, etc.) para ordenar todo, en vez de limitar la red a un único productor de bloques por turno.

Estudios de caso: ejemplos de proyectos blockchain basados en DAG

Varios proyectos han implementado ledgers basados en DAG, cada uno con decisiones de diseño y casos de uso específicos. A continuación analizamos algunas plataformas DAG destacadas:

  • IOTA (The Tangle): IOTA es una de las primeras criptomonedas basadas en DAG, diseñada para el Internet de las Cosas. Su ledger, llamado Tangle, es un DAG de transacciones donde cada nueva transacción confirma dos anteriores. El objetivo de IOTA es habilitar microtransacciones sin comisiones entre dispositivos IoT (pagos diminutos por datos o servicios). Lanzada en 2016, para arrancar con seguridad usó un Coordinador (ejecutado por la Fundación IOTA) que prevenía ataques en la red temprana. IOTA ha estado trabajando en “Coordicide” para descentralizar completamente la red introduciendo un consenso por votación (como describimos antes) donde los nodos votan transacciones conflictivas usando un consenso tipo Nakamoto sin líderes sobre el DAG más pesado. En términos de rendimiento, IOTA puede, en teoría, lograr un rendimiento muy alto (el protocolo no impone un límite rígido de TPS; mayor actividad incluso ayuda a confirmar más rápido). En la práctica, las testnets han demostrado cientos de TPS, y se espera que IOTA 2.0 escale bien para la demanda IoT. Los casos de uso de IOTA giran en torno al IoT y la integridad de datos: por ejemplo, transmisión de datos de sensores con pruebas de integridad, pagos entre vehículos, trazabilidad en la cadena de suministro e incluso identidad descentralizada (el marco IOTA Identity permite emitir y verificar credenciales/identificadores descentralizados en el Tangle). IOTA no admite contratos inteligentes en su capa base, pero el proyecto introdujo un marco paralelo de Smart Contracts y tokens en una capa secundaria para habilitar DApps más complejas. Una característica destacada de IOTA es su ausencia de comisiones, habilitada al requerir una pequeña prueba de trabajo del emisor en lugar de cobrar una tarifa, lo cual es atractivo para transacciones de bajo valor y alto volumen (p. ej., un sensor enviando datos cada pocos segundos a coste insignificante).
  • Hedera Hashgraph (HBAR): Hedera es un ledger público distribuido que usa el algoritmo de consenso Hashgraph (inventado por Leemon Baird). Hedera comenzó en 2018 y está gobernada por un consejo de grandes organizaciones (Google, IBM, Boeing y otras) que operan el conjunto inicial de nodos. A diferencia de la mayoría, Hedera es permisionada en la gobernanza (solo miembros aprobados del consejo ejecutan nodos de consenso actualmente, hasta 39 nodos), aunque cualquiera puede utilizar la red. Su DAG Hashgraph permite altísimo rendimiento y finalidad rápida: Hedera puede procesar más de 10.000 TPS con finalidad en 3-5 segundos en condiciones óptimas. Lo consigue gracias al consenso aBFT basado en gossip que describimos antes. Hedera enfatiza casos de uso empresariales y Web3 que necesitan fiabilidad a escala: la red ofrece servicios de tokenización (Hedera Token Service), un Servicio de Consenso para registro inmutable de eventos y un servicio de Smart Contracts (compatible con la EVM). Aplicaciones notables en Hedera incluyen trazabilidad en la cadena de suministro (p. ej., seguimiento de prendas por Avery Dennison), minting masivo de NFT (las bajas comisiones abaratan el proceso), pagos y micropagos (como micropagos en ad tech) e incluso soluciones de identidad descentralizada. Hedera tiene un método DID registrado en el W3C y marcos como Hedera Guardian para admitir credenciales verificables y cumplimiento normativo (por ejemplo, seguimiento de créditos de carbono). Un aspecto clave es el fuerte rendimiento de Hedera combinado con la estabilidad declarada (el algoritmo Hashgraph garantiza ausencia de forks y una equidad matemática en el orden). El compromiso es que Hedera es menos descentralizada en número de nodos que redes abiertas (por diseño, con su modelo de gobernanza), aunque los nodos del consejo están distribuidos globalmente y el plan es aumentar la apertura con el tiempo. En resumen, Hedera Hashgraph es un ejemplo destacado de DLT basada en DAG orientada a aplicaciones empresariales, con énfasis en alto rendimiento, seguridad y gobernanza.
  • Fantom (FTM): Fantom es una plataforma de contratos inteligentes (blockchain de Capa 1) que utiliza un consenso basado en DAG llamado Lachesis. Lanzada en 2019, Fantom ganó popularidad especialmente durante el auge DeFi de 2021-2022 como una cadena compatible con Ethereum pero con mayor rendimiento. La red Opera de Fantom ejecuta el consenso Lachesis aBFT (ya detallado), donde los validadores mantienen un DAG local de bloques de eventos, logran consenso de forma asíncrona y luego finalizan las transacciones en una cadena principal. Esto otorga a Fantom un tiempo de finalidad de ~1 segundo por transacción y la capacidad de manejar miles de TPS. Fantom es compatible con la EVM, lo que permite a los desarrolladores desplegar contratos Solidity y usar las mismas herramientas que Ethereum, facilitando su adopción en DeFi. De hecho, Fantom se convirtió en hogar de numerosos proyectos DeFi (DEX, protocolos de préstamos, yield farms) atraídos por su velocidad y bajas comisiones. También alberga proyectos NFT y DApps de gaming, prácticamente cualquier aplicación Web3 que se beneficie de transacciones rápidas y baratas. Un punto notable es que Fantom alcanzó un alto grado de descentralización para una plataforma DAG: cuenta con decenas de validadores independientes que aseguran la red (sin permisos, cualquiera puede ejecutar un validador con el stake mínimo), a diferencia de algunas redes DAG que restringen los validadores. Esto posiciona a Fantom como una alternativa creíble a blockchains más tradicionales para aplicaciones descentralizadas, aprovechando la tecnología DAG para superar el cuello de botella del rendimiento. El token FTM se usa para staking, gobernanza y comisiones (solo unos céntimos por transacción, mucho menos que el gas de Ethereum). Fantom demostró que el consenso basado en DAG puede integrarse con plataformas de contratos inteligentes para lograr simultáneamente velocidad y compatibilidad.
  • Nano (XNO): Nano es una criptomoneda ligera lanzada en 2015 (originalmente como RaiBlocks) que usa una estructura DAG block-lattice. El enfoque principal de Nano es ser dinero digital punto a punto: transacciones instantáneas, sin comisiones y con un consumo mínimo de recursos. En Nano, cada cuenta tiene su propia cadena de transacciones, y las transferencias entre cuentas se gestionan mediante un bloque de envío en la cadena del remitente y un bloque de recepción en la del destinatario. Este diseño asíncrono permite que la red procese transacciones de forma independiente y en paralelo. El consenso se logra mediante la votación de representantes abiertos (ORV), donde la comunidad designa nodos representantes delegando su saldo. Los representantes votan en transacciones conflictivas (lo cual es raro, generalmente solo en intentos de doble gasto) y, una vez que una mayoría cualificada (67% del peso) está de acuerdo, la transacción se consolida (confirmada irrevocablemente). Los tiempos típicos de confirmación en Nano son muy inferiores a un segundo, lo que la hace sentir instantánea en el uso cotidiano. Al no existir recompensas de minería ni comisiones, operar un nodo o representante Nano es un esfuerzo voluntario, pero el diseño de la red minimiza la carga (cada transacción pesa apenas 200 bytes y se procesa rápidamente). El enfoque DAG y el consenso de Nano le permiten ser extremadamente eficiente energéticamente: existe una pequeña prueba de trabajo realizada por los remitentes (principalmente como medida antispam), pero es trivial comparada con la PoW blockchain. Los casos de uso de Nano son sencillos por diseño: está pensada para transferencias monetarias, desde compras diarias hasta remesas, donde la velocidad y la ausencia de tarifas son su propuesta de valor. Nano no admite contratos inteligentes ni scripting complejo; se centra en hacer muy bien una sola cosa. Un desafío de su modelo es que se basa en la honestidad de la mayoría de los representantes; al no haber incentivos monetarios, el modelo de seguridad se apoya en la suposición de que los grandes tenedores actuarán en beneficio de la red. Hasta ahora, Nano ha mantenido un conjunto bastante descentralizado de representantes principales y ha visto uso en pagos comerciales, propinas y otros micropagos en línea.
  • Comparativa rápida Hedera vs IOTA vs Fantom vs Nano: La siguiente tabla resume algunas características clave de estos proyectos basados en DAG:
Proyecto (Año)Estructura de datos y consensoRendimiento (TPS y finalidad)Características / casos de uso destacados
IOTA (2016)DAG de transacciones (“Tangle”); cada tx aprueba 2 previas. Originalmente con coordinador; migrando a un consenso sin líderes descentralizado (voto sobre el DAG más pesado, sin mineros).TPS teóricamente alto (escala con la actividad); ~10 s de confirmación en redes activas (más rápido con mayor carga). Investigación en curso para mejorar la finalidad. Transacciones sin comisiones.Micropagos y datos IoT (microtransacciones sin comisiones), cadena de suministro, datos de sensores, automoción, identidad descentralizada (método DID de IOTA Identity). Sin smart contracts en la capa base (se gestionan en capas separadas).
Hedera Hashgraph (2018)DAG de eventos (Hashgraph); consenso gossip-about-gossip + votación virtual (aBFT), operado por ~29–39 nodos del consejo (ponderados por PoS). Sin mineros; marcas de tiempo para ordenar.~10.000 TPS máx.; finalidad en 3-5 segundos por transacción. Energía extremadamente baja por tx (~0,0001 kWh). Tarifas fijas muy bajas (~0,0001 $ por transferencia).Aplicaciones empresariales y Web3: tokenización (HTS), NFTs y servicios de contenidos, pagos, trazabilidad en cadena de suministro, datos sanitarios, gaming, etc. Gobernanza por grandes corporaciones; red compatible con la EVM para smart contracts (Solidity). Enfoque en alto rendimiento y seguridad empresarial.
Fantom (FTM) (2019)DAG de bloques de eventos de validadores; consenso PoS Lachesis aBFT (sin líderes). Cada validador construye un DAG de eventos que se confirma y se ensambla en una blockchain final (Opera Chain).Empíricamente cientos de TPS en uso DeFi; finalidad típica de 1-2 segundos. Capaz de miles de TPS en benchmarks. Tarifas bajas (fracciones de centavo).DeFi y smart contracts en una L1 de alta velocidad. Compatible con la EVM (ejecuta DApps Solidity). Soporta DEX, préstamos, marketplaces NFT (trading rápido, mint barato). El consenso DAG queda oculto tras una interfaz blockchain amigable. Cualquier persona puede hacer staking (conjunto de validadores descentralizado).
Nano (XNO) (2015)DAG de cadenas de cuenta (block-lattice); cada tx es su propio bloque. Consenso por votación de representantes abiertos (tipo dPoS en conflictos). Sin minería ni comisiones.~Cientos de TPS factibles (limitados principalmente por E/S de red). Confirmación <1 s típica. Sin comisiones. Uso de recursos extremadamente bajo (eficiente para IoT/móvil).Moneda digital para pagos instantáneos. Ideal para micropagos, propinas, comercio minorista, donde las tarifas y la latencia deben ser mínimas. No está diseñada para smart contracts; se centra en transferencias simples. Consumo energético muy bajo (criptomoneda ecológica). Representantes administrados por la comunidad (sin autoridad central).

(Tabla: comparación de proyectos de ledger basados en DAG seleccionados y sus características. TPS = transacciones por segundo.)

Otros proyectos basados en DAG no detallados incluyen Obyte (Byteball) – un ledger DAG para pagos condicionales y almacenamiento de datos, IoT Chain (ITC) – un proyecto DAG orientado al IoT, Avalanche – que ya mencionamos por usar DAG en su consenso y se ha convertido en una plataforma DeFi importante, Conflux – un DAG PoW de alto rendimiento en China, y prototipos académicos como SPECTRE/PHANTOM. Cada uno explora el espacio de diseño de los ledgers DAG de distintas maneras, pero los cuatro ejemplos anteriores (IOTA, Hedera, Fantom, Nano) ilustran la diversidad: desde microtransacciones IoT sin comisiones hasta redes empresariales y cadenas de contratos inteligentes DeFi, todos aprovechando estructuras DAG.

Casos de uso de la tecnología DAG en el ecosistema Web3

Los sistemas blockchain basados en DAG desbloquean determinados casos de uso gracias a su alto rendimiento y propiedades únicas. Estos son algunos casos de uso actuales y potenciales en los que los DAG están impactando en Web3:

  • Internet de las Cosas (IoT): El IoT implica millones de dispositivos transmitiendo datos y potencialmente transaccionando entre sí (pagos máquina a máquina). Ledgers DAG como IOTA se diseñaron explícitamente para este escenario. Con microtransacciones sin comisiones y la capacidad de manejar frecuencias altas de pagos pequeños, un ledger DAG puede permitir que dispositivos IoT paguen por servicios o ancho de banda sobre la marcha. Por ejemplo, un coche eléctrico inteligente podría pagar automáticamente a una estación de carga unos céntimos por la energía, o los sensores podrían vender datos a una plataforma en tiempo real. El Tangle de IOTA se ha usado en pilotos de ciudades inteligentes, integraciones de IoT en cadenas de suministro (seguimiento de mercancías y condiciones ambientales) y mercados descentralizados de datos donde se registran y comercian los datos de sensores de forma inmutable. La escalabilidad de los DAG aborda el enorme volumen que generan las redes IoT masivas, y su bajo coste se ajusta a la economía de los micropagos.
  • Finanzas descentralizadas (DeFi): Aplicaciones DeFi como los exchanges descentralizados (DEX), plataformas de préstamos y redes de pagos se benefician de un alto rendimiento y baja latencia. Las plataformas de smart contracts basadas en DAG (p. ej., Fantom, y en cierta medida la X-Chain de Avalanche para transferencias simples de activos) ofrecen la ventaja de liquidar operaciones más rápido y mantener comisiones bajas incluso durante alta demanda. En 2021, Fantom experimentó un aumento de actividad DeFi (yield farming, market makers automatizados, etc.) y pudo manejarlo con mucha menos congestión que Ethereum en ese momento. Además, la finalidad rápida de los DAG reduce el riesgo de incertidumbre en la ejecución de operaciones (en cadenas lentas, los usuarios esperan varios bloques para la finalidad, lo que introduce riesgo en el trading veloz). Otra perspectiva son las redes de pagos descentralizados: Nano, por ejemplo, puede considerarse parte del espectro DeFi, habilitando transferencias peer-to-peer y posiblemente actuando como carril de micropagos para capas 2 de otros sistemas. El rendimiento de los DAG también podría soportar trading de alta frecuencia o transacciones DeFi complejas multi-paso ejecutándose con mayor fluidez.
  • NFT y gaming: El boom de los NFT evidenció la necesidad de minting y transferencias de bajo coste. En Ethereum, acuñar NFT se volvió costoso cuando el gas se disparó. Redes DAG como Hedera y Fantom se han planteado como alternativas donde acuñar un NFT cuesta una fracción de centavo, haciéndolas viables para activos en juegos, coleccionables o lanzamientos a gran escala. El Token Service de Hedera permite la emisión nativa de tokens y NFT con tarifas bajas y predecibles, y ha sido usado por plataformas de contenido e incluso empresas (p. ej., artistas musicales emitiendo tokens o universidades registrando títulos). En gaming, donde abundan las microtransacciones, un ledger DAG rápido puede gestionar frecuentes intercambios de activos o distribución de recompensas sin ralentizar el juego ni arruinar a los jugadores con comisiones. El alto rendimiento garantiza que, incluso si un juego o colección NFT popular atrae a millones de usuarios, la red pueda soportar la carga (hemos visto juegos en Ethereum congestionar la red en el pasado). Por ejemplo, un juego basado en NFT en Fantom puede actualizar el estado lo suficientemente rápido como para ofrecer una experiencia casi en tiempo real.
  • Identidad descentralizada (DID) y credenciales: Los sistemas de identidad se benefician de un ledger inmutable para anclar identidades, credenciales y atestaciones. Las redes DAG se exploran aquí porque ofrecen escalabilidad para potencialmente miles de millones de transacciones de identidad (cada login, emisión de certificado, etc.) y bajo coste, crucial si, por ejemplo, cada interacción de identidad de un ciudadano se registrara. IOTA Identity es un ejemplo: proporciona un método DID did:iota donde los documentos de identidad se referencian en el Tangle. Se puede usar para identidad autosoberana: los usuarios controlan sus documentos y los verificadores pueden obtener pruebas del DAG. Hedera también está activa en el ámbito DID: tiene una especificación DID y se ha usado en proyectos como registros inmutables de títulos universitarios, certificados de vacunación COVID o documentos de cumplimiento en la cadena de suministro (a través del Hedera Consensus Service como servicio de anclaje). Las ventajas de los DAG aquí son que es barato y rápido escribir datos, de modo que actualizar un estado de identidad (rotar claves, añadir credenciales) no enfrenta el coste o retraso de una blockchain congestionada. Además, las garantías de finalidad y orden pueden ser importantes para auditorías (Hashgraph, por ejemplo, proporciona un orden temporal confiable útil para registros de cumplimiento).
  • Cadena de suministro e integridad de datos: Más allá de la identidad, cualquier caso de uso que involucre registrar un alto volumen de datos puede aprovechar DLT basadas en DAG. La trazabilidad en cadenas de suministro es uno: los productos generan muchos eventos (fabricado, enviado, inspeccionado, etc.). Proyectos han usado Hedera e IOTA para registrar estos eventos en un ledger DAG, aportando inmutabilidad y transparencia. El alto rendimiento garantiza que el ledger no sea un cuello de botella, incluso si se escanea y registra cada artículo de una red de suministro grande. Además, las comisiones nulas o bajas permiten registrar eventos de bajo valor sin costes elevados. Otro ejemplo es la integridad de datos IoT: redes eléctricas o telecomunicaciones pueden registrar lecturas de dispositivos en un ledger DAG para demostrar posteriormente que los datos no fueron manipulados. El DAG de Constellation Network (otro proyecto DAG) se centra en la validación de grandes volúmenes de datos para empresas y gobiernos (como la integridad de datos de drones de la Fuerza Aérea de EE. UU.), destacando cómo un DAG escalable puede manejar flujos masivos de datos de forma confiable.
  • Pagos y remesas: Transacciones rápidas y sin comisiones hacen que criptomonedas DAG como Nano e IOTA sean adecuadas para pagos. Nano ha sido adoptada en escenarios como propinas online (donde un usuario puede enviar unos céntimos instantáneamente a un creador de contenido) y remesas internacionales (donde la velocidad y coste cero marcan una gran diferencia frente a esperar horas y pagar porcentajes elevados). Las redes DAG pueden servir como carriles de pago de alta velocidad integrados en sistemas de punto de venta o aplicaciones móviles. Por ejemplo, una cafetería podría usar una criptomoneda DAG para los pagos sin preocuparse por la latencia o el coste (la experiencia puede rivalizar con una tarjeta de crédito contactless). HBAR de Hedera también se usa en algunas pruebas de pago (su finalidad rápida y baja tarifa atraen a aplicaciones fintech para liquidación). Además, como las redes DAG suelen tener mayor capacidad, pueden mantener el rendimiento incluso durante eventos globales de compras o picos de uso, algo valioso para la fiabilidad de pagos.
  • Feeds de datos en tiempo real y oráculos: Los oráculos (servicios que introducen datos externos en contratos inteligentes) requieren escribir muchos datos en un ledger. Un ledger DAG podría actuar como una red de oráculos de alto rendimiento, registrando precios, datos climáticos, lecturas de sensores IoT, etc., con garantía de orden y marca temporal. El Hedera Consensus Service, por ejemplo, es utilizado por algunos proveedores de oráculos para sellar datos antes de alimentarlos a otras cadenas. La velocidad asegura datos frescos y el rendimiento permite manejar flujos rápidos. En analítica Web3 descentralizada o publicidad, donde cada clic o impresión podría registrarse para transparencia, un backend DAG puede soportar el volumen de eventos.

En todos estos casos, el hilo común es que las redes DAG buscan proporcionar la escalabilidad, velocidad y eficiencia de costes que amplían el alcance de lo que se puede descentralizar. Son particularmente útiles donde ocurren transacciones de alta frecuencia o alto volumen (IoT, microtransacciones, datos de máquinas) o donde la experiencia del usuario exige interacciones rápidas y fluidas (gaming, pagos). No obstante, no todos los casos de uso migrarán a ledgers DAG: a veces la madurez y seguridad de las blockchains tradicionales, o simplemente los efectos de red (por ejemplo, la enorme base de desarrolladores de Ethereum), pesan más que la necesidad de rendimiento bruto. Aun así, los DAG están labrándose un nicho en la pila Web3 para escenarios que tensionan a las cadenas convencionales.

Limitaciones y desafíos de las redes basadas en DAG

Aunque los ledgers distribuidos basados en DAG ofrecen ventajas atractivas, también implican compromisos y desafíos. Es importante examinar críticamente estas limitaciones:

  • Madurez y seguridad: La mayoría de los algoritmos de consenso DAG son relativamente nuevos y están menos probados en batalla que los protocolos blockchain bien estudiados de Bitcoin o Ethereum. Esto puede significar vulnerabilidades de seguridad o vectores de ataque aún desconocidos. La complejidad de los sistemas DAG puede abrir nuevas vías de ataque: por ejemplo, un atacante podría intentar inundar o inflar el DAG con subtangles conflictivos, o aprovechar la estructura paralela para gastar doble antes de que la red alcance consenso. Análisis académicos señalan que la complejidad incrementada introduce una gama más amplia de vulnerabilidades frente a cadenas lineales más simples. Algunas redes DAG han sufrido incidencias: por ejemplo, en sus inicios la red de IOTA tuvo que pausarse en un par de ocasiones por irregularidades/ataques (en 2020 se robó un fondo y el Coordinador se detuvo temporalmente para resolverlo). Estos incidentes subrayan que los modelos de seguridad siguen perfeccionándose. Además, en algunos DAG la finalidad es probabilística (p. ej., antes de Coordicide IOTA no tenía finalidad absoluta, solo confianza creciente), lo que puede ser problemático para ciertas aplicaciones (aunque DAG más recientes como Hashgraph y Fantom ofrecen finalidad instantánea con garantías aBFT).
  • Complejidad del consenso: Lograr consenso en un DAG suele implicar algoritmos complejos (protocolos gossip, votación virtual, muestreo aleatorio, etc.). Esta complejidad se traduce en bases de código más extensas e implementaciones complicadas, aumentando el riesgo de bugs de software. También hace el sistema más difícil de entender para los desarrolladores. La regla de la cadena más larga en una blockchain es conceptualmente simple, mientras que la votación virtual de Hashgraph o el muestreo repetido de Avalanche no son tan intuitivos. La complejidad puede frenar la adopción: desarrolladores y empresas pueden dudar en confiar en un sistema que les cuesta comprender o auditar. Como señaló un estudio, los sistemas basados en órdenes parciales (DAG) requieren más esfuerzo para integrarse con la infraestructura existente y la mentalidad de los desarrolladores. Las herramientas y librerías para redes DAG también son menos maduras en muchos casos, lo que puede empeorar la experiencia de desarrollo frente a Ethereum o Bitcoin.
  • Compromisos de descentralización: Algunas implementaciones DAG actuales sacrifican cierto grado de descentralización para lograr su rendimiento. Por ejemplo, la dependencia de Hedera en un consejo fijo de 39 nodos implica que la red no está abierta a cualquiera para participar en el consenso, lo cual ha recibido críticas pese a sus fortalezas técnicas. IOTA, durante mucho tiempo, dependió de un Coordinador central para evitar ataques, un punto único de fallo/control. El consenso de Nano se basa en un pequeño número de representantes principales que concentran la mayor parte del peso de voto (en 2023, los pocos representantes principales controlaban gran parte del peso en línea), lo que puede considerarse una concentración de poder, aunque es algo análogo a los pools de minería en PoW. En general, se percibe que las blockchains son más fáciles de descentralizar ampliamente (miles de nodos) que algunas redes DAG. Las razones varían: ciertos algoritmos DAG pueden exigir mayores requisitos de ancho de banda (dificultando la participación plena de muchos nodos), o el diseño del proyecto puede mantener intencionalmente una estructura permisionada al inicio. No es una limitación inherente de los DAG, pero en la práctica muchos aún no alcanzan el número de nodos de las grandes blockchains.
  • Necesidad de volumen (seguridad vs rendimiento): Algunas redes DAG requieren paradójicamente un alto volumen de transacciones para funcionar de forma óptima. Por ejemplo, el modelo de seguridad de IOTA se fortalece cuando muchas transacciones honestas se confirman constantemente entre sí (aumentando el peso acumulado de los subtangles honestos). Si la actividad es muy baja, el DAG puede volverse perezoso: puntas sin aprobar rápidamente o atacantes que lo tienen más fácil para intentar sobrescribir partes del grafo. En contraste, una blockchain tradicional como Bitcoin no necesita un número mínimo de transacciones para seguir segura (incluso con pocas transacciones, los mineros siguen compitiendo por extender la cadena). Así, los DAG suelen rendir mejor bajo carga, pero pueden estancarse con uso escaso, salvo que se apliquen medidas especiales (como el coordinador de IOTA o transacciones de “mantenimiento” en segundo plano). Esto significa que el rendimiento puede ser inconsistente: excelente cuando el uso es alto, pero con confirmaciones más lentas en periodos valle o redes con poca actividad.
  • Ordenamiento y compatibilidad: Como los DAG producen un orden parcial de eventos que luego debe hacerse consistente, los algoritmos de consenso pueden ser bastante intrincados. En contextos de contratos inteligentes, se requiere un orden total de las transacciones para evitar doble gastos y mantener la ejecución determinista. Sistemas DAG como Fantom resuelven esto construyendo una capa de ordenamiento (la Opera Chain final), pero no todos los DAG soportan fácilmente smart contracts complejos. El manejo del estado y el modelo de programación puede ser desafiante en un DAG puro. Por ejemplo, si dos transacciones no conflictivas, se pueden confirmar en paralelo en un DAG —eso está bien—. Pero si confligen (p. ej., dos tx gastan el mismo output o dos operaciones sobre el mismo pedido), la red debe decidir una y descartar la otra. Garantizar que todos los nodos tomen la misma decisión de forma descentralizada es más difícil sin una cadena única que lo ordene todo. Por eso muchos proyectos DAG inicialmente evitaron los contratos inteligentes o el estado global y se enfocaron en pagos (donde los conflictos son más sencillos de detectar via UTXO o balances). Interconectar ledgers DAG con ecosistemas blockchain existentes tampoco es trivial; por ejemplo, conectar una EVM a un DAG requirió que Fantom creara un mecanismo para linearizar el DAG para la ejecución EVM. Estas complejidades implican que no todos los casos de uso pueden implementarse inmediatamente sobre un DAG sin un diseño cuidadoso.
  • Almacenamiento y sincronización: Un potencial problema es que, si un ledger DAG permite un volumen alto de transacciones paralelas, el ledger puede crecer rápidamente. Son importantes algoritmos eficientes para podar el DAG (eliminar transacciones antiguas que ya no son necesarias para la seguridad) y para permitir nodos ligeros (los light clients necesitan confirmar transacciones sin almacenar todo el DAG). La investigación ha identificado el desafío de alcanzabilidad: asegurar que las nuevas transacciones puedan alcanzar y referenciar a las anteriores con eficiencia y determinar cómo truncar la historia de forma segura en un DAG. Aunque las blockchains también enfrentan problemas de crecimiento, la estructura del DAG puede complicar tareas como calcular saldos o pruebas para estados parciales, ya que el ledger no es una simple lista de bloques. Es un desafío técnico que puede resolverse, pero añade más carga al diseño de un sistema DAG robusto.
  • Percepción y efectos de red: Más allá de los aspectos técnicos, los proyectos DAG enfrentan el reto de demostrarse en un espacio dominado por blockchains. Muchos desarrolladores y usuarios se sienten más cómodos con las L1 blockchain, y los efectos de red (más usuarios, más dApps, más herramientas en las cadenas existentes) pueden ser difíciles de superar. A veces los DAG se promocionan con afirmaciones audaces (“blockchain killer”), lo que puede invitar al escepticismo. Por ejemplo, un proyecto puede alegar escalabilidad ilimitada, pero los usuarios esperarán ver pruebas en condiciones reales. Hasta que las redes DAG alojan “killer apps” o bases de usuarios grandes, pueden percibirse como experimentales. Además, lograr listados en exchanges, soluciones de custodia, wallets —toda la infraestructura que ya soporta las grandes blockchains— es un esfuerzo continuo para cada nueva plataforma DAG. Hay, por tanto, un desafío de arranque: a pesar de los méritos técnicos, la adopción puede rezagarse por la inercia del ecosistema.

En resumen, los ledgers basados en DAG intercambian simplicidad por rendimiento, y eso conlleva dolores de crecimiento. La complejidad del consenso, la posible centralización en algunas implementaciones y la necesidad de ganarse una confianza comparable a los sistemas blockchain veteranos son obstáculos a superar. La comunidad de investigación estudia activamente estos problemas; por ejemplo, un paper de 2024 de sistematización del conocimiento sobre protocolos DAG destaca la creciente variedad de diseños y la necesidad de comprender integralmente sus compromisos. A medida que los proyectos DAG maduren, probablemente se aborden muchos de estos desafíos (eliminación de coordinadores, participación abierta, mejores herramientas), pero es importante considerarlos al evaluar DAG vs blockchain para una aplicación específica.

Tendencias de adopción y perspectivas futuras

La adopción de la tecnología blockchain basada en DAG todavía está en fases tempranas frente al uso generalizado de las blockchains tradicionales. A 2025, solo un puñado de ledgers públicos usan DAG a escala: entre ellos Hedera Hashgraph, IOTA, Fantom, Nano, Avalanche (en parte de su sistema) y algunos otros. Las blockchains (cadenas lineales) siguen siendo la arquitectura dominante en los sistemas desplegados. Sin embargo, el interés en los DAG ha ido aumentando tanto en la industria como en la academia. Podemos identificar varias tendencias y una perspectiva para los DAG en blockchain:

  • Creciente número de proyectos y estudios DAG: Se aprecia un aumento en la cantidad de proyectos nuevos que exploran arquitecturas DAG o híbridas. Por ejemplo, plataformas recientes como Aleph Zero (una red enfocada en privacidad) usan un consenso DAG para un orden rápido, y Sui y Aptos (cadenas con lenguaje Move) incorporan mempools basados en DAG o motores de ejecución paralela para escalar el rendimiento. La investigación académica en consenso DAG está floreciendo: protocolos como SPECTRE, PHANTOM, GhostDAG y otros más recientes están ampliando los límites, y se publican análisis exhaustivos (papers SoK) para clasificar y evaluar los enfoques DAG. Esto indica una exploración saludable y la aparición de buenas prácticas. A medida que la investigación identifica soluciones a debilidades previas (por ejemplo, cómo lograr equidad, cómo podar DAG, cómo asegurar DAG bajo condiciones dinámicas), es probable que estas innovaciones lleguen a las implementaciones.
  • Modelos híbridos en uso general: Una tendencia interesante es que incluso las blockchains tradicionales están adoptando conceptos DAG para mejorar el rendimiento. Avalanche es un ejemplo principal de híbrido: se presenta como una plataforma blockchain, pero en su núcleo usa un consenso DAG. Ha ganado adopción significativa en DeFi y NFT, demostrando que los usuarios a veces adoptan un sistema DAG sin siquiera notarlo, siempre que satisfaga sus necesidades (rapidez y bajo coste). Esta tendencia puede continuar: DAG como motor interno exponiendo una interfaz blockchain familiar podría ser una estrategia ganadora, facilitando a los desarrolladores la transición. Fantom hizo esto con su Opera Chain, y otros proyectos podrían seguir el mismo camino, convirtiendo la tecnología DAG en el motor invisible de las cadenas de próxima generación.
  • Adopción empresarial y de nicho: Las empresas que requieren alto rendimiento, costes predecibles y que se sienten cómodas con redes más permisionadas se han inclinado a explorar ledgers DAG. El modelo de Consejo de Hedera atrajo a grandes compañías; estas impulsan casos de uso como tokenización de activos para servicios financieros o seguimiento de licencias de software en Hedera. También vemos consorcios considerar DLT basadas en DAG para liquidaciones en telecomunicaciones, seguimiento de impresiones publicitarias o transferencias interbancarias, donde el volumen es alto y necesitan finalidad. IOTA ha participado en proyectos financiados por la Unión Europea para infraestructura, pilotos de identidad digital e IoT industrial: son caminos de adopción a largo plazo, pero demuestran que los DAG están en el radar más allá de la comunidad cripto. Si algunas de estas pruebas tienen éxito y escalan, podríamos ver adopciones sectoriales de redes DAG (p. ej., un consorcio IoT usando un ledger DAG para compartir y monetizar datos).
  • Progreso comunitario y descentralización: Las críticas tempranas a las redes DAG (coordinadores centrales, validadores permisionados) se están abordando gradualmente. Coordicide de IOTA, si tiene éxito, eliminará el coordinador central y transformará IOTA en una red completamente descentralizada con una forma de staking y validadores comunitarios. Hedera ha abierto su código y ha insinuado planes para descentralizar aún más la gobernanza a largo plazo (más allá del consejo inicial). La comunidad de Nano trabaja continuamente para distribuir el peso de los representantes (alentando a más usuarios a operar nodos o repartir sus delegaciones). Estos pasos son importantes para la credibilidad y confianza en las redes DAG, alineándolas más con la ética blockchain. Conforme aumente la descentralización, es probable que más usuarios y desarrolladores cripto-nativos estén dispuestos a construir sobre o contribuir a proyectos DAG, acelerando su crecimiento.
  • Interoperabilidad y uso como capa 2: También podríamos ver a los DAG usarse como capas de escalado o redes interoperables en lugar de ecosistemas independientes. Por ejemplo, un ledger DAG podría servir como capa 2 de alta velocidad para Ethereum, anclando periódicamente resultados agregados en Ethereum para seguridad. Alternativamente, redes DAG podrían conectarse mediante puentes a blockchains existentes, permitiendo mover activos hacia donde sea más barato transaccionar. Si la experiencia de usuario es fluida, los usuarios podrían operar en una red DAG (disfrutando de alta velocidad) mientras confían en una blockchain base para la liquidación o seguridad, obteniendo lo mejor de ambos mundos. Algunos proyectos contemplan este enfoque por capas.
  • Perspectiva futura – complemento, no reemplazo (por ahora): Es revelador que incluso los defensores suelen decir que los DAG son una “alternativa” o complemento a las blockchains, más que un reemplazo total. En el futuro cercano podemos esperar redes heterogéneas: algunas basadas en blockchain, otras en DAG, cada una optimizada para distintos escenarios. Los DAG podrían alimentar la columna vertebral de alta frecuencia de Web3 (gestionando el trabajo pesado de microtransacciones y registro de datos), mientras que las blockchains podrían seguir siendo preferidas para la liquidación, transacciones de muy alto valor o donde la simplicidad y robustez sean críticas. A más largo plazo, si los sistemas DAG siguen demostrando su valía y logran igualar o superar la seguridad y descentralización, es concebible que se conviertan en el paradigma dominante de los ledgers distribuidos. El enfoque en eficiencia energética también alinea a los DAG con las presiones globales de sostenibilidad, lo que podría hacerlos más aceptables política y socialmente a largo plazo. Los beneficios de huella de carbono reducida, junto con las ventajas de rendimiento, podrían ser un impulsor clave si los entornos regulatorios enfatizan la tecnología verde.
  • Sentimiento comunitario: Existe un segmento de la comunidad cripto muy entusiasmado con los DAG, viéndolos como el siguiente paso evolutivo de la DLT. Es común oír frases como “los DAG son el futuro; las blockchains se verán como el internet por dial-up frente a la banda ancha de los DAG”. Este entusiasmo debe equilibrarse con resultados prácticos, pero sugiere que talento e inversiones están fluyendo hacia este ámbito. Por otro lado, persisten los escépticos, señalando que no debe sacrificarse la descentralización y seguridad por velocidad, por lo que los proyectos DAG deberán demostrar que pueden lograr lo mejor de ambos mundos.

En conclusión, el futuro de los DAG en blockchain es cautelosamente optimista. Actualmente las blockchains siguen dominando, pero las plataformas basadas en DAG se están abriendo espacio y demostrando su capacidad en dominios específicos. A medida que la investigación resuelva los desafíos actuales, probablemente veremos más convergencia de ideas: blockchains adoptando mejoras inspiradas en DAG y redes DAG asimilando las lecciones de las blockchains en gobernanza y seguridad. Los investigadores y desarrolladores Web3 harían bien en seguir de cerca los avances DAG, ya que representan una rama significativa de la evolución de los ledgers distribuidos. En los próximos años podríamos ver un ecosistema diverso de ledgers interoperables donde los DAG desempeñen un papel vital en la escalabilidad y aplicaciones especializadas, acercándonos a la visión de una web escalable y descentralizada.

En palabras de una publicación de Hedera: los ledgers basados en DAG son “un paso prometedor” en la evolución de las monedas digitales y la tecnología descentralizada: no una bala de plata para reemplazar completamente a las blockchains, sino una innovación importante que trabajará junto a ellas e inspirará mejoras en todo el panorama de los ledgers distribuidos.

Fuentes: La información de este informe proviene de diversas fuentes confiables, como investigaciones académicas sobre consenso DAG, documentación oficial y whitepapers de proyectos como IOTA, Hedera Hashgraph, Fantom y Nano, además de blogs técnicos y artículos que aportan perspectivas sobre las diferencias DAG vs blockchain. Estas referencias respaldan el análisis comparativo, los beneficios y los estudios de caso discutidos. El diálogo constante en la comunidad de investigación Web3 sugiere que los DAG seguirán siendo un tema candente mientras buscamos resolver la trinidad de escalabilidad, seguridad y descentralización en la próxima generación de tecnología blockchain.

Análisis Profundo de la Blockchain de Capa 1 Somnia: 1M de TPS y Finalidad en Menos de un Segundo

· 80 min de lectura
Dora Noda
Software Engineer

Somnia es una blockchain de Capa 1 compatible con EVM construida para un rendimiento extremo, capaz de procesar más de 1.000.000 de transacciones por segundo (TPS) con una finalidad en menos de un segundo. Para lograr esto, Somnia reimagina el diseño central de la blockchain con cuatro innovaciones técnicas clave:

  • Consenso MultiStream: El consenso de Somnia es un novedoso protocolo BFT de prueba de participación donde cada validador mantiene su propia "cadena de datos" de transacciones, produciendo bloques de forma independiente. Una cadena de consenso separada confirma periódicamente el último bloque de la cadena de datos de cada validador y los ordena en una única blockchain global. Esto permite la ingesta de transacciones en paralelo: múltiples validadores pueden propagar transacciones simultáneamente en sus flujos de datos, que luego se fusionan en un único registro ordenado. La cadena de consenso (inspirada en la investigación de Autobahn BFT) garantiza la seguridad al evitar que cualquier validador bifurque o altere su propio flujo una vez que el bloque global está finalizado. La Figura 1 ilustra esta arquitectura, donde las cadenas específicas de los validadores alimentan un bloque de consenso global.

  • Ejecución Secuencial Acelerada: En lugar de depender de la ejecución multi-hilo, Somnia opta por hacer que un solo núcleo sea extremadamente rápido. El cliente de Somnia compila los contratos inteligentes de EVM a código máquina x86 nativo (justo a tiempo o antes de tiempo). Los contratos de uso frecuente se traducen en instrucciones de máquina optimizadas, eliminando la sobrecarga de interpretación típica y logrando una velocidad casi nativa de C++ para la ejecución. En las pruebas de rendimiento, esto produce cientos de nanosegundos por transferencia ERC-20, soportando millones de TX/seg en un solo núcleo. Los contratos menos llamados aún pueden ejecutarse en el intérprete estándar de EVM, equilibrando el costo de compilación. Además, Somnia aprovecha la ejecución fuera de orden y el pipelining de las CPU modernas ("paralelismo a nivel de hardware") para acelerar las transacciones individuales. Al compilar a código nativo, la CPU puede ejecutar instrucciones en paralelo a nivel de chip (por ejemplo, superponiendo búsquedas de memoria y cálculos), acelerando aún más la lógica secuencial como las transferencias de tokens. Esta elección de diseño reconoce que el paralelismo de software a menudo falla bajo picos de carga altamente correlacionados (por ejemplo, una acuñación de NFT muy popular donde todas las transacciones afectan al mismo contrato). Las optimizaciones de un solo hilo de Somnia aseguran que incluso los escenarios de contratos "calientes" alcancen un alto rendimiento donde la ejecución paralela ingenua se detendría.
  • IceDB (Motor de Almacenamiento Determinista): Somnia incluye una base de datos de blockchain personalizada llamada IceDB para maximizar el rendimiento y la previsibilidad del acceso al estado. A diferencia de los backends típicos de LevelDB/RocksDB, IceDB proporciona costos de lectura/escritura deterministas: cada operación devuelve un "informe de rendimiento" de exactamente cuántas líneas de caché de RAM y páginas de disco se accedieron. Esto permite a Somnia cobrar tarifas de gas basadas en el uso real de recursos de una manera consistente y determinista para el consenso. Por ejemplo, las lecturas servidas desde la memoria pueden costar menos gas que las lecturas frías que acceden al disco, sin no determinismo. IceDB también utiliza una capa de caché mejorada optimizada tanto para lectura como para escritura, lo que produce una latencia extremadamente baja (15–100 nanosegundos por operación en promedio). Además, IceDB cuenta con snapshotting de estado incorporado: explota la estructura interna del almacenamiento estructurado en log para mantener y actualizar los hashes de estado global de manera eficiente, en lugar de construir un árbol de Merkle separado a nivel de aplicación. Esto reduce la sobrecarga para calcular las raíces de estado y las pruebas. En general, el diseño de IceDB garantiza un acceso al estado predecible y de alta velocidad y una medición justa del gas, que son críticos a la escala de Somnia.
  • Compresión y Red Avanzadas: Impulsar millones de TPS significa que los nodos deben intercambiar enormes volúmenes de datos de transacciones (por ejemplo, 1M de transferencias ERC-20/seg ~ 1.5 Gbps de datos brutos). Somnia aborda esto mediante optimizaciones de compresión y red:
    • Compresión por Flujo: Debido a que cada validador publica un flujo de datos continuo, Somnia puede usar compresión de flujo con estado a través de los bloques. Los patrones comunes (como direcciones repetitivas, llamadas a contratos, parámetros) se comprimen haciendo referencia a ocurrencias previas en el flujo, logrando tasas mucho mejores que la compresión de bloques independientes. Esto aprovecha la distribución de ley de potencias de la actividad de la blockchain: un pequeño subconjunto de direcciones o llamadas representa una gran fracción de las transacciones, por lo que codificarlas con símbolos cortos produce una compresión masiva (por ejemplo, una dirección utilizada en el 10 % de las TX puede codificarse en ~3 bits en lugar de 20 bytes). Las cadenas tradicionales no pueden usar fácilmente la compresión de flujo porque los productores de bloques rotan; los flujos fijos por validador de Somnia desbloquean esta capacidad.
    • Agregación de Firmas BLS: Para eliminar las partes incompresibles más grandes de las transacciones (firmas y hashes), Somnia utiliza firmas BLS para las transacciones y admite la agregación de muchas firmas en una sola. Esto significa que un bloque de cientos de transacciones puede llevar una única firma combinada, reduciendo drásticamente el tamaño de los datos (y el costo de verificación) en comparación con tener 64 bytes de firma ECDSA por transacción. Los hashes de las transacciones tampoco se transmiten (los pares los recalculan según sea necesario). Juntas, la compresión y la agregación BLS reducen los requisitos de ancho de banda lo suficiente como para sostener el alto rendimiento de Somnia sin "ahogar" la red.
    • Simetría de Ancho de Banda: En el diseño de múltiples líderes de Somnia, cada validador comparte continuamente su fracción de nuevos datos en cada bloque, en lugar de que un solo líder envíe el bloque completo a los demás. En consecuencia, la carga de la red se distribuye simétricamente: cada uno de los N validadores sube aproximadamente 1/N del total de datos a N-1 pares (y descarga las otras porciones) en cada bloque, en lugar de que un solo líder suba N-1 copias. Ningún nodo necesita un ancho de banda de salida mayor que el rendimiento general de la cadena, evitando el cuello de botella donde un solo líder debe tener una enorme capacidad de subida. Esta utilización uniforme permite a Somnia acercarse a los límites físicos de ancho de banda de los nodos sin centralizarse en unos pocos supernodos. En resumen, la pila de red de Somnia está diseñada para que todos los validadores compartan el trabajo de propagar transacciones, permitiendo un rendimiento cercano al nivel de gigabit en toda la red descentralizada.

Consenso y Seguridad: La cadena de consenso utiliza un protocolo de prueba de participación PBFT modificado (Tolerancia a Fallas Bizantinas Práctica) con una suposición parcialmente síncrona. Somnia se lanzó con 60–100 validadores distribuidos globalmente (la red principal comenzó con ~60 y apunta a 100). Se requiere que los validadores ejecuten hardware potente (especificaciones aproximadamente entre un nodo de Solana y Aptos en rendimiento) para manejar la carga. Este número de validadores equilibra el rendimiento con una descentralización suficiente: la filosofía del equipo es la "descentralización suficiente" (suficiente para garantizar la seguridad y la resistencia a la censura, pero no tan extrema como para paralizar el rendimiento). Notablemente, Google Cloud participó como validador en el lanzamiento, junto con otros operadores de nodos profesionales.

Somnia implementa medidas de seguridad estándar de PoS como depósitos de staking y slashing por comportamiento malicioso. Para reforzar la seguridad en su novedoso motor de ejecución, Somnia utiliza un sistema único llamado "Cuthbert": una implementación de referencia alternativa (no optimizada) que se ejecuta en paralelo con el cliente principal en cada nodo. Cada transacción se ejecuta en ambos motores; si se detecta una divergencia o un error en los resultados del cliente optimizado, el validador se detendrá y se negará a finalizar, evitando errores de consenso. Esta ejecución dual actúa como una auditoría en tiempo real, asegurando que las optimizaciones de rendimiento agresivas nunca produzcan transiciones de estado incorrectas. Con el tiempo, a medida que crece la confianza en el cliente principal, Cuthbert puede ser eliminado, pero durante las primeras etapas añade una capa extra de seguridad.

En resumen, la arquitectura de Somnia está diseñada para aplicaciones en tiempo real con usuarios masivos. Al desacoplar la propagación de transacciones de la finalización (MultiStream), sobrealimentar la ejecución de un solo núcleo (compilación de EVM y paralelismo a nivel de CPU), optimizar la capa de datos (IceDB) y minimizar el ancho de banda por transacción (compresión + agregación), Somnia logra un rendimiento órdenes de magnitud más allá de las L1 tradicionales. El CEO de Improbable, Herman Narula, afirma que es "la capa uno más avanzada... capaz de manejar miles de veces el rendimiento de Ethereum o Solana", construida específicamente para la velocidad, escala y capacidad de respuesta necesarias para los juegos de próxima generación, redes sociales y experiencias inmersivas del metaverso.

Tokenomics – Suministro, Utilidad y Diseño Económico

Suministro y Distribución: El token nativo de Somnia, SOMI, tiene un suministro máximo fijo de 1.000.000.000 de tokens (1 mil millones). No hay inflación continua: el suministro está limitado y los tokens se asignaron por adelantado a varias partes interesadas con calendarios de adjudicación (vesting). El desglose de la asignación es el siguiente:

Categoría de AsignaciónPorcentajeCantidad de TokensCalendario de Liberación
Equipo11.0 %110.000.0000 % en el lanzamiento; acantilado de 12 meses, luego adjudicación durante 48 meses.
Socios de Lanzamiento15.0 %150.000.0000 % en el lanzamiento; acantilado de 12 meses, luego adjudicación durante 48 meses (incluye contribuyentes tempranos del ecosistema como Improbable).
Inversores (Semilla)15.15 %151.500.0000 % en el lanzamiento; acantilado de 12 meses, luego adjudicación durante 36 meses.
Asesores3.58 %35.800.0000 % en el lanzamiento; acantilado de 12 meses, luego adjudicación durante 36 meses.
Fondo del Ecosistema27.345 %273.450.0005.075 % desbloqueado en el lanzamiento, el resto se adjudica linealmente durante 48 meses. Usado para financiar el desarrollo del ecosistema y la Fundación Somnia.
Comunidad y Recompensas27.925 %279.250.00010.945 % desbloqueado en el lanzamiento, más liberaciones adicionales a 1 y 2 meses post-lanzamiento, luego adjudicación lineal durante 36 meses. Usado para incentivos comunitarios, airdrops, liquidez y recompensas de staking para validadores.
Total100 %1.000.000.000~16 % en circulación en el TGE (Evento de Generación de Tokens), el resto adjudicado durante 3–4 años.

En el lanzamiento de la red principal (TGE en el tercer trimestre de 2025), alrededor del 16 % del suministro entró en circulación (principalmente de los desbloqueos iniciales de las asignaciones de Comunidad y Ecosistema). La mayoría de los tokens (equipo, socios, inversores) están bloqueados durante el primer año y luego se liberan gradualmente, alineando los incentivos para el desarrollo a largo plazo. Este vesting estructurado ayuda a prevenir grandes ventas inmediatas y asegura que la fundación y los contribuyentes principales tengan recursos a lo largo del tiempo para hacer crecer la red.

Utilidad del Token: SOMI es central para el ecosistema de Somnia y sigue un modelo de Prueba de Participación Delegada (DPoS). Sus usos principales incluyen:

  • Staking y Seguridad: Los validadores deben hacer staking de 5.000.000 de SOMI cada uno para operar un nodo y participar en el consenso. Esta participación significativa (~0.5 % del suministro total por validador) proporciona seguridad económica; los actores maliciosos corren el riesgo de perder su fianza. Somnia apunta inicialmente a 100 validadores, lo que significa que hasta 500 millones de SOMI podrían estar en staking para la operación de nodos (parte de lo cual puede provenir de la delegación, ver más abajo). Además, los delegadores (cualquier poseedor de tokens) pueden hacer staking de SOMI delegando a los validadores para ayudarles a cumplir el requisito de 5M. Los delegadores ganan una parte de las recompensas a cambio. Esto abre los rendimientos del staking a los no validadores y ayuda a descentralizar la participación entre muchos poseedores de tokens. Solo los tokens en staking (ya sea por validadores o mediante delegación) son elegibles para recompensas de la red: simplemente mantener tokens sin hacer staking no genera recompensas.
  • Tarifas de Gas: Todas las transacciones en la cadena y las ejecuciones de contratos inteligentes requieren SOMI para las tarifas de gas. Esto significa que cada interacción (transferencias, acuñaciones, uso de DApps) crea demanda para el token. El modelo de gas de Somnia se basa en el de Ethereum (mismas definiciones de unidades) pero con ajustes y costos base mucho más bajos. Como se detalla más adelante, Somnia tiene tarifas de sub-céntimo e incluso descuentos dinámicos para DApps de alto volumen, pero las tarifas todavía se pagan en SOMI. Por lo tanto, si la red ve un uso intensivo (por ejemplo, un juego popular o una aplicación social), los usuarios y desarrolladores necesitarán SOMI para alimentar sus transacciones, impulsando la utilidad.
  • Recompensas para Validadores/Delegadores: Las recompensas de bloque en Somnia provienen de las tarifas de transacción y de una tesorería comunitaria, no de la inflación. Específicamente, el 50 % de todas las tarifas de gas se distribuye a los validadores (y sus delegadores) como recompensas. El otro 50 % de las tarifas se quema (se elimina de la circulación) como un mecanismo deflacionario. Esta división de tarifas (mitad para los validadores, mitad quemada) se asemeja al modelo EIP-1559 de Ethereum, excepto que es una división fija de 50/50 en el diseño actual de Somnia. En la práctica, las ganancias de los validadores se derivarán del volumen de tarifas de la red: a medida que el uso crece, las recompensas por tarifas crecen. Para impulsar la seguridad antes de que las tarifas sean significativas, Somnia también tiene incentivos de tesorería para los validadores. La asignación de la Comunidad incluye tokens destinados a recompensas de staking y liquidez; la fundación puede distribuirlos según sea necesario (probablemente como suplementos de rendimiento de staking en los primeros años). Es importante destacar que solo los tokens en staking ganan recompensas, lo que fomenta la participación activa y bloquea el suministro. Los delegadores comparten las recompensas de las tarifas de su validador elegido proporcionalmente a su participación, menos la comisión del validador (cada validador establece una "tasa de delegación", por ejemplo, si se establece en 80 %, entonces el 80 % de las recompensas de ese validador se comparte con los delegados). Somnia ofrece dos opciones de delegación: delegar a un pool de un validador específico (sujeto a un período de desvinculación de 28 días, o un desestakeo de emergencia inmediato con una penalización severa del 50 %), o delegar a un pool general que se distribuye automáticamente entre todos los validadores con poca participación (sin período de bloqueo, pero probablemente un rendimiento combinado más bajo). Este diseño flexible de DPoS incentiva a los poseedores de tokens a asegurar la red a cambio de recompensas, al tiempo que proporciona una salida fácil (pool general) para aquellos que desean liquidez.
  • Gobernanza: A medida que Somnia madure, SOMI gobernará las decisiones de la red. Los poseedores de tokens eventualmente votarán sobre propuestas que afecten las actualizaciones del protocolo, el uso de los fondos de la tesorería, los parámetros económicos, etc. El proyecto prevé una gobernanza multifacética (ver "Gobernanza de Tokens" más abajo) donde los poseedores de SOMI (la "Casa del Token") controlan principalmente las asignaciones de los fondos de la fundación y la comunidad, mientras que los validadores, desarrolladores y usuarios tienen consejos para decisiones técnicas y de políticas. En la red principal temprana, la gobernanza es manejada principalmente por la Fundación Somnia (para agilidad y seguridad), pero durante 1–2 años se descentralizará progresivamente hacia la comunidad de tokens y los consejos. Por lo tanto, poseer SOMI conferirá influencia sobre la dirección del ecosistema, convirtiéndolo en un token de gobernanza además de un token de utilidad.

Mecánicas Deflacionarias: Debido a que el suministro es fijo, Somnia depende de la quema de tarifas para introducir presión deflacionaria. Como se señaló, el 50 % de cada tarifa de gas se quema permanentemente. Esto significa que si el uso de la red es alto, el suministro circulante de SOMI disminuirá con el tiempo, aumentando potencialmente la escasez del token. Por ejemplo, si se generan 1 millón de SOMI en tarifas en un mes, 500k SOMI serían destruidos. Este mecanismo de quema puede compensar los desbloqueos de tokens o las ventas, y alinea el valor del token a largo plazo con el uso de la red (más actividad -> más quema). Además, Somnia actualmente no admite propinas especificadas por el usuario (tarifas de prioridad) en el lanzamiento; el modelo de tarifa base es lo suficientemente eficiente dado el alto rendimiento, aunque pueden introducir propinas más tarde si surge congestión. Con tarifas ultra bajas, la quema por transacción es pequeña, pero a escala (miles de millones de transacciones), se acumula. El modelo económico de Somnia, por lo tanto, combina cero inflación, desbloqueos programados y quema de tarifas, apuntando a la sostenibilidad a largo plazo. Si la red alcanza un volumen masivo, SOMI podría volverse deflacionario, beneficiando a los stakers y poseedores a medida que el suministro disminuye.

Aspectos Destacados del Modelo de Gas: El precio del gas de Somnia es generalmente mucho más barato que el de Ethereum, pero con algunos giros novedosos para la equidad y la escalabilidad. La mayoría de los costos de los opcodes se ajustan a la baja (ya que el rendimiento y la eficiencia de Somnia son mayores), pero los costos de almacenamiento se recalibraron al alza por unidad (para evitar abusos dado el bajo costo por gas). Dos características especialmente notables planeadas para 2025 son:

  • Descuentos por Volumen Dinámicos: Somnia introduce un descuento escalonado en el precio del gas para cuentas o aplicaciones que mantienen un alto uso de TPS. En efecto, cuantas más transacciones ejecute una aplicación o usuario por hora, menor será el precio efectivo del gas que pagan (hasta un 90 % de descuento a ~400 TPS). Este precio basado en el volumen tiene como objetivo incentivar a las DApps a gran escala a ejecutarse en Somnia reduciendo drásticamente sus costos a escala. Se implementa como un precio de gas que disminuye por pasos una vez que se superan ciertos umbrales de TPS por cuenta (0.1, 1, 10, 100, 400 TPS, etc.). Este modelo (que se espera que se implemente después del lanzamiento de la red principal) recompensa a los proyectos que traen una carga pesada, asegurando que Somnia siga siendo asequible incluso cuando alimenta juegos en tiempo real o feeds sociales con cientos de transacciones por segundo. Es un mecanismo inusual (la mayoría de las cadenas tienen un mercado de tarifas planas), lo que indica la priorización de Somnia de los casos de uso de rendimiento masivo.
  • Almacenamiento Transitorio: Somnia planea ofrecer opciones de almacenamiento con límite de tiempo donde un desarrollador puede optar por almacenar datos en la cadena solo temporalmente (por horas o días) a un costo de gas mucho menor que el almacenamiento permanente. Por ejemplo, una variable en la cadena que solo necesita persistir durante una hora (como el estado de un lobby de juego o la posición efímera de un jugador) puede almacenarse con ~90 % menos de gas que una escritura permanente normal. El programa de gas para un SSTORE de 32 bytes podría ser de 20k de gas para una retención de 1 hora frente a 200k para una retención indefinida. Este concepto de "estado transitorio" está explícitamente dirigido a aplicaciones de juegos y entretenimiento que generan una gran cantidad de datos temporales (tablas de clasificación, estado del juego) que no necesitan vivir para siempre en la cadena. Al proporcionar un almacenamiento basado en la expiración con descuentos, Somnia puede soportar tales aplicaciones en tiempo real de manera más eficiente. La implementación probablemente implica descartar automáticamente el estado después de la duración elegida (o moverlo a un almacén separado), aunque los detalles están por implementarse. Esta característica, combinada con la compresión de Somnia, está orientada a juegos en la cadena que gestionan grandes volúmenes de actualizaciones de estado sin inflar la cadena o incurrir en costos enormes.

En general, la tokenomics de Somnia se alinea con su objetivo de potenciar la Web3 a escala Web2. Un gran fondo inicial de tokens financió el desarrollo y el crecimiento del ecosistema (con patrocinadores de renombre y largos bloqueos que señalan compromiso), mientras que el diseño económico continuo utiliza recompensas impulsadas por el mercado (a través de tarifas) y la deflación para mantener el valor. Se incentiva a los poseedores de SOMI a hacer staking y participar, ya que todos los beneficios de la red (ingresos por tarifas, poder de gobernanza) se acumulan para los stakers activos. Con un suministro limitado y una quema proporcional al uso, el valor de SOMI está estrechamente ligado al éxito de la red: a medida que más usuarios y aplicaciones se unen, la demanda de tokens (para gas y staking) aumenta y el suministro disminuye por las quemas, creando un bucle de retroalimentación que apoya la sostenibilidad a largo plazo del token.

Ecosistema y Asociaciones

A pesar de lanzar su red principal a finales de 2025, Somnia entró en escena con un ecosistema robusto de proyectos y socios estratégicos gracias a una extensa fase de red de prueba y el apoyo de pesos pesados de la industria.

dApps y Protocolos del Ecosistema: Para el lanzamiento de la red principal, más de 70 proyectos y dApps ya estaban construyendo o integrándose con Somnia. El ecosistema inicial se inclina fuertemente hacia aplicaciones de juegos y sociales, reflejando el mercado objetivo de Somnia de aplicaciones inmersivas y en tiempo real. Proyectos notables incluyen:

  • Sparkball: Un juego Web3 insignia en Somnia, Sparkball es un MOBA/brawler deportivo 4v4 de ritmo rápido desarrollado por Opti Games. Se unió a Somnia como título de lanzamiento, introduciendo jugabilidad en la cadena y activos de equipo basados en NFT. Sparkball demuestra la capacidad de Somnia para manejar emparejamientos rápidos y transacciones dentro del juego (por ejemplo, acuñar/intercambiar jugadores o artículos) con una latencia insignificante.
  • Variance: Un RPG roguelite con temática de anime, una historia rica y sin mecánicas de pago para ganar. Los desarrolladores de Variance (veteranos de Pokémon GO y Axie Infinity) eligieron Somnia por su capacidad para manejar economías de juego a gran escala y transacciones de forma económica. Después de conversaciones con el fundador de Somnia, el equipo se convenció de que Somnia entendía las necesidades de los desarrolladores de juegos y la visión para los juegos Web3. Variance trasladó su token en el juego ($VOID) y la lógica de NFT a Somnia, permitiendo características como botines en la cadena y activos propiedad del jugador a escala. La comunidad del juego creció significativamente después de anunciar el cambio a Somnia. Variance realizó pruebas de juego y misiones comunitarias en la red de prueba de Somnia, demostrando combate multijugador en la cadena y recompensando a los jugadores con NFTs y tokens.
  • Maelstrom Rise: Un juego de batalla naval (piensa en Fortnite en el mar) de Uprising Labs. Maelstrom presenta combate de barcos en tiempo real y una economía integrada en la cadena para mejoras y coleccionables. Ya disponible fuera de la cadena (en Steam), Maelstrom está transicionando a Somnia para dar a los jugadores la verdadera propiedad de los buques de guerra y los artículos. Es uno de los juegos Web3 más accesibles, con el objetivo de incorporar a los jugadores tradicionales mezclando una jugabilidad familiar con las ventajas de la blockchain.
  • Dark Table CCG: Un juego de cartas coleccionables en la cadena que admite hasta 4 jugadores por partida. Ofrece construcción de mazos gratuita, con todas las cartas como NFTs que los jugadores poseen e intercambian libremente. Dark Table aprovecha Somnia para ejecutar una economía de cartas multiplataforma sin servidores centrales, permitiendo a los jugadores ser verdaderamente dueños de sus mazos. Está diseñado para ser de fácil entrada (no se necesita comprar cripto para empezar) para atraer tanto a jugadores de cartas casuales como competitivos a la Web3.
  • Netherak Demons: Un RPG de acción de fantasía oscura respaldado por el acelerador Dream Catalyst de Somnia. Los jugadores personalizan personajes demoníacos y participan en batallas PvE y PvP en tiempo real, con una colección de NFT que se vincula con el progreso del juego. Netherak utiliza la tecnología de Somnia para permitir la progresión persistente de los personajes en la cadena: los logros y el botín de los jugadores se registran como activos que controlan, añadiendo un valor significativo a la jugabilidad.
  • Masks of the Void: Un juego de acción y aventura roguelite con niveles generados proceduralmente, también apoyado por Uprising Labs. Planeó una prueba de juego cerrada donde acuñar un NFT gratuito otorga acceso temprano, mostrando cómo Somnia puede integrar el acceso restringido por NFT para el contenido del juego. Masks of the Void enfatiza la rejugabilidad y la progresión mejorada por blockchain (por ejemplo, recompensas de metajuego que persisten de una partida a otra como NFTs).

Estos son solo algunos ejemplos. El ecosistema de juegos de Somnia abarca muchos géneros, desde shooters navales hasta batallas de cartas y RPGs, lo que indica el amplio atractivo de la plataforma para los desarrolladores. Todos estos juegos aprovechan las características en la cadena (propiedad de artículos, tokens para recompensas, personajes NFT, etc.) que requieren una cadena de alto rendimiento para ser disfrutables por los jugadores. Los primeros resultados son prometedores: por ejemplo, la red de prueba de Somnia ejecutó una demostración de MMO sandbox completamente en la cadena llamada "Chunked" (construida por Improbable) donde miles de jugadores interactuaron en tiempo real, generando 250 millones de transacciones en 5 días, una carga récord que validó las capacidades de Somnia.

Más allá de los juegos, el ecosistema inicial de Somnia incluye otros dominios de Web3:

  • Social y Metaverso: Somnia está destinada a potenciar redes sociales descentralizadas y mundos virtuales, aunque las aplicaciones específicas son tempranas. Sin embargo, hay indicios de plataformas sociales. Por ejemplo, Somnia se asoció con Yuga Labs para integrar NFTs de Otherside (del metaverso de Bored Ape Yacht Club) en el mundo de Somnia, permitiendo que esos activos se usen en experiencias inmersivas. Eventos impulsados por la comunidad como los "gamevents" Edison de BoredElon Musk se realizaron con tecnología de Improbable en 2023, y Somnia está preparada para llevar tales eventos metaversales completamente a la cadena en el futuro. También hay una aplicación Somnia Metaverse Browser, esencialmente un navegador/billetera Web3 personalizado orientado a la interacción en mundos virtuales, facilitando a los usuarios el acceso a DApps y experiencias de metaverso en una sola interfaz. A medida que la red madure, se espera que se lancen dApps sociales (análogos descentralizados de Twitter/Reddit, centros comunitarios) y plataformas de metaverso en Somnia, aprovechando sus características de portabilidad de identidad (Somnia admite nativamente los estándares abiertos de MSquared para la interoperabilidad de avatares y activos entre mundos).
  • DeFi y Otros: En su lanzamiento, Somnia no estaba principalmente enfocada en DeFi, pero hay alguna infraestructura en su lugar. Hay integraciones con oráculos de precios como DIA (para feeds de precios en la cadena) y Chainlink VRF a través de adaptadores de Protofire (para aleatoriedad en los juegos). Se discutieron algunos casos de uso de estilo DeFi, como intercambios de libros de órdenes completamente en la cadena (la baja latencia de Somnia podría permitir la coincidencia de órdenes en la cadena de manera similar a un intercambio centralizado). Podemos esperar que aparezca un AMM o DEX (la documentación incluso incluye una guía para construir un DEX en Somnia), y quizás protocolos novedosos que mezclen juegos y finanzas (por ejemplo, préstamos de NFT o mercados de activos de juegos tokenizados). La presencia de proveedores de custodia BitGo y Fireblocks como socios también indica una mirada hacia el soporte de casos de uso institucionales y financieros (hacen que la tenencia de tokens sea segura para intercambios y fondos). Además, la tecnología de Somnia puede soportar IA y aplicaciones con gran cantidad de datos (el programa Dreamthon llama explícitamente a proyectos de IA e InfoFi), por lo que podríamos ver innovaciones como agentes de IA descentralizados o mercados de datos en la cadena.

Asociaciones Estratégicas: Somnia está respaldada por una impresionante lista de socios y patrocinadores:

  • Improbable y MSquared: Improbable, una empresa líder en tecnología de metaverso, es el principal socio de desarrollo de Somnia. De hecho, Improbable construyó la blockchain de Somnia bajo contrato para la Fundación Somnia, aportando su década de experiencia en sistemas distribuidos. MSquared (M²), una iniciativa de red de metaverso respaldada por Improbable, también está estrechamente involucrada. Juntos, Improbable y MSquared comprometieron hasta 270 millones de dólares para apoyar el desarrollo y el ecosistema de Somnia. Este enorme fondo de inversión (anunciado a principios de 2025) provino en parte de la recaudación de 150 millones de dólares de M² en 2022 (que incluyó a Andreessen Horowitz, SoftBank Vision Fund 2, Mirana y otros como inversores) y 120 millones de dólares de la asignación de riesgo de Improbable. La financiación apoya subvenciones, marketing e incorporación de proyectos. La participación de Improbable también trae integraciones técnicas: Somnia está diseñada para funcionar con la tecnología Morpheus de Improbable para eventos virtuales masivos. En 2023, Improbable impulsó experiencias virtuales como el Virtual Ballpark de la MLB y conciertos de K-pop con decenas de miles de usuarios concurrentes; esos usuarios pronto podrían ser incorporados a Somnia para que las interacciones en los eventos generen activos o tokens en la cadena. Improbable y MSquared esencialmente aseguran que Somnia tenga tanto la pista financiera como los casos de uso reales (eventos de metaverso, juegos) para impulsar la adopción.
  • Infraestructura y Servicios Web3: Somnia se integró con muchos de los principales proveedores de servicios de blockchain desde el primer día:
    • OpenSea: El mercado de NFT más grande del mundo está integrado con Somnia, lo que significa que los NFTs basados en Somnia pueden ser intercambiados en OpenSea. Esta es una gran victoria para los desarrolladores de juegos en Somnia: sus NFTs en el juego (personajes, skins, etc.) tienen liquidez y visibilidad inmediatas en un mercado popular.
    • LayerZero: Somnia está conectada a otras cadenas a través del protocolo Stargate de LayerZero, permitiendo transferencias de activos omnichain y puentes. Por ejemplo, los usuarios pueden puentear USDC u otras stablecoins desde Ethereum a Somnia fácilmente a través de Stargate. Esta interoperabilidad es crucial para incorporar liquidez al ecosistema de Somnia.
    • Ankr: Ankr proporciona nodos RPC e infraestructura de nodos global. Es probable que se utilice para ofrecer endpoints RPC públicos, alojamiento de nodos y servicios de API para Somnia, facilitando a los desarrolladores el acceso a la red sin ejecutar sus propios nodos completos.
    • Sequence (Horizon): Sequence es una billetera de contrato inteligente y una plataforma de desarrollo adaptada para juegos (por Horizon). La integración con Sequence sugiere que Somnia puede aprovechar las características de billetera inteligente (por ejemplo, abstracciones de gas, inicio de sesión con correo electrónico/redes sociales) para incorporar a usuarios convencionales. La billetera multi-cadena de Sequence probablemente añadió soporte para Somnia, para que los jugadores puedan firmar transacciones con una interfaz fácil de usar.
    • Thirdweb: Los SDKs y herramientas Web3 de Thirdweb son totalmente compatibles con Somnia. Thirdweb proporciona módulos plug-and-play para lanzamientos de NFT, mercados, tokens y especialmente Abstracción de Cuentas. De hecho, la documentación de Somnia tiene guías sobre transacciones sin gas y abstracción de cuentas a través de Thirdweb. Esta asociación significa que los desarrolladores en Somnia pueden construir DApps rápidamente usando las bibliotecas de Thirdweb y los usuarios pueden beneficiarse de características como la incorporación sin billetera con un solo clic (tarifas de gas patrocinadas por la DApp, etc.).
    • DIA y Oráculos: DIA es un proveedor de oráculos descentralizado; Somnia utiliza los feeds de precios de DIA para datos de DeFi o de la economía del juego. Además, Somnia trabajó con Protofire para adaptar Chainlink VRF (función de aleatoriedad verificable) para la generación de números aleatorios en los contratos inteligentes de Somnia. Esto asegura que los juegos puedan obtener aleatoriedad segura (para botines, etc.). Podemos esperar más integraciones de oráculos (quizás feeds de precios completos de Chainlink en el futuro) según lo necesiten los proyectos de DeFi.
  • Socios de Nube y Empresariales: Google Cloud no solo invirtió, sino que también opera un validador, proporcionando credibilidad y experiencia en infraestructura en la nube. Tener a la división de nube de un gigante tecnológico validando activamente la red ayuda con la fiabilidad y abre puertas a colaboraciones empresariales (por ejemplo, Google Cloud podría ofrecer servicios de nodos de blockchain para Somnia o incluir a Somnia en su mercado). También hubo asociaciones con Fireblocks y BitGo: estos son los principales proveedores de custodia de activos digitales y billeteras. Su participación significa que los intercambios e instituciones pueden custodiar de forma segura SOMI y activos basados en Somnia desde el primer día, allanando el camino para las listas de SOMI y la adopción institucional. De hecho, poco después de la red principal, Binance listó SOMI y lo presentó en una campaña promocional de airdrop, probablemente facilitado por dicha preparación de custodia.
  • Programas de Crecimiento del Ecosistema: La Fundación Somnia estableció un Programa de Subvenciones de 10 millones de dólares para financiar a los desarrolladores que construyen en Somnia. Este programa de subvenciones se lanzó junto con la red principal para incentivar el desarrollo de herramientas, DApps, investigación e iniciativas comunitarias. Complementándolo está Dream Catalyst, el acelerador de Somnia específicamente para startups de juegos Web3. Dream Catalyst (dirigido con Uprising Labs) proporciona financiación, créditos de infraestructura, mentoría y apoyo para la salida al mercado a los estudios de juegos que construyen en Somnia. Al menos media docena de juegos (como Netherak Demons y otros) formaron parte de la primera cohorte de Dream Catalyst, recibiendo porciones de ese fondo de 10 millones de dólares. También está Dreamthon, un próximo programa acelerador para otras verticales, centrado en proyectos de DeFi, IA, "InfoFi" (mercados de información) y SocialFi en el ecosistema de Somnia. Además, Somnia organizó hackathons y misiones en línea durante la red de prueba: por ejemplo, un evento Somnia Odyssey de 60 días recompensó a los usuarios por completar tareas y probablemente culminó en un airdrop. Los primeros usuarios podían ganar "puntos" y NFTs por probar dApps (un Programa de Puntos), y se planean mini-hackathons para involucrar continuamente a los desarrolladores. Este enfoque multifacético —subvenciones, aceleradores, hackathons, misiones comunitarias— muestra el fuerte compromiso de Somnia para construir un ecosistema vibrante rápidamente, reduciendo las barreras y financiando a los experimentadores.

En resumen, Somnia no se lanzó de forma aislada, sino respaldada por una poderosa alianza de empresas tecnológicas, inversores y proveedores de servicios. El apoyo de Improbable le proporciona tecnología de vanguardia y una cartera de eventos virtuales masivos. Las asociaciones con empresas como Google Cloud, Binance, LayerZero, OpenSea y otras aseguran que Somnia esté conectada a la infraestructura cripto más amplia desde el principio, mejorando su atractivo para los desarrolladores (que quieren herramientas fiables y liquidez) y para los usuarios (que demandan puentes fáciles y comercio de activos). Mientras tanto, una serie de juegos Web3 —Sparkball, Variance, Maelstrom y más— están construyendo activamente en Somnia, con el objetivo de ser la primera ola de entretenimiento completamente en la cadena que muestre las capacidades de la red. Con docenas de proyectos en vivo o en desarrollo, el ecosistema de Somnia en la red principal ya era más rico que algunas cadenas con años de lanzamiento. Es probable que este fuerte impulso crezca a medida que las subvenciones y las asociaciones continúen dando sus frutos, posicionando potencialmente a Somnia como un centro neurálgico para los juegos en la cadena y las aplicaciones de metaverso en los próximos años.

Infraestructura para Desarrolladores y Usuarios

Somnia fue construida para ser amigable para los desarrolladores y para incorporar a millones de usuarios que pueden no ser expertos en cripto. Como una cadena compatible con EVM, soporta el familiar conjunto de herramientas de Ethereum desde el principio, al tiempo que ofrece SDKs y servicios personalizados para mejorar la experiencia del desarrollador y la incorporación de usuarios.

Herramientas para Desarrolladores y Compatibilidad: Somnia mantiene compatibilidad total con la Ethereum Virtual Machine, lo que significa que los desarrolladores pueden escribir contratos inteligentes en Solidity o Vyper y desplegarlos con cambios mínimos. La red soporta interfaces RPC estándar de Ethereum y ID de cadena, por lo que herramientas como Hardhat, Truffle, Foundry, y bibliotecas como Web3.js o ethers.js funcionan sin problemas (la documentación de Somnia incluso proporciona guías específicas sobre cómo desplegar con Hardhat y Foundry). Esto reduce significativamente la curva de aprendizaje: cualquier desarrollador de Solidity puede convertirse en un desarrollador de Somnia sin aprender un nuevo lenguaje o VM.

Para acelerar el desarrollo y las pruebas, Somnia lanzó un entorno interactivo de Playground. El Playground permite a los equipos (especialmente a los de juegos/metaverso) prototipar lógica en la cadena de una manera de baja fricción, utilizando plantillas para NFTs, minijuegos, tokens sociales, etc. Es probable que proporcione una red de sandbox o un portal para desarrolladores para iteraciones rápidas. Además, la documentación de Somnia en GitBook es completa, cubriendo todo, desde el despliegue de contratos hasta el uso de características avanzadas (como las APIs de Ormi, ver más abajo).

SDKs y APIs de Somnia: Reconociendo que consultar datos en la cadena de manera eficiente es tan importante como escribir contratos, Somnia se asoció con Ormi Labs para proporcionar robustos servicios de indexación de datos y API. Ormi es esencialmente la respuesta de Somnia a The Graph: ofrece subgrafos y APIs GraphQL para indexar eventos y estado de contratos. Los desarrolladores pueden crear subgrafos personalizados para sus DApps (por ejemplo, para indexar todos los NFTs de artículos de juego o publicaciones sociales) a través de Ormi, y luego consultar esos datos fácilmente. Las APIs de Datos de Ormi entregan datos estructurados en la cadena con alta disponibilidad, por lo que las aplicaciones de front-end no necesitan ejecutar sus propios nodos de indexación. Esto simplifica significativamente la construcción de interfaces de usuario ricas en Somnia. Somnia ha realizado Codelabs y tutoriales que muestran cómo construir interfaces de usuario de dApps con los endpoints GraphQL de Ormi, lo que indica un fuerte apoyo a esta herramienta. En resumen, Somnia proporciona soporte de indexación de primera clase, lo cual es crucial para cosas como tablas de clasificación en juegos o feeds en aplicaciones sociales, datos que necesitan ser filtrados y recuperados rápidamente.

Además de Ormi, la página de infraestructura de Somnia enumera múltiples endpoints RPC públicos y servicios de explorador:

  • Endpoints RPC de proveedores como Ankr (para acceso público a la red).
  • Exploradores de Bloques: Parece que Somnia tenía un explorador de testnet ("Shannon") y presumiblemente un explorador de mainnet para rastrear transacciones y cuentas. Los exploradores son vitales para que los desarrolladores y usuarios depuren transacciones y verifiquen la actividad en la cadena.
  • Safes (Multifirma): La documentación menciona "Safes", probablemente una integración con Safe (anteriormente Gnosis Safe) para billeteras de firma múltiple. Esto significa que las DAOs o los estudios de juegos en Somnia pueden usar billeteras multifirma seguras para gestionar su tesorería o activos en el juego. La integración de Safe es otra pieza de infraestructura que hace que Somnia esté lista para empresas y DAOs.
  • Adaptadores de Billetera: Se admiten muchas billeteras Web3 populares. MetaMask puede conectarse a Somnia configurando el RPC de la red (la documentación guía a los usuarios para agregar la red de Somnia a MetaMask). Para una experiencia de usuario más fluida, Somnia trabajó con RainbowKit y ConnectKit (bibliotecas de React para conexiones de billetera), asegurando que los desarrolladores de DApps puedan permitir fácilmente a los usuarios conectarse con una variedad de billeteras. También hay una guía para usar Privy (una solución de billetera centrada en un inicio de sesión fácil de usar).
  • Abstracción de Cuentas: A través del SDK de Thirdweb, Somnia soporta características de abstracción de cuentas. Por ejemplo, la Smart Wallet o el SDK de Abstracción de Cuentas de Thirdweb se pueden usar en Somnia, permitiendo meta-transacciones (UX sin gas) o billeteras con inicio de sesión social. La documentación describe explícitamente las transacciones sin gas con Thirdweb, lo que significa que las DApps pueden pagar el gas en nombre de los usuarios, una capacidad crítica para la adopción masiva, ya que los usuarios finales podrían ni siquiera necesitar tener SOMI para jugar un juego inicialmente.

Incorporación de Usuarios y Participación Comunitaria: El equipo de Somnia ha sido proactivo en el crecimiento de una comunidad tanto de desarrolladores como de usuarios finales:

  • El Discord de Somnia es el centro neurálgico para los desarrolladores (con un chat de desarrollo dedicado y soporte del equipo central). Durante la testnet, los desarrolladores podían solicitar tokens de prueba (STT) a través de Discord para desplegar y probar sus contratos. Este canal de soporte directo ayudó a incorporar muchos proyectos.
  • Para los usuarios finales, Somnia organizó eventos como la Somnia Quest y la Somnia Odyssey. La Quest fue una campaña en junio de 2025 donde los usuarios completaban tareas sociales y de testnet (como seguir en X, unirse a Discord, probar DApps) para ganar recompensas y subir en una tabla de clasificación. La Odyssey (mencionada en un blog el 9 de septiembre de 2025) fue una aventura de 60 días que probablemente condujo a la mainnet, donde los usuarios que interactuaban consistentemente con las aplicaciones de testnet o aprendían sobre Somnia podían desbloquear un airdrop. De hecho, el HODLer Airdrop de Binance el 1 de septiembre de 2025, distribuyó 30 millones de SOMI (3 % del suministro) a los usuarios de Binance que cumplían ciertos criterios. Este fue un evento importante de adquisición de usuarios, dando efectivamente a miles de usuarios de cripto una participación en Somnia y un incentivo para probar la red. El airdrop y varias misiones han ayudado a Somnia a construir una base de usuarios inicial y presencia en redes sociales (el Twitter de Somnia – ahora X – y otros canales han crecido rápidamente).
  • Metaverse Browser: Como se mencionó, Somnia introdujo una aplicación especializada de Metaverse Browser. Es probable que sirva como una puerta de entrada fácil de usar donde alguien puede crear una billetera, navegar por las DApps de Somnia y entrar en eventos virtuales sin problemas. Tiene una billetera Web3 integrada y una interfaz simple para acceder a las DApps. Este tipo de experiencia curada podría facilitar la entrada de usuarios no cripto a la blockchain (por ejemplo, un jugador podría descargar el navegador de Somnia y unirse a un concierto virtual donde el navegador maneja la creación de la billetera y las transacciones de tokens de fondo).
  • Programas de Aceleración para Desarrolladores: Cubrimos Dream Catalyst y Dreamthon en la sección de ecosistema, pero desde una perspectiva de infraestructura para desarrolladores, estos programas también aseguran que los nuevos desarrolladores tengan orientación y recursos. Dream Catalyst proporcionó no solo financiación, sino también herramientas de infraestructura y apoyo para la construcción de comunidades. Eso significa que los equipos participantes probablemente recibieron ayuda para integrar los SDKs de Somnia, optimizar sus contratos para la arquitectura de Somnia, etc.

En términos de documentación y recursos:

  • Somnia ofrece un Lightpaper y un OnePager para resúmenes rápidos (enlazados en su sitio), y un Litepaper/whitepaper más detallado en la documentación (la sección de Conceptos que referenciamos cumple ese propósito).
  • Tienen repositorios de ejemplo y plantillas de código (por ejemplo, cómo construir un DEX, cómo usar Subgraphs, cómo integrar billeteras, todo proporcionado en su GitBook oficial). Al proporcionar esto, Somnia reduce la barrera de entrada para los desarrolladores de otras cadenas que quieren poner algo en funcionamiento rápidamente.
  • Auditorías: La documentación menciona una sección de Auditorías, lo que implica que el código de Somnia ha sido sometido a auditorías de seguridad de terceros. Aunque no se proporcionan detalles en nuestras fuentes, esta es una infraestructura importante: asegurar que el software del nodo y los contratos clave (como los de staking o tokens) estén auditados para proteger a desarrolladores y usuarios.

En general, la infraestructura para desarrolladores de Somnia parece bien pensada: compatibilidad con EVM para familiaridad, mejorada con APIs de datos personalizadas, abstracción de cuentas incorporada y un fuerte soporte para desarrolladores. Para los usuarios, la combinación de tarifas ultra bajas, posibles transacciones sin gas y aplicaciones especializadas (Metaverse Browser, misiones, etc.) tiene como objetivo proporcionar una experiencia de usuario de nivel Web2 en una plataforma Web3. El enfoque temprano de Somnia en la participación comunitaria (airdrops, misiones) muestra una mentalidad de growth-hacking: sembrar la red con contenido y usuarios para que los desarrolladores tengan una razón para construir, y viceversa. A medida que Somnia crezca, podemos esperar SDKs aún más refinados (quizás plugins para Unity/Unreal para desarrolladores de juegos) y mejoras continuas en las billeteras de usuario (quizás billeteras móviles nativas o inicios de sesión sociales). La financiación sustancial de la fundación asegura que tanto los desarrolladores como los usuarios serán apoyados con las herramientas que necesitan para prosperar en Somnia.

Casos de Uso y Aplicaciones

Somnia está diseñada específicamente para permitir una nueva clase de aplicaciones descentralizadas que antes eran inviables debido a las limitaciones de la blockchain. Su alto rendimiento y baja latencia abren la puerta a experiencias en tiempo real y completamente en la cadena en diversos dominios:

  • Juegos (GameFi): Este es el enfoque principal de Somnia. Con Somnia, los desarrolladores pueden construir juegos donde cada acción del juego (movimiento, combate, obtención de objetos, intercambios) puede ser registrada o ejecutada en la cadena en tiempo real. Esto significa verdadera propiedad de los activos del juego: los jugadores poseen sus personajes, skins, cartas o botín como NFTs/tokens en sus propias billeteras, no en la base de datos de una compañía de juegos. Economías de juego enteras pueden funcionar en la cadena, permitiendo características como recompensas de jugar para ganar, comercio de jugador a jugador sin intermediarios y modificaciones del juego impulsadas por la comunidad. Crucialmente, la capacidad de Somnia (más de 1M de TPS) y su rápida finalidad hacen que los juegos en la cadena sean responsivos. Por ejemplo, un RPG de acción en Somnia puede ejecutar miles de acciones de jugadores por segundo sin lag, o un juego de cartas coleccionables puede tener movimientos y barajados instantáneos en la cadena. La abstracción de cuentas y las bajas tarifas de Somnia también permiten que los juegos cubran potencialmente el gas para los jugadores, haciendo la experiencia fluida (los jugadores pueden ni siquiera darse cuenta de que hay una blockchain debajo). La plataforma prevé específicamente "juegos completamente en la cadena a escala de internet": mundos virtuales persistentes o MMOs donde el estado del juego vive en Somnia y continúa mientras la comunidad lo mantenga vivo. Debido a que los activos están en la cadena, un juego en Somnia podría incluso seguir evolucionando bajo el control de la comunidad si el desarrollador original se va, un concepto imposible en la Web2. Ejemplos actuales: Sparkball demuestra un brawler deportivo multijugador en la cadena; Chunked (la demostración tecnológica de Improbable) mostró un sandbox tipo Minecraft completamente en la cadena con interacciones de usuarios reales; Variance y Maelstrom mostrarán cómo experiencias más ricas de RPG y battle royale se traducen a la blockchain. La promesa final son juegos donde cientos de miles de jugadores juegan simultáneamente en un mundo compartido en la cadena, algo que Somnia está en una posición única para manejar.
  • Redes Sociales y Medios Sociales Web3: Con Somnia, se podría construir una plataforma social descentralizada donde los perfiles de usuario, publicaciones, seguidores y "me gusta" son todos datos en la cadena bajo el control del usuario. Por ejemplo, una DApp tipo Twitter en Somnia podría almacenar cada tuit como un NFT de mensaje en la cadena y cada seguimiento como una relación en la cadena. En tal red, los usuarios son verdaderamente dueños de su contenido y su grafo social, que podría ser portado a otras aplicaciones fácilmente. La escala de Somnia significa que un feed social podría manejar la actividad viral (millones de publicaciones y comentarios) sin colapsar. Y la finalidad en menos de un segundo significa que las interacciones (publicar, comentar) aparecen casi instantáneamente, como los usuarios esperan en la Web2. Un beneficio de las redes sociales en la cadena es la resistencia a la censura (ninguna compañía puede eliminar tu contenido o prohibir tu cuenta) y la portabilidad de datos (podrías moverte a un frontend o cliente diferente y mantener tus seguidores/contenido porque está en un registro público). El equipo de Somnia menciona explícitamente redes sociales descentralizadas construidas sobre identidad soberana y grafos sociales portátiles como un caso de uso principal. También prevén una gobernanza de asamblea de usuarios donde los usuarios clave tienen voz (esto podría vincularse a cómo las redes sociales moderan el contenido de manera descentralizada). Un ejemplo temprano concreto son probablemente los foros comunitarios dentro de los juegos: por ejemplo, un juego en Somnia podría tener un chat de gremio en la cadena o un tablero de eventos descentralizado. Pero a largo plazo, Somnia podría albergar alternativas completas a Facebook o Twitter, especialmente para comunidades que valoran la libertad y la propiedad. Otro ángulo interesante son las plataformas propiedad de los creadores: imagina un servicio tipo YouTube en Somnia donde los NFTs de video representan el contenido y los creadores ganan directamente a través de microtransacciones o participación tokenizada. El rendimiento de Somnia podría manejar los metadatos y las interacciones (aunque el almacenamiento de video sería fuera de la cadena), y sus transacciones baratas permiten micro-propinas y recompensas en tokens por la creación de contenido.
  • Metaverso y Mundos Virtuales: Somnia proporciona la infraestructura de identidad y económica para los metaversos. En la práctica, esto significa que las plataformas de mundos virtuales pueden usar Somnia para identidades de avatares, activos entre mundos y transacciones dentro de experiencias virtuales. Los estándares abiertos de MSquared para avatares/activos son compatibles con Somnia, por lo que el avatar 3D de un usuario o sus artículos de moda digital pueden representarse como tokens en Somnia y portarse a través de diferentes mundos. Por ejemplo, podrías tener un único NFT de avatar que usas en un concierto virtual, una reunión deportiva y un juego, todo en plataformas basadas en Somnia. A medida que Improbable orquesta eventos masivos (como fiestas para ver deportes virtuales, festivales de música, etc.), Somnia puede manejar la capa económica: acuñar POAPs (tokens de prueba de asistencia), vender mercancía virtual como NFTs, recompensar a los participantes con tokens y permitir el comercio entre pares en tiempo real durante los eventos. La capacidad de Somnia para soportar decenas de miles de usuarios concurrentes en un estado compartido (a través del consenso multi-stream) es crucial para escenarios de metaverso donde una gran multitud podría realizar transacciones o interactuar simultáneamente. El Virtual Ballpark de la MLB y los eventos de K-pop en 2023 (pre-Somnia) alcanzaron a miles de usuarios; con Somnia, esos usuarios podrían tener cada uno billeteras y activos, permitiendo cosas como un lanzamiento de NFT en vivo para todos en el "estadio" o un marcador de tokens en tiempo real para la participación en el evento. Esencialmente, Somnia puede sustentar una economía de metaverso persistente e interoperable: piénsalo como el libro mayor que registra quién posee qué a través de muchos mundos virtuales interconectados. Esto soporta casos de uso como bienes raíces virtuales (NFTs de tierra) que pueden ser comerciados o usados como garantía, recompensas de misiones entre mundos (completa un objetivo en el juego A, obtén un artículo utilizable en el mundo B), o incluso reputación de identidad (registros en la cadena de los logros o credenciales de un usuario a través de plataformas).
  • Finanzas Descentralizadas (DeFi): Aunque Somnia se posiciona principalmente como una cadena para aplicaciones de consumo, su alto rendimiento abre algunas posibilidades de DeFi intrigantes. Por un lado, Somnia puede albergar comercio de alta frecuencia e instrumentos financieros complejos en la cadena. El equipo menciona específicamente libros de órdenes de límite completamente en la cadena. En Ethereum, los intercambios de libros de órdenes son imprácticos (demasiado lentos/caros), por lo que DeFi utiliza AMMs. Pero en Somnia, un DEX podría mantener un contrato inteligente de libro de órdenes y emparejar órdenes en tiempo real, al igual que un intercambio centralizado, porque la cadena puede manejar miles de operaciones por segundo. Esto podría traer funcionalidad y liquidez similares a las de un CEX a la cadena con transparencia y auto-custodia. Otra área es la gestión de riesgos en tiempo real: la velocidad de Somnia podría permitir derivados en la cadena que actualicen los requisitos de margen cada segundo, o libros de órdenes de opciones en vivo. Además, con su característica de almacenamiento transitorio, Somnia podría soportar cosas como contratos de seguro efímeros o pagos por streaming que existen solo por un corto período. Los protocolos DeFi en Somnia también podrían aprovechar su gas determinista para costos más predecibles. Por ejemplo, una plataforma de micro-préstamos en Somnia podría procesar factiblemente transacciones diminutas (como pagos de intereses de 0,01 $ cada minuto) porque las tarifas son fracciones de un céntimo. Así que Somnia podría potenciar microtransacciones y flujos de pago Web3 en DeFi y más allá (algo que Ethereum no puede hacer económicamente a escala). Además, la capacidad de Somnia para comprimir datos y agregar firmas podría permitir el procesamiento por lotes de miles de transferencias o intercambios en un solo bloque, impulsando aún más el rendimiento para casos de uso de DeFi como airdrops o pagos masivos. Aunque DeFi no es el enfoque de marketing, es probable que surja un ecosistema financiero eficiente en Somnia para apoyar los juegos y metaversos (por ejemplo, DEXes para tokens de juegos, mercados de préstamos para NFTs, etc.). Podríamos ver protocolos especializados, por ejemplo, un intercambio de fraccionamiento de NFT donde los artículos de juego pueden ser comerciados fraccionalmente; Somnia puede manejar la demanda explosiva si un artículo popular se dispara de repente.
  • Identidad y Credenciales: La combinación de identidad soberana y alta capacidad de Somnia permite sistemas de identidad en la cadena que podrían usarse para autenticación, reputación y credenciales en Web3. Por ejemplo, un usuario podría tener un NFT de identidad o un token soulbound en Somnia que atestigüe sus logros (como "completó X misiones de juego" o "asistió a Y eventos" o incluso credenciales fuera de la cadena como títulos o membresías). Estos podrían usarse en múltiples aplicaciones. El grafo social portable de un usuario (quiénes son sus amigos, a qué comunidades pertenecen) puede almacenarse en Somnia y llevarse de un juego o plataforma social a otra. Esto es poderoso para romper los silos de la Web2: imagina cambiar de aplicación social pero mantener a tus seguidores, o un perfil de jugador que lleva tu historial a nuevos juegos (quizás ganándote ventajas de veterano). Con el modelo de gobernanza de Somnia incorporando una Asamblea de Usuarios (usuarios clave que proporcionan supervisión), también podríamos ver una gobernanza basada en la identidad donde los usuarios con participación probada tienen más voz en ciertas decisiones (todo aplicable en la cadena a través de esas credenciales). Otro caso de uso son las economías de creadores de contenido: un creador podría emitir su propio token o serie de NFT en Somnia para su base de fans, y estos podrían desbloquear el acceso a varias plataformas (videos, chats, eventos virtuales). Dado que Somnia puede manejar grandes volúmenes, un creador popular con millones de fans podría hacer un airdrop de insignias a todos ellos o manejar micro-propinas en tiempo real durante una transmisión en vivo.
  • Servicios Web en Tiempo Real: En términos generales, Somnia puede actuar como un backend descentralizado para servicios que requieren respuestas instantáneas. Considera una aplicación de mensajería descentralizada donde los mensajes son eventos en la cadena: con finalidad en menos de un segundo, dos usuarios podrían chatear a través de Somnia y ver los mensajes aparecer casi instantáneamente e inmutablemente (quizás con encriptación en el contenido, pero marcas de tiempo y pruebas en la cadena). O un mercado en línea donde los pedidos y listados son contratos inteligentes: Somnia podría actualizar el inventario y las ventas en tiempo real, evitando el doble gasto de artículos y permitiendo intercambios atómicos de bienes por pago. Incluso las plataformas de streaming podrían integrar la blockchain para la gestión de derechos: por ejemplo, un servicio de streaming de música en Somnia podría gestionar los recuentos de reproducción de canciones y los micropagos de licencias a los artistas cada pocos segundos de reproducción (porque puede manejar transacciones pequeñas de alta frecuencia). En esencia, Somnia permite una interactividad de nivel Web2 con la confianza y propiedad de la Web3. Cualquier aplicación donde muchos usuarios interactúan simultáneamente (subastas, herramientas de colaboración multijugador, feeds de datos en vivo) podría descentralizarse en Somnia sin sacrificar el rendimiento.

Estado Actual de los Casos de Uso: A finales de 2025, los casos de uso más tangibles en vivo en Somnia giran en torno a juegos y coleccionables: varios juegos están en fase de prueba o acceso temprano en la red principal, y se están acuñando colecciones de NFT (avatares, activos de juego) en Somnia. La red ha facilitado con éxito enormes eventos de prueba (miles de millones de transacciones en la testnet, demostraciones a gran escala) demostrando que estos casos de uso no son solo teóricos. El siguiente paso es convertir esas pruebas en aplicaciones en vivo continuas con usuarios reales. Los primeros adoptantes como Sparkball y Variance serán pruebas de fuego importantes: si pueden atraer a miles de jugadores diarios en Somnia, veremos a la cadena mostrar realmente su poder y quizás atraer a aún más desarrolladores de juegos.

Las posibles aplicaciones futuras son emocionantes de considerar. Por ejemplo, proyectos a escala nacional o empresarial: un gobierno podría usar Somnia para emitir una identificación digital o manejar una elección en la cadena (millones de votos en segundos, con transparencia), o una bolsa de valores podría usarla para negociar valores tokenizados a alta frecuencia. La parte de InfoFi mencionada para Dreamthon insinúa cosas como un Reddit descentralizado o mercados de predicción (un número masivo de pequeñas apuestas y votos) que Somnia podría potenciar.

En resumen, los casos de uso de Somnia abarcan juegos, redes sociales, metaverso, DeFi, identidad y más, todos unidos por un hilo común: transacciones a escala masiva y en tiempo real con total confianza en la cadena. Su objetivo es llevar experiencias generalmente reservadas para servidores centralizados al ámbito descentralizado. Si Ethereum fue pionero en las finanzas descentralizadas, la ambición de Somnia es ser pionera en la vida descentralizada, desde el entretenimiento hasta las conexiones sociales, al ofrecer finalmente el rendimiento necesario para las aplicaciones de estilo masivo. A medida que la red madure, es probable que veamos nuevas innovaciones que aprovechen sus características únicas (por ejemplo, juegos que usan estado transitorio para simulaciones de física, o aplicaciones sociales que usan compresión de flujo para manejar millones de pequeñas acciones). El próximo año o dos revelarán cuáles de estas aplicaciones potenciales ganan tracción y demuestran la promesa de Somnia en el mundo real.

Panorama Competitivo

Somnia entra en un abarrotado campo de Capa 1, pero se diferencia por su rendimiento extremo y su enfoque en aplicaciones de consumo completamente en la cadena. Así es como Somnia se compara con otras blockchains L1 prominentes:

AspectoSomnia (SOMI)Ethereum (ETH)Solana (SOL)Avalanche (AVAX)Sui (SUI)
Lanzamiento (Mainnet)2025 (Q3) – nuevo participante respaldado por Improbable2015 (pionero, ahora ecosistema L1 + L2)2020 (L1 monolítica de alto rendimiento)2020 (plataforma multi-cadena: P-Chain, C-Chain, subnets)2023 (L1 basada en Move)
Mecanismo de ConsensoMultiStream PoS-BFT: Muchas cadenas de validadores paralelas + cadena de consenso PBFT (inspirada en Autobahn). PoS con ~100 validadores.Proof-of-Stake + Consenso Nakamoto (Gasper): ~700k validadores (sin permisos). Bloques cada ~12 seg, finalizados en ~2 épocas (≈12 min) en su forma actual.Tower BFT PoS usando Proof-of-History para la sincronización. ~2200 validadores. Líder rotativo, procesamiento de bloques en paralelo.Consenso Snowman (Avalanche) en la P-Chain, con submuestreo repetido sin líder. ~1000 validadores. La C-Chain usa un consenso PoS similar a Ethereum (Snowman). Las subnets pueden usar consensos personalizados.Narwhal & Bullshark PoS basado en DAG con rotación instantánea de líder. ~100 validadores (conjunto creciente sin permisos). Usa la VM Move.
RendimientoMás de 1.000.000 de TPS demostrado en pruebas (1.05M de TX ERC-20/seg en 100 nodos). Apunta a escala de internet (más de 1 millón de TPS sostenido).~15–30 TPS en la L1 de la mainnet. Escala a través de rollups L2 (teóricamente ilimitado, pero cada rollup es separado).~2.000–3.000 TPS típico; probado hasta ~50k TPS en testnet (teórico más de 65k TPS). Altamente paralelo para TX no superpuestas.~4.500 TPS en la C-Chain (EVM) en condiciones ideales. Las subnets permiten el escalado horizontal añadiendo más cadenas.Más de 20.000 TPS en pruebas (la devnet de Sui alcanzó 297k TPS en una prueba). El TPS en el mundo real es menor (cientos a miles bajos). Usa ejecución paralela para transacciones independientes.
Finalidad de Transacción~0.1–0.5 segundos (finalidad determinista en menos de un segundo). Esencialmente en tiempo real.Tiempo de bloque de ~12 segundos, ~6-12 minutos para finalidad probabilística (con PoS, final después de ~2 épocas). Futuras actualizaciones (Danksharding/ajustes de PoS) pueden reducir el tiempo.Tiempo de bloque de ~0.4 segundos en promedio. La finalidad suele ser de ~1-2 segundos (los bloques de Solana se finalizan rápidamente salvo bifurcaciones).~1–2 segundos para la finalidad en la C-Chain (el consenso de Avalanche es de finalidad rápida). La finalidad de las subnets puede variar pero generalmente es de 1-3s.~1 segundo de finalidad típica (el consenso de Sui finaliza las transacciones muy rápido en condiciones de red optimistas).
Modelo de EscalabilidadScale-up (vertical) + flujos paralelos: Cadena única con rendimiento masivo a través de ejecución optimizada + consenso de múltiples líderes. No se necesita sharding; un estado global. Planea añadir validadores a medida que la tecnología madure.Escalado de Capa 2 y Sharding (futuro): Ethereum en sí mismo permanece descentralizado pero con bajo TPS; escala a través de rollups (Arbitrum, Optimism, etc.) por encima. El sharding está en la hoja de ruta (Danksharding) para aumentar moderadamente el rendimiento de la L1.Cadena monolítica: Todo el estado en una cadena. Depende del alto rendimiento de los nodos y la ejecución paralela. Sin sharding (Solana sacrifica algo de descentralización por TPS bruto).Subnet y múltiples cadenas: La P-Chain de Avalanche gestiona los validadores; la C-Chain (EVM) es una cadena (~4.5k TPS). Se pueden lanzar subnets adicionales para nuevas aplicaciones, cada una con su propio rendimiento. Escala horizontalmente añadiendo más cadenas (pero cada subnet es un estado separado).Ejecución multi-carril: Sui utiliza la ejecución basada en objetos para paralelizar las TX. Como Solana, una única cadena donde el rendimiento proviene del paralelismo y los altos requisitos de hardware. Sin sharding; un estado global (con particionamiento de objetos internamente).
Programación y VMCompatible con EVM (Solidity, Vyper). Los contratos inteligentes se compilan a x86 para mayor rendimiento. Soporta todas las herramientas de Ethereum.EVM (Solidity, Vyper) en la mainnet. Ecosistema maduro y enorme de herramientas y frameworks de desarrollo.VM personalizada (llamada Sealevel) usando Rust o C/C++. No es compatible con EVM. Usa LLVM para bytecode BPF. Curva de aprendizaje más pronunciada (Rust) pero alto rendimiento.Múltiples VMs: La C-Chain por defecto es EVM (Solidity) – amigable para desarrolladores pero con menor rendimiento. Otras subnets pueden ejecutar VMs personalizadas (por ejemplo, Avalanche tiene una VM de testnet basada en WASM) para necesidades específicas.Move VM: Usa Move, un lenguaje seguro basado en Rust para activos. No es compatible con EVM, por lo que se necesita un nuevo ecosistema. Se enfoca en la programación orientada a activos (recursos).
Innovaciones ÚnicasEVM compilado, IceDB, consenso multi-stream, agregación BLS, almacenamiento transitorio – permitiendo un TPS extremo y un estado grande. Costos de gas deterministas por acceso a almacenamiento. Compresión para ancho de banda. Énfasis en dApps en tiempo real (juegos/metaverso).Seguridad y descentralización – Ethereum prioriza la máxima descentralización y seguridad económica (cientos de miles de validadores, más de 20 mil millones de dólares en staking). Tiene características pioneras como la Abstracción de Cuentas (ERC-4337) y el ecosistema líder de contratos inteligentes. Sin embargo, la capa base tiene un rendimiento limitado por diseño (el escalado se traslada a las L2).Proof-of-History (reloj antes del consenso) para acelerar el ordenamiento; cliente de validador altamente optimizado. Runtime paralelo para TX no conflictivas. El diferenciador de Solana es la velocidad bruta en una cadena monolítica, pero requiere hardware potente (más de 128 GB de RAM, CPU/GPU de gama alta). No es EVM, lo que limita la adopción fácil de los desarrolladores de Ethereum.Flexibilidad de las subnets – capacidad de lanzar blockchains personalizadas bajo el conjunto de validadores de Avalanche, adaptadas para aplicaciones específicas (por ejemplo, con su propio token de gas o reglas). Finalidad rápida a través del consenso de Avalanche. Sin embargo, el rendimiento de la C-Chain (EVM) es mucho menor que el de Somnia, y el uso de múltiples subnets sacrifica la componibilidad entre aplicaciones.Paralelismo centrado en objetos – el modelo de objetos de Sui permite que las transacciones independientes se ejecuten simultáneamente, mejorando el rendimiento cuando hay muchas TX no relacionadas. También cuenta con características como agrupación de transacciones, orden causal para ciertos tipos de TX. El lenguaje Move garantiza la seguridad de los activos (sin pérdida accidental de tokens). Menor rendimiento que Somnia, pero también se enfoca en juegos (Sui enfatiza los NFTs y juegos simples con Move).
Compromisos de DescentralizaciónComienza con ~60–100 validadores (seleccionados inicialmente por la fundación, luego elegidos por los poseedores de tokens). Los requisitos de hardware son relativamente altos (comparables a un nodo de Solana/Aptos). No es tan sin permisos como Ethereum, pero es suficiente para sus casos de uso (objetivo de hacer crecer el conjunto de validadores con el tiempo). Adopta la "descentralización suficiente" para el rendimiento.Descentralización muy alta (cualquiera puede hacer staking de 32 ETH para ejecutar un validador; miles de validadores independientes). La seguridad y la resistencia a la censura son de primera categoría. Pero el rendimiento se ve afectado; necesita L2s para escalar, lo que añade complejidad.Más centralizado en la práctica: <2500 validadores, con un pequeño número que a menudo produce la mayoría de los bloques. Los altos costos de hardware significan que muchos participantes usan Google Cloud o centros de datos (menos nodos domésticos). La red ha experimentado interrupciones en el pasado bajo alta carga.Bastante descentralizado: ~1000 validadores, y cualquiera puede unirse haciendo staking de un mínimo de ~2.000 AVAX. El consenso de Avalanche es escalable en número de validadores sin ralentizarse mucho. Sin embargo, cada subnet puede formar su propio conjunto de validadores más pequeño, posiblemente sacrificando algo de seguridad por rendimiento.Descentralización moderada: alrededor de 100 validadores (escala similar a la de Somnia). Sin permisos, pero en su génesis fuertemente respaldado por unas pocas entidades. También usa PoS delegado. El enfoque de Sui es similar al de Somnia/Aptos en que es un conjunto de validadores nuevo y relativamente pequeño destinado a crecer.
Ecosistema y AdopciónEmergente – ~70 proyectos en el lanzamiento, principalmente juegos (Sparkball, Variance, etc.). Fuerte apoyo de Improbable (eventos de metaverso) y financiación (270M $). Necesita demostrar su valía con la adopción real de usuarios después del lanzamiento. Integrado con grandes servicios (OpenSea, LayerZero) para un arranque rápido.Maduro y vasto – miles de dApps, más de 20 mil millones de dólares de TVL en DeFi, mercado de NFT establecido. El grupo de desarrolladores es el más grande aquí. Sin embargo, para juegos de alto rendimiento, no se usa la L1 de Ethereum; esos proyectos usan sidechains o L2s. Ethereum es la opción segura para dApps de propósito general pero no para aplicaciones en tiempo real sin L2.Creciente (especialmente DeFi/NFT) – Solana tiene un fuerte ecosistema DeFi (Serum, Raydium) y una escena NFT (por ejemplo, Degenerate Apes). También es conocida por aplicaciones sociales Web3 (el teléfono Saga de Solana, etc.). Algunos proyectos de juegos también están en Solana. Tiene usuarios reales (decenas de millones de direcciones) pero también tuvo problemas de estabilidad. Solana atrae a quienes quieren velocidad L1 sin sharding, a costa de una infraestructura más centralizada.Maduro (especialmente empresarial y nichos) – Avalanche tiene DeFi (Trader Joe, etc.) y lanzó subnets de juegos (por ejemplo, DeFi Kingdoms se mudó a una subnet de Avalanche). Su fortaleza es la flexibilidad: los proyectos pueden tener su propia cadena. Sin embargo, la C-Chain principal de Avalanche está limitada por el rendimiento de EVM. La única cadena de Somnia puede superar a la cadena única de Avalanche por órdenes de magnitud, pero Avalanche puede tener múltiples cadenas paralelas. La componibilidad entre subnets es un problema (necesitan puentes).Nuevo y enfocado en juegos/NFT – Sui, como Somnia, se posiciona para juegos y aplicaciones de próxima generación (también demostraron juegos en la cadena). El lenguaje Move de Sui es una barrera para algunos desarrolladores (no es Solidity), pero ofrece características de seguridad. Su ecosistema en 2023 estaba en su infancia: algunas demos de juegos, NFTs y DeFi básico. Somnia podría competir más con Sui/Aptos por la atención en los juegos Web3, ya que todos prometen un alto TPS. Somnia tiene la ventaja de EVM (adopción más fácil), mientras que Sui apuesta por la seguridad y el diseño paralelo de Move.

En esencia, los análogos más cercanos de Somnia son Solana, Sui/Aptos, y quizás app-chains especializadas como ciertas subnets de Avalanche o las próximas cadenas de alto rendimiento de Polygon. Al igual que Solana, Somnia renuncia a la descentralización extrema en favor del rendimiento, pero Somnia se diferencia al mantenerse en la EVM (ayudándole a aprovechar la base de desarrolladores de Ethereum) y al introducir un consenso único de múltiples cadenas en lugar de un líder a la vez. El enfoque de Solana hacia el paralelismo (múltiples hilos de GPU procesando diferentes transacciones) contrasta con el enfoque de Somnia (múltiples validadores procesando cada uno diferentes flujos). Durante cargas correlacionadas (un contrato popular), la optimización de un solo núcleo de Somnia brilla, mientras que el paralelismo de Solana se vería limitado ya que todos los hilos compiten por el mismo estado.

En comparación con la mainnet de Ethereum, Somnia es órdenes de magnitud más rápida pero sacrifica la descentralización (100 validadores frente a los cientos de miles de Ethereum). Ethereum también tiene un ecosistema mucho más grande y probado en batalla. Sin embargo, Ethereum no puede manejar directamente juegos o aplicaciones sociales a escala; esos terminan en L2s o sidechains. Somnia se posiciona esencialmente como una alternativa a un rollup de Ethereum, una que es su propia L1 con un rendimiento superior a cualquier rollup actual y sin necesidad de pruebas de fraude o suposiciones de seguridad separadas (aparte de su conjunto de validadores más pequeño). A largo plazo, la hoja de ruta de Ethereum (sharding, danksharding, etc.) aumentará el rendimiento pero probablemente no a millones de TPS en la L1. En cambio, Ethereum apuesta por los rollups; Somnia apuesta por escalar la L1 misma con ingeniería avanzada. Puede que no compitan por los mismos casos de uso inicialmente (DeFi podría quedarse en Ethereum/L2, mientras que los juegos van a Somnia o cadenas similares). La interoperabilidad (a través de LayerZero u otros) podría permitirles complementarse, con activos moviéndose entre Ethereum y Somnia según sea necesario.

Avalanche ofrece subnets que, como Somnia, pueden dedicarse a juegos con alto rendimiento. La diferencia es que cada subnet de Avalanche es una instancia separada (tendrías que poner en marcha tus propios validadores o reclutar algunos para que se unan). Somnia, en cambio, proporciona una cadena de alta capacidad compartida, lo que facilita la interoperabilidad entre aplicaciones (todas las aplicaciones de Somnia viven en una cadena, componibles, como en Ethereum o Solana). La subnet principal de Avalanche (C-Chain) es EVM pero mucho más lenta que Somnia. Así que Somnia supera con creces a la cadena común de Avalanche, aunque Avalanche puede escalar si un proyecto crea una subnet personalizada (pero entonces esa subnet podría no tener la componibilidad general completa o la base de usuarios). Para un desarrollador, desplegar en Somnia podría ser más simple que gestionar una subnet de Avalanche, y aprovechas inmediatamente el grupo de usuarios y la liquidez compartidos de Somnia.

Sui (y Aptos) a menudo se citan como cadenas de alto TPS de próxima generación, utilizando Move y consenso paralelo. La ventaja de Somnia sobre Sui es el rendimiento (Sui no ha demostrado millones de TPS; su diseño está quizás en los cientos de miles bajos en el mejor de los casos) y la compatibilidad con EVM. La ventaja de Sui podría ser la seguridad de Move para la lógica de activos complejos y posiblemente una hoja de ruta más descentralizada (aunque en el lanzamiento Sui también tenía alrededor de 100 validadores). Si Somnia captura a los estudios de juegos que prefieren usar Solidity (quizás portando contratos de Solidity de prototipos de juegos de Ethereum), podría superar a Sui en ecosistema rápidamente, dado lo grande que es la comunidad de desarrolladores de Solidity.

Somnia también se compara con Solana en su objetivo de Web3 de consumo (ambos han enfatizado las integraciones sociales y telefónicas: Solana tuvo un teléfono Saga, Somnia un navegador, etc.). La audaz afirmación de Herman Narula de que Somnia puede hacer "miles de veces el rendimiento de Solana" establece el tono de que Somnia se ve a sí misma no solo como otra cadena rápida, sino como la cadena EVM más rápida donde Solana es la cadena no EVM más rápida. Si Somnia ofrece incluso un orden de magnitud mejor de TPS sostenido que Solana en la práctica (digamos que Solana hace 5k TPS de promedio y Somnia podría hacer 50k o más de promedio con picos en los millones), realmente se abrirá un nicho para aplicaciones que incluso Solana no puede manejar (por ejemplo, un juego de blockchain a escala de Fortnite o una red social a escala global).

Un competidor más a tener en cuenta es Polygon 2.0 o los zkEVMs: aunque no son L1s, ofrecen escalado para EVM. Polygon está trabajando en una serie de ZK-rollups y cadenas de alto rendimiento. Esos podrían potencialmente igualar parte del rendimiento de Somnia mientras se benefician de la seguridad de Ethereum. Sin embargo, los ZK-rollups con 1M de TPS aún no existen, e incluso entonces, podrían enfrentar límites de disponibilidad de datos. El enfoque de Somnia es una solución todo en uno con su propia seguridad. Tendrá que demostrar que su seguridad (100 validadores PoS) es lo suficientemente robusta para aplicaciones de mucho dinero, algo que los rollups de Ethereum heredan inherentemente de ETH. Pero para juegos y redes sociales, donde los requisitos de seguridad son ligeramente diferentes (robar una espada de juego NFT no es tan catastrófico como robar miles de millones en TVL de DeFi), el compromiso de Somnia podría ser perfectamente aceptable e incluso preferible debido a la experiencia del usuario.

En conclusión, Somnia se destaca por llevar el rendimiento más allá que cualquier L1 de propósito general actual, manteniendo la familiaridad de la EVM. Su objetivo es ocupar un espacio en el mercado para "Web3 a escala Web2" que otros solo han abordado parcialmente:

  • Ethereum dominará la confianza y DeFi, pero delegará las tareas de alta frecuencia a las L2 (que añaden complejidad y fragmentación).
  • Solana mostró un alto TPS para DeFi y NFTs, pero no es EVM y tuvo problemas de estabilidad; Somnia podría atraer proyectos que quieren una velocidad similar a la de Solana con las herramientas de Ethereum.
  • Avalanche ofrece personalización y comodidad EVM, pero no ha demostrado un rendimiento de cadena única cercano al de Somnia.
  • Sui/Aptos están en la misma generación que Somnia, compitiendo por los desarrolladores de juegos, pero las asociaciones tempranas de Somnia (Improbable, grandes marcas) y la compatibilidad con EVM le dan una fuerte ventaja si se ejecuta bien.

Como dijo Narula, Somnia es posiblemente la primera cadena construida específicamente para experiencias virtuales en tiempo real a escala masiva. Si esas experiencias (juegos, eventos, mundos sociales) se convierten en la próxima gran ola de adopción de blockchain, la competencia de Somnia podría ser en realidad la infraestructura de nube tradicional (AWS, etc.) tanto como otras blockchains, porque está tratando de reemplazar los servidores de juegos centralizados y las bases de datos sociales, no solo competir por las aplicaciones de blockchain existentes. En ese sentido, el éxito de Somnia se medirá por si puede albergar aplicaciones que atraigan a millones de usuarios que quizás ni siquiera sepan (o les importe) que una blockchain está funcionando por debajo. Ninguna L1 actual ha alcanzado aún ese nivel de aplicación de usuario masivo (incluso las aplicaciones más grandes de Solana tienen cientos de miles, no millones de usuarios activos). Esa es la vara que Somnia se ha puesto, y contra la cual su innovadora arquitectura será probada en los próximos años.

Hoja de Ruta y Estado Actual

El viaje de Somnia ha progresado rápidamente del concepto a la realidad en poco tiempo, y continúa evolucionando después de la mainnet con objetivos claros:

Desarrollos Recientes (2024–2025):

  • Financiación y Testnet (2024): El proyecto surgió del sigilo respaldado por una financiación significativa. A principios de 2024, Improbable anunció el compromiso de 270 millones de dólares para el ecosistema de Somnia y MSquared. Esto proporcionó una enorme pista de despegue. Somnia ejecutó una Devnet a finales de 2024 (noviembre) donde batió récords: alcanzó 1.05 millones de TPS y otros benchmarks en una configuración global de 100 nodos. Esos resultados (incluyendo 50k intercambios de Uniswap/seg, 300k acuñaciones de NFT/seg) se publicitaron para construir credibilidad. Después de la Devnet, se lanzó una Testnet totalmente pública el 20 de febrero de 2025. La testnet (nombre en clave Shannon) funcionó durante unos 6 meses. Durante ese tiempo, Somnia afirma haber procesado más de 10 mil millones de transacciones e incorporado 118 millones de direcciones de billetera de prueba, cifras asombrosas. Estos números probablemente incluyen pruebas de carga programadas y participación de la comunidad. La testnet también vio un rendimiento diario máximo de 1.9 mil millones de transacciones en un día (un récord para cualquier contexto EVM). CoinDesk señaló estas cifras pero también que el explorador público estaba fuera de línea en ese momento para verificar, lo que implica que algunas de estas eran métricas internas. No obstante, la testnet demostró estabilidad bajo una carga sin precedentes.

    A lo largo de la testnet, Somnia ejecutó programas de participación: un programa de incentivos de Puntos donde los primeros usuarios que completaban tareas podían ganar puntos (probablemente convertibles en futuros tokens o recompensas), y colaboró con socios (los desarrolladores de juegos hicieron pruebas de juego, se celebraron hackathons). La fase de testnet también fue cuando se incorporaron más de 70 socios/proyectos del ecosistema. Esto indica que para la mainnet, muchas integraciones y aplicaciones estaban listas o casi listas.

  • Lanzamiento de la Mainnet (Q3 2025): Somnia lanzó la mainnet el 2 de septiembre de 2025. El lanzamiento incluyó la liberación del token SOMI y la habilitación del staking. Notablemente, en la mainnet:

    • 60 validadores se pusieron en línea (con grandes nombres como Google Cloud entre ellos).
    • La Fundación Somnia está operativa, supervisando la cadena como un administrador neutral. Improbable entregó la tecnología y ahora la Fundación (también conocida como la Fundación de la Sociedad Virtual) está a cargo de la gobernanza y el desarrollo futuro.
    • Listado y distribución de SOMI: A un día del lanzamiento, Binance reveló a SOMI como parte de sus listados "Seed Tag" y realizó el airdrop HODLer. Esto fue un gran impulso, efectivamente un respaldo de un exchange de primer nivel. Muchas nuevas L1s luchan por conseguir tracción en los exchanges, pero Somnia inmediatamente puso SOMI en manos de los usuarios a través de Binance.
    • En las redes sociales, el equipo de Somnia y sus socios promocionaron las capacidades de la mainnet. Un comunicado de prensa de Improbable y la cobertura en medios como CoinDesk, Yahoo Finance, etc., difundieron la noticia de que "la cadena EVM más rápida" está en vivo.
    • Las dApps iniciales del ecosistema comenzaron su despliegue. Por ejemplo, el puente de NFT a través de LayerZero estaba activo (se podían puentear stablecoins según la documentación), y algunos de los juegos de la testnet comenzaron a moverse a la mainnet (el lanzamiento de Sparkball, etc., alrededor de septiembre según lo indicado por blogs y actualizaciones).
    • Los eventos de airdrop comunitarios (la Somnia Odyssey) probablemente culminaron alrededor del lanzamiento, distribuyendo parte de esa asignación de tokens de la Comunidad a los primeros partidarios.

En resumen, el lanzamiento de la mainnet fue exitoso y posicionó a Somnia con validadores en vivo, un token en vivo y más de 70 proyectos en vivo o a punto de lanzarse. Es importante destacar que llegaron al mercado justo cuando el interés en los juegos Web3 y el metaverso estaba repuntando a finales de 2025, aprovechando esa tendencia.

Estado Actual (Finales de 2025): La mainnet de Somnia está operativa con bloques en menos de un segundo. La red todavía está en una fase de arranque donde la Fundación Somnia y el equipo central mantienen un control significativo para garantizar la estabilidad. Por ejemplo, es probable que las propuestas de gobernanza aún no estén completamente abiertas; la fundación probablemente está gestionando las actualizaciones y los ajustes de parámetros mientras se educa a la comunidad sobre los procesos de gobernanza. La distribución de tokens todavía está muy concentrada (ya que solo circula ~16 % y los tokens de inversores/equipo no comenzarán a desbloquearse hasta finales de 2026). Esto significa que la Fundación tiene amplias reservas de tokens para apoyar el ecosistema (a través de subvenciones, provisión de liquidez, etc.).

En el frente técnico, Somnia probablemente está monitoreando y ajustando el rendimiento en condiciones reales. ¿Las dApps reales la están llevando a sus límites? Posiblemente aún no; los recuentos iniciales de usuarios probablemente están en los miles, no en los millones. Así que puede que no haya 1M de TPS ocurriendo regularmente en la mainnet, pero la capacidad está ahí. El equipo podría usar este período para optimizar el software del cliente, incorporar cualquier retroalimentación de Cuthbert (si se encontraron divergencias, se corregirían rápidamente) y reforzar la seguridad. Los resultados de las auditorías de seguridad (si no se han publicado ya) podrían publicarse en este momento o a principios de 2026 para asegurar a los desarrolladores la seguridad.

Hoja de Ruta a Corto Plazo (2026): La documentación y las comunicaciones de Somnia insinúan varios objetivos a corto plazo:

  • Lanzamiento de Características: Se planeó activar algunas características después del lanzamiento:
    • La Fijación de Precios de Gas Dinámica y los Descuentos por Volumen están programados para implementarse a finales de 2025. Esto requiere algunas pruebas y quizás la aprobación de la gobernanza para activarse. Una vez habilitado, las dApps de alto rendimiento comenzarán a disfrutar de un gas más barato, lo que podría ser un punto de venta para atraer a socios empresariales o grandes de la Web2.
    • La característica de Almacenamiento Transitorio también está programada para finales de 2025. La implementación probablemente necesita ser probada cuidadosamente (asegurando que la eliminación de datos funcione correctamente y no introduzca problemas de consenso). Cuando esto se active, Somnia será una de las primeras cadenas en ofrecer datos en la cadena con caducidad, lo que será enorme para los desarrolladores de juegos (imagina sesiones de juego temporales en la cadena).
    • Propinas (tarifas de prioridad): Señalaron que las propinas podrían introducirse más tarde si fuera necesario. Si el uso de la red aumenta hasta el punto en que los bloques están consistentemente llenos, para 2026 podrían habilitar propinas opcionales para priorizar transacciones (al igual que el modelo de tarifa base y propina de Ethereum). Esto sería una señal de congestión saludable si sucede.
    • Expansión del Conjunto de Validadores: Inicialmente ~60, el objetivo es aumentar el número de validadores con el tiempo para mejorar la descentralización sin perjudicar el rendimiento. Mencionaron que esperan un crecimiento más allá de 100 a medida que la red madure. El cronograma podría depender de qué tan bien escale el consenso con más validadores (PBFT tiende a volverse más lento a medida que aumentan los validadores, pero quizás su variante inspirada en Autobahn pueda manejar unos pocos cientos). En 2026, podrían incorporar validadores adicionales, posiblemente de su comunidad o nuevos socios. Esto podría hacerse a través de votos de gobernanza (poseedores de tokens aprobando nuevos validadores) o automáticamente si hay suficiente stake respaldando a los nuevos participantes.
    • Descentralización de la Gobernanza: Somnia estableció una hoja de ruta de Descentralización Progresiva en la gobernanza. En los primeros 6 meses (fase de arranque), la junta de la Fundación tiene el control total. Así que aproximadamente hasta el Q1/Q2 de 2026, estaremos en arranque, durante el cual probablemente refinen los procesos e incorporen miembros a los consejos. Luego, de 6 a 24 meses (mediados de 2026 a finales de 2027), entran en la fase de Transición donde la Casa del Token (poseedores de tokens) puede comenzar a votar sobre propuestas, aunque la Fundación puede vetar si es necesario. Podríamos ver los primeros votos en la cadena en 2026 para cosas como asignaciones de subvenciones o cambios menores de parámetros. Para el año 2 (2027), el objetivo es la fase Madura donde las decisiones de los poseedores de tokens se mantienen en su mayoría y la Fundación solo realiza intervenciones de emergencia. Así que para 2026, un objetivo clave es establecer esos órganos de gobernanza: posiblemente elegir miembros para el Consejo de Validadores, el Consejo de Desarrolladores, la Asamblea de Usuarios que se describieron. Esto implicará organización comunitaria, probablemente algo que la Fundación facilitará seleccionando miembros de buena reputación inicialmente (por ejemplo, invitando a los mejores desarrolladores de juegos a un consejo de desarrolladores, o a grandes líderes de gremios comunitarios a una asamblea de usuarios).
  • Crecimiento del Ecosistema: En el frente de la adopción, 2026 se tratará de convertir proyectos piloto en éxitos masivos:
    • Esperamos lanzamientos completos de juegos: Sparkball y Variance podrían pasar de beta a lanzamiento oficial en la mainnet de Somnia en 2026, con el objetivo de atraer a decenas de miles de jugadores. Otros juegos de la cohorte de Dream Catalyst (Maelstrom, Netherak, Dark Table, etc.) probablemente se lanzarán al público. El equipo de Somnia apoyará estos lanzamientos, posiblemente a través de campañas de marketing, torneos y programas de incentivos (como jugar para ganar o airdrops) para atraer a los jugadores.
    • Nuevas asociaciones: Improbable/MSquared planeaba escalar de 30 eventos en 2023 a más de 300 eventos de metaverso en 2024. En 2024 hicieron muchos eventos fuera de la cadena; en 2025/2026, esperamos que esos eventos integren Somnia. Por ejemplo, quizás un evento deportivo importante o un festival de música en 2026 use Somnia para la venta de entradas o recompensas para los fans. La participación de Google Cloud sugiere posibles eventos empresariales o exhibiciones a través de los clientes de la nube de Google. Además, dado que Mirana (asociada con Bybit/BitDAO) y otros invirtieron, Somnia podría ver colaboraciones con exchanges o grandes marcas de Web3 para utilizar la red.
    • Integración de MSquared: El comunicado de prensa de Chainwire señaló que M² planea integrar Somnia en su red de metaversos. Eso significa que cualquier mundo virtual que use la tecnología de MSquared podría adoptar Somnia como su capa de transacciones. Para 2026, podríamos ver a MSquared lanzar formalmente su red de metaverso con Somnia sustentando la identidad de los avatares, el comercio de artículos, etc. Si Otherside de Yuga Labs sigue en marcha, quizás ocurra una demostración de interoperabilidad con Somnia (por ejemplo, usar tu NFT de Otherside en un mundo impulsado por Somnia).
    • Expansión de la Comunidad de Desarrolladores: Los 10 millones de dólares en subvenciones se distribuirán con el tiempo; para 2026, es probable que docenas de proyectos hayan recibido financiación. El resultado de eso podría ser más herramientas (digamos, un SDK de Unity para Somnia, o más mejoras en Ormi), más aplicaciones (quizás alguien construya un Twitter descentralizado basado en Somnia o una nueva plataforma DeFi). Somnia probablemente celebrará más hackathons (potencialmente algunos en persona en conferencias, etc.) y continuará con un devrel agresivo para atraer talento. Podrían dirigirse especialmente a los desarrolladores de Ethereum que están alcanzando los límites de escalado con sus dApps, ofreciéndoles un puerto fácil a Somnia.
    • Interoperabilidad y Puentes: Ya integrada con LayerZero, Somnia probablemente expandirá los puentes a otros ecosistemas para un soporte de activos más amplio. Por ejemplo, la integración con Polygon o Cosmos IBC podría estar sobre la mesa. Además, se podrían buscar estándares entre cadenas para NFTs (quizás permitiendo que los NFTs de Ethereum se reflejen en Somnia para su uso en juegos). Dado que Somnia es EVM, desplegar contratos de puente para tokens populares (USDC, USDT, WETH) es sencillo; 2026 podría ver una liquidez más profunda a medida que más de estos activos entre cadenas fluyan.
    • Monitoreo del Rendimiento: A medida que llegue más uso real, el equipo monitoreará cualquier problema de estabilidad. ¿Hay algún vector de ataque (spam en muchas cadenas de datos, etc.)? Podrían implementar refinamientos como límites de tasa por cadena de datos u optimizaciones adicionales si es necesario. La ejecución dual de Cuthbert probablemente se ejecutará al menos hasta 2026 para detectar cualquier divergencia; si el sistema demuestra ser muy estable, podrían considerar apagarlo para reducir la sobrecarga después de un año o dos, pero eso depende de la confianza total.
  • Marketing y Divulgación: Con la mainnet y las aplicaciones iniciales en vivo, el desafío de Somnia para 2026 es construir una base de usuarios. Se espera un marketing intenso dirigido tanto a jugadores como a usuarios de cripto:
    • Podríamos ver asociaciones con gremios de juegos o equipos de esports, para atraer jugadores a los juegos de Somnia.
    • Quizás colaboraciones con celebridades para eventos virtuales (dado que hicieron K-Pop y leyendas del deporte en eventos de prueba, podrían escalar eso; imagina a un músico famoso lanzando un álbum a través de un espectáculo en el metaverso de Somnia con merchandising NFT).
    • Además, asistir y patrocinar conferencias importantes (GDC para desarrolladores de juegos, Consensus para cripto, etc.) para promover la plataforma.
    • A finales de 2025, ya tenían una prensa significativa (artículo de Binance Academy, cobertura de CoinDesk, etc.). En 2026, saldrán más análisis independientes (perfiles de Messari, etc.), y Somnia querrá mostrar métricas de uso para demostrar tracción (como "X usuarios activos diarios, Y transacciones procesadas").

Visión a Largo Plazo: Aunque no se preguntó explícitamente, vale la pena señalar la trayectoria de Somnia:

  • En unos pocos años, imaginan a Somnia como una capa base ampliamente utilizada para el entretenimiento Web3, con miles de millones de transacciones como rutina, y una gobernanza descentralizada dirigida por su comunidad y consejos. También es probable que prevean una mejora técnica continua: por ejemplo, explorar el sharding si es necesario, o adoptar nueva criptografía (quizás pruebas zk para comprimir datos aún más, o criptografía post-cuántica eventualmente).
  • Otro objetivo a largo plazo podría ser la neutralidad de carbono o la eficiencia: las cadenas de alto TPS a menudo se preocupan por el uso de energía. Si Somnia alcanza millones de TPS, será importante asegurar que los nodos puedan manejarlo de manera eficiente (quizás a través de aceleración de hardware o escalado en la nube). Con Google Cloud en la mezcla, quizás se podrían considerar iniciativas de centros de datos verdes o hardware especial (como GPUs o FPGAs para la compresión).
  • Para entonces, la competencia también habrá aumentado (Ethereum 2.0 con sharding, zkEVMs, mejoras de Solana, etc.). Somnia tendrá que mantener su ventaja a través de la innovación y los efectos de red (si captura una gran base de jugadores temprano, ese impulso puede llevarla adelante).

En resumen, la hoja de ruta para los próximos 1-2 años se centra en:

  1. Activar características clave del protocolo (descuentos de gas, almacenamiento transitorio) para ofrecer completamente la funcionalidad prometida.
  2. Descentralizar la gobernanza gradualmente, pasando de ser dirigida por la fundación a ser dirigida por la comunidad sin poner en peligro el progreso.
  3. Impulsar el crecimiento del ecosistema: asegurar que los proyectos financiados se lancen y atraigan usuarios, forjar nuevas asociaciones (con creadores de contenido, estudios de juegos, quizás incluso empresas Web2 interesadas en Web3), y posiblemente expandirse a más regiones y comunidades.
  4. Mantener el rendimiento y la seguridad a medida que el uso escala: vigilar cualquier problema cuando, por ejemplo, un juego impulse un pico de 10k TPS de tráfico real, y responder en consecuencia (esto podría incluir la ejecución de más eventos de prueba públicos, quizás un evento de "prueba de estrés de la Mainnet" donde se alienten toneladas de transacciones para probar los límites).

Somnia ha hecho un debut espectacular, pero 2026 será el campo de pruebas: necesita convertir su impresionante tecnología y su ecosistema bien financiado en una adopción real y una red sostenible y descentralizada. La gran tesorería de tokens de la fundación (Ecosistema y Comunidad ~55 % del suministro) le da los medios para impulsar la actividad durante años, por lo que a corto plazo veremos esos tokens en uso, a través de airdrops, recompensas (posiblemente minería de liquidez si se lanza un DEX), recompensas para desarrolladores y campañas de adquisición de usuarios. El eslogan del lanzamiento de la mainnet de Improbable fue que Somnia "marca la fundación de una economía de activos digitales abierta, donde miles de millones de personas pueden interactuar a través de experiencias inmersivas". Los siguientes pasos en la hoja de ruta consisten en sentar las bases de esa fundación: conseguir que los primeros millones de personas y las primeras aplicaciones estrella interactúen con la "computadora de los sueños" de Somnia (como la apodan), y así validar que la Web3 puede, de hecho, operar a escala de internet.

Si Somnia continúa en su trayectoria actual, para finales de 2026 podríamos ver docenas de juegos y plataformas sociales completamente en la cadena en funcionamiento, una red floreciente dirigida por la comunidad con cientos de validadores, y a SOMI siendo utilizado diariamente por usuarios convencionales (a menudo sin saberlo, bajo el capó de los juegos). Lograr eso marcaría un hito significativo no solo para Somnia, sino para el impulso de la industria de la blockchain hacia aplicaciones masivas y en tiempo real. Las piezas están en su lugar; ahora se trata de la ejecución y la adopción en esta fase crítica de la hoja de ruta del proyecto, impulsada por una profunda investigación.

Fuentes:

  • Somnia Official Documentation (Litepaper & Technical Concepts)
  • Somnia Tokenomics and Governance Docs
  • Improbable Press Release (Mainnet Launch)
  • CoinDesk Coverage of Somnia Launch
  • Binance Academy – What is Somnia (SOMI)
  • Gam3s.gg – Coverage of Somnia Games (Variance, Sparkball, etc.)
  • Stakin Research – Introduction to Somnia
  • Chainwire Press Release – $270M Investment & Devnet results
  • Somnia Blog – Improbable & MSquared Events, Mainnet News
  • Official Somnia Docs – Developer Guides (bridging, wallets, etc.)

Construyendo Encriptación Descentralizada con @mysten/seal: Tutorial para Desarrolladores

· 14 min de lectura
Dora Noda
Software Engineer

La privacidad se está convirtiendo en infraestructura pública. En 2025, los desarrolladores necesitan herramientas que hagan la encriptación tan fácil como almacenar datos. Seal de Mysten Labs proporciona exactamente eso: gestión de secretos descentralizada con control de acceso onchain. Este tutorial te enseñará cómo construir aplicaciones Web3 seguras usando encriptación basada en identidad, seguridad threshold y políticas de acceso programables.


Introducción: Por Qué Seal Importa para Web3

Las aplicaciones cloud tradicionales dependen de sistemas centralizados de gestión de claves donde un solo proveedor controla el acceso a datos encriptados. Aunque esto es conveniente, crea peligrosos puntos únicos de falla. Si el proveedor se ve comprometido, se desconecta o decide restringir el acceso, tus datos se vuelven inaccesibles o vulnerables.

Seal cambia completamente este paradigma. Construido por Mysten Labs para la blockchain Sui, Seal es un servicio de gestión de secretos descentralizada (DSM) que permite:

  • Encriptación basada en identidad donde el contenido se protege antes de salir de tu entorno
  • Encriptación threshold que distribuye el acceso a claves entre múltiples nodos independientes
  • Control de acceso onchain con bloqueos temporales, token-gating y lógica de autorización personalizada
  • Diseño agnóstico de almacenamiento que funciona con Walrus, IPFS o cualquier solución de almacenamiento

Ya sea que estés construyendo aplicaciones de mensajería segura, plataformas de contenido con acceso restringido o transferencias de activos con bloqueo temporal, Seal proporciona las primitivas criptográficas y la infraestructura de control de acceso que necesitas.


Primeros Pasos

Prerrequisitos

Antes de comenzar, asegúrate de tener:

  • Node.js 18+ instalado
  • Familiaridad básica con TypeScript/JavaScript
  • Una wallet de Sui para pruebas (como Sui Wallet)
  • Comprensión de conceptos blockchain

Instalación

Instala el SDK de Seal vía npm:

npm install @mysten/seal

También querrás el SDK de Sui para interacciones blockchain:

npm install @mysten/sui

Configuración del Proyecto

Crea un nuevo proyecto e inicialízalo:

mkdir seal-tutorial
cd seal-tutorial
npm init -y
npm install @mysten/seal @mysten/sui typescript @types/node

Crea una configuración simple de TypeScript:

// tsconfig.json
{
"compilerOptions": {
"target": "ES2020",
"module": "commonjs",
"strict": true,
"esModuleInterop": true,
"skipLibCheck": true,
"forceConsistentCasingInFileNames": true
}
}

Conceptos Fundamentales: Cómo Funciona Seal

Antes de escribir código, entendamos la arquitectura de Seal:

1. Encriptación Basada en Identidad (IBE)

A diferencia de la encriptación tradicional donde encriptas a una clave pública, IBE te permite encriptar a una identidad (como una dirección de email o dirección Sui). El destinatario solo puede desencriptar si puede probar que controla esa identidad.

2. Encriptación Threshold

En lugar de confiar en un solo servidor de claves, Seal usa esquemas threshold t-de-n. Podrías configurar 3-de-5 servidores de claves, significando que cualquier 3 servidores pueden cooperar para proporcionar claves de desencriptación, pero 2 o menos no pueden.

3. Control de Acceso Onchain

Las políticas de acceso son aplicadas por smart contracts de Sui. Antes de que un servidor de claves proporcione claves de desencriptación, verifica que el solicitante cumpla con los requisitos de política onchain (propiedad de tokens, restricciones temporales, etc.).

4. Red de Servidores de Claves

Los servidores de claves distribuidos validan políticas de acceso y generan claves de desencriptación. Estos servidores son operados por diferentes partes para asegurar que no haya un punto único de control.


Implementación Básica: Tu Primera Aplicación Seal

Construyamos una aplicación simple que encripte datos sensibles y controle el acceso a través de políticas blockchain de Sui.

Paso 1: Inicializar el Cliente Seal

// src/seal-client.ts
import { SealClient } from '@mysten/seal';
import { SuiClient } from '@mysten/sui/client';

export async function createSealClient() {
// Inicializar cliente Sui para testnet
const suiClient = new SuiClient({
url: 'https://fullnode.testnet.sui.io'
});

// Configurar cliente Seal con servidores de claves de testnet
const sealClient = new SealClient({
suiClient,
keyServers: [
'https://keyserver1.seal-testnet.com',
'https://keyserver2.seal-testnet.com',
'https://keyserver3.seal-testnet.com'
],
threshold: 2, // threshold 2-de-3
network: 'testnet'
});

return { sealClient, suiClient };
}

Paso 2: Encriptación/Desencriptación Simple

// src/basic-encryption.ts
import { createSealClient } from './seal-client';

async function basicExample() {
const { sealClient } = await createSealClient();

// Datos a encriptar
const sensitiveData = "¡Este es mi mensaje secreto!";
const recipientAddress = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

try {
// Encriptar datos para una dirección Sui específica
const encryptedData = await sealClient.encrypt({
data: Buffer.from(sensitiveData, 'utf-8'),
recipientId: recipientAddress,
// Opcional: agregar metadata
metadata: {
contentType: 'text/plain',
timestamp: Date.now()
}
});

console.log('Datos encriptados:', {
ciphertext: encryptedData.ciphertext.toString('base64'),
encryptionId: encryptedData.encryptionId
});

// Más tarde, desencriptar los datos (requiere autorización apropiada)
const decryptedData = await sealClient.decrypt({
ciphertext: encryptedData.ciphertext,
encryptionId: encryptedData.encryptionId,
recipientId: recipientAddress
});

console.log('Datos desencriptados:', decryptedData.toString('utf-8'));

} catch (error) {
console.error('Encriptación/desencriptación falló:', error);
}
}

basicExample();

Control de Acceso con Smart Contracts de Sui

El verdadero poder de Seal viene del control de acceso programable. Creemos un ejemplo de encriptación con bloqueo temporal donde los datos solo pueden ser desencriptados después de un tiempo específico.

Paso 1: Desplegar Contrato de Control de Acceso

Primero, necesitamos un smart contract Move que defina nuestra política de acceso:

// contracts/time_lock.move
module time_lock::policy {
use sui::clock::{Self, Clock};
use sui::object::{Self, UID};
use sui::tx_context::{Self, TxContext};

public struct TimeLockPolicy has key, store {
id: UID,
unlock_time: u64,
authorized_user: address,
}

public fun create_time_lock(
unlock_time: u64,
authorized_user: address,
ctx: &mut TxContext
): TimeLockPolicy {
TimeLockPolicy {
id: object::new(ctx),
unlock_time,
authorized_user,
}
}

public fun can_decrypt(
policy: &TimeLockPolicy,
user: address,
clock: &Clock
): bool {
let current_time = clock::timestamp_ms(clock);
policy.authorized_user == user && current_time >= policy.unlock_time
}
}

Paso 2: Integrar con Seal

// src/time-locked-encryption.ts
import { createSealClient } from './seal-client';
import { TransactionBlock } from '@mysten/sui/transactions';

async function createTimeLocked() {
const { sealClient, suiClient } = await createSealClient();

// Crear política de acceso en Sui
const txb = new TransactionBlock();

const unlockTime = Date.now() + 60000; // Desbloquear en 1 minuto
const authorizedUser = "0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8";

txb.moveCall({
target: 'time_lock::policy::create_time_lock',
arguments: [
txb.pure(unlockTime),
txb.pure(authorizedUser)
]
});

// Ejecutar transacción para crear política
const result = await suiClient.signAndExecuteTransactionBlock({
transactionBlock: txb,
signer: yourKeypair, // Tu keypair de Sui
});

const policyId = result.objectChanges?.find(
change => change.type === 'created'
)?.objectId;

// Ahora encriptar con esta política
const sensitiveData = "¡Esto se desbloqueará en 1 minuto!";

const encryptedData = await sealClient.encrypt({
data: Buffer.from(sensitiveData, 'utf-8'),
recipientId: authorizedUser,
accessPolicy: {
policyId,
policyType: 'time_lock'
}
});

console.log('Datos con bloqueo temporal creados. Intenta desencriptar después de 1 minuto.');

return {
encryptedData,
policyId,
unlockTime
};
}

Ejemplos Prácticos

Ejemplo 1: Aplicación de Mensajería Segura

// src/secure-messaging.ts
import { createSealClient } from './seal-client';

class SecureMessenger {
private sealClient: any;

constructor(sealClient: any) {
this.sealClient = sealClient;
}

async sendMessage(
message: string,
recipientAddress: string,
senderKeypair: any
) {
const messageData = {
content: message,
timestamp: Date.now(),
sender: senderKeypair.toSuiAddress(),
messageId: crypto.randomUUID()
};

const encryptedMessage = await this.sealClient.encrypt({
data: Buffer.from(JSON.stringify(messageData), 'utf-8'),
recipientId: recipientAddress,
metadata: {
type: 'secure_message',
sender: senderKeypair.toSuiAddress()
}
});

// Almacenar mensaje encriptado en almacenamiento descentralizado (Walrus)
return this.storeOnWalrus(encryptedMessage);
}

async readMessage(encryptionId: string, recipientKeypair: any) {
// Recuperar del almacenamiento
const encryptedData = await this.retrieveFromWalrus(encryptionId);

// Desencriptar con Seal
const decryptedData = await this.sealClient.decrypt({
ciphertext: encryptedData.ciphertext,
encryptionId: encryptedData.encryptionId,
recipientId: recipientKeypair.toSuiAddress()
});

return JSON.parse(decryptedData.toString('utf-8'));
}

private async storeOnWalrus(data: any) {
// Integración con almacenamiento Walrus
// Esto subiría los datos encriptados a Walrus
// y devolvería el blob ID para recuperación
}

private async retrieveFromWalrus(blobId: string) {
// Recuperar datos encriptados de Walrus usando blob ID
}
}

Ejemplo 2: Plataforma de Contenido con Token-Gating

// src/gated-content.ts
import { createSealClient } from './seal-client';

class ContentGating {
private sealClient: any;
private suiClient: any;

constructor(sealClient: any, suiClient: any) {
this.sealClient = sealClient;
this.suiClient = suiClient;
}

async createGatedContent(
content: string,
requiredNftCollection: string,
creatorKeypair: any
) {
// Crear política de propiedad NFT
const accessPolicy = await this.createNftPolicy(
requiredNftCollection,
creatorKeypair
);

// Encriptar contenido con requisito de acceso NFT
const encryptedContent = await this.sealClient.encrypt({
data: Buffer.from(content, 'utf-8'),
recipientId: 'nft_holders', // Destinatario especial para holders de NFT
accessPolicy: {
policyId: accessPolicy.policyId,
policyType: 'nft_ownership'
}
});

return {
contentId: encryptedContent.encryptionId,
accessPolicy: accessPolicy.policyId
};
}

async accessGatedContent(
contentId: string,
userAddress: string,
userKeypair: any
) {
// Verificar propiedad NFT primero
const hasAccess = await this.verifyNftOwnership(
userAddress,
contentId
);

if (!hasAccess) {
throw new Error('Acceso denegado: NFT requerido no encontrado');
}

// Desencriptar contenido
const decryptedContent = await this.sealClient.decrypt({
encryptionId: contentId,
recipientId: userAddress
});

return decryptedContent.toString('utf-8');
}

private async createNftPolicy(collection: string, creator: any) {
// Crear contrato Move que verifique propiedad NFT
// Devuelve ID del objeto política
}

private async verifyNftOwnership(user: string, contentId: string) {
// Verificar si el usuario posee NFT requerido
// Consultar Sui por propiedad NFT
}
}

Ejemplo 3: Transferencia de Activos con Bloqueo Temporal

// src/time-locked-transfer.ts
import { createSealClient } from './seal-client';

async function createTimeLockTransfer(
assetData: any,
recipientAddress: string,
unlockTimestamp: number,
senderKeypair: any
) {
const { sealClient, suiClient } = await createSealClient();

// Crear política de bloqueo temporal en Sui
const timeLockPolicy = await createTimeLockPolicy(
unlockTimestamp,
recipientAddress,
senderKeypair,
suiClient
);

// Encriptar datos de transferencia de activos
const transferData = {
asset: assetData,
recipient: recipientAddress,
unlockTime: unlockTimestamp,
transferId: crypto.randomUUID()
};

const encryptedTransfer = await sealClient.encrypt({
data: Buffer.from(JSON.stringify(transferData), 'utf-8'),
recipientId: recipientAddress,
accessPolicy: {
policyId: timeLockPolicy.policyId,
policyType: 'time_lock'
}
});

console.log(`Activo bloqueado hasta ${new Date(unlockTimestamp)}`);

return {
transferId: encryptedTransfer.encryptionId,
unlockTime: unlockTimestamp,
policyId: timeLockPolicy.policyId
};
}

async function claimTimeLockTransfer(
transferId: string,
recipientKeypair: any
) {
const { sealClient } = await createSealClient();

try {
const decryptedData = await sealClient.decrypt({
encryptionId: transferId,
recipientId: recipientKeypair.toSuiAddress()
});

const transferData = JSON.parse(decryptedData.toString('utf-8'));

// Procesar la transferencia de activos
console.log('Transferencia de activos desbloqueada:', transferData);

return transferData;
} catch (error) {
console.error('Transferencia aún no desbloqueada o acceso denegado:', error);
throw error;
}
}

Integración con Almacenamiento Descentralizado Walrus

Seal funciona perfectamente con Walrus, la solución de almacenamiento descentralizado de Sui. Aquí te mostramos cómo integrar ambos:

// src/walrus-integration.ts
import { createSealClient } from './seal-client';

class SealWalrusIntegration {
private sealClient: any;
private walrusClient: any;

constructor(sealClient: any, walrusClient: any) {
this.sealClient = sealClient;
this.walrusClient = walrusClient;
}

async storeEncryptedData(
data: Buffer,
recipientAddress: string,
accessPolicy?: any
) {
// Encriptar con Seal
const encryptedData = await this.sealClient.encrypt({
data,
recipientId: recipientAddress,
accessPolicy
});

// Almacenar datos encriptados en Walrus
const blobId = await this.walrusClient.store(
encryptedData.ciphertext
);

// Devolver referencia que incluye info tanto de Seal como Walrus
return {
blobId,
encryptionId: encryptedData.encryptionId,
accessPolicy: encryptedData.accessPolicy
};
}

async retrieveAndDecrypt(
blobId: string,
encryptionId: string,
userKeypair: any
) {
// Recuperar de Walrus
const encryptedData = await this.walrusClient.retrieve(blobId);

// Desencriptar con Seal
const decryptedData = await this.sealClient.decrypt({
ciphertext: encryptedData,
encryptionId,
recipientId: userKeypair.toSuiAddress()
});

return decryptedData;
}
}

// Ejemplo de uso
async function walrusExample() {
const { sealClient } = await createSealClient();
const walrusClient = new WalrusClient('https://walrus-testnet.sui.io');

const integration = new SealWalrusIntegration(sealClient, walrusClient);

const fileData = Buffer.from('Contenido de documento importante');
const recipientAddress = '0x...';

// Almacenar encriptado
const result = await integration.storeEncryptedData(
fileData,
recipientAddress
);

console.log('Almacenado con Blob ID:', result.blobId);

// Más tarde, recuperar y desencriptar
const decrypted = await integration.retrieveAndDecrypt(
result.blobId,
result.encryptionId,
recipientKeypair
);

console.log('Datos recuperados:', decrypted.toString());
}

Configuración Avanzada de Encriptación Threshold

Para aplicaciones de producción, querrás configurar encriptación threshold personalizada con múltiples servidores de claves:

// src/advanced-threshold.ts
import { SealClient } from '@mysten/seal';

async function setupProductionSeal() {
// Configurar con múltiples servidores de claves independientes
const keyServers = [
'https://keyserver-1.your-org.com',
'https://keyserver-2.partner-org.com',
'https://keyserver-3.third-party.com',
'https://keyserver-4.backup-provider.com',
'https://keyserver-5.fallback.com'
];

const sealClient = new SealClient({
keyServers,
threshold: 3, // threshold 3-de-5
network: 'mainnet',
// Opciones avanzadas
retryAttempts: 3,
timeoutMs: 10000,
backupKeyServers: [
'https://backup-1.emergency.com',
'https://backup-2.emergency.com'
]
});

return sealClient;
}

async function robustEncryption() {
const sealClient = await setupProductionSeal();

const criticalData = "Datos encriptados de misión crítica";

// Encriptar con garantías de alta seguridad
const encrypted = await sealClient.encrypt({
data: Buffer.from(criticalData, 'utf-8'),
recipientId: '0x...',
// Requerir todos los 5 servidores para máxima seguridad
customThreshold: 5,
// Agregar redundancia
redundancy: 2,
accessPolicy: {
// Requisitos multi-factor
requirements: ['nft_ownership', 'time_lock', 'multisig_approval']
}
});

return encrypted;
}

Mejores Prácticas de Seguridad

1. Gestión de Claves

// src/security-practices.ts

// BUENO: Usar derivación segura de claves
import { generateKeypair } from '@mysten/sui/cryptography/ed25519';

const keypair = generateKeypair();

// BUENO: Almacenar claves de forma segura (ejemplo con variables de entorno)
const keypair = Ed25519Keypair.fromSecretKey(
process.env.PRIVATE_KEY
);

// MALO: Nunca hardcodear claves
const badKeypair = Ed25519Keypair.fromSecretKey(
"hardcoded-secret-key-12345" // ¡No hagas esto!
);

2. Validación de Políticas de Acceso

// Siempre validar políticas de acceso antes de encriptar
async function secureEncrypt(data: Buffer, recipient: string) {
const { sealClient } = await createSealClient();

// Validar dirección del destinatario
if (!isValidSuiAddress(recipient)) {
throw new Error('Dirección de destinatario inválida');
}

// Verificar que la política existe y es válida
const policy = await validateAccessPolicy(policyId);
if (!policy.isValid) {
throw new Error('Política de acceso inválida');
}

return sealClient.encrypt({
data,
recipientId: recipient,
accessPolicy: policy
});
}

3. Manejo de Errores y Respaldos

// Manejo robusto de errores
async function resilientDecrypt(encryptionId: string, userKeypair: any) {
const { sealClient } = await createSealClient();

try {
return await sealClient.decrypt({
encryptionId,
recipientId: userKeypair.toSuiAddress()
});
} catch (error) {
if (error.code === 'ACCESS_DENIED') {
throw new Error('Acceso denegado: Verifica tus permisos');
} else if (error.code === 'KEY_SERVER_UNAVAILABLE') {
// Intentar con configuración de respaldo
return await retryWithBackupServers(encryptionId, userKeypair);
} else if (error.code === 'THRESHOLD_NOT_MET') {
throw new Error('Servidores de claves insuficientes disponibles');
} else {
throw new Error(`Desencriptación falló: ${error.message}`);
}
}
}

4. Validación de Datos

// Validar datos antes de encriptar
function validateDataForEncryption(data: Buffer): boolean {
// Verificar límites de tamaño
if (data.length > 1024 * 1024) { // límite de 1MB
throw new Error('Datos demasiado grandes para encriptar');
}

// Verificar patrones sensibles (opcional)
const dataStr = data.toString();
if (containsSensitivePatterns(dataStr)) {
console.warn('Advertencia: Los datos contienen patrones potencialmente sensibles');
}

return true;
}

Optimización de Rendimiento

1. Operaciones en Lotes

// Procesar múltiples encriptaciones por lotes para eficiencia
async function batchEncrypt(dataItems: Buffer[], recipients: string[]) {
const { sealClient } = await createSealClient();

const promises = dataItems.map((data, index) =>
sealClient.encrypt({
data,
recipientId: recipients[index]
})
);

return Promise.all(promises);
}

2. Caché de Respuestas de Servidores de Claves

// Cachear sesiones de servidores de claves para reducir latencia
class OptimizedSealClient {
private sessionCache = new Map();

async encryptWithCaching(data: Buffer, recipient: string) {
let session = this.sessionCache.get(recipient);

if (!session || this.isSessionExpired(session)) {
session = await this.createNewSession(recipient);
this.sessionCache.set(recipient, session);
}

return this.encryptWithSession(data, session);
}
}

Probando tu Integración Seal

Pruebas Unitarias

// tests/seal-integration.test.ts
import { describe, it, expect } from 'jest';
import { createSealClient } from '../src/seal-client';

describe('Integración Seal', () => {
it('debería encriptar y desencriptar datos exitosamente', async () => {
const { sealClient } = await createSealClient();
const testData = Buffer.from('mensaje de prueba');
const recipient = '0x742d35cc6d4c0c08c0f9bf3c9b2b6c64b3b4f5c6d7e8f9a0b1c2d3e4f5a6b7c8';

const encrypted = await sealClient.encrypt({
data: testData,
recipientId: recipient
});

expect(encrypted.encryptionId).toBeDefined();
expect(encrypted.ciphertext).toBeDefined();

const decrypted = await sealClient.decrypt({
ciphertext: encrypted.ciphertext,
encryptionId: encrypted.encryptionId,
recipientId: recipient
});

expect(decrypted.toString()).toBe('mensaje de prueba');
});

it('debería aplicar políticas de control de acceso', async () => {
// Probar que usuarios no autorizados no pueden desencriptar
const { sealClient } = await createSealClient();

const encrypted = await sealClient.encrypt({
data: Buffer.from('secreto'),
recipientId: 'authorized-user'
});

await expect(
sealClient.decrypt({
ciphertext: encrypted.ciphertext,
encryptionId: encrypted.encryptionId,
recipientId: 'unauthorized-user'
})
).rejects.toThrow('Acceso denegado');
});
});

Despliegue a Producción

Configuración de Entorno

// config/production.ts
export const productionConfig = {
keyServers: [
process.env.KEY_SERVER_1,
process.env.KEY_SERVER_2,
process.env.KEY_SERVER_3,
process.env.KEY_SERVER_4,
process.env.KEY_SERVER_5
],
threshold: 3,
network: 'mainnet',
suiRpc: process.env.SUI_RPC_URL,
walrusGateway: process.env.WALRUS_GATEWAY,
// Configuraciones de seguridad
maxDataSize: 1024 * 1024, // 1MB
sessionTimeout: 3600000, // 1 hora
retryAttempts: 3
};

Monitoreo y Logging

// utils/monitoring.ts
export class SealMonitoring {
static logEncryption(encryptionId: string, recipient: string) {
console.log(`[SEAL] Datos encriptados ${encryptionId} para ${recipient}`);
// Enviar a tu servicio de monitoreo
}

static logDecryption(encryptionId: string, success: boolean) {
console.log(`[SEAL] Desencriptación ${encryptionId}: ${success ? 'ÉXITO' : 'FALLÓ'}`);
}

static logKeyServerHealth(serverUrl: string, status: string) {
console.log(`[SEAL] Servidor de claves ${serverUrl}: ${status}`);
}
}

Recursos y Próximos Pasos

Documentación Oficial

Comunidad y Soporte

  • Discord de Sui: Únete al canal #seal para soporte comunitario
  • GitHub Issues: Reporta bugs y solicita funcionalidades
  • Foros de Desarrolladores: Foros comunitarios de Sui para discusiones

Temas Avanzados para Explorar

  1. Políticas de Acceso Personalizadas: Construir lógica de autorización compleja con contratos Move
  2. Integración Cross-Chain: Usar Seal con otras redes blockchain
  3. Gestión de Claves Empresarial: Configurar tu propia infraestructura de servidores de claves
  4. Auditoría y Cumplimiento: Implementar logging y monitoreo para entornos regulados

Aplicaciones de Ejemplo

  • App de Chat Seguro: Mensajería con encriptación extremo a extremo con Seal
  • Gestión de Documentos: Compartir documentos empresariales con controles de acceso
  • Gestión de Derechos Digitales: Distribución de contenido con políticas de uso
  • Análisis Preservando Privacidad: Flujos de trabajo de procesamiento de datos encriptados

Conclusión

Seal representa un cambio fundamental hacia hacer de la privacidad y la infraestructura de encriptación preocupaciones a nivel de infraestructura en Web3. Al combinar encriptación basada en identidad, seguridad threshold y control de acceso programable, proporciona a los desarrolladores herramientas poderosas para construir aplicaciones verdaderamente seguras y descentralizadas.

Las ventajas clave de construir con Seal incluyen:

  • Sin Punto Único de Falla: Los servidores de claves distribuidos eliminan autoridades centrales
  • Seguridad Programable: Las políticas de acceso basadas en smart contracts proporcionan autorización flexible
  • Amigable para Desarrolladores: El SDK TypeScript se integra perfectamente con herramientas Web3 existentes
  • Agnóstico de Almacenamiento: Funciona con Walrus, IPFS o cualquier solución de almacenamiento
  • Listo para Producción: Construido por Mysten Labs con estándares de seguridad empresarial

Ya sea que estés asegurando datos de usuarios, implementando modelos de suscripción o construyendo aplicaciones complejas multi-party, Seal proporciona las primitivas criptográficas y la infraestructura de control de acceso que necesitas para construir con confianza.

Comienza a construir hoy y únete al creciente ecosistema de desarrolladores haciendo de la privacidad una parte fundamental de la infraestructura pública.


¿Listo para empezar a construir? Instala @mysten/seal y comienza a experimentar con los ejemplos de este tutorial. La web descentralizada está esperando aplicaciones que pongan la privacidad y seguridad primero.

BASS 2025: Trazando el Futuro de las Aplicaciones Blockchain, del Espacio a Wall Street

· 9 min de lectura
Dora Noda
Software Engineer

La Cumbre de Aplicaciones Blockchain de Stanford (BASS) dio inicio a la semana de la Conferencia Ciencia de Blockchain (SBC), reuniendo a innovadores, investigadores y constructores para explorar la vanguardia del ecosistema. Los organizadores Gil, Kung y Stephen dieron la bienvenida a los asistentes, resaltando el enfoque del evento en el emprendimiento y las aplicaciones del mundo real, un espíritu nacido de su estrecha colaboración con SBC. Con el apoyo de organizaciones como Blockchain Builders y el Alumni de Criptografía y Blockchain de Stanford, el día estuvo repleto de inmersiones profundas en blockchains celestiales, el futuro de Ethereum, DeFi institucional y la creciente intersección de IA y cripto.

Dalia Maliki: Construyendo una Raíz Orbital de Confianza con Computadora Espacial

Dalia Maliki, profesora en UC Santa Barbara y asesora de Space Computer, abrió con una mirada a una aplicación verdaderamente fuera de este mundo: construir una plataforma de cómputo segura en órbita.

¿Qué es Space Computer?
En pocas palabras, Space Computer es una “raíz orbital de confianza”, que brinda una plataforma para ejecutar cálculos seguros y confidenciales en satélites. La propuesta de valor central radica en las garantías de seguridad únicas del espacio. “Una vez que una caja se lanza de forma segura y se despliega en el espacio, nadie puede venir después y hackearla”, explicó Maliki. “Es puramente, perfectamente a prueba de manipulaciones en este punto”. Este entorno la hace a prueba de fugas, asegura que las comunicaciones no puedan ser interferidas fácilmente y proporciona geolocalización verificable, ofreciendo potentes propiedades de descentralización.

Arquitectura y Casos de Uso
El sistema está diseñado con una arquitectura de dos capas:

  • Capa 1 (Celestial): La raíz de confianza autoritativa funciona en una red de satélites en órbita, optimizada para comunicaciones limitadas e intermitentes.
  • Capa 2 (Terrestre): Soluciones de escalado estándar como rollups y canales de estado se ejecutan en la Tierra, anclándose a la Capa 1 celestial para obtener finalización y seguridad.

Los primeros casos de uso incluyen ejecutar validadores de blockchain altamente seguros y un generador de números aleatorios verdadero que captura radiación cósmica. Sin embargo, Maliki enfatizó el potencial de la plataforma para innovaciones imprevistas. “Lo más genial de construir una plataforma es que siempre construyes una plataforma y otras personas vienen y crean casos de uso que ni siquiera soñaste”.

Trazando un paralelismo con el ambicioso Proyecto Corona de los años 50, que dejaba caer cubos de película desde satélites espía para ser atrapados en el aire por aviones, Maliki instó a la audiencia a pensar en grande. “En comparación, lo que trabajamos hoy con la computadora espacial es un lujo, y estamos muy entusiasmados con el futuro”.

Tomasz Stanczak: La Hoja de Ruta de Ethereum – Escalado, Privacidad e IA

Tomasz Stanczak, Director Ejecutivo de la Ethereum Foundation, ofreció una visión integral de la hoja de ruta evolutiva de Ethereum, centrada fuertemente en el escalado, la mejora de la privacidad y la integración con el mundo de la IA.

Enfoque a Corto Plazo: Soporte a L2s
La prioridad inmediata para Ethereum es consolidar su papel como la mejor plataforma para que las Layer 2 construyan sobre ella. Los próximos forks, Fusaka y Glumpsterdom, están centrados en este objetivo. “Queremos hacer declaraciones mucho más fuertes de que sí, las L2 innovan, extienden Ethereum y contarán con el compromiso de los constructores de protocolo de que la Layer 1 apoyará a las L2 de la mejor manera posible”, afirmó Stanczak.

Visión a Largo Plazo: Lean Ethereum y Pruebas en Tiempo Real
Mirando más adelante, la visión de “Lean Ethereum” apunta a una escalabilidad masiva y al endurecimiento de la seguridad. Un componente clave es la hoja de ruta ZK‑EVM, que persigue pruebas en tiempo real con latencias menores a 10 segundos para el 99 % de los bloques, alcanzables por stakers solos. Esto, combinado con mejoras en la disponibilidad de datos, podría impulsar a las L2 a un teórico “10 millones de TPS”. El plan a largo plazo también incluye un enfoque en criptografía post‑cuántica mediante firmas basadas en hash y ZK‑EVMs.

Privacidad e Intersección con IA
La privacidad es otro pilar crítico. La Ethereum Foundation ha creado el equipo Privacy and Scaling Explorations (PSC) para coordinar esfuerzos, apoyar herramientas y explorar integraciones de privacidad a nivel de protocolo. Stanczak ve esto como esencial para la interacción de Ethereum con la IA, habilitando casos de uso como mercados financieros resistentes a la censura, IA que preserva la privacidad y sistemas agentes de código abierto. Subrayó que la cultura de Ethereum de conectar múltiples disciplinas —desde finanzas y arte hasta robótica e IA— es fundamental para navegar los retos y oportunidades de la próxima década.

Sreeram Kannan: El Marco de Confianza para Apps Crypto Ambiciosas con EigenCloud

Sreeram Kannan, fundador de Eigen Labs, desafió a la audiencia a pensar más allá del alcance actual de las aplicaciones crypto, presentando un marco para entender el valor central de crypto e introduciendo EigenCloud como la plataforma para materializar esta visión.

Tesis Central de Crypto: Una Capa de Verificabilidad
“Subyacente a todo esto hay una tesis central de que crypto es la capa de confianza o verificabilidad sobre la cual puedes construir aplicaciones muy poderosas”, explicó Kannan. Presentó un marco “TAM vs. Trust”, ilustrando que el mercado total direccionable (TAM) para una aplicación crypto crece exponencialmente a medida que la confianza que subyace aumenta. El mercado de Bitcoin crece al volverse más confiable que las monedas fiat; el mercado de una plataforma de préstamos crece al volverse más creíble su garantía de solvencia del prestatario.

EigenCloud: Liberando la Programabilidad
Kannan argumentó que el principal cuello de botella para construir apps más ambiciosas —como un Uber descentralizado o plataformas de IA confiables— no es el rendimiento sino la programabilidad. Para resolverlo, EigenCloud introduce una nueva arquitectura que separa la lógica de la aplicación de la lógica del token.

“Mantengamos la lógica del token on‑chain en Ethereum”, propuso, “pero la lógica de la aplicación se traslada fuera. Ahora puedes escribir tu lógica central en contenedores arbitrarios… ejecutarlos en cualquier dispositivo que elijas, sea CPU o GPU… y luego traer esos resultados de forma verificable de vuelta on‑chain”.

Este enfoque, según él, extiende crypto de una “escala de laptop o servidor a escala de nube”, permitiendo a los desarrolladores crear las aplicaciones verdaderamente disruptivas que se imaginaron en los primeros días de crypto.

Panel: Un Análisis Profundo de la Arquitectura Blockchain

Un panel con Leiyang de MegaETH, Adi de Realo y Solomon de la Solana Foundation exploró los trade‑offs entre arquitecturas monolíticas, modulares y “super modulares”.

  • MegaETH (L2 Modular): Leiyang describió el enfoque de MegaETH de usar un secuenciador centralizado para velocidad extrema mientras delega la seguridad a Ethereum. Este diseño busca ofrecer una experiencia en tiempo real al nivel de Web2 para aplicaciones, reviviendo las ambiciosas ideas de la era ICO que antes estaban limitadas por el rendimiento.
  • Solana (L1 Monolítica): Solomon explicó que la arquitectura de Solana, con sus altos requisitos de nodos, está diseñada deliberadamente para el máximo rendimiento y apoyar su visión de poner toda la actividad financiera global on‑chain. El foco actual está en emisión de activos y pagos. Sobre interoperabilidad, Solomon fue franco: “En general, no nos importa mucho la interoperabilidad… Se trata de conseguir la mayor liquidez y uso de activos on‑chain posible”.
  • Realo (L1 “Super Modular”): Adi presentó el concepto “super modular” de Realo, que consolida servicios esenciales como oráculos directamente en la capa base para reducir la fricción del desarrollador. Este diseño busca conectar nativamente la blockchain al mundo real, con un enfoque go‑to‑market en RWAs y haciendo que la blockchain sea invisible para los usuarios finales.

Panel: La Intersección Real de IA y Blockchain

Moderado por Ed Roman de HackVC, este panel mostró tres enfoques distintos para fusionar IA y crypto.

  • Ping AI (Bill): Ping AI está construyendo una “IA personal” donde los usuarios mantienen la auto‑custodia de sus datos. La visión es reemplazar el modelo tradicional de intercambio de anuncios. En lugar de que las empresas moneticen los datos de los usuarios, el sistema de Ping AI recompensará directamente a los usuarios cuando sus datos generen una conversión, permitiéndoles capturar el valor económico de su huella digital.
  • Public AI (Jordan): Descrita como la “capa humana de la IA”, Public AI es un marketplace para obtener datos de alta calidad bajo demanda que no pueden ser raspados ni generados sintéticamente. Utiliza un sistema de reputación on‑chain y mecanismos de staking para asegurar que los contribuyentes aporten señal, no ruido, recompensándolos por su trabajo en la construcción de mejores modelos de IA.
  • Gradient (Eric): Gradient está creando un runtime descentralizado para IA, habilitando inferencia y entrenamiento distribuidos en una red de hardware de consumo subutilizado. El objetivo es proporcionar un contrapeso al poder centralizador de las grandes compañías de IA al permitir que una comunidad global entrene y sirva modelos de forma colaborativa, manteniendo la “soberanía inteligente”.

Más Destacados de la Cumbre

  • Orin Katz (Starkware) presentó bloques de construcción para “privacidad on‑chain compliant”, detallando cómo los ZK‑proofs pueden usarse para crear pools de privacidad y tokens privados (ZRC20) que incluyen mecanismos como “claves de visualización” para supervisión regulatoria.
  • Sam Green (Cambrian) ofreció una visión general del panorama “Agentic Finance”, categorizando agentes crypto en trading, provisión de liquidez, préstamos, predicción e información, y resaltó la necesidad de datos rápidos, integrales y verificables para alimentarlos.
  • Max Siegel (Privy) compartió lecciones de la incorporación de más de 75 millones de usuarios, enfatizando la necesidad de encontrarse donde están los usuarios, simplificar experiencias de producto y dejar que las necesidades del producto guíen las decisiones de infraestructura, no al revés.
  • Nil Dalal (Coinbase) introdujo el “Onchain Agentic Commerce Stack” y el estándar abierto X42, un protocolo nativo de crypto diseñado para crear una “web pagable por máquinas” donde agentes de IA puedan transaccionar sin problemas usando stablecoins para datos, APIs y servicios.
  • Gordon Liao & Austin Adams (Circle) revelaron Circle Gateway, una nueva primitiva para crear un balance USDC unificado que está abstractado por cadena. Esto permite despliegues de liquidez casi instantáneos (< 500 ms) en múltiples cadenas, mejorando drásticamente la eficiencia de capital para empresas y solucionadores.

El día concluyó con un mensaje claro: las capas fundacionales de crypto están madurando, y el foco se está desplazando decisivamente hacia la construcción de aplicaciones robustas, amigables para el usuario y económicamente sostenibles que puedan cerrar la brecha entre el mundo on‑chain y la economía global.

Guía para Desarrolladores de Stripe L1 Tempo

· 12 min de lectura
Dora Noda
Software Engineer

Introducción

Tempo de Stripe es una red blockchain Layer-1 (L1) recién lanzada con un enfoque central en procesar pagos de stablecoins de alta velocidad y bajo costo. El proyecto fue co-incubado por el gigante de pagos Stripe y la destacada firma de capital de riesgo cripto Paradigm. Desde su concepción, se ha posicionado como una blockchain "orientada a pagos", diseñada para cumplir con los exigentes requisitos de escala y rendimiento de escenarios financieros del mundo real. En 2025, Tempo entró en una fase de testnet privada, co-diseñando y validando sus características con varios socios importantes, incluyendo Visa, Deutsche Bank, Shopify y OpenAI. Para la comunidad de desarrolladores, la emergencia de Tempo presenta una nueva oportunidad—construir la próxima generación de aplicaciones de pago sobre una infraestructura subyacente optimizada para stablecoins y casos de uso comerciales. Esta guía detallará cómo los desarrolladores pueden integrarse técnicamente con Tempo, qué recursos y comunidades están disponibles, y cómo participar en este ecosistema en crecimiento.

1. Integración Técnica: Construyendo en L1 Tempo

Una filosofía de diseño central de Tempo es reducir la barrera de entrada para desarrolladores eligiendo un camino de compatibilidad total con Ethereum. Esto significa que los desarrolladores pueden construir sobre él usando herramientas maduras existentes y bases de conocimiento. La arquitectura de Tempo está basada en Reth (una implementación en Rust de un cliente Ethereum liderada por Paradigm), haciéndolo naturalmente compatible con contratos inteligentes de Ethereum y su cadena de herramientas para desarrolladores.

Aquí están sus características técnicas clave y puntos de integración:

  • EVM y Contratos Inteligentes: Tempo soporta completamente contratos inteligentes en Solidity y la Máquina Virtual de Ethereum (EVM). Los desarrolladores pueden usar marcos estándar como Hardhat, Truffle y Foundry, así como bibliotecas como ethers.js y web3.js, para escribir, probar y desplegar contratos inteligentes. Para desarrolladores Web3, esta compatibilidad sin fricciones significa que prácticamente no hay curva de aprendizaje. DApps existentes, billeteras (como MetaMask) y herramientas de desarrollo funcionan "listas para usar" en Tempo, allanando el camino para la migración fácil de aplicaciones maduras desde Ethereum.

  • Alto Rendimiento y Finalidad: Tempo ha sido profundamente optimizado para los requisitos de velocidad de escenarios de pago. Su objetivo de diseño es lograr una capacidad de procesamiento de más de 100,000 transacciones por segundo (TPS) y alcanzar finalidad determinística sub-segundo. Esto significa que una vez que una transacción es confirmada, es irreversible, eliminando el riesgo de reordenamiento de transacciones (reorgs) que puede ocurrir con confirmaciones probabilísticas tradicionales (como Proof-of-Work). Este alto rendimiento y certeza son cruciales para aplicaciones con requisitos estrictos de liquidación instantánea, como sistemas de punto de venta (POS), intercambios y micropagos.

  • Diseño Nativo para Stablecoins: A diferencia de la mayoría de cadenas públicas de propósito general, la red Tempo no depende de un token nativo volátil para pagar las tarifas de transacción (Gas). Las tarifas de transacción en su red se pueden pagar directamente usando stablecoins principales (como USDC, USDT, etc.). Para lograr esto, el protocolo integra un creador de mercado automatizado (AMM) que puede manejar automáticamente intercambios entre diferentes stablecoins en segundo plano, asegurando "neutralidad del emisor" para pagos de tarifas. Para desarrolladores y usuarios, esto mejora enormemente la experiencia, ya que los costos de transacción pueden estar establemente vinculados al valor fiat (ej. siempre alrededor de $0.001), evitando la incertidumbre causada por la volatilidad del precio del token nativo.

  • Características Orientadas a Pagos: Tempo añade varias características a nivel de protocolo adaptadas para aplicaciones financieras y de pago. Estas incluyen:

    • "Carriles de Pago": Al aislar transacciones tipo pago de otros tipos de actividad en cadena (como operaciones DeFi complejas), estos carriles aseguran baja latencia y alta prioridad para pagos.
    • Transferencias en Lote Nativas: Aprovechando tecnologías como Account Abstraction, soporta el envío eficiente de pagos a múltiples direcciones en una sola transacción, lo cual es altamente práctico para escenarios como nómina y pagos a proveedores.
    • Campos de Memo de Transacciones: Este campo es compatible con el estándar de mensajería financiera ISO 20022, permitiendo que metadatos como números de referencia de facturas o datos de cumplimiento se adjunten a transacciones en cadena, simplificando enormemente los procesos de reconciliación financiera corporativa.
    • Privacidad Opcional: El protocolo soporta características opcionales de privacidad de transacciones para cumplir con necesidades de cumplimiento empresarial para proteger información comercialmente sensible.
  • Integración vía API de Stripe: Stripe planea integrar profundamente Tempo en su suite de productos existente, ofreciendo a los desarrolladores dos rutas de integración. La primera es desarrollo directo en cadena, donde desarrolladores Web3 usan cadenas de herramientas familiares para desplegar contratos inteligentes directamente en Tempo. La segunda es integración vía APIs de alto nivel de Stripe, que abstrae completamente la complejidad de la blockchain. Por ejemplo, la plataforma Bridge de Stripe (una herramienta para flujos de stablecoin cross-chain) usará Tempo como uno de sus rieles de liquidación centrales en el futuro. Los desarrolladores solo necesitarán llamar a la familiar API REST de Stripe para iniciar un pago o transferencia, y el sistema Stripe automáticamente lo ejecutará en la red Tempo en segundo plano. Esto les permite disfrutar de las ventajas de velocidad y costo de la blockchain sin necesidad de preocuparse por detalles subyacentes como gestión de nodos o firma de claves privadas.

2. Documentación para Desarrolladores, Tutoriales y Recursos de Incorporación

A finales de 2025, Tempo aún está en una fase de testnet privada, y su documentación oficial para desarrolladores se está escribiendo activamente. Sin embargo, el sitio web oficial de Tempo ha confirmado que "documentación técnica comprensiva para desarrolladores estará disponible pronto."

Mientras tanto, los desarrolladores interesados pueden obtener información preliminar a través de los siguientes canales:

  • Sitio Web Oficial y FAQ: Visitar el sitio web oficial de Tempo y su página de Preguntas Frecuentes (FAQ) proporciona una visión general de alto nivel de su filosofía de diseño, características centrales y cómo difiere de blockchains de propósito general.
  • Solicitar Acceso a Testnet: Los desarrolladores o empresas interesados pueden enviar una solicitud a través del canal proporcionado en el sitio web de Tempo (partners@tempo.xyz) para obtener acceso a su testnet privada para exploración temprana y prototipado.

Basado en el enfoque consistente de Stripe en la experiencia del desarrollador, podemos esperar que la documentación oficial, una vez lanzada, incluya los siguientes recursos:

  • Guías de Inicio: Tutoriales detallados guiando a los desarrolladores sobre cómo configurar su entorno de desarrollo, conectarse al testnet de Tempo y desplegar su primer contrato inteligente.
  • Referencias de API y Documentación de SDK: Referencias técnicas completas para la ruta de integración de API de Stripe, así como documentación para los endpoints JSON-RPC para interactuar con el protocolo Tempo.
  • Tutoriales y Aplicaciones de Muestra: Código de muestra open-source y proyectos demostrando cómo construir aplicaciones de pago comunes en Tempo.
  • Mejores Prácticas: Consejo profesional sobre seguridad, cumplimiento, optimización de rendimiento y otras áreas.

Stripe es reconocido por su documentación de API clara y de alta calidad, y hay buenas razones para creer que la documentación de Tempo mantendrá el mismo estándar.

3. Canales de Participación de Desarrolladores y Comunidad de Stripe

Stripe tiene un ecosistema maduro y activo de comunidad de desarrolladores. Para desarrolladores que quieren mantenerse actualizados sobre Tempo y recibir soporte técnico, los siguientes canales oficiales están disponibles:

  • Discord de Desarrolladores de Stripe: Esta es una gran comunidad con más de 120,000 miembros, donde ingenieros de Stripe participan directamente respondiendo preguntas. Los últimos anuncios, discusiones técnicas y soporte comunitario para Tempo se pueden encontrar aquí.
  • Foros en Línea y Plataformas de Q&A: El equipo de Stripe monitorea activamente y responde a preguntas publicadas en Stack Overflow (usando la etiqueta stripe) y Twitter/X (@StripeDev).
  • Blog y Boletines de Stripe: Este es el canal principal para información oficial, artículos técnicos profundos y actualizaciones de productos. Hitos importantes y estudios de casos para Tempo serán publicados aquí.
  • Eventos y Webinars para Desarrolladores: Stripe regularmente aloja eventos en línea y offline. En particular, su conferencia anual de desarrolladores, Stripe Sessions, es a menudo la plataforma para anuncios importantes de productos y probablemente contará con sesiones técnicas dedicadas y talleres para Tempo en el futuro.

Al aprovechar estos canales establecidos, los desarrolladores pueden fácilmente obtener información, resolver problemas y conectarse con otros desarrolladores interesados en Tempo.

4. Oportunidades para Contribuir al Ecosistema Tempo

Mientras Tempo transiciona de un proyecto de incubación interno a una red pública abierta, los desarrolladores tienen varias maneras de participar y contribuir a su ecosistema más allá de solo construir aplicaciones:

  • Contribuciones Open Source: Tempo está basado en el cliente open-source Reth, y se espera que sus propios componentes centrales sean gradualmente open-sourced. Los desarrolladores podrán revisar el código, enviar issues, proponer mejoras e incluso contribuir código directamente para mejorar conjuntamente el rendimiento y seguridad del protocolo.
  • Participación de Validadores y Gobernanza de Red: Los nodos validadores de Tempo están actualmente operados por socios fundadores en un modelo con permisos, pero el plan a largo plazo es transicionar a un modelo sin permisos. En ese punto, cualquier desarrollador u organización técnicamente capaz puede ejecutar un nodo validador, participar en el consenso de red y ganar tarifas de transacción en forma de stablecoins mientras aseguran la red. Mientras la red se descentraliza, también se puede establecer un mecanismo de gobernanza comunitaria, permitiendo a los desarrolladores participar en decisiones de actualización del protocolo.
  • Propuestas de Mejora del Protocolo (TIPs): Los desarrolladores pueden inspirarse en el modelo de EIPs de Ethereum escribiendo y discutiendo Propuestas de Mejora de Tempo (TIPs) para sugerir nuevas características u optimizaciones a mecanismos existentes, influenciando así directamente la evolución del protocolo.
  • Participar en Hackathons y Desafíos para Desarrolladores: Tanto Stripe como Paradigm tienen una tradición de apoyar eventos para desarrolladores. Es previsible que una vez que la cadena de herramientas de desarrollador de Tempo madure, habrá tracks de hackathon dedicados o desafíos de premios para alentar a los desarrolladores a innovar sobre él.
  • Educación Comunitaria y Compartir Conocimiento: Como participantes tempranos, los desarrolladores pueden compartir sus experiencias e insights escribiendo blogs técnicos, creando tutoriales en video, respondiendo preguntas en la comunidad o hablando en conferencias técnicas, ayudando a hacer crecer toda la comunidad de desarrolladores.

El ecosistema Tempo está en sus primeras etapas de construcción, proporcionando una oportunidad valiosa para que los desarrolladores se involucren profundamente de varias maneras y den forma a su futuro.

5. Incentivos y Programas de Subvenciones para Desarrolladores

Actualmente, Stripe no ha anunciado formalmente ningún programa de subvenciones o incentivos para desarrolladores de Tempo. Al mismo tiempo, el diseño de Tempo excluye explícitamente emitir un nuevo token nativo especulativo. Sin embargo, esto no significa que el ecosistema carezca de soporte para desarrolladores. Es previsible que los incentivos futuros se enfoquen más en utilidad y construcción de ecosistema, y pueden incluir:

  • Fondo del Ecosistema: Establecido por Stripe, Paradigm o una fundación independiente para proporcionar subvenciones directas a equipos construyendo infraestructura crítica (como billeteras, exploradores, herramientas de analítica) o aplicaciones prometedoras para el ecosistema Tempo.
  • Premios de Hackathon y Recompensas: Incentivando desarrolladores a través de competiciones y publicando recompensas para tareas específicas de desarrollo, como desarrollar una biblioteca open-source para una característica particular.
  • Incentivos para Socios: Para socios empresariales que eligen integrar Tempo en su negocio, Stripe puede ofrecer incentivos comerciales como reducciones de tarifas, soporte técnico prioritario o promociones de marketing conjunto.
  • Recompensas de Validadores: Una vez que la red transicione a un modelo sin permisos, ejecutar un nodo validador y procesar transacciones proporcionará un flujo continuo de ingresos de tarifas de transacción denominadas en stablecoins.
  • Inversión Estratégica: Para startups que construyen productos o servicios destacados en Tempo, inversión estratégica o adquisición potencial de Stripe o Paradigm también es un incentivo importante.

En resumen, el modelo de incentivos de Tempo girará en torno a construir valor del mundo real en lugar de especulación de tokens.

6. Eventos, Talleres y Meetups sobre Tempo

Los desarrolladores que quieren aprender más sobre Tempo y conectarse con la comunidad pueden prestar atención a los siguientes tipos de eventos:

  • Stripe Sessions: La conferencia anual de desarrolladores de Stripe es el lugar más importante para obtener la hoja de ruta oficial y actualizaciones importantes para Tempo.
  • Paradigm Frontiers: Alojado por Paradigm para desarrolladores de tecnología cripto de vanguardia, eventos futuros probablemente incluirán sesiones técnicas profundas y desafíos de hackathon para Tempo.
  • Conferencias de la Industria Fintech y Cripto: En conferencias importantes como Money20/20 y Consensus, discusiones sobre innovación en pagos inevitablemente involucrarán Tempo, haciéndolas buenas oportunidades para entender su posicionamiento en el mercado y perspectivas de aplicación comercial.
  • Meetups Locales y Webinars en Línea: Eventos más pequeños organizados por Stripe o comunidades locales de desarrolladores a menudo proporcionan más interacción directa y experiencias de aprendizaje práctico.
  • Hackathons Globales: Grandes eventos de hackathon como ETHGlobal pueden presentar Tempo como plataforma patrocinadora en el futuro, proporcionando una oportunidad para que los desarrolladores innoven en un escenario internacional.

Conclusión

La blockchain Tempo de Stripe ofrece a los desarrolladores una intersección única, mezclando el rigor del fintech tradicional con la apertura del mundo cripto. Los desarrolladores pueden aprovechar su compatibilidad con Ethereum para comenzar rápidamente con herramientas familiares, o integrar sin problemas las poderosas características de Tempo en negocios existentes a través de las APIs de Stripe. Aunque el proyecto aún está en sus primeras etapas con mucha de la documentación y programas de soporte aún en desarrollo, el fuerte respaldo de Stripe y Paradigm señala un alto compromiso con la experiencia del desarrollador y el avance tecnológico. Al usar activamente recursos existentes, unirse a la comunidad y participar en eventos relevantes, los desarrolladores pueden aprovechar una valiosa oportunidad temprana en una red blockchain enfocada en resolver problemas de pago del mundo real.

La abstracción de cadenas es cómo las empresas finalmente usarán Web3 (sin pensar en las cadenas)

· 9 min de lectura
Dora Noda
Software Engineer

TL;DR

La abstracción intercadena convierte un laberinto de cadenas, puentes y billeteras en una experiencia de plataforma única y coherente tanto para desarrolladores como para usuarios finales. El ecosistema ha madurado silenciosamente: estándares de intención, abstracción de cuentas, movilidad nativa de stablecoins y iniciativas a nivel de red como OP Superchain y AggLayer de Polygon hacen realista un futuro de “muchas cadenas, una experiencia” en 2025. Para las empresas, la ventaja es pragmática: integraciones más simples, controles de riesgo ejecutables, operaciones determinísticas y auditoría lista para cumplimiento, sin apostar todo a una sola cadena.


El problema real que tienen las empresas (y por qué los puentes solos no lo solucionaron)

La mayoría de los equipos empresariales no quieren “elegir una cadena”. Quieren resultados: liquidar un pago, emitir un activo, cerrar una operación o actualizar un registro, de forma fiable, auditable y con un costo predecible. El problema es que la producción de Web3 hoy es irrevocablemente multichain. Cientos de rollups, appchains y L2 se han lanzado en los últimos 18 meses, cada uno con sus propias tarifas, tiempos de finalización, herramientas y supuestos de confianza.

Los enfoques tradicionales de cross‑chain resolvieron el transporte — mover tokens o mensajes de A a B — pero no la experiencia. Los equipos siguen obligados a gestionar billeteras por red, provisionar gas por cadena, elegir un puente por ruta y asumir diferencias de seguridad que no pueden cuantificar fácilmente. Esa fricción es el verdadero impuesto a la adopción.

La abstracción intercadena elimina ese impuesto al ocultar la selección de cadena y el transporte detrás de APIs declarativas, experiencias impulsadas por intención y una identidad y gas unificados. En otras palabras, usuarios y aplicaciones expresan qué quieren; la plataforma determina cómo y dónde ocurre, de forma segura. La abstracción de cadenas hace que la tecnología blockchain sea invisible para los usuarios finales mientras preserva sus beneficios esenciales.

Por qué 2025 es diferente: los bloques de construcción finalmente encajan

La visión de un mundo multichain sin fricciones no es nueva, pero la tecnología subyacente está lista para producción. Varios componentes clave han madurado y convergido, haciendo posible una abstracción de cadenas robusta.

  • Unificación a nivel de red: Los proyectos están construyendo marcos que hacen que cadenas separadas se sientan como una única red unificada. OP Superchain busca estandarizar L2 basados en OP‑Stack con herramientas y capas de comunicación compartidas. AggLayer de Polygon agrega muchas cadenas aseguradas con ZK mediante “pruebas pesimistas” para la contabilidad a nivel de cadena, evitando que los problemas de una cadena contaminen a las demás. Mientras tanto, IBC v2 está expandiendo la interoperabilidad estandarizada más allá del ecosistema Cosmos, impulsando “IBC en todas partes”.

  • Rieles de interoperabilidad maduros: El middleware para la comunicación intercadena está ahora probado en batalla y ampliamente disponible. Chainlink CCIP ofrece transferencia de tokens y datos de nivel empresarial a través de un número creciente de cadenas. LayerZero v2 proporciona mensajería omnichain y tokens OFT estandarizados con suministro unificado. Axelar entrega General Message Passing (GMP) para llamadas de contrato complejas entre ecosistemas, conectando cadenas EVM y Cosmos. Plataformas como Hyperlane permiten despliegues sin permisos, facilitando que nuevas cadenas se unan a la red sin gatekeepers, mientras que Wormhole ofrece una capa de mensajería general usada en más de 40 cadenas.

  • Intención y abstracción de cuentas: La experiencia de usuario ha sido transformada por dos estándares críticos. ERC‑7683 estandariza intenciones intercadena, permitiendo que las apps declaren metas y que una red de solucionadores compartida las ejecute eficientemente en distintas cadenas. Simultáneamente, las cuentas inteligentes EIP‑4337, combinadas con Paymasters, habilitan abstracción de gas. Esto permite que una aplicación patrocine las tarifas de transacción o que los usuarios paguen con stablecoins, esencial para flujos que atraviesen múltiples redes.

  • Movilidad nativa de stablecoins: El Cross‑Chain Transfer Protocol (CCTP) de Circle mueve USDC nativo entre cadenas mediante un proceso seguro de quemado‑y‑mint, reduciendo el riesgo de activos envueltos y unificando liquidez. La última versión, CCTP v2, reduce aún más la latencia y simplifica los flujos de trabajo de los desarrolladores, haciendo que la liquidación con stablecoins sea una parte fluida de la experiencia abstracta.

Cómo se ve la “abstracción intercadena” en una arquitectura empresarial

Piénsalo como una capacidad en capas que puedes añadir a sistemas existentes. El objetivo es disponer de un único endpoint para expresar una intención y de un plano de políticas único que gobierne su ejecución a través de cualquier número de cadenas.

  1. Identidad y política unificadas: En la capa superior están las cuentas inteligentes (EIP‑4337) con controles de acceso basados en roles, recuperación social y opciones modernas de custodia como passkeys o MPC. Todo ello es gobernado por un motor de políticas central que define quién puede hacer qué, dónde, usando listas de permitidos y denegados para cadenas, activos y puentes específicos.

  2. Abstracción de gas y tarifas: Los Paymasters eliminan el dolor de “necesito gas nativo en la cadena X”. Los usuarios o servicios pueden pagar tarifas en stablecoins, o la aplicación puede patrocinarlas completamente, bajo políticas y presupuestos predefinidos.

  3. Ejecución impulsada por intención: Los usuarios expresan resultados, no transacciones. Por ejemplo, “intercambiar USDC por wETH y entregarlo a la billetera de nuestro proveedor en la cadena Y antes de las 17:00”. El estándar ERC‑7683 define el formato de estas órdenes, permitiendo que redes de solucionadores compitan para ejecutarlas de forma segura y económica.

  4. Liquidación y mensajería programables: Bajo el capó, el sistema usa una API consistente para seleccionar el riel adecuado para cada ruta. Puede usar CCIP para una transferencia de token donde el soporte empresarial es clave, Axelar GMP para una llamada de contrato inter‑ecosistema, o IBC donde la seguridad de light‑client nativo se alinea con el modelo de riesgo.

  5. Observabilidad y cumplimiento por defecto: Todo el flujo es trazable, desde la intención inicial hasta la liquidación final. Esto genera auditorías claras y permite exportar datos a SIEMs existentes. Los marcos de riesgo pueden programarse para aplicar listas de permitidos o activar frenos de emergencia, por ejemplo pausando rutas si la postura de seguridad de un puente se degrada.

Arquitectura de referencia

De arriba a abajo, un sistema con abstracción de cadenas se compone de capas bien definidas:

  • Capa de experiencia: Interfaces de aplicación que recogen intenciones de usuario y ocultan completamente los detalles de cadena, combinadas con flujos de billetera de cuenta inteligente al estilo SSO.
  • Plano de control: Motor de políticas para gestionar permisos, cuotas y presupuestos. Este plano se integra con KMS/HSM y mantiene listas de permitidos para cadenas, activos y puentes. También ingiere feeds de riesgo para cortar automáticamente rutas vulnerables.
  • Capa de ejecución: Enrutador de intenciones que selecciona el mejor riel de interoperabilidad (CCIP, LayerZero, Axelar, etc.) según política, precio y requisitos de latencia. Un Paymaster gestiona tarifas, extrayendo de un tesoro de gas agrupado y presupuestos en stablecoins.
  • Liquidación y estado: Contratos canónicos on‑chain para funciones centrales como custodia y emisión. Un indexador unificado rastrea eventos y pruebas intercadena, exportando datos a un data‑warehouse o SIEM para análisis y cumplimiento.

Construir vs. comprar: cómo evaluar proveedores de abstracción de cadenas

Al seleccionar un socio que ofrezca capacidades de abstracción de cadenas, las empresas deben formular varias preguntas clave:

  • Seguridad y modelo de confianza: ¿Cuáles son los supuestos de verificación subyacentes? ¿El sistema depende de oráculos, conjuntos de guardianes, light‑clients o redes de validadores? ¿Qué puede ser sancionado o vetado?
  • Cobertura y neutralidad: ¿Qué cadenas y activos están soportados hoy? ¿Con qué rapidez pueden añadirse nuevos? ¿El proceso es sin permisos o está controlado por el proveedor?
  • Alineación con estándares: ¿La plataforma soporta estándares clave como ERC‑7683, EIP‑4337, OFT, IBC y CCIP?
  • Operaciones: ¿Cuáles son los SLA del proveedor? ¿Qué tan transparentes son respecto a incidentes? ¿Ofrecen pruebas reproducibles, reintentos determinísticos y registros de auditoría estructurados?
  • Gobernanza y portabilidad: ¿Puedes cambiar de riel de interoperabilidad por ruta sin reescribir tu aplicación? Las abstracciones neutrales al proveedor son críticas para la flexibilidad a largo plazo.
  • Cumplimiento: ¿Qué controles existen para retención y residencia de datos? ¿Cuál es su postura SOC2/ISO? ¿Puedes llevar tu propio KMS/HSM?

Despliegue empresarial pragmático de 90 días

  • Días 0‑15: Línea base y política: Inventariar todas las cadenas, activos, puentes y billeteras en uso. Definir una lista de permitidos inicial y establecer reglas de corte basadas en un marco de riesgo claro.
  • Días 16‑45: Prototipo: Convertir un flujo de usuario único, como un pago intercadena, a un flujo basado en intención con abstracción de cuenta y un Paymaster. Medir el impacto en abandono de usuarios, latencia y carga de soporte.
  • Días 46‑75: Expandir rieles: Añadir un segundo riel de interoperabilidad al sistema y enrutar transacciones dinámicamente según política. Integrar CCTP para movilidad nativa de USDC si los stablecoins forman parte del flujo.
  • Días 76‑90: Endurecer: Conectar los datos de observabilidad de la plataforma a tu SIEM, ejecutar pruebas de caos en fallos de ruta y documentar todos los procedimientos operativos, incluidos los protocolos de pausa de emergencia.

Errores comunes (y cómo evitarlos)

  • Rutar solo por “precio del gas”: La latencia, la finalización y los supuestos de seguridad importan tanto como las tarifas. El precio solo no constituye un modelo de riesgo completo.
  • Ignorar el gas: Si tu experiencia toca múltiples cadenas, la abstracción de gas no es opcional; es un requisito básico para un producto usable.
  • Tratar los puentes como intercambiables: No lo son. Sus supuestos de seguridad difieren significativamente. Codifica listas de permitidos e implementa cortacircuitos para gestionar este riesgo.
  • Proliferación de activos envueltos: Siempre que sea posible, prefiere la movilidad nativa de activos (como USDC vía CCTP) para minimizar la fragmentación de liquidez y reducir el riesgo de contrapartida.

Beneficios empresariales

Cuando la abstracción de cadenas se implementa correctamente, blockchain deja de ser una colección de redes idiosincráticas y se convierte en una tela de ejecución que tus equipos pueden programar. Ofrece políticas, SLA y trazas de auditoría que coinciden con los estándares bajo los que ya operas. Gracias a los estándares de intención maduros, la abstracción de cuentas, rieles de interoperabilidad robustos y el transporte nativo de stablecoins, finalmente puedes entregar resultados de Web3 sin obligar a usuarios —ni a tus propios desarrolladores— a preocuparse por qué cadena realizó el trabajo.

Hyperliquid en 2025: Un DEX de alto rendimiento que construye el futuro de las finanzas on-chain

· 53 min de lectura
Dora Noda
Software Engineer

Los exchanges descentralizados (DEX) han madurado hasta convertirse en pilares fundamentales del trading de criptomonedas, capturando ahora aproximadamente el 20 % del volumen total del mercado. Dentro de este espacio, Hyperliquid ha surgido como el líder indiscutible en derivados on-chain. Lanzado en 2022 con el ambicioso objetivo de igualar el rendimiento de los exchanges centralizados (CEX) en la cadena, Hyperliquid procesa hoy miles de millones en trading diario y controla alrededor del 70–75 % del mercado de futuros perpetuos de los DEX. Lo logra combinando una velocidad de nivel CEX y una profunda liquidez con la transparencia y la autocustodia de DeFi. El resultado es una blockchain y un exchange de Capa 1 verticalmente integrados que muchos ahora llaman “la blockchain para albergar todas las finanzas”. Este informe profundiza en la arquitectura técnica de Hyperliquid, su tokenomics, las métricas de crecimiento para 2025, comparaciones con otros líderes de DEX, desarrollos del ecosistema y su visión para el futuro de las finanzas on-chain.

Arquitectura Técnica: Una Cadena de Alto Rendimiento Verticalmente Integrada

Hyperliquid no es solo una aplicación DEX, es una blockchain de Capa 1 completa construida para el rendimiento en el trading. Su arquitectura consta de tres componentes estrechamente acoplados que operan en un estado unificado:

  • HyperBFT (Consenso): Un mecanismo de consenso personalizado de Tolerancia a Fallos Bizantinos optimizado para velocidad y rendimiento. Inspirado en protocolos modernos como HotStuff, HyperBFT proporciona finalidad de menos de un segundo y alta consistencia para asegurar que todos los nodos estén de acuerdo en el orden de las transacciones. Este consenso de Prueba de Participación (Proof-of-Stake) está diseñado para manejar la intensa carga de una plataforma de trading, soportando del orden de 100,000–200,000 operaciones por segundo en la práctica. A principios de 2025, Hyperliquid contaba con alrededor de 27 validadores independientes asegurando la red, un número que crece constantemente para descentralizar el consenso.
  • HyperCore (Motor de Ejecución): Un motor on-chain especializado para aplicaciones financieras. En lugar de usar contratos inteligentes genéricos para la lógica crítica del exchange, HyperCore implementa libros de órdenes de límite central (CLOBs) integrados para mercados de futuros perpetuos y spot, así como otros módulos para préstamos, subastas, oráculos y más. Cada colocación de orden, cancelación, coincidencia de operación y liquidación se procesa on-chain con finalidad en un solo bloque, produciendo velocidades de ejecución comparables a las de los exchanges tradicionales. Al evitar los AMM y manejar la coincidencia de órdenes dentro del protocolo, Hyperliquid logra una profunda liquidez y baja latencia; ha demostrado una finalidad de operación de <1s y un rendimiento que rivaliza con los centros de operaciones centralizados. Esta capa de ejecución personalizada (escrita en Rust) puede manejar, según se informa, hasta 200k órdenes por segundo después de optimizaciones recientes, eliminando los cuellos de botella que anteriormente hacían inviables los libros de órdenes on-chain.
  • HyperEVM (Contratos Inteligentes): Una capa de ejecución de propósito general compatible con Ethereum introducida en febrero de 2025. HyperEVM permite a los desarrolladores desplegar contratos inteligentes en Solidity y dApps en Hyperliquid con total compatibilidad con EVM, similar a construir en Ethereum. Crucialmente, HyperEVM no es un shard o rollup separado, comparte el mismo estado unificado con HyperCore. Esto significa que las dApps en HyperEVM pueden interoperar nativamente con los libros de órdenes y la liquidez del exchange. Por ejemplo, un protocolo de préstamos en HyperEVM puede leer precios en vivo del libro de órdenes de HyperCore o incluso publicar órdenes de liquidación directamente en el libro de órdenes a través de llamadas al sistema. Esta componibilidad entre los contratos inteligentes y la capa de exchange de alta velocidad es un diseño único: no se necesitan puentes ni oráculos off-chain para que las dApps aprovechen la infraestructura de trading de Hyperliquid.

Figura: Arquitectura verticalmente integrada de Hyperliquid que muestra el estado unificado entre el consenso (HyperBFT), el motor de exchange (HyperCore), los contratos inteligentes (HyperEVM) y el puente de activos (HyperUnit).

Integración con la Infraestructura On-Chain: Al construir su propia cadena, Hyperliquid integra estrechamente funciones normalmente aisladas en una sola plataforma. HyperUnit, por ejemplo, es el módulo descentralizado de puente y tokenización de activos de Hyperliquid que permite depósitos directos de activos externos como BTC, ETH y SOL sin envoltorios custodiados. Los usuarios pueden bloquear BTC o ETH nativos y recibir tokens equivalentes (p. ej., uBTC, uETH) en Hyperliquid para usarlos como colateral de trading, sin depender de custodios centralizados. Este diseño proporciona una “verdadera movilidad de colateral” y un marco más consciente de la regulación para traer activos del mundo real a la cadena. Gracias a HyperUnit (y a la integración de USDC de Circle que se discutirá más adelante), los traders en Hyperliquid pueden mover liquidez sin problemas desde otras redes al rápido entorno de exchange de Hyperliquid.

Rendimiento y Latencia: Todas las partes de la pila están optimizadas para una latencia mínima y un rendimiento máximo. HyperBFT finaliza los bloques en menos de un segundo, y HyperCore procesa las operaciones en tiempo real, por lo que los usuarios experimentan una ejecución de órdenes casi instantánea. Efectivamente, no hay tarifas de gas para las acciones de trading: las transacciones de HyperCore no tienen comisiones, lo que permite la colocación y cancelación de órdenes de alta frecuencia sin costo para los usuarios. (Las llamadas a contratos EVM normales en HyperEVM sí incurren en una baja tarifa de gas, pero las operaciones del exchange se ejecutan sin gas en el motor nativo). Este diseño de cero gas y baja latencia hace viables las características de trading avanzadas on-chain. De hecho, Hyperliquid soporta los mismos tipos de órdenes avanzadas y controles de riesgo que los principales CEX, como órdenes límite y stop, margen cruzado y hasta 50× de apalancamiento en los principales mercados. En resumen, la cadena L1 personalizada de Hyperliquid elimina el tradicional compromiso entre velocidad y descentralización. Cada operación es on-chain y transparente, pero la experiencia del usuario, en términos de velocidad de ejecución e interfaz, es paralela a la de un exchange centralizado profesional.

Evolución y Escalabilidad: La arquitectura de Hyperliquid nació de la ingeniería desde los primeros principios. El proyecto se lanzó discretamente en 2022 como un DEX de perpetuos en alfa cerrada en una cadena personalizada basada en Tendermint, probando el concepto de CLOB con ~20 activos y 50× de apalancamiento. Para 2023, se transformó en una L1 totalmente soberana con el nuevo consenso HyperBFT, alcanzando más de 100K órdenes por segundo e introduciendo el trading sin gas y los pools de liquidez comunitarios. La adición de HyperEVM a principios de 2025 abrió las compuertas para los desarrolladores, marcando la evolución de Hyperliquid de un exchange de un solo propósito a una plataforma DeFi completa. Notablemente, todas estas mejoras han mantenido el sistema estable: Hyperliquid reporta un **99.99 % de tiempo de actividad históricamente[25]_. Este historial y la integración vertical_ le dan a Hyperliquid una ventaja técnica significativa: controla toda la pila (consenso, ejecución, aplicación), permitiendo una optimización continua. A medida que la demanda crece, el equipo continúa refinando el software del nodo para un rendimiento aún mayor, asegurando la escalabilidad para la próxima ola de usuarios y mercados on-chain más complejos.

Tokenomics de $HYPE: Gobernanza, Staking y Acumulación de Valor

El diseño económico de Hyperliquid se centra en su token nativo HYPE,introducidoafinalesde2024paradescentralizarlapropiedadylagobernanzadelaplataforma.Ellanzamientoyladistribucioˊndeltokenfueronnotablementecentradosenlacomunidad:ennoviembrede2024,HyperliquidrealizoˊunEventodeGeneracioˊndeTokens(TGE)medianteunairdrop,asignandoel31HYPE**, introducido a finales de 2024 para descentralizar la propiedad y la gobernanza de la plataforma. El lanzamiento y la distribución del token fueron notablemente _centrados en la comunidad_: en noviembre de 2024, Hyperliquid realizó un Evento de Generación de Tokens (TGE) mediante un airdrop, asignando el **31 % del suministro fijo de 1 mil millones a los primeros usuarios** como recompensa por su participación. Una porción aún mayor (≈38.8 %) se reservó para **futuros incentivos comunitarios** como la minería de liquidez o el desarrollo del ecosistema. Es importante destacar que **HYPE no tuvo asignaciones para VCs o inversores privados, reflejando una filosofía de priorizar la propiedad comunitaria. Esta distribución transparente tenía como objetivo evitar la fuerte propiedad de insiders vista en muchos proyectos y, en cambio, empoderar a los traders y constructores reales en Hyperliquid.

El token $HYPE cumple múltiples roles en el ecosistema de Hyperliquid:

  • Gobernanza: $HYPE es un token de gobernanza que permite a los tenedores votar en las Propuestas de Mejora de Hyperliquid (HIPs) y dar forma a la evolución del protocolo. Ya se han aprobado actualizaciones críticas como HIP-1, HIP-2 y HIP-3, que establecieron estándares de listado sin permisos para tokens spot y mercados perpetuos. Por ejemplo, HIP-3 abrió la capacidad para que los miembros de la comunidad desplieguen nuevos mercados de perpetuos sin permisos, de manera muy similar a como lo hizo Uniswap para el trading spot, desbloqueando activos de cola larga (long-tail) (incluidos perpetuos del mercado tradicional) en Hyperliquid. La gobernanza decidirá cada vez más sobre listados, ajustes de parámetros y el uso de los fondos de incentivos comunitarios.
  • Staking y Seguridad de la Red: Hyperliquid es una cadena de Prueba de Participación (Proof-of-Stake), por lo que **hacer staking de HYPEenlosvalidadoresaseguralaredHyperBFT.Losstakersdeleganalosvalidadoresygananunaporcioˊndelasrecompensasdebloqueylastarifas.Pocodespueˊsdellanzamiento,Hyperliquidhabilitoˊelstakingconunrendimientoanualde 22.5HYPE en los validadores asegura la red HyperBFT**. Los stakers delegan a los validadores y ganan una porción de las recompensas de bloque y las tarifas. Poco después del lanzamiento, Hyperliquid habilitó el staking con un **rendimiento anual de ~2–2.5 %** para incentivar la participación en el consenso. A medida que más usuarios hacen staking, la seguridad y la descentralización de la cadena mejoran. El HYPE en staking (o formas derivadas como el próximo staking líquido beHYPE) también puede usarse en la votación de gobernanza, alineando a los participantes de la seguridad con la toma de decisiones.
  • Utilidad en el Exchange (Descuentos en Tarifas): Tener o hacer staking de HYPEconfieredescuentosenlastarifasdetradingenelexchangedeHyperliquid.SimilaracoˊmoeltokenBNBdeBinanceoeltokenDYDXdedYdXofrecentarifasreducidas,seincentivaalostradersactivosamantenerHYPE confiere **descuentos en las tarifas de trading** en el exchange de Hyperliquid. Similar a cómo el token BNB de Binance o el token DYDX de dYdX ofrecen tarifas reducidas, se incentiva a los traders activos a mantener HYPE para minimizar sus costos. Esto crea una demanda natural del token entre la base de usuarios del exchange, especialmente los traders de alto volumen.
  • Acumulación de Valor a través de Recompras: El aspecto más llamativo de la tokenomics de Hyperliquid es su agresivo mecanismo de tarifa a valor. Hyperliquid utiliza la gran mayoría de sus ingresos por tarifas de trading para recomprar y quemar HYPEenelmercadoabierto,devolviendovalordirectamentealostenedoresdetokens.Dehecho,el97HYPE en el mercado abierto, devolviendo valor directamente a los tenedores de tokens. De hecho, el **97 % de todas las tarifas de trading del protocolo se destinan a la recompra de HYPE** (y el resto a un fondo de seguro y a los proveedores de liquidez). Esta es una de las tasas de retorno de tarifas más altas de la industria. A mediados de 2025, Hyperliquid generaba más de 65 millones de dólares en ingresos del protocolo por mes a partir de las tarifas de trading, y prácticamente todo eso se destinaba a recompras de HYPE,creandounapresioˊndecompraconstante.Estemodelodetokendeflacionario,combinadoconunsuministrofijode1B,significaquelatokenomicsdeHYPE, creando una presión de compra constante. Este modelo de token deflacionario, combinado con un suministro fijo de 1B, significa que la tokenomics de HYPE está orientada a la acumulación de valor a largo plazo para los stakeholders leales. También indica que el equipo de Hyperliquid renuncia a las ganancias a corto plazo (ningún ingreso por tarifas se toma como ganancia o se distribuye a insiders; incluso el equipo central presumiblemente solo se beneficia como tenedores de tokens), en su lugar, canaliza los ingresos al tesoro comunitario y al valor del token.
  • Recompensas para Proveedores de Liquidez: Una pequeña porción de las tarifas (≈3–8 %) se utiliza para recompensar a los proveedores de liquidez en el único Pool de Hiperliquidez (HLP) de Hyperliquid. HLP es un pool de liquidez de USDC on-chain que facilita la creación de mercado (market-making) y la liquidación automática para los libros de órdenes, análogo a una “bóveda de LP”. Los usuarios que proporcionan USDC a HLP ganan una parte de las tarifas de trading a cambio. A principios de 2025, HLP ofrecía a los depositantes un rendimiento anualizado de ~11 % a partir de las tarifas de trading acumuladas. Este mecanismo permite a los miembros de la comunidad compartir el éxito del exchange contribuyendo con capital para respaldar la liquidez (similar en espíritu al pool GLP de GMX, pero para un sistema de libro de órdenes). Notablemente, el Fondo de Asistencia de seguro de Hyperliquid (denominado en HYPE)tambieˊnutilizaunaporcioˊndelosingresosparacubrircualquierpeˊrdidadeHLPoeventosinusuales;porejemplo,unexploitJellyenelprimertrimestrede2025incurrioˊenundeˊficitde12MHYPE) también utiliza una porción de los ingresos para cubrir cualquier pérdida de HLP o eventos inusuales; por ejemplo, un _exploit “Jelly” en el primer trimestre de 2025_ incurrió en un déficit de 12 M en HLP, que fue completamente reembolsado a los usuarios del pool. El modelo de recompra de tarifas fue tan robusto que, a pesar de ese golpe, las recompras de $HYPE continuaron sin cesar y HLP se mantuvo rentable, demostrando una fuerte alineación entre el protocolo y sus proveedores de liquidez comunitarios.

En resumen, la tokenomics de Hyperliquid enfatiza la propiedad comunitaria, la seguridad y la sostenibilidad a largo plazo. La ausencia de asignaciones a VCs y la alta tasa de recompra fueron decisiones que señalaron confianza en el crecimiento orgánico. Los primeros resultados han sido positivos: desde su TGE, el precio de $HYPE subió 4× (a mediados de 2025) gracias a la adopción real y los ingresos. Más importante aún, los usuarios se mantuvieron comprometidos después del airdrop; la actividad de trading de hecho se aceleró después del lanzamiento del token, en lugar de sufrir la típica caída post-incentivo. Esto sugiere que el modelo del token está alineando con éxito los incentivos de los usuarios con el crecimiento de la plataforma, creando un ciclo virtuoso para el ecosistema de Hyperliquid.

Volumen de Trading, Adopción y Liquidez en 2025

Hyperliquid en Cifras: En 2025, Hyperliquid se destaca no solo por su tecnología, sino por la escala pura de su actividad on-chain. Se ha convertido rápidamente en el mayor exchange de derivados descentralizado por un amplio margen, estableciendo nuevos puntos de referencia para DeFi. Las métricas clave que ilustran la tracción de Hyperliquid incluyen:

  • Dominio del Mercado: Hyperliquid maneja aproximadamente el 70–77 % de todo el volumen de futuros perpetuos de los DEX en 2025, una participación 8 veces mayor que la del siguiente competidor. En otras palabras, Hyperliquid por sí solo representa más de tres cuartas partes del trading de perpetuos descentralizado en todo el mundo, lo que lo convierte en el líder claro de su categoría. (Para contextualizar, a partir del primer trimestre de 2025, esto equivalía a aproximadamente el 56–73 % del volumen de perpetuos descentralizado, frente al ~4.5 % a principios de 2024, un aumento impresionante en un año).
  • Volúmenes de Trading: El volumen de trading acumulado en Hyperliquid superó los 1.5 billones de dólares a mediados de 2025, destacando cuánta liquidez ha fluido a través de sus mercados. A finales de 2024, el exchange ya registraba volúmenes diarios de alrededor de 10–14 mil millones de dólares, y el volumen continuó aumentando con la afluencia de nuevos usuarios en 2025. De hecho, durante la actividad máxima del mercado (p. ej., una frenesí de memecoins en mayo de 2025), el volumen de trading semanal de Hyperliquid alcanzó hasta 780 mil millones de dólares en una semana, con un promedio de más de 100 Bpordıˊa,rivalizandoosuperandoamuchosexchangescentralizadosdetaman~omediano.Inclusoencondicionesestables,Hyperliquidpromediabaaproximadamente470B por día, rivalizando o superando a muchos exchanges centralizados de tamaño mediano. Incluso en condiciones estables, Hyperliquid promediaba aproximadamente **470 B en volumen semanal** en la primera mitad de 2025. Esta escala no tiene precedentes para una plataforma DeFi; a mediados de 2025, Hyperliquid ejecutaba alrededor del 6 % de *todo* el volumen de trading de criptomonedas a nivel mundial (incluidos los CEX), reduciendo la brecha entre DeFi y CeFi.
  • Interés Abierto y Liquidez: La profundidad de los mercados de Hyperliquid también es evidente en su interés abierto (OI), el valor total de las posiciones activas. El OI creció desde ~$3.3B a finales de 2024 hasta alrededor de 15 mil millones de dólares a mediados de 2025. Para tener una perspectiva, este OI es aproximadamente el 60–120 % de los niveles en los principales CEX como Bybit, OKX o Bitget, lo que indica que los traders profesionales se sienten tan cómodos desplegando grandes posiciones en Hyperliquid como en los centros de operaciones centralizados establecidos. La profundidad del libro de órdenes en Hyperliquid para los principales pares como BTC o ETH se informa que es comparable a la de los principales CEX, con spreads de compra-venta (bid-ask) ajustados. Durante ciertos lanzamientos de tokens (p. ej., la popular memecoin PUMP), Hyperliquid incluso logró la liquidez más profunda y el mayor volumen de cualquier centro de operaciones, superando a los CEX para ese activo. Esto demuestra cómo un libro de órdenes on-chain, cuando está bien diseñado, puede igualar la liquidez de un CEX, un hito en la evolución de los DEX.
  • Usuarios y Adopción: La base de usuarios de la plataforma se ha expandido drásticamente durante 2024–2025. Hyperliquid superó las 500,000 direcciones de usuario únicas a mediados de 2025. Solo en la primera mitad de 2025, el recuento de direcciones activas casi se duplicó (de ~291k a 518k). Este crecimiento del 78 % en seis meses fue impulsado por el boca a boca, un exitoso programa de referidos y puntos, y el entusiasmo en torno al airdrop de $HYPE (que curiosamente retuvo a los usuarios en lugar de solo atraer a mercenarios; no hubo una caída en el uso después del airdrop, y la actividad siguió aumentando). Tal crecimiento indica no solo una curiosidad puntual, sino una adopción genuina por parte de los traders. Se cree que una porción significativa de estos usuarios son “ballenas” y traders profesionales que migraron desde los CEX, atraídos por la liquidez y las tarifas más bajas de Hyperliquid. De hecho, las instituciones y las empresas de trading de alto volumen han comenzado a tratar a Hyperliquid como un centro de operaciones principal para el trading de perpetuos, validando el atractivo de DeFi cuando se resuelven los problemas de rendimiento.
  • Ingresos y Tarifas: Los robustos volúmenes de Hyperliquid se traducen en ingresos sustanciales para el protocolo (que, como se señaló, se acumulan en gran medida en las recompras de HYPE).Enlosuˊltimos30dıˊas(amediadosde2025),Hyperliquidgeneroˊalrededorde65.45millonesdedoˊlaresentarifasdeprotocolo.Diariamente,esoesaproximadamente2.02.5millonesdedoˊlaresentarifasobtenidasdelaactividaddetrading.Anualizado,laplataformaestaˊencaminodealcanzarmaˊsde800MHYPE). En los últimos 30 días (a mediados de 2025), Hyperliquid generó alrededor de **65.45 millones de dólares en tarifas de protocolo**. Diariamente, eso es aproximadamente **2.0–2.5 millones de dólares en tarifas** obtenidas de la actividad de trading. Anualizado, la plataforma está en camino de alcanzar **más de 800 M en ingresos**, una cifra asombrosa que se acerca a los ingresos de algunos de los principales exchanges centralizados, y muy por encima de los protocolos DeFi típicos. Subraya cómo el alto volumen y la estructura de tarifas de Hyperliquid (pequeñas tarifas por operación que se suman a escala) producen un modelo de ingresos próspero para respaldar su economía de tokens.
  • Valor Total Bloqueado (TVL) y Activos: El TVL del ecosistema de Hyperliquid, que representa los activos puenteados a su cadena y la liquidez en sus protocolos DeFi, ha aumentado rápidamente junto con la actividad de trading. A principios del cuarto trimestre de 2024 (antes del token), el TVL de la cadena de Hyperliquid era de alrededor de 0.5 B$, pero después del lanzamiento del token y la expansión de HyperEVM, el TVL se disparó a más de 2 mil millones de dólares a principios de 2025. A mediados de 2025, alcanzó aproximadamente 3.5 mil millones de dólares (30 de junio de 2025) y continuó al alza. La introducción de USDC nativo (a través de Circle) y otros activos impulsó el capital on-chain a un estimado de 5.5 mil millones de dólares en AUM para julio de 2025. Esto incluye activos en el pool HLP, pools de préstamos DeFi, AMMs y los saldos de colateral de los usuarios. El Pool de Hiperliquidez (HLP) de Hyperliquid por sí solo mantuvo un TVL de alrededor de 370–500 millones de dólares en el primer semestre de 2025, proporcionando una profunda reserva de liquidez de USDC para el exchange. Además, el TVL de DeFi en HyperEVM (excluyendo el exchange principal) superó los mil millones de dólares a los pocos meses de su lanzamiento, reflejando un rápido crecimiento de nuevas dApps en la cadena. Estas cifras colocan firmemente a Hyperliquid entre los mayores ecosistemas de blockchain por TVL, a pesar de ser una cadena especializada.

En resumen, 2025 ha visto a Hyperliquid escalar a volúmenes y liquidez similares a los de un CEX. Se clasifica constantemente como el principal DEX por volumen, e incluso se mide como una fracción significativa del trading de criptomonedas en general. La capacidad de sostener medio billón de dólares en volumen semanal on-chain, con medio millón de usuarios, ilustra que la promesa largamente sostenida de un DeFi de alto rendimiento se está haciendo realidad. El éxito de Hyperliquid está expandiendo los límites de lo que los mercados on-chain pueden hacer: por ejemplo, se convirtió en el lugar de referencia para el listado rápido de nuevas monedas (a menudo es el primero en listar perpetuos para activos de tendencia, atrayendo una gran actividad) y ha demostrado que los libros de órdenes on-chain pueden manejar el trading de blue-chips a escala (sus mercados de BTC y ETH tienen una liquidez comparable a la de los principales CEX). Estos logros respaldan la afirmación de Hyperliquid como una potencial base para todas las finanzas on-chain en el futuro.

Comparación con Otros DEX Líderes (dYdX, GMX, UniswapX, etc.)

El ascenso de Hyperliquid invita a comparaciones con otros exchanges descentralizados prominentes. Cada uno de los principales modelos de DEX, desde derivados basados en libros de órdenes como dYdX, hasta perpetuos basados en pools de liquidez como GMX, y agregadores de DEX spot como UniswapX, adopta un enfoque diferente para equilibrar el rendimiento, la descentralización y la experiencia del usuario. A continuación, analizamos cómo se compara Hyperliquid con estas plataformas:

  • Hyperliquid vs. dYdX: dYdX fue el líder inicial en perpetuos descentralizados, pero su diseño inicial (v3) se basaba en un enfoque híbrido: un libro de órdenes y un motor de coincidencias off-chain, combinados con una liquidación en L2 en StarkWare. Esto le dio a dYdX un rendimiento decente, pero a costa de la descentralización y la componibilidad: el libro de órdenes era operado por un servidor central, y el sistema no estaba abierto a contratos inteligentes generales. A finales de 2023, dYdX lanzó v4 como una app-chain de Cosmos, con el objetivo de descentralizar completamente el libro de órdenes dentro de una cadena PoS dedicada. Esto es filosóficamente similar al enfoque de Hyperliquid (ambos construyeron cadenas personalizadas para la coincidencia de órdenes on-chain). La ventaja clave de Hyperliquid ha sido su arquitectura unificada y su ventaja en el ajuste del rendimiento. Al diseñar HyperCore y HyperEVM juntos, Hyperliquid logró una velocidad de nivel CEX completamente on-chain antes de que la cadena de Cosmos de dYdX ganara tracción. De hecho, el rendimiento de Hyperliquid superó al de dYdX: puede manejar mucho más rendimiento (cientos de miles de tx/seg) y ofrece una componibilidad entre contratos que dYdX (una cadena específica de la aplicación sin un entorno EVM) actualmente carece. Artemis Research señala: los protocolos anteriores comprometían el rendimiento (como GMX) o la descentralización (como dYdX), pero Hyperliquid entregó ambos, resolviendo el desafío más profundo. Esto se refleja en la cuota de mercado: para 2025, Hyperliquid comanda ~75 % del mercado de DEX de perpetuos, mientras que la cuota de dYdX ha disminuido a un solo dígito. En términos prácticos, los traders encuentran que la interfaz de usuario y la velocidad de Hyperliquid son comparables a las de dYdX (ambos ofrecen interfaces de exchange profesionales, órdenes avanzadas, etc.), pero Hyperliquid ofrece una mayor variedad de activos e integración on-chain. Otra diferencia son los modelos de tarifas y tokens: el token de dYdX es principalmente un token de gobernanza con descuentos indirectos en las tarifas, mientras que el $HYPE de Hyperliquid acumula directamente el valor del exchange (a través de recompras) y ofrece derechos de staking. Finalmente, en cuanto a la descentralización, ambas son cadenas PoS (dYdX tenía ~20 validadores en su lanzamiento frente a los ~27 de Hyperliquid a principios de 2025), pero el ecosistema de constructores abierto de Hyperliquid (HyperEVM) podría decirse que lo hace más descentralizado en términos de desarrollo y uso. En general, Hyperliquid puede ser visto como el sucesor espiritual de dYdX: tomó el concepto de DEX de libro de órdenes y lo llevó completamente on-chain con un mayor rendimiento, lo que se evidencia en que Hyperliquid atrajo un volumen significativo incluso de exchanges centralizados (algo que dYdX v3 tuvo dificultades para hacer).
  • Hyperliquid vs. GMX: GMX representa el modelo basado en AMM/pool para perpetuos. Se hizo popular en Arbitrum en 2022 al permitir a los usuarios operar perpetuos contra una liquidez agrupada (GLP) con precios basados en oráculos. El enfoque de GMX priorizó la simplicidad y el cero impacto en el precio para operaciones pequeñas, pero sacrifica algo de rendimiento y eficiencia de capital. Debido a que GMX depende de oráculos de precios y un único pool de liquidez, las operaciones grandes o frecuentes pueden ser desafiantes: el pool puede incurrir en pérdidas si los traders ganan (los tenedores de GLP toman el lado opuesto de las operaciones), y la latencia del precio del oráculo puede ser explotada. El modelo de libro de órdenes de Hyperliquid evita estos problemas al hacer coincidir a los traders peer-to-peer a precios impulsados por el mercado, con creadores de mercado profesionales que proporcionan una profunda liquidez. Esto produce spreads mucho más ajustados y una mejor ejecución para grandes operaciones en comparación con el modelo de GMX. En esencia, el diseño de GMX compromete el rendimiento de alta frecuencia (las operaciones solo se actualizan cuando los oráculos envían precios, y no hay colocación/cancelación rápida de órdenes), mientras que el diseño de Hyperliquid sobresale en ello. Las cifras lo reflejan: los volúmenes y el OI de GMX son un orden de magnitud más pequeños, y su cuota de mercado ha sido eclipsada por el ascenso de Hyperliquid. Por ejemplo, GMX típicamente soportaba menos de 20 mercados (principalmente de gran capitalización), mientras que Hyperliquid ofrece más de 100 mercados, incluyendo muchos activos de cola larga (long-tail); esto último es posible porque mantener muchos libros de órdenes es factible en la cadena de Hyperliquid, mientras que en GMX agregar nuevos pools de activos es más lento y arriesgado. Desde el punto de vista de la experiencia del usuario, GMX ofrece una interfaz simple estilo swap (buena para novatos en DeFi), mientras que Hyperliquid proporciona un panel de exchange completo con gráficos y libros de órdenes para traders avanzados. Tarifas: GMX cobra una tarifa de ~0.1 % en las operaciones (que va a GLP y a los stakers de GMX) y no tiene recompra de tokens; Hyperliquid cobra tarifas de maker/taker muy bajas (del orden de 0.01–0.02 %) y utiliza las tarifas para recomprar $HYPE para los tenedores. Descentralización: GMX se ejecuta en L2 de Ethereum (Arbitrum, Avalanche), heredando una fuerte seguridad de base, pero su dependencia de un oráculo de precios centralizado (Chainlink) y un único pool de liquidez introduce diferentes riesgos centralizados. Hyperliquid ejecuta su propia cadena, que es más nueva y menos probada en batalla que Ethereum, pero sus mecanismos (libro de órdenes + muchos makers) evitan la dependencia de oráculos centralizados. En resumen, Hyperliquid ofrece un rendimiento superior y una liquidez de grado institucional en relación con GMX, a costa de una infraestructura más compleja. GMX demostró que hay demanda de perpetuos on-chain, pero los libros de órdenes de Hyperliquid han demostrado ser mucho más escalables para el trading de alto volumen.
  • Hyperliquid vs. UniswapX (y DEX Spot): UniswapX es un agregador de operaciones para swaps spot recientemente introducido (construido por Uniswap Labs) que encuentra el mejor precio a través de AMMs y otras fuentes de liquidez. Aunque no es un competidor directo en perpetuos, UniswapX representa la vanguardia de la experiencia de usuario de los DEX spot. Permite swaps de tokens sin gas y optimizados por agregación al permitir que "fillers" off-chain ejecuten operaciones para los usuarios. Por el contrario, el trading spot de Hyperliquid utiliza sus propios libros de órdenes on-chain (y también tiene un AMM nativo llamado HyperSwap en su ecosistema). Para un usuario que busca operar tokens spot, ¿cómo se comparan? Rendimiento: Los libros de órdenes spot de Hyperliquid ofrecen ejecución inmediata con baja latencia, similar a un exchange centralizado, y gracias a que no hay tarifas de gas en HyperCore, tomar una orden es barato y rápido. UniswapX tiene como objetivo ahorrar gas a los usuarios en Ethereum al abstraer la ejecución, pero en última instancia, la liquidación de la operación todavía ocurre en Ethereum (u otras cadenas subyacentes) y puede incurrir en latencia (esperando a los fillers y las confirmaciones de bloque). Liquidez: UniswapX obtiene liquidez de muchos AMMs y creadores de mercado a través de múltiples DEX, lo cual es excelente para tokens de cola larga (long-tail) en Ethereum; sin embargo, para los pares principales, el único libro de órdenes de Hyperliquid a menudo tiene una liquidez más profunda y menos deslizamiento (slippage) porque todos los traders se congregan en un solo lugar. De hecho, después de lanzar los mercados spot en marzo de 2024, Hyperliquid vio rápidamente cómo los volúmenes spot se disparaban a niveles récord, con grandes traders puenteando activos como BTC, ETH y SOL a Hyperliquid para el trading spot debido a la ejecución superior, para luego puentearlos de vuelta. UniswapX sobresale en la amplitud del acceso a tokens, mientras que Hyperliquid se enfoca en la profundidad y eficiencia para un conjunto más curado de activos (aquellos listados a través de su proceso de gobernanza/subasta). Descentralización y UX: Uniswap (y X) aprovechan la base muy descentralizada de Ethereum y no tienen custodia, pero los agregadores como UniswapX introducen actores off-chain (fillers que retransmiten órdenes), aunque de manera sin permisos. El enfoque de Hyperliquid mantiene todas las acciones de trading on-chain con total transparencia, y cualquier activo listado en Hyperliquid obtiene los beneficios del trading nativo en libro de órdenes más la componibilidad con sus aplicaciones DeFi. La experiencia del usuario en Hyperliquid es más cercana a una aplicación de trading centralizada (que los usuarios avanzados prefieren), mientras que UniswapX es más como un "meta-DEX" para swaps de un solo clic (conveniente para operaciones casuales). Tarifas: Las tarifas de UniswapX dependen de la liquidez del DEX utilizada (típicamente 0.05–0.3 % en AMMs) más posiblemente un incentivo para el filler; las tarifas spot de Hyperliquid son mínimas y a menudo se compensan con descuentos de HYPE.Enresumen,HyperliquidcompiteconUniswapyotrosDEXspotofreciendounnuevomodelo:unexchangespotbasadoenlibrodeoˊrdenesenunacadenapersonalizada.Sehahechounnichodondelostradersspotdealtovolumen(especialmenteparaactivosdegrancapitalizacioˊn)prefierenHyperliquidporsuliquidezmaˊsprofundaysuexperienciasimilaraladeunCEX,mientrasquelosusuariosminoristasqueintercambianERC20oscurospuedenseguirprefiriendoelecosistemadeUniswap.Notablemente,elecosistemadeHyperliquidinclusointrodujoHyperswap(unAMMenHyperEVMcon HYPE. En resumen, **Hyperliquid compite con Uniswap y otros DEX spot ofreciendo un nuevo modelo: un exchange spot basado en libro de órdenes en una cadena personalizada**. Se ha hecho un nicho donde los traders spot de alto volumen (especialmente para activos de gran capitalización) prefieren Hyperliquid por su liquidez más profunda y su experiencia similar a la de un CEX, mientras que los usuarios minoristas que intercambian ERC-20 oscuros pueden seguir prefiriendo el ecosistema de Uniswap. Notablemente, el ecosistema de Hyperliquid incluso introdujo _Hyperswap_ (un AMM en HyperEVM con ~70M de TVL) para capturar tokens de cola larga (long-tail) a través de pools de AMM, reconociendo que los AMMs y los libros de órdenes pueden coexistir, sirviendo a diferentes segmentos del mercado.

Resumen de Diferencias Clave: La siguiente tabla resume una comparación de alto nivel:

Plataforma DEXDiseño y CadenaModelo de TradingRendimientoDescentralizaciónMecanismo de Tarifas
HyperliquidL1 personalizada (HyperBFT PoS, ~27 validadores)CLOB on-chain para perpetuos/spot; también apps EVM~0.5s de finalidad, 100k+ tx/seg, UI tipo CEXCadena PoS (gestionada por la comunidad, estado unificado para dApps)Tarifas de trading mínimas, ~97 % de las tarifas recompran $HYPE (recompensando indirectamente a los tenedores)
dYdX v4App-chain de Cosmos SDK (PoS, ~20 validadores)CLOB on-chain solo para perpetuos (sin contratos inteligentes generales)~1-2s de finalidad, alto rendimiento (matching de órdenes por validadores)Cadena PoS (matching descentralizado, pero no componible con EVM)Tarifas de trading pagadas en USDC; token DYDX para gobernanza y descuentos (sin recompra de tarifas)
GMXArbitrum y Avalanche (L2/L1 de Ethereum)Liquidez agrupada AMM (GLP) con precios de oráculo para perpetuosDependiente de la actualización del oráculo (~30s); bueno para operaciones casuales, no para HFTAsegurado por L1 de Ethereum/Avax; totalmente on-chain pero depende de oráculos centralizadosTarifa de trading de ~0.1 %; 70 % para proveedores de liquidez (GLP), 30 % para stakers de GMX (reparto de ingresos)
UniswapXMainnet de Ethereum (y cross-chain)Agregador para swaps spot (rutas a través de AMMs o creadores de mercado RFQ)~12s de tiempo de bloque de Ethereum (fills abstraídos off-chain); tarifas de gas abstraídasSe ejecuta en Ethereum (alta seguridad base); utiliza nodos filler off-chain para la ejecuciónUtiliza tarifas de AMM subyacentes (0.05–0.3 %) + posible incentivo para filler; el token UNI no es necesario para su uso

En esencia, Hyperliquid ha establecido un nuevo punto de referencia al combinar las fortalezas de estos enfoques sin las debilidades habituales: ofrece los tipos de órdenes sofisticados, la velocidad y la liquidez de un CEX (superando el intento anterior de dYdX), sin sacrificar la transparencia y la naturaleza sin permisos de DeFi (mejorando el rendimiento de GMX y la componibilidad de Uniswap). Como resultado, en lugar de simplemente robar cuota de mercado a dYdX o GMX, Hyperliquid en realidad expandió el mercado de trading on-chain al atraer a traders que anteriormente se mantenían en los CEX. Su éxito ha estimulado a otros a evolucionar; por ejemplo, incluso Coinbase y Robinhood han considerado entrar en el mercado de perpetuos on-chain, aunque con mucho menos apalancamiento y liquidez hasta ahora. Si esta tendencia continúa, podemos esperar un impulso competitivo donde tanto los CEX como los DEX compitan para combinar rendimiento con confianza, una carrera en la que Hyperliquid actualmente disfruta de una fuerte ventaja.

Crecimiento del Ecosistema, Alianzas e Iniciativas Comunitarias

Uno de los mayores logros de Hyperliquid en 2025 es haber pasado de ser un exchange de un solo producto a un próspero ecosistema de blockchain. El lanzamiento de HyperEVM desbloqueó una explosión cámbrica de proyectos y alianzas que se construyen alrededor del núcleo de Hyperliquid, convirtiéndolo no solo en un lugar de trading, sino en un entorno completo de DeFi y Web3. Aquí exploramos la expansión del ecosistema y las alianzas estratégicas clave:

Proyectos del Ecosistema y Tracción de Desarrolladores: Desde principios de 2025, docenas de dApps se han desplegado en Hyperliquid, atraídas por su liquidez incorporada y su base de usuarios. Estas abarcan toda la gama de primitivas de DeFi e incluso se extienden a los NFT y los juegos:

  • Exchanges Descentralizados (DEX): Además de los libros de órdenes nativos de Hyperliquid, han aparecido DEX construidos por la comunidad para satisfacer otras necesidades. Notablemente, Hyperswap se lanzó como un AMM en HyperEVM, convirtiéndose rápidamente en el principal centro de liquidez para tokens de cola larga (long-tail) (acumuló más de 70 MdeTVLy2B de TVL y 2 B de volumen en 4 meses). Los pools automatizados de Hyperswap complementan el CLOB de Hyperliquid al permitir el listado sin permisos de nuevos tokens y proporcionar un lugar fácil para que los proyectos inicien su liquidez. Otro proyecto, KittenSwap (una bifurcación de Velodrome con tokenomics ve(3,3)), también se puso en marcha para ofrecer trading AMM incentivado para activos más pequeños. Estas adiciones de DEX aseguran que incluso las memecoins y los tokens experimentales puedan prosperar en Hyperliquid a través de AMMs, mientras que los activos principales se negocian en libros de órdenes, una sinergia que impulsa el volumen general.
  • Protocolos de Préstamos y Rendimiento: El ecosistema de Hyperliquid ahora cuenta con mercados monetarios y optimizadores de rendimiento que se interconectan con el exchange. HyperBeat es un protocolo insignia de préstamos y empréstitos en HyperEVM (con ~145MdeTVLamediadosde2025).Permitealosusuariosdepositaractivoscomo145M de TVL a mediados de 2025). Permite a los usuarios depositar activos como HYPE, stablecoins o incluso tokens LP para ganar intereses, y pedir prestado contra colateral para operar en Hyperliquid con apalancamiento adicional. Debido a que HyperBeat puede leer los precios del libro de órdenes de Hyperliquid directamente e incluso activar liquidaciones on-chain a través de HyperCore, opera de manera más eficiente y segura que los protocolos de préstamos cross-chain. También están surgiendo agregadores de rendimiento: el programa de recompensas “Hearts” de HyperBeat y otros incentivan la provisión de liquidez o los depósitos en bóvedas. Otro participante notable es Kinetiq, un proyecto de staking líquido para HYPEqueatrajomaˊsde400MHYPE que atrajo más de 400 M en depósitos el primer día, lo que indica un enorme apetito de la comunidad por obtener rendimiento con HYPE. Incluso protocolos externos basados en Ethereum se están integrando: EtherFi, un importante proveedor de staking líquido (con ~$9B en ETH en staking), anunció una colaboración para llevar ETH en staking y nuevas estrategias de rendimiento a Hyperliquid a través de HyperBeat. Esta alianza introducirá beHYPE, un token de staking líquido para HYPE, y potencialmente traerá el ETH en staking de EtherFi como colateral a los mercados de Hyperliquid. Tales movimientos muestran la confianza de los actores establecidos de DeFi en el potencial del ecosistema de Hyperliquid.
  • Stablecoins y Banca Cripto: Reconociendo la necesidad de una moneda on-chain estable, Hyperliquid ha atraído tanto el soporte de stablecoins externas como nativas. Lo más significativo es que Circle (emisor de USDC) formó una alianza estratégica para lanzar USDC nativo en Hyperliquid en 2025. Usando el Protocolo de Transferencia entre Cadenas (CCTP) de Circle, los usuarios podrán quemar USDC en Ethereum y acuñar USDC 1:1 en Hyperliquid, eliminando los envoltorios y permitiendo una liquidez directa de stablecoin en la cadena. Se espera que esta integración agilice las grandes transferencias de capital a Hyperliquid y reduzca la dependencia de solo USDT/USDC puenteados. De hecho, para el momento del anuncio, los activos bajo gestión de Hyperliquid aumentaron a 5.5 B$, en parte por la anticipación del soporte nativo de USDC. En el lado nativo, proyectos como Hyperstable han lanzado una stablecoin sobrecolateralizada (USH) en HyperEVM con un token de gobernanza que genera rendimiento, PEG, agregando diversidad a las opciones de stablecoin disponibles para traders y usuarios de DeFi.
  • Infraestructura DeFi Innovadora: Las capacidades únicas de Hyperliquid han estimulado la innovación en el diseño de DEX y derivados. Valantis, por ejemplo, es un protocolo de DEX modular en HyperEVM que permite a los desarrolladores crear AMMs personalizados y "pools soberanos" con lógica especializada. Soporta características avanzadas como tokens de rebase y tarifas dinámicas, y tiene 44 M$ de TVL, lo que demuestra que los equipos ven a Hyperliquid como un terreno fértil para impulsar el diseño de DeFi. Específicamente para los perpetuos, la comunidad aprobó la HIP-3, que abrió el motor Core de Hyperliquid a cualquiera que quiera lanzar un nuevo mercado de perpetuos. Esto es un cambio de juego: significa que si un usuario quiere un mercado de perpetuos para, digamos, un índice bursátil o una materia prima, puede desplegarlo (sujeto a los parámetros de gobernanza) sin necesidad del equipo de Hyperliquid, un marco de derivados verdaderamente sin permisos, muy similar a lo que hizo Uniswap para los swaps de ERC20. Ya están apareciendo mercados lanzados por la comunidad para activos novedosos, demostrando el poder de esta apertura.
  • Análisis, Bots y Herramientas: Ha surgido una vibrante gama de herramientas para apoyar a los traders en Hyperliquid. Por ejemplo, PvP.trade es un bot de trading basado en Telegram que se integra con la API de Hyperliquid, permitiendo a los usuarios ejecutar operaciones de perpetuos a través del chat e incluso seguir las posiciones de amigos para una experiencia de trading social. Llevó a cabo un programa de puntos y un airdrop de tokens que resultó bastante popular. En el lado del análisis, plataformas impulsadas por IA como Insilico Terminal y Katoshi AI han añadido soporte para Hyperliquid, proporcionando a los traders señales de mercado avanzadas, bots de estrategia automatizados y análisis predictivos adaptados a los mercados de Hyperliquid. La presencia de estas herramientas de terceros indica que los desarrolladores ven a Hyperliquid como un mercado significativo, para el cual vale la pena construir bots y terminales, de manera similar a cómo existen muchas herramientas para Binance o Uniswap. Además, los proveedores de infraestructura han adoptado Hyperliquid: QuickNode y otros ofrecen puntos finales RPC para la cadena de Hyperliquid, Nansen ha integrado los datos de Hyperliquid en su rastreador de portafolios, y los exploradores de blockchain y agregadores están soportando la red. Esta adopción de infraestructura es crucial para la experiencia del usuario y significa que Hyperliquid es reconocido como una red importante en el panorama multi-cadena.
  • NFTs y Juegos: Más allá de las finanzas puras, el ecosistema de Hyperliquid también incursiona en los NFT y los juegos cripto, añadiendo un sabor comunitario. HypurrFun es una plataforma de lanzamiento (launchpad) de memecoins que ganó atención al usar un sistema de subastas con un bot de Telegram para listar tokens de broma (como PIPyPIP y JEFF) en el mercado spot de Hyperliquid. Proporcionó una experiencia divertida, al estilo de Pump.win, para la comunidad y fue fundamental para probar los mecanismos de subasta de tokens de Hyperliquid antes de HyperEVM. Proyectos de NFT como Hypio (una colección de NFT que integra utilidad DeFi) se han lanzado en Hyperliquid, e incluso un juego impulsado por IA (TheFarm.fun) está aprovechando la cadena para acuñar NFT creativos y planificar un airdrop de tokens. Estos pueden ser de nicho, pero indican que se está formando una comunidad orgánica: traders que también participan en memes, NFT y juegos sociales en la misma cadena, aumentando la retención de usuarios.

Alianzas Estratégicas: Junto con los proyectos de base, el equipo de Hyperliquid (a través de la Fundación Hyper) ha buscado activamente alianzas para extender su alcance:

  • Billetera Phantom (Ecosistema Solana): En julio de 2025, Hyperliquid anunció una importante alianza con Phantom, la popular billetera de Solana, para llevar el trading de perpetuos dentro de la billetera a los usuarios de Phantom. Esta integración permite que la aplicación móvil de Phantom (con millones de usuarios) opere perpetuos de Hyperliquid de forma nativa, sin salir de la interfaz de la billetera. Más de 100 mercados con hasta 50× de apalancamiento estuvieron disponibles en Phantom, cubriendo BTC, ETH, SOL y más, con controles de riesgo incorporados como órdenes de stop-loss. La importancia es doble: da a los usuarios de la comunidad de Solana un fácil acceso a los mercados de Hyperliquid (puenteando ecosistemas), y muestra la fortaleza de la API y el backend de Hyperliquid; Phantom no integraría un DEX que no pudiera manejar un gran flujo de usuarios. El equipo de Phantom destacó que la liquidez y la rápida liquidación de Hyperliquid fueron clave para ofrecer una experiencia de trading móvil fluida. Esta alianza esencialmente incrusta a Hyperliquid como el "motor de perpetuos" dentro de una billetera cripto líder, reduciendo drásticamente la fricción para que nuevos usuarios comiencen a operar en Hyperliquid. Es una victoria estratégica para la adquisición de usuarios y demuestra la intención de Hyperliquid de colaborar en lugar de competir con otros ecosistemas (Solana en este caso).
  • Circle (USDC): Como se mencionó, la alianza de Circle para desplegar USDC nativo a través de CCTP en Hyperliquid es una integración fundamental. No solo legitima a Hyperliquid como una cadena de primera clase a los ojos de un importante emisor de stablecoins, sino que también resuelve una pieza crítica de infraestructura: la liquidez fiduciaria. Cuando Circle active el USDC nativo para Hyperliquid, los traders podrán transferir dólares dentro y fuera de la red de Hyperliquid con la misma facilidad (y confianza) que mover USDC en Ethereum o Solana. Esto agiliza el arbitraje y los flujos entre exchanges. Además, el Protocolo de Transferencia entre Cadenas v2 de Circle permitirá que el USDC se mueva entre Hyperliquid y otras cadenas sin intermediarios, integrando aún más a Hyperliquid en la red de liquidez multi-cadena. Para julio de 2025, la anticipación de la llegada de USDC y otros activos ya había impulsado los pools de activos totales de Hyperliquid a 5.5 B$. Podemos esperar que este número crezca una vez que la integración de Circle esté completamente activa. En esencia, esta alianza aborda una de las últimas barreras para los traders: rampas de entrada/salida de fiat fáciles hacia el entorno de alta velocidad de Hyperliquid.
  • Creadores de Mercado y Socios de Liquidez: Aunque no siempre se publicitan, es probable que Hyperliquid haya cultivado relaciones con empresas profesionales de creación de mercado (market-making) para iniciar la liquidez de su libro de órdenes. La profundidad observada (a menudo rivalizando con Binance en algunos pares) sugiere que los principales proveedores de liquidez cripto (posiblemente empresas como Wintermute, Jump, etc.) están creando mercados activamente en Hyperliquid. Un indicador indirecto: Auros Global, una firma de trading, publicó una guía "Hyperliquid listing 101" a principios de 2025 señalando que Hyperliquid promedió 6.1 B$ de volumen diario de perpetuos en el primer trimestre de 2025, lo que implica que los creadores de mercado están prestando atención. Además, el diseño de Hyperliquid (con incentivos como reembolsos para makers o rendimientos de HLP) y el beneficio de no tener gas son muy atractivos para las empresas de HFT (High-Frequency Trading). Aunque no se nombran alianzas específicas con MM, el ecosistema se beneficia claramente de su participación.
  • Otros: La Fundación Hyper, que gestiona el desarrollo del protocolo, ha iniciado iniciativas como un Programa de Delegación para incentivar a validadores fiables y programas comunitarios globales (se celebró un Hackatón con 250k $ en premios en 2025). Estos ayudan a fortalecer la descentralización de la red y a atraer nuevo talento. También hay colaboración con proveedores de oráculos (Chainlink o Pyth) para datos externos cuando sea necesario; por ejemplo, si se lanzan mercados de activos sintéticos del mundo real, esas alianzas serán importantes. Dado que Hyperliquid es compatible con EVM, las herramientas de Ethereum (como Hardhat, The Graph, etc.) pueden extenderse con relativa facilidad a Hyperliquid a medida que los desarrolladores lo demanden.

Comunidad y Gobernanza: La participación de la comunidad en Hyperliquid ha sido alta debido al airdrop temprano y a las votaciones de gobernanza en curso. El marco de Propuestas de Mejora de Hyperliquid (HIP) ha visto la aprobación de propuestas importantes (HIP-1 a HIP-3) en su primer año, lo que indica un proceso de gobernanza activo. La comunidad ha desempeñado un papel en los listados de tokens a través del modelo de subasta de Hyperliquid: los nuevos tokens se lanzan a través de una subasta on-chain (a menudo facilitada por HypurrFun o similar), y las subastas exitosas se listan en el libro de órdenes. Este proceso, aunque requiere permiso a través de una tarifa y una investigación, ha permitido que los tokens impulsados por la comunidad (como las memecoins) ganen tracción en Hyperliquid sin un control centralizado. También ayudó a Hyperliquid a evitar tokens de spam, ya que hay un costo para listar, asegurando que solo proyectos serios o comunidades entusiastas lo persigan. El resultado es un ecosistema que equilibra la innovación sin permisos con un grado de control de calidad, un enfoque novedoso en DeFi.

Además, la Fundación Hyper (una entidad sin fines de lucro) se estableció para apoyar el crecimiento del ecosistema. Ha sido responsable de iniciativas como el lanzamiento del token $HYPE y la gestión de los fondos de incentivos. La decisión de la Fundación de no emitir incentivos de manera imprudente (como se señaló en The Defiant, no proporcionaron minería de liquidez adicional después del airdrop) puede haber moderado inicialmente a algunos "yield-farmers", pero subraya un enfoque en el uso orgánico sobre los aumentos de TVL a corto plazo. Esta estrategia parece haber dado sus frutos con un crecimiento constante. Ahora, movimientos como la participación de EtherFi y otros muestran que incluso sin una minería de liquidez masiva, la actividad DeFi real está echando raíces en Hyperliquid debido a sus oportunidades únicas (como altos rendimientos de los ingresos reales por tarifas y acceso a una base de trading activa).

Para resumir, Hyperliquid en 2025 está rodeado de un ecosistema floreciente y alianzas sólidas. Su cadena alberga una pila DeFi completa, desde perpetuos y trading spot, hasta AMMs, préstamos, stablecoins, staking líquido, NFTs y más, gran parte de lo cual surgió en el último año. Las alianzas estratégicas con entidades como Phantom y Circle están expandiendo su alcance de usuarios y el acceso a la liquidez en todo el universo cripto. Los aspectos impulsados por la comunidad (subastas, gobernanza, hackatones) muestran una base de usuarios comprometida que está cada vez más invertida en el éxito de Hyperliquid. Todos estos factores refuerzan la posición de Hyperliquid como más que un exchange; se está convirtiendo en una capa financiera holística.

Perspectivas Futuras: La Visión de Hyperliquid para las Finanzas Onchain (Derivados, RWA y Más Allá)

El rápido ascenso de Hyperliquid plantea la pregunta: ¿Qué sigue? La visión del proyecto siempre ha sido ambiciosa: convertirse en la infraestructura fundamental para todas las finanzas onchain. Habiendo logrado el dominio en los perpetuos on-chain, Hyperliquid está preparado para expandirse a nuevos productos y mercados, remodelando potencialmente cómo los activos financieros tradicionales interactúan con las criptomonedas. Aquí hay algunos elementos clave de su visión a futuro:

  • Ampliación de la Suite de Derivados: Los futuros perpetuos fueron la cabeza de playa inicial, pero Hyperliquid puede extenderse a otros derivados. La arquitectura (HyperCore + HyperEVM) podría soportar instrumentos adicionales como opciones, swaps de tasas de interés o productos estructurados. Un siguiente paso lógico podría ser un exchange de opciones on-chain o un AMM de opciones lanzándose en HyperEVM, aprovechando la liquidez y la rápida ejecución de la cadena. Con un estado unificado, un protocolo de opciones en Hyperliquid podría cubrirse directamente a través del libro de órdenes de perpetuos, creando una gestión de riesgos eficiente. Aún no hemos visto surgir una plataforma importante de opciones on-chain en Hyperliquid, pero dado el crecimiento del ecosistema, es plausible para 2025-26. Además, los futuros tradicionales y los derivados tokenizados (p. ej., futuros sobre índices bursátiles, materias primas o tasas de cambio) podrían introducirse a través de propuestas HIP, esencialmente trayendo los mercados financieros tradicionales a la cadena. La HIP-3 de Hyperliquid ya allanó el camino para listar “cualquier activo, cripto o tradicional” como un mercado de perpetuos siempre que haya un oráculo o una fuente de precios. Esto abre la puerta para que los miembros de la comunidad lancen mercados sobre acciones, oro u otros activos de manera sin permisos. Si la liquidez y las consideraciones legales lo permiten, Hyperliquid podría convertirse en un centro para el trading tokenizado 24/7 de mercados del mundo real, algo que incluso muchos CEX no ofrecen a escala. Tal desarrollo realizaría verdaderamente la visión de una plataforma de trading global unificada on-chain.
  • Activos del Mundo Real (RWA) y Mercados Regulados: Puentes entre los activos del mundo real y DeFi es una tendencia importante, y Hyperliquid está bien posicionado para facilitarlo. A través de HyperUnit y alianzas como la de Circle, la cadena se está integrando con activos reales (fiat a través de USDC, BTC/SOL a través de tokens envueltos). El siguiente paso podría ser el trading de valores o bonos tokenizados en Hyperliquid. Por ejemplo, uno podría imaginar un futuro donde los bonos del gobierno o las acciones se tokenicen (quizás bajo un sandbox regulatorio) y se negocien en los libros de órdenes de Hyperliquid 24/7. El diseño de Hyperliquid ya es “consciente de la regulación”: el uso de activos nativos en lugar de pagarés sintéticos puede simplificar el cumplimiento. La Fundación Hyper podría explorar trabajar con jurisdicciones para permitir ciertos RWA en la plataforma, especialmente a medida que mejora la tecnología de KYC/listas blancas on-chain (HyperEVM podría soportar pools con permisos si fuera necesario para activos regulados). Incluso sin tokens RWA formales, los perpetuos sin permisos de Hyperliquid podrían listar derivados que sigan a los RWA (por ejemplo, un swap perpetuo sobre el índice S&P 500). Eso traería exposición a los RWA a los usuarios de DeFi de una manera indirecta pero efectiva. En resumen, Hyperliquid tiene como objetivo difuminar la línea entre los mercados cripto y los mercados tradicionales; para albergar todas las finanzas, eventualmente necesitas acomodar activos y participantes del lado tradicional. Se están sentando las bases (en tecnología y liquidez) para esa convergencia.
  • Escalabilidad e Interoperabilidad: Hyperliquid continuará escalando verticalmente (más rendimiento, más validadores) y probablemente horizontalmente a través de la interoperabilidad. Con el IBC de Cosmos u otros protocolos cross-chain, Hyperliquid podría conectarse a redes más amplias, permitiendo que los activos y los mensajes fluyan sin confianza. Ya utiliza el CCTP de Circle para USDC; la integración con algo como el CCIP de Chainlink o el IBC de Cosmos podría extender las posibilidades de trading cross-chain. Hyperliquid podría convertirse en un centro de liquidez al que otras cadenas recurran (imagina dApps en Ethereum o Solana ejecutando operaciones en Hyperliquid a través de puentes sin confianza, obteniendo la liquidez de Hyperliquid sin salir de su cadena nativa). La mención de Hyperliquid como un “centro de liquidez” y su creciente participación en el interés abierto (ya ~18 % de todo el OI de futuros cripto a mediados de 2025) indica que podría anclar una red más grande de protocolos DeFi. El enfoque colaborativo de la Fundación Hyper (p. ej., asociándose con billeteras, otras L1) sugiere que ven a Hyperliquid como parte de un futuro multi-cadena en lugar de una isla aislada.
  • Infraestructura DeFi Avanzada: Al combinar un exchange de alto rendimiento con programabilidad general, Hyperliquid podría permitir productos financieros sofisticados que antes no eran factibles on-chain. Por ejemplo, se pueden construir fondos de cobertura on-chain o estrategias de bóveda en HyperEVM que ejecuten estrategias complejas directamente a través de HyperCore (arbitraje, creación de mercado automatizada en libros de órdenes, etc.) todo en una sola cadena. Esta integración vertical elimina ineficiencias como mover fondos entre capas o ser víctima de front-running por bots de MEV durante el arbitraje cross-chain; todo puede suceder bajo el consenso de HyperBFT con total atomicidad. Podríamos ver un crecimiento en bóvedas de estrategia automatizadas que utilizan las primitivas de Hyperliquid para generar rendimiento (algunas bóvedas tempranas probablemente ya existen, posiblemente gestionadas por HyperBeat u otros). El fundador de Hyperliquid resumió la estrategia como “pulir una aplicación nativa y luego crecer hacia una infraestructura de propósito general”. Ahora que la aplicación de trading nativa está pulida y hay una amplia base de usuarios, la puerta está abierta para que Hyperliquid se convierta en una capa de infraestructura DeFi general. Esto podría ponerlo en competencia no solo con los DEX, sino con las Capas 1 como Ethereum o Solana para alojar dApps financieras, aunque la especialidad de Hyperliquid seguirá siendo cualquier cosa que requiera una profunda liquidez o baja latencia.
  • Adopción Institucional y Cumplimiento: El futuro de Hyperliquid probablemente implique cortejar a los actores institucionales (fondos de cobertura, creadores de mercado, incluso empresas fintech) para que usen la plataforma. El interés institucional ya está aumentando dados los volúmenes y el hecho de que empresas como Coinbase, Robinhood y otras están considerando los perpetuos. Hyperliquid podría posicionarse como el proveedor de infraestructura para que las instituciones se muevan on-chain. Podría ofrecer características como subcuentas, herramientas de informes de cumplimiento o pools con listas blancas (si es necesario para ciertos usuarios regulados), todo mientras se preserva la naturaleza pública y on-chain para el comercio minorista. El clima regulatorio influirá en esto: si las jurisdicciones aclaran el estado de los derivados DeFi, Hyperliquid podría convertirse en un lugar con licencia de alguna forma o permanecer como una red puramente descentralizada a la que las instituciones se conectan indirectamente. La mención de un “diseño consciente de la regulación” sugiere que el equipo es consciente de lograr un equilibrio que permita la integración con el mundo real sin infringir las leyes.
  • Empoderamiento Continuo de la Comunidad: A medida que la plataforma crezca, más toma de decisiones podría trasladarse a los tenedores de tokens. Podemos esperar que futuras HIPs cubran cosas como ajustar los parámetros de las tarifas, asignar el fondo de incentivos (el ~39 % del suministro reservado), introducir nuevos productos (p. ej., si se propusiera un módulo de opciones) y expandir los conjuntos de validadores. La comunidad jugará un papel importante en la guía de la trayectoria de Hyperliquid, actuando efectivamente como los accionistas de este exchange descentralizado. El tesoro comunitario (financiado por cualquier token aún no distribuido y posiblemente por cualquier ingreso no utilizado en recompras) podría dirigirse a financiar nuevos proyectos en Hyperliquid o proporcionar subvenciones, reforzando aún más el desarrollo del ecosistema.

Conclusión: Hyperliquid en 2025 ha logrado lo que muchos pensaban imposible: un exchange completamente on-chain que rivaliza con las plataformas centralizadas en rendimiento y liquidez. Su arquitectura técnica (HyperBFT, HyperCore, HyperEVM) ha demostrado ser un modelo para la próxima generación de redes financieras. El modelo del token $HYPE alinea estrechamente a la comunidad con el éxito de la plataforma, creando una de las economías de tokens más lucrativas y deflacionarias de DeFi. Con volúmenes de trading masivos, una base de usuarios en expansión y un ecosistema DeFi de rápido crecimiento a su alrededor, Hyperliquid se ha posicionado como una capa 1 de primer nivel para aplicaciones financieras. Mirando hacia el futuro, su visión de convertirse en “la blockchain para albergar todas las finanzas” no parece descabellada. Al traer más clases de activos on-chain (potencialmente incluyendo activos del mundo real) y continuar integrándose con otras redes y socios, Hyperliquid podría servir como la columna vertebral de un sistema financiero verdaderamente global, 24/7 y descentralizado. En tal futuro, las líneas entre los mercados cripto y tradicionales se difuminan, y la mezcla de alto rendimiento y arquitectura sin confianza de Hyperliquid bien podría ser el modelo que los una, construyendo el futuro de las finanzas onchain, un bloque a la vez.

Fuentes:

  1. Blog de QuickNode – “Hyperliquid in 2025: A High-Performance DEX...” (Arquitectura, métricas, tokenomics, visión)
  2. Artemis Research – “Hyperliquid: A Valuation Model and Bull Case” (Cuota de mercado, modelo de token, comparaciones)
  3. The Defiant – “EtherFi Expands to HyperLiquid…HyperBeat” (TVL del ecosistema, interés institucional)
  4. BlockBeats – “Inside Hyperliquid’s Growth – Semiannual Report 2025” (Métricas on-chain, volumen, OI, estadísticas de usuarios)
  5. Coingape – “Hyperliquid Expands to Solana via Phantom Partnership” (Integración con la billetera Phantom, perpetuos móviles)
  6. Mitrade/Cryptopolitan – “Circle integrates USDC with Hyperliquid” (Lanzamiento de USDC nativo, 5.5 B$ de AUM)
  7. Nansen – “What is Hyperliquid? – Blockchain DEX & Trading Explained” (Descripción técnica, finalidad de menos de un segundo, usos del token)
  8. DeFi Prime – “Exploring the Hyperliquid Chain Ecosystem: Deep Dive” (Proyectos del ecosistema: DEX, préstamos, NFTs, etc.)
  9. Wiki/Docs de Hyperliquid – GitBook y Estadísticas de Hyperliquid (Listados de activos a través de HIPs, panel de estadísticas)
  10. CoinMarketCap – Listado de Hyperliquid (HYPE) (Información básica sobre la L1 de Hyperliquid y el diseño del libro de órdenes on-chain)

¿Qué son los airdrops de criptomonedas? Una guía concisa para constructores y usuarios (edición 2025)

· 12 min de lectura
Dora Noda
Software Engineer

TL;DR

Un airdrop de cripto es una distribución de tokens a direcciones de billetera específicas — a menudo de forma gratuita — para impulsar una red, descentralizar la propiedad o recompensar a los primeros miembros de la comunidad. Los métodos más populares incluyen recompensas retroactivas por acciones pasadas, conversiones de puntos a tokens, drops para poseedores de NFT o tokens, y campañas interactivas tipo “misión”. El diablo está en los detalles: reglas de snapshot, mecánicas de reclamo como pruebas Merkle, resistencia Sybil, comunicación clara y cumplimiento legal son críticos para el éxito. Para los usuarios, el valor está ligado a la tokenómica y la seguridad. Para los equipos, un airdrop exitoso debe alinearse con los objetivos centrales del producto, no solo generar hype temporal.


¿Qué es realmente un airdrop?

En esencia, un airdrop de cripto es una estrategia de marketing y distribución donde un proyecto envía su token nativo a las billeteras de un grupo específico de usuarios. No es solo un regalo; es una jugada calculada para alcanzar metas concretas. Según recursos educativos de Coinbase y Binance Academy, los airdrops se usan comúnmente cuando una nueva red, protocolo DeFi o dApp quiere construir rápidamente una base de usuarios. Al dar tokens a usuarios potenciales, los proyectos pueden incentivarlos a participar en la gobernanza, proveer liquidez, probar nuevas funcionalidades o simplemente convertirse en miembros activos de la comunidad, impulsando el efecto red.

Dónde aparecen los airdrops en la práctica

Los airdrops vienen en varios sabores, cada uno con un propósito estratégico distinto. Aquí están los modelos más comunes que se observan hoy en día.

Retroactivo (recompensa por comportamiento pasado)

Este es el modelo clásico, diseñado para premiar a los adoptadores tempranos que usaron un protocolo antes de que tuviera token. El airdrop de Uniswap en 2020 es el ejemplo definitivo, estableciendo la plantilla moderna al distribuir 400UNI400 UNI tokens a cada dirección que haya interactuado con el protocolo. Fue un “gracias” poderoso que convirtió a los usuarios en propietarios de la noche a la mañana.

Puntos → token (incentivos primero, token después)

Tendencia dominante en 2024 y 2025, el modelo de puntos gamifica la participación. Los proyectos rastrean acciones de los usuarios — como puentes, swaps o staking — y otorgan “puntos” off‑chain. Más tarde, esos puntos se convierten en una asignación de tokens. Este enfoque permite a los equipos medir e incentivar comportamientos deseados durante un período más largo antes de comprometerse con un lanzamiento de token.

Drops para poseedores/NFT

Este tipo de airdrop se dirige a usuarios que ya poseen un token o NFT específico. Es una forma de recompensar la lealtad dentro de un ecosistema existente o de impulsar un nuevo proyecto con una comunidad comprometida. Un caso famoso es ApeCoin, que concedió derechos de reclamo de su token $APE a los poseedores de los NFT Bored Ape y Mutant Ape Yacht Club al lanzar en 2022.

Programas de ecosistema/gobernanza

Algunos proyectos usan una serie de airdrops como parte de una estrategia a largo plazo para descentralización y crecimiento comunitario. Optimism, por ejemplo, ha realizado múltiples airdrops para usuarios, al tiempo que reserva una porción significativa de su suministro de tokens para financiar bienes públicos mediante su programa RetroPGF. Esto demuestra un compromiso con la construcción de un ecosistema sostenible y alineado con el valor.

Cómo funciona un airdrop (mecánicas que importan)

La diferencia entre un airdrop exitoso y uno caótico suele reducirse a la ejecución técnica y estratégica. Estas son las mecánicas que realmente importan.

Snapshot y elegibilidad

Primero, el proyecto debe decidir quién califica. Esto implica elegir un snapshot — una altura de bloque o fecha específica — después de la cual la actividad del usuario ya no se contará. Luego se definen criterios de elegibilidad basados en los comportamientos que el proyecto quiera recompensar, como puentes de fondos, swaps, provisión de liquidez, participación en gobernanza o incluso contribuciones de código. Para su airdrop, Arbitrum colaboró con la firma de analítica Nansen para desarrollar un modelo de distribución sofisticado basado en un snapshot tomado en un bloque específico el 6 de febrero de 2023.

Reclamo vs. envío directo

Aunque enviar tokens directamente a billeteras parece más simple, la mayoría de los proyectos maduros usan un flujo basado en reclamo. Esto evita que los tokens se envíen a direcciones perdidas o comprometidas y requiere que los usuarios participen activamente. El patrón más común es un Distribuidor Merkle. El proyecto publica una huella criptográfica (una raíz Merkle) de las direcciones elegibles on‑chain. Cada usuario puede generar una “prueba” única para verificar su elegibilidad y reclamar sus tokens. Este método, popularizado por la implementación open‑source de Uniswap, es eficiente en gas y seguro.

Resistencia Sybil

Los airdrops son un objetivo principal para los “farmers” — individuos que usan cientos o miles de billeteras (un “ataque Sybil”) para maximizar sus recompensas. Los equipos emplean varios métodos para combatir esto: usar analítica para agrupar billeteras controladas por una sola entidad, aplicar heurísticas (como edad de la billetera o diversidad de actividad) y, más recientemente, implementar programas de autorreporte. La campaña de LayerZero en 2024 introdujo un modelo ampliamente discutido donde los usuarios podían autorreportar actividad Sybil a cambio de una asignación del 15 %; quienes no lo hicieron y fueron atrapados después fueron excluidos.

Calendario de liberación y gobernanza

No todos los tokens de un airdrop están disponibles de inmediato. Muchos proyectos implementan un calendario de liberación (o período de vesting) para asignaciones a equipo, inversores y fondos del ecosistema. Entender este calendario es crucial para que los usuarios evalúen la presión futura de suministro en el mercado. Plataformas como TokenUnlocks ofrecen paneles públicos que rastrean estas líneas de tiempo en cientos de activos.

Estudios de caso (datos rápidos)

  • Uniswap (2020): Distribuyó 400UNI400 UNI por dirección elegible, con asignaciones mayores para proveedores de liquidez. Estableció el modelo de reclamo basado en pruebas Merkle como estándar de la industria y demostró el poder de recompensar retroactivamente a una comunidad.
  • Arbitrum (2023): Lanzó su token de gobernanza L2, $ARB, con una oferta inicial de 10 mil millones. El airdrop usó un sistema de puntos basado en actividad on‑chain antes de un snapshot del 6 de febrero de 2023, incorporando analítica avanzada y filtros Sybil de Nansen.
  • Starknet (2024): Nombró su airdrop como el “Programa de Provisiones”, con reclamos abiertos el 20 de febrero de 2024. Apuntó a una amplia gama de contribuyentes, incluidos usuarios tempranos, desarrolladores de red e incluso stakers de Ethereum, ofreciendo una ventana de varios meses para reclamar.
  • ZKsync (2024): Anunciado el 11 de junio de 2024, fue una de las mayores distribuciones de usuarios en Layer 2 hasta la fecha. Un airdrop único distribuyó el 17,5 % del suministro total a casi 700 000 billeteras, recompensando a la comunidad temprana del protocolo.

Por qué los equipos hacen airdrops (y cuándo no deberían)

Los equipos utilizan airdrops por varias razones estratégicas:

  • Impulsar una red de dos caras: Los airdrops pueden sembrar una red con los participantes necesarios, ya sean proveedores de liquidez, traders, creadores o restakers.
  • Descentralizar la gobernanza: Distribuir tokens a una base amplia de usuarios activos es un paso fundamental hacia una descentralización creíble y una gobernanza liderada por la comunidad.
  • Recompensar a los primeros contribuyentes: Para proyectos que no realizaron ICO o venta de tokens, el airdrop es la forma principal de premiar a los creyentes tempranos que aportaron valor cuando el resultado era incierto.
  • Comunicar valores: El diseño de un airdrop puede transmitir los principios centrales de un proyecto. El enfoque de Optimism en financiar bienes públicos es un ejemplo claro.

Sin embargo, los airdrops no son una solución mágica. Los equipos no deberían lanzar un airdrop si el producto tiene baja retención, la comunidad es débil o la utilidad del token está mal definida. Un airdrop amplifica los bucles de retroalimentación positivos existentes; no puede arreglar un producto defectuoso.

Para usuarios: cómo evaluar y participar — de forma segura

Los airdrops pueden ser lucrativos, pero también conllevan riesgos significativos. Aquí tienes una guía para navegar de forma segura.

Antes de perseguir un drop

  • Verifica la legitimidad: Siempre confirma los anuncios de airdrop a través de los canales oficiales del proyecto (sitio web, cuenta de X, Discord). Desconfía mucho de enlaces de “reclamo” enviados por DM, encontrados en anuncios o promocionados por cuentas no verificadas.
  • Mapea la economía: Entiende la tokenómica. ¿Cuál es el suministro total? ¿Qué porcentaje se asigna a usuarios? ¿Cuál es el calendario de vesting para insiders? Herramientas como TokenUnlocks pueden ayudarte a rastrear futuras liberaciones de suministro.
  • Conoce el estilo: ¿Es un drop retroactivo que recompensa comportamientos pasados, o un programa de puntos que requiere participación continua? Las reglas difieren, y los programas de puntos pueden cambiar sus criterios con el tiempo.

Higiene de la billetera

  • Usa una billetera nueva: Cuando sea posible, emplea una billetera dedicada y de bajo valor (“burner”) para reclamar airdrops. Así aísla el riesgo de tus tenencias principales.
  • Lee lo que firmas: Nunca apruebes transacciones a ciegas. Sitios maliciosos pueden engañarte para que firmes permisos que les permitan drenar tus activos. Usa simuladores de billetera para entender una transacción antes de firmar. Revisa y revoca aprobaciones obsoletas periódicamente con herramientas como Revoke.cash.
  • Cuidado con firmas off‑chain: Los estafadores abusan cada vez más de firmas Permit y Permit2, que son aprobaciones off‑chain que pueden usarse para mover tus activos sin una transacción on‑chain. Sé tan cauteloso con estas como con las aprobaciones on‑chain.

Riesgos comunes

  • Phishing y drenadores: El riesgo más frecuente es interactuar con un sitio “de reclamo” falso diseñado para drenar tu billetera. Investigaciones de firmas como Scam Sniffer muestran que kits de drenaje sofisticados fueron responsables de pérdidas masivas en 2023‑2025.
  • Geofencing y KYC: Algunos airdrops pueden tener restricciones geográficas o requerir verificación KYC. Lee siempre los términos y condiciones, ya que residentes de ciertos países pueden quedar excluidos.
  • Impuestos (orientación rápida, no asesoría): El tratamiento fiscal varía por jurisdicción. En EE. UU., el IRS generalmente trata los tokens airdropeados como ingreso gravable al valor de mercado justo en la fecha en que tomas control de ellos. En el Reino Unido, HMRC puede considerar un airdrop como ingreso si realizaste una acción para recibirlo. Disponer de los tokens más tarde puede generar Ganancias de Capital. Consulta a un profesional calificado.

Para equipos: lista de verificación pragmática de diseño de airdrop

¿Planeando un airdrop? Aquí tienes una lista para guiar tu proceso de diseño.

  1. Clarifica el objetivo: ¿Qué buscas lograr? ¿Recompensar uso real, descentralizar la gobernanza, sembrar liquidez o financiar constructores? Define tu meta principal y haz explícito el comportamiento objetivo.
  2. Establece elegibilidad que refleje tu producto: Diseña criterios que premien a usuarios pegajosos y de alta calidad. Pondera acciones que correlacionen con retención (por ejemplo, balances ponderados por tiempo, trading consistente) sobre simple volumen, y considera limitar recompensas para “whales”. Estudia post‑mortems públicos de airdrops mayores en plataformas como Nansen.
  3. Construye resistencia Sybil: No dependas de un solo método. Combina heurísticas on‑chain (edad de la billetera, diversidad de actividad) con análisis de clustering. Considera enfoques novedosos como el modelo de autorreporte asistido por la comunidad pionero por LayerZero.
  4. Implementa un flujo de reclamo robusto: Usa un contrato Distribuidor Merkle probado en batalla. Publica el dataset completo y el árbol Merkle para que cualquiera pueda verificar de forma independiente la raíz y su propia elegibilidad. Mantén la UI de reclamo mínima, auditada y con limitación de velocidad para manejar picos sin saturar tus endpoints RPC.
  5. Comunica el plan de liberación: Sé transparente sobre el suministro total de tokens, asignaciones para diferentes grupos de receptores (comunidad, equipo, fondos) y el calendario de vesting. Esto ayuda a los usuarios a evaluar riesgos de dilución futura.
  6. Cumplimiento legal: Revisa regulaciones locales e internacionales sobre distribución de valores. Considera obtener opiniones legales antes del anuncio público.

Implementación en Blockseed

Blockseed facilita la creación y gestión de airdrops con una arquitectura modular que incluye:

  • Módulo de Snapshot: Captura automática de estados de balances en bloques específicos, con soporte para múltiples cadenas.
  • Generador de Pruebas Merkle: Herramienta de línea de comandos que crea árboles Merkle a partir de listas de elegibilidad y exporta pruebas listas para usar en contratos.
  • Panel de Resistencia Sybil: Dashboard que muestra métricas de concentración de billeteras, puntuaciones de riesgo Sybil y permite aplicar filtros personalizados.
  • Gestor de Reclamos: Interfaz web alojada que se conecta a tu contrato Merkle, con soporte para firmas off‑chain (Permit) y opciones de autorreporte.
  • Monitor de Cumplimiento: Integración con proveedores de KYC/AML y generación de reportes regulatorios automatizados.
  • Analytics de Tokenomics: Visualizaciones de distribución de tokens, vesting y simulaciones de impacto en el mercado.

Con estas herramientas, los equipos pueden lanzar airdrops que sean seguros, transparentes y alineados con su visión estratégica, mientras que los usuarios disfrutan de una experiencia de reclamo sencilla y protegida.

Conclusión

Los airdrops de cripto siguen siendo una de las tácticas más efectivas para acelerar la adopción, fortalecer comunidades y distribuir valor de manera descentralizada. Sin embargo, su éxito depende de una planificación meticulosa, ejecución técnica sólida y comunicación clara. Tanto constructores como usuarios deben abordar los airdrops con una mentalidad crítica: evaluar la tokenómica, verificar la legitimidad y proteger sus activos. Cuando se hacen bien, los airdrops pueden ser una poderosa palanca para impulsar la innovación y la participación en el ecosistema blockchain.

Construyendo experiencias sin gas con Sui Paymaster: Guía de arquitectura e implementación

· 11 min de lectura
Dora Noda
Software Engineer

Imagina un mundo donde los usuarios puedan interactuar con tu dApp de forma fluida, sin necesidad de poseer tokens nativos (SUI). Esto ya no es un sueño lejano. Con la Gas Station de Sui (también conocida como Paymaster), los desarrolladores pueden cubrir las tarifas de gas en nombre de sus usuarios, eliminando por completo una de las mayores barreras para los nuevos participantes en Web3 y habilitando una experiencia verdaderamente sin fricción en cadena.

Este artículo ofrece una guía completa para actualizar tu dApp y hacerla sin gas. Profundizaremos en los conceptos centrales del Sui Paymaster, su arquitectura, patrones de implementación y mejores prácticas.

1. Antecedentes y conceptos clave: ¿Qué es una transacción patrocinada?

En el mundo de la blockchain, cada transacción requiere una tarifa de red, o “gas”. Para los usuarios acostumbrados a la fluidez de Web2, esto representa un obstáculo cognitivo y operativo significativo. Sui aborda este desafío a nivel de protocolo con Transacciones Patrocinadas.

La idea central es simple: permitir que una parte (el Patrocinador) pague las tarifas de gas en SUI por la transacción de otra parte (el Usuario). De este modo, incluso si un usuario no tiene SUI en su billetera, puede iniciar acciones en cadena con éxito.

Paymaster ≈ Gas Station

En el ecosistema Sui, la lógica para patrocinar transacciones suele ser manejada por un servicio fuera de cadena o en cadena llamado Gas Station o Paymaster. Sus responsabilidades principales incluyen:

  1. Evaluar la transacción: recibe los datos de la transacción sin gas del usuario (GasLessTransactionData).
  2. Proveer gas: bloquea y asigna la tarifa de gas necesaria para la transacción. Esto normalmente se gestiona mediante un pool de gas compuesto por muchos objetos SUI Coin.
  3. Generar una firma del patrocinador: tras aprobar el patrocinio, la Gas Station firma la transacción con su clave privada (SponsorSig), certificando su disposición a pagar la tarifa.
  4. Devolver la transacción firmada: envía de vuelta el TransactionData, que ahora incluye los datos de gas y la firma del patrocinador, a la espera de la firma final del usuario.

En resumen, una Gas Station actúa como un servicio de repostaje para los usuarios de tu dApp, asegurando que sus “vehículos” (transacciones) puedan viajar sin problemas por la red Sui.

2. Arquitectura de alto nivel y flujo de interacción

Una transacción sin gas típica implica coordinación entre el usuario, el frontend de la dApp, la Gas Station y un nodo completo de Sui. La secuencia de interacción es la siguiente:

Desglose del flujo:

  1. El Usuario realiza una acción en la UI de la dApp, que construye un paquete de datos de transacción sin información de gas.
  2. La dApp envía estos datos a su Gas Station designada para solicitar patrocinio.
  3. La Gas Station verifica la validez de la solicitud (p. ej., comprueba si el usuario es elegible para el patrocinio), luego rellena la transacción con una Gas Coin y su firma, devolviendo la transacción semicompleta a la dApp.
  4. El Usuario ve los detalles completos de la transacción en su billetera (p. ej., “Comprar un NFT”) y proporciona la firma final. Este paso es crucial para garantizar que el usuario mantenga su consentimiento y control sobre sus acciones.
  5. La dApp difunde la transacción completa, que contiene tanto la firma del usuario como la del patrocinador, a un Nodo Completo de Sui.
  6. Tras la finalización en cadena, la Gas Station puede confirmar esto escuchando eventos o recibos en cadena y luego notificar al backend de la dApp mediante un webhook para cerrar el bucle del proceso de negocio.

3. Tres modelos de interacción principales

Puedes usar los siguientes tres modelos de interacción de forma individual o combinada, según tus necesidades comerciales.

Modelo 1: Iniciado por el usuario → Aprobado por el patrocinador (más común)

Este es el modelo estándar, adecuado para la gran mayoría de interacciones dentro de la dApp.

  1. El usuario construye GasLessTransactionData: el usuario realiza una acción dentro de la dApp.
  2. El patrocinador añade GasData y firma: el backend de la dApp envía la transacción a la Gas Station, que la aprueba, adjunta una Gas Coin y añade su firma.
  3. El usuario revisa y da la firma final: el usuario confirma los detalles finales en su billetera y firma. La dApp entonces la envía a la red.

Este modelo logra un excelente equilibrio entre seguridad y experiencia de usuario.

Modelo 2: Patrocinador inicia airdrops/incentivos

Este modelo es perfecto para airdrops, incentivos a usuarios o distribuciones masivas de activos.

  1. Patrocinador pre‑llena TransactionData + firma: el patrocinador (normalmente el equipo del proyecto) construye la mayor parte de la transacción (p. ej., airdrop de un NFT a una dirección específica) y adjunta su firma de patrocinio.
  2. La segunda firma del usuario la hace efectiva: el usuario solo necesita firmar esta transacción “pre‑aprobada” una vez para que se ejecute.

Esto crea una experiencia de usuario extremadamente fluida. Con un solo clic para confirmar, los usuarios pueden reclamar recompensas o completar tareas, aumentando drásticamente las tasas de conversión de campañas de marketing.

Modelo 3: GasData comodín (modelo de línea de crédito)

Este es un modelo más flexible y basado en permisos.

  1. El patrocinador transfiere un objeto GasData: primero crea uno o varios objetos Gas Coin con un presupuesto específico y transfiere la propiedad directamente al usuario.
  2. El usuario gasta libremente dentro del presupuesto: el usuario puede usar esos Gas Coins para pagar cualquier transacción que inicie, siempre que se mantenga dentro de los límites y el periodo de validez del presupuesto.
  3. El Gas Coin se devuelve: una vez agotado o expirado, el objeto Gas Coin puede ser diseñado para destruirse automáticamente o volver al patrocinador.

Este modelo equivale a entregar al usuario una “tarjeta de crédito de tarifas de gas” limitada en tiempo y presupuesto, adecuada para escenarios que requieren alta autonomía del usuario, como ofrecer una experiencia free‑to‑play durante una temporada de juego.

4. Escenarios de aplicación típicos

El poder del Sui Paymaster no solo radica en resolver el problema de las tarifas de gas, sino también en su capacidad de integrarse profundamente con la lógica de negocio para crear nuevas posibilidades.

Escenario 1: Paywalls

Muchas plataformas de contenido o servicios de dApp requieren que los usuarios cumplan ciertos criterios (p. ej., poseer un NFT VIP, alcanzar un nivel de membresía) para acceder a funcionalidades. El Paymaster puede implementar esta lógica de forma perfecta.

  • Flujo: un usuario solicita una acción → el backend de la dApp verifica las calificaciones del usuario (p. ej., propiedad de NFT) → si es elegible, llama al Paymaster para patrocinar la tarifa de gas; si no, simplemente niega la solicitud de firma.
  • Ventaja: este modelo es inherentemente resistente a bots y abusos. Dado que la decisión de patrocinio se toma en el backend, los usuarios malintencionados no pueden eludir la verificación de calificaciones para drenar fondos de gas.

Escenario 2: Checkout con un clic

En e‑commerce o compras dentro de juegos, simplificar el proceso de pago es crítico.

  • Flujo: el usuario hace clic en “Comprar ahora” en la página de checkout. La dApp construye una transacción que incluye la lógica de negocio (p. ej., transfer_nft_to_user). El usuario solo necesita firmar para aprobar la transacción de negocio en su billetera, sin preocuparse por el gas. La tarifa de gas la cubre el patrocinador de la dApp.
  • Ventaja: puedes codificar parámetros de negocio como un order_id directamente en el ProgrammableTransactionBlock, permitiendo una atribución on‑chain precisa para los pedidos del backend.

Escenario 3: Atribución de datos

El seguimiento preciso de datos es fundamental para la optimización del negocio.

  • Flujo: al construir la transacción, escribe un identificador único (como un order_hash) en los parámetros de la transacción o en un evento que se emitirá al ejecutarse.
  • Ventaja: cuando la Gas Station recibe el recibo on‑chain de una transacción exitosa, puede extraer fácilmente ese order_hash analizando el evento o los datos de la transacción. Esto permite mapear con precisión los cambios de estado on‑chain a pedidos o acciones específicas del backend.

5. Esqueleto de código (basado en el SDK de Rust)

A continuación se muestra un fragmento simplificado que demuestra los pasos centrales de interacción.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Para una implementación completa, consulta el Tutorial de Gas Station de la documentación oficial de Sui, que ofrece ejemplos de código listos para usar.

6. Riesgos y protecciones

Aunque potente, desplegar una Gas Station en producción requiere considerar cuidadosamente los siguientes riesgos:

  • Equivocación (doble gasto): un usuario malicioso podría intentar usar la misma Gas Coin en múltiples transacciones paralelas, lo que bloquearía la Gas Coin en la red Sui. Esto se mitiga eficazmente asignando una Gas Coin única por usuario o por transacción, manteniendo una lista negra y limitando la tasa de solicitudes de firma.
  • Gestión del pool de gas: en escenarios de alta concurrencia, una sola Gas Coin de gran valor puede convertirse en un cuello de botella de rendimiento. El servicio de Gas Station debe ser capaz de dividir automáticamente grandes SUI Coins en muchas Gas Coins de menor valor y recuperarlas eficientemente después de su uso. Proveedores profesionales de Gas Station como Shinami ofrecen soluciones gestionadas y maduras para esto.
  • Autorización y limitación de velocidad: es imprescindible establecer políticas estrictas de autorización y limitación de velocidad. Por ejemplo, gestionar límites y frecuencias de patrocinio basados en la IP del usuario, la dirección de la billetera o tokens API para evitar que el servicio sea drenado por actores malintencionados.

7. Herramientas del ecosistema

El ecosistema Sui ya ofrece un conjunto rico de herramientas para simplificar el desarrollo y despliegue de Paymasters:

  • SDK oficiales (Rust/TypeScript): incluyen APIs de alto nivel como sponsor_transaction_block(), reduciendo significativamente la complejidad de integración.
  • Shinami Gas Station: proporciona un servicio gestionado todo‑en‑uno, que incluye división/reclamación automática de Gas Coins, métricas detalladas y notificaciones webhook, permitiendo a los desarrolladores centrarse en la lógica de negocio.
  • Enoki / Demos de Mysten: la comunidad y Mysten Labs también ofrecen implementaciones de Paymaster de código abierto que pueden usarse como referencia para construir tu propio servicio.

8. Lista de verificación de implementación

¿Listo para actualizar tu dApp a la era sin gas? Recorre esta lista antes de comenzar:

  • Planifica tu flujo de financiación: define la fuente de fondos del patrocinador, el presupuesto y la estrategia de reposición. Configura monitoreo y alertas para métricas clave (p. ej., saldo del pool de gas, tasa de consumo).
  • Reserva campos de atribución: al diseñar los parámetros de tu transacción, asegura reservar campos para identificadores de negocio como order_id o user_id.
  • Despliega políticas anti‑abuso: implementa autorización estricta, limitación de velocidad y mecanismos de registro antes de lanzar.
  • Ensaya en testnet: ya sea construyendo tu propio servicio o integrando una Gas Station de terceros, realiza pruebas exhaustivas de concurrencia y estrés en una testnet o devnet primero.
  • Optimiza continuamente: después del lanzamiento, monitorea continuamente las tasas de éxito de transacciones, razones de fallos y costos de gas. Ajusta tu presupuesto y estrategias basándote en los datos.

Conclusión

El Sui Paymaster (Gas Station) es mucho más que una herramienta para cubrir tarifas de gas de los usuarios. Es un paradigma poderoso que combina elegantemente una experiencia “cero SUI en cadena” para el usuario con la necesidad empresarial de “atribución a nivel de orden on‑chain” dentro de una única transacción atómica. Allana el camino para que usuarios de Web2 ingresen a Web3 y brinda a los desarrolladores una flexibilidad sin precedentes para la personalización de negocios.

Con un ecosistema de herramientas cada vez más maduro y los actuales bajos costos de gas en la red Sui, nunca ha habido un mejor momento para actualizar los flujos de pago e interacción de tu dApp a la era sin gas.