47 publicaciones etiquetados con "blockchain"

The concert ticket in your digital wallet is on the verge of a massive upgrade. For decades, a ticket has been a static, disposable proof of purchase—a barcode to get you in the door, and nothing more. That model is evolving. The ticket is becoming a programmable, portable membership object, capable of unlocking experiences long after the show ends.

Done right, NFT tickets can drastically reduce fraud and scalping, create fairer access for superfans, and give organizers powerful new ways to reward loyalty—all without forcing fans to understand cryptocurrency. This isn't a theoretical future; real deployments are already live across major concerts, professional sports, aviation, and even Formula 1. The next wave of adoption hinges on seamless user experience, thoughtful policy design, and pragmatic technology choices.

The Old Ticket Stack Is Fraying​

The traditional digital ticketing system is brittle and showing its age. Fans and organizers alike feel the pain points:

• Fraud & Bots: Predatory bots snatch up inventory the moment it goes on sale, only to list it on secondary markets at hugely inflated prices, shutting out real fans. Fake or duplicate tickets plague these markets, leaving buyers with empty hands and lighter wallets.
• Fragmented Systems: A fan’s history is scattered across dozens of vendor accounts. This makes simple actions like transferring a ticket to a friend a painful process and leaves organizers with no unified view of their most loyal attendees.
• Disposable Artifacts: Once scanned, a QR code or PDF ticket becomes useless digital trash. It holds no ongoing value, tells no story, and offers no future utility.

Meanwhile, the market remains dominated by a primary seller facing ongoing antitrust scrutiny. State-by-state reform efforts are gaining steam, signaling that the status quo is neither beloved nor stable. The system is ripe for a change.

Tickets, But Programmable​

NFT tickets aren’t about speculative digital art; they're about programmable access and ownership. By representing a ticket as a unique token on a blockchain, we fundamentally change what it can do:

• Provable Ownership: Tickets live in a user's digital wallet, not just in a vendor's siloed database. This cryptographic proof of ownership dramatically reduces the risk of counterfeit tickets and enables secure, verifiable transfers between fans.
• On-Chain Transfer Rules: Organizers can embed rules directly into the ticket’s smart contract. This could mean setting fair-transfer windows, capping resale prices at face value, or building in other logic that curbs predatory scalping and aligns incentives for everyone.
• Loyalty That Compounds: A wallet containing tickets from past events becomes a portable and verifiable “fan graph.” Organizers can use this history to offer token-gated presales, seat upgrades, and exclusive perks that reward actual attendance, not just names on an email list.
• Interoperability: “Sign in with wallet” can become a universal identity layer across different venues, artists, and partners. Fans get a unified experience without spreading their personal information across countless platforms.

This technology is already leaving the lab and proving its value in the wild.

Proof It Works: Live Deployments to Study​

These are not “maybe someday” pilots; they are live systems processing real fan traffic and solving real problems today.

• Token-Gated Presales at Scale: Ticketmaster has already launched NFT-gated ticket sales. In a pilot with the band Avenged Sevenfold, members of the "Deathbats Club" NFT community received exclusive early and discounted access to tickets, rewarding dedicated fans and filtering out bots.
• Souvenir NFTs with Mainstream Brands: Live Nation and Ticketmaster have issued millions of virtual commemorative ticket NFTs, called “Live Stubs,” for major concerts and NFL games. This introduces fans to digital collectibles with virtually zero friction, turning a simple ticket into a lasting keepsake.
• Aviation Goes On-Chain: Argentinian airline Flybondi began issuing its tickets as NFTs via the TravelX platform on the Algorand blockchain. This model enables flexible name changes and new commerce opportunities, proving the technology can work in an industry with strict operational, security, and identity requirements.
• Global Sports & Premium Hospitality: Formula 1’s ticketing provider, Platinium Group, rolled out Polygon-based NFT tickets that come with perks persisting long after race day, such as hospitality access and future discounts. This transforms a one-time seat into an enduring membership touchpoint.

What NFT Tickets Unlock for Fans & Organizers​

This shift creates a win-win scenario, offering tangible benefits to everyone in the ecosystem.

• Fairer Access, Less Chaos: Token-gated presales can effectively reward verified attendees or fan club members, bypassing the captcha wars and bot-driven chaos of a general sale. The fact that the largest U.S. primary ticket seller now natively supports this proves its viability.
• Transfers with Guardrails: Smart contracts allow organizers to define how and when tickets can be transferred, aligning with local laws and artist preferences. Secondary royalties are also possible through standards like EIP-2981, though enforcement depends on marketplace adoption. This gives organizers more control over the secondary market.
• Portable Loyalty: Commemorative drops, like digital stubs or POAPs (Proof of Attendance Protocols), build a verifiable fan history that can actually be used across different venues, brands, and seasons. Your attendance record becomes a key to unlocking future rewards.
• Interoperable User Experience: With custodial wallets and simple email or SMS logins, fans don’t need to manage complex seed phrases. Mass-market rollouts like Reddit’s millions of on-chain avatars—purchased with standard currency—prove this user-friendly pattern can scale.

Patterns We Recommend Shipping (In Order)​

1. Start with “Souvenir Mode.” The lowest-risk, highest-reward entry point is to issue free or bundled commemorative NFTs delivered after a ticket is scanned. This builds your on-chain fan graph and educates users without adding friction to the core job of getting them in the door. Live Nation’s “Live Stubs” is the perfect precedent.
2. Layer in Token-Gated Presales for Superfans. Use the fan graph you’ve built. Let proven attendees or fan club members unlock prime seats or early access windows. This creates a clear reward for loyalty, reduces bot competition, and provides much cleaner economic data. The Avenged Sevenfold presale is the canonical case study here.
3. Make the Ticket a Wallet. Treat each ticket as the root credential for delivering ongoing perks. This could be exclusive merchandise access, instant seat upgrades, food and beverage credits, or even artist AMAs—delivered before, during, and after the show. Formula 1’s membership-style approach points the way forward.
4. Design the Secondary Market Thoughtfully. If you allow resale, establish clear rules that fit your policies and fan expectations. This could mean time-boxed transfer windows, fee caps, or face-value requirements. While standards like EIP-2981 signal royalty preferences, some marketplaces have made them optional. A direct, branded resale channel can be a wise move to ensure your rules are respected.

What Can Go Wrong (and How to Avoid It)​

• Custody & Platform Risk: Don’t strand your customers on a centralized island. When the crypto exchange FTX collapsed, some Coachella NFTs tied to the platform were stuck. If a technology partner disappears, fans shouldn’t lose their assets or benefits. Use portable wallets and ensure perks can be reissued or recognized elsewhere.
• UX Over Crypto Jargon: The average fan should never have to see terms like “seed phrase,” “gas fees,” or “blockchain.” As Reddit demonstrated, gentle, custodial onboarding with familiar fiat checkouts is the key to scaling to millions of users. The complexity should remain under the hood.
• Unrealistic Royalty Expectations: “Automatic royalties forever” is not guaranteed across all secondary markets. If resale economics are a key part of your strategy, consider launching your own resale venue or enforcing your rules through allowlists and clear branding terms with partners.
• The Policy Patchwork: Ticketing laws are actively being revised across the U.S., with a focus on refunds, price transparency, anti-bot measures, and transfer rights. Your system must be architected to allow for configuration by region, and your policies must be communicated explicitly to fans.

Architecture Blueprint (Pragmatic, Chain-Agnostic)​

• Chain Selection: Favor low-fee, high-throughput networks already used in consumer contexts, such as Polygon, Flow, or Algorand. Mainstream deployments have gravitated toward these chains for their low cost, speed, and better environmental footprint.
• Token Standard: Use ERC-721 for unique, assigned seats and ERC-1155 for general admission sections or tiers. Add EIP-2981 metadata if you plan to support royalties within compliant marketplaces.
• Wallet UX: Default to custodial wallets that use email/SMS login or passkeys for authentication. Provide an easy, optional path for users to “export to self-custody.” Pre-mint tickets to wallets or use a mint-on-claim model to reduce waste.
• Gating & Scanning: Use fast, off-chain allowlists or Merkle proofs at the gate for quick entry. Verify ownership with time-limited digital signatures to prevent simple QR code screenshotting. After a successful scan, delight the fan by airdropping perks like POAPs, collectibles, or coupons.
• Secondary Market & Compliance: If you enable resale, route it through a branded marketplace or a partner that respects your rules. Parameterize transferability settings to comply with different state and local laws, and pair on-chain rules with clear, human-readable refund and transfer policies.

Metrics That Actually Matter​

Move beyond vanity metrics and focus on what truly indicates success.

• Access Fairness: Measure the presale conversion rate for verified fans versus the general public. Track the percentage of tickets that are resold within a face-value price band.
• Operational Reliability: Monitor gate throughput, scan failure rates, and the load on your customer support team. A successful implementation should reduce friction, not create it.
• Fan Compounding: Track repeat attendance among NFT holders, measure the redemption rates for digital perks, and analyze the revenue uplift from token-gated campaigns.
• Unit Economics: Analyze your fee take-rate net of fraud-related chargebacks. Calculate the blended customer acquisition cost and lifetime value when wallet data is used to inform marketing and targeting.

Case Study Nuggets to Borrow​

• Use NFTs as a "Thank You," Not a Hurdle: Live Nation’s commemoratives cost fans nothing and teach them the flow. Start there before you touch access control.
• Reward Real Attendance: Token-gated presales that reference past check-ins feel fair and build loyalty.
• Design Perks with a Shelf-Life: Formula 1’s persistent benefits, like hospitality access and future discounts, extend the ticket’s utility far beyond the event itself.
• Avoid a Single Point of Failure: The Coachella-FTX saga underscores why portability matters. Own the fan relationship; let users take their assets with them when they want.

The Policy Reality (Briefly)​

The regulatory landscape is heating up. Federal and state attention on ticketing is rising, with transparency, refunds, anti-bot rules, and transferability becoming hot-button issues. Your smart contracts and user experience must be flexible enough to adapt on a jurisdiction-by-jurisdiction basis. The entire market structure is in flux, and building on portable, open rails is the safest long-term bet.

A Practical Rollout Plan (90 Days)​

Phase 1: Collectibles (Weeks 1-4)

• Implement free commemorative NFTs for all attendees, claimed via email after the event. Measure your claim rate and wallet creation stats.

Phase 2: Fan-First Presales (Weeks 5-8)

• Pilot a small, token-gated presale for verified past attendees. Communicate the process clearly and keep a traditional queue open as a backup.

Phase 3: Perks & Partnerships (Weeks 9-10)

• Turn the ticket into a perks wallet. Link it to merchandise unlocks, partner discounts, or exclusive content drops for specific seat sections or cities.

Phase 4: Controlled Resale (Weeks 11-12)

• Launch a branded resale page with rules aligned to local law. Test face-value caps and transfer windows on a small scale before rolling out nationally.

Closing Thought​

The paper stub was once a cherished souvenir of a great night out. NFT tickets can be that—and so much more. When access is programmable, loyalty becomes a composable asset that travels with a fan across venues, artists, and seasons. Fans get fairer access and better perks; organizers get durable relationships and cleaner economics. And when the crypto complexity stays under the hood where it belongs, everybody wins.

Architecture Diagram​

Here is a Mermaid diagram illustrating the pragmatic, chain-agnostic architecture described in the blueprint.

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.

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.

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**, 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$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 $HYPE 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$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 $HYPE 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 $HYPE en el mercado abierto, devolviendo valor directamente a los tenedores de tokens. De hecho, el **97$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, 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) 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 B$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). 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. 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:

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 M$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 ~$145M 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 $HYPE 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 $PIP 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)

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 $400 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ó $400 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.

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.

¡Nos complace anunciar el lanzamiento del staking de token SUI en BlockEden.xyz! A partir de hoy, puedes hacer staking de tus tokens SUI directamente a través de nuestra plataforma y ganar un 2.08% APY mientras apoyas la seguridad y descentralización de la red SUI.

Novedades: Una Experiencia de Staking SUI sin Fricciones​

Nuestra nueva función de staking lleva staking de nivel institucional a todos, con una interfaz simple e intuitiva que hace que ganar recompensas sea sin esfuerzo.

Características Clave​

Staking con Un Clic
El staking de SUI nunca ha sido tan fácil. Simplemente conecta tu billetera Suisplash, ingresa la cantidad de SUI que deseas stakear y aprueba la transacción. Comenzarás a ganar recompensas casi de inmediato sin procedimientos complejos.

Recompensas Competitivas
Gana un 2.08% APY competitivo sobre tu SUI stakeado. Nuestra comisión del 8% es transparente, asegurando que sepas exactamente qué esperar. Las recompensas se distribuyen diariamente al completarse cada epoch.

Validador de Confianza
Únete a una comunidad en crecimiento que ya ha stakeado más de 22 millones de SUI con el validador de BlockEden.xyz. Tenemos un historial probado de servicios de validación fiables, respaldados por infraestructura de nivel empresarial que garantiza un tiempo de actividad del 99.9%.

Gestión Flexible
Tus activos siguen siendo flexibles. El staking es instantáneo, lo que significa que tus recompensas comienzan a acumularse de inmediato. Si necesitas acceder a tus fondos, puedes iniciar el proceso de unstaking en cualquier momento. Tu SUI estará disponible después del período estándar de desbloqueo de la red SUI de 24-48 horas. Puedes rastrear tus stakes y recompensas en tiempo real a través de nuestro panel.

¿Por Qué Hacer Staking de SUI con BlockEden.xyz?​

Confiabilidad en la que Puedes Confiar​

BlockEden.xyz ha sido una piedra angular de la infraestructura blockchain desde nuestros inicios. Nuestra infraestructura de validadores impulsa aplicaciones empresariales y ha mantenido un tiempo de actividad excepcional en múltiples redes, garantizando una generación constante de recompensas.

Transparente y Justo​

Creemos en la total transparencia. No hay tarifas ocultas, solo una comisión del 8% clara sobre las recompensas que ganas. Puedes monitorear tu desempeño de staking con reportes en tiempo real y verificar la actividad de nuestro validador en cadena.

• Open Address: 0x0000000000000000000000000000000000000000

Integración Sin Fricciones​

Nuestra plataforma está diseñada para la simplicidad. No es necesario crear una cuenta; puedes hacer staking directamente desde tu billetera. La experiencia está optimizada para la billetera Suisplash, y nuestra interfaz limpia e intuitiva está construida tanto para principiantes como para expertos.

Cómo Empezar​

Paso 1: Visita la Página de Staking​

Visita blockeden.xyz/dash/stake. Puedes iniciar el proceso de inmediato sin necesidad de registrar una cuenta.

Paso 2: Conecta tu Billetera​

Si aún no la tienes, instala la billetera Suisplash. Haz clic en el botón "Conectar Billetera" en nuestra página de staking y aprueba la conexión en la extensión de la billetera. Tu saldo de SUI se mostrará automáticamente.

Paso 3: Elige la Cantidad a Stakear​

Ingresa la cantidad de SUI que deseas stakear (mínimo 1 SUI). Puedes usar el botón "MAX" para stakear convenientemente todo tu saldo disponible, dejando una pequeña cantidad para tarifas de gas. Un resumen mostrará tu cantidad stakeada y las recompensas anuales estimadas.

Paso 4: Confirma y Comienza a Ganar​

Haz clic en "Stake SUI" y aprueba la transacción final en tu billetera. Tu nuevo stake aparecerá en el panel en tiempo real, y comenzarás a acumular recompensas de inmediato.

Economía del Staking: Lo Que Necesitas Saber​

Estructura de Recompensas​

• APY Base: 2.08% anual
• Frecuencia de Recompensas: Distribuida cada epoch (aproximadamente cada 24 horas)
• Comisión: 8% de las recompensas ganadas
• Capitalización: Las recompensas se añaden a tu billetera y pueden ser re‑stakeadas para lograr crecimiento compuesto.

Ejemplo de Ganancias​

Nota: Estas son estimaciones. Las recompensas reales pueden variar según las condiciones de la red.

Consideraciones de Riesgo​

• Período de Desbloqueo: Cuando haces unstake, tu SUI está sujeto a un período de desbloqueo de 24-48 horas en el que no es accesible y no genera recompensas.
• Riesgo del Validador: Aunque mantenemos altos estándares, cualquier validador conlleva riesgos operativos. Elegir un validador reputado como BlockEden.xyz es importante.
• Riesgo de Red: El staking es una forma de participación en la red y está sujeto a los riesgos inherentes al protocolo blockchain subyacente.
• Riesgo de Mercado: El valor de mercado del token SUI puede fluctuar, lo que afectará el valor total de tus activos stakeados.

Excelencia Técnica​

Infraestructura Empresarial​

Nuestros nodos validadores están construidos sobre una base de excelencia técnica. Utilizamos sistemas redundantes distribuidos en múltiples regiones geográficas para garantizar alta disponibilidad. Nuestra infraestructura está bajo monitoreo 24/7 con capacidades de conmutación automática, y un equipo profesional de operaciones gestiona el sistema las 24 horas. También realizamos auditorías de seguridad y verificaciones de cumplimiento de forma regular.

Código Abierto y Transparencia​

Estamos comprometidos con los principios de código abierto. Nuestra integración de staking está construida para ser transparente, permitiendo a los usuarios inspeccionar los procesos subyacentes. Métricas en tiempo real están disponibles públicamente en los exploradores de la red SUI, y nuestra estructura de tarifas es completamente abierta sin costos ocultos. También participamos activamente en la gobernanza comunitaria para apoyar el ecosistema SUI.

Apoyando el Ecosistema SUI​

• Seguridad de la Red: Tu stake se suma al total que asegura la red SUI, haciéndola más robusta contra posibles ataques.
• Descentralización: Apoyar validadores independientes como BlockEden.xyz mejora la resiliencia de la red y previene la centralización.
• Crecimiento del Ecosistema: Las comisiones que ganamos se reinvierten en mantener y desarrollar infraestructura crítica.
• Innovación: Los ingresos respaldan nuestra investigación y desarrollo de nuevas herramientas y servicios para la comunidad blockchain.

Seguridad y Mejores Prácticas​

Seguridad de la Billetera​

• Nunca compartas tus claves privadas o frase semilla con nadie.
• Utiliza una billetera hardware para almacenar y stakear grandes cantidades.
• Siempre verifica los detalles de la transacción en tu billetera antes de firmar.
• Mantén tu software de billetera actualizado a la última versión.

Seguridad del Staking​

• Si eres nuevo en el staking, comienza con una pequeña cantidad para familiarizarte con el proceso.
• Considera diversificar tu stake entre varios validadores reputados para reducir el riesgo.
• Monitorea regularmente tus activos stakeados y recompensas.
• Asegúrate de comprender el período de desbloqueo antes de comprometer tus fondos.

Únete al Futuro del Staking SUI​

El lanzamiento del staking SUI en BlockEden.xyz es más que una nueva función; es una puerta de entrada a la participación activa en la economía descentralizada. Ya seas un usuario experimentado de DeFi o estés comenzando tu camino, nuestra plataforma ofrece una forma simple y segura de ganar recompensas mientras contribuyes al futuro de la red SUI.

¿Listo para comenzar a ganar?
Visita blockeden.xyz/dash/stake y stakea tus primeros tokens SUI hoy!

Acerca de BlockEden.xyz​

BlockEden.xyz es un proveedor líder de infraestructura blockchain que ofrece servicios fiables, escalables y seguros a desarrolladores, empresas y a la comunidad Web3 en general. Desde servicios API hasta operaciones de validadores, estamos comprometidos a construir la base para un futuro descentralizado.

• Fundado: 2021
• Redes Soportadas: más de 15 redes blockchain
• Clientes Empresariales: más de 500 empresas en todo el mundo
• Valor Total Asegurado: más de $100M en todas las redes

Síguenos en Twitter, únete a nuestro Discord y explora nuestra suite completa de servicios en BlockEden.xyz.

Aviso: Esta publicación del blog es solo con fines informativos y no constituye asesoramiento financiero. El staking de criptomonedas implica riesgos, incluida la posible pérdida del capital. Por favor, realiza tu propia investigación y considera tu tolerancia al riesgo antes de hacer staking.

Introducción​

Los mercados descentralizados de inferencia/entrenamiento de IA buscan aprovechar los recursos de cómputo globales y los modelos comunitarios de una manera sin confianza (trustless). Proyectos como Bittensor, Gensyn y Cuckoo Network (Cuckoo AI) ilustran cómo la tecnología blockchain puede potenciar mercados abiertos de IA. Cada plataforma tokeniza activos clave de IA —poder de cómputo, modelos de aprendizaje automático y, a veces, datos— en unidades económicas en la cadena. A continuación, profundizamos en las arquitecturas técnicas que sustentan estas redes, cómo tokenizan los recursos, sus estructuras de gobernanza e incentivos, los métodos para rastrear la propiedad de los modelos, los mecanismos de reparto de ingresos y las superficies de ataque (por ejemplo, ataques Sybil, colusión, parasitismo, envenenamiento) que surgen. Una tabla comparativa al final resume todas las dimensiones clave entre Bittensor, Gensyn y Cuckoo AI.

Arquitecturas Técnicas​

Bittensor: “Internet Neuronal” Descentralizado en Subredes​

Bittensor está construido sobre una blockchain de Capa 1 personalizada (la cadena Subtensor, basada en Substrate) que coordina una red de nodos de modelos de IA a través de muchas subredes especializadas. Cada subred es una minirred independiente que se enfoca en una tarea de IA particular (por ejemplo, una subred para la generación de lenguaje, otra para la generación de imágenes, etc.). Los participantes en Bittensor asumen roles distintos:

• Mineros – ejecutan modelos de aprendizaje automático en su hardware y proporcionan respuestas de inferencia (o incluso realizan entrenamiento) para la tarea de la subred. En esencia, un minero es un nodo que aloja un modelo de IA que responderá a las consultas.
• Validadores – consultan los modelos de los mineros con prompts y evalúan la calidad de las respuestas, formando una opinión sobre qué mineros están contribuyendo con resultados valiosos. Los validadores califican efectivamente el rendimiento de los mineros.
• Propietarios de Subred – crean y definen subredes, estableciendo las reglas sobre qué tareas se realizan y cómo se lleva a cabo la validación en esa subred. Un propietario de subred podría, por ejemplo, especificar que una subred es para un cierto conjunto de datos o modalidad y definir el procedimiento de validación.
• Delegadores – los poseedores de tokens que no ejecutan nodos pueden delegar (hacer stake) sus tokens de Bittensor (TAO) a mineros o validadores para respaldar a los de mejor rendimiento y ganar una parte de las recompensas (similar al staking en redes de prueba de participación).

El mecanismo de consenso de Bittensor es novedoso: en lugar de la validación de bloques tradicional, Bittensor utiliza el consenso Yuma, que es una forma de "prueba de inteligencia". En el consenso Yuma, las evaluaciones de los validadores sobre los mineros se agregan en la cadena para determinar la distribución de recompensas. Cada bloque de 12 segundos, la red acuña nuevos tokens TAO y los distribuye según el consenso de los validadores sobre qué mineros proporcionaron trabajo útil. Las puntuaciones de los validadores se combinan en un esquema de mediana ponderada por participación (stake): las opiniones atípicas se recortan y prevalece la opinión de la mayoría honesta. Esto significa que si la mayoría de los validadores están de acuerdo en que un minero fue de alta calidad, ese minero obtendrá una fuerte recompensa; si un validador se desvía mucho de los demás (posiblemente debido a colusión o error), ese validador es penalizado ganando menos. De esta manera, la blockchain de Bittensor coordina un bucle de retroalimentación minero-validador: los mineros compiten para producir los mejores resultados de IA, y los validadores curan y clasifican esos resultados, ganando ambas partes tokens proporcionales al valor que agregan. Esta arquitectura a menudo se describe como una "red neuronal descentralizada" o "cerebro global", donde los modelos aprenden de las señales de los demás y evolucionan colectivamente. Notablemente, Bittensor actualizó recientemente su cadena para admitir la compatibilidad con EVM (para contratos inteligentes) e introdujo dTAO, un sistema de tokens y staking específicos de subred (explicado más adelante) para descentralizar aún más el control de la asignación de recursos.

Gensyn: Protocolo de Cómputo Distribuido sin Confianza (Trustless)​

Gensyn aborda la IA descentralizada desde el ángulo de un protocolo de computación distribuida para el aprendizaje automático. Su arquitectura conecta a desarrolladores (solicitantes) que tienen tareas de IA (como entrenar un modelo o ejecutar un trabajo de inferencia) con proveedores de cómputo (resolutores) de todo el mundo que tienen recursos de GPU/TPU de sobra. Originalmente, Gensyn planeaba una cadena L1 en Substrate, pero giró hacia la construcción en Ethereum como un rollup para una mayor seguridad y liquidez. La red Gensyn es, por lo tanto, una Capa 2 de Ethereum (un rollup de Ethereum) que coordina la publicación de trabajos y los pagos, mientras que la computación ocurre fuera de la cadena en el hardware de los proveedores.

Una innovación central del diseño de Gensyn es su sistema de verificación para el trabajo fuera de la cadena. Gensyn utiliza una combinación de verificación optimista (pruebas de fraude) y técnicas criptográficas para garantizar que cuando un resolutor afirma haber ejecutado una tarea de entrenamiento/inferencia, el resultado sea correcto. En la práctica, el protocolo involucra múltiples roles de participantes:

• Solicitante – la parte que solicita un trabajo (por ejemplo, alguien que necesita entrenar un modelo). Pagan la tarifa de la red y proporcionan el modelo/datos o la especificación de la tarea.
• Resolutor – un nodo que puja y ejecuta la tarea de ML en su hardware. Entrenarán el modelo o ejecutarán la inferencia según lo solicitado, luego enviarán los resultados y una prueba de computación.
• Verificador/Desafiador – nodos que pueden auditar o verificar aleatoriamente el trabajo del resolutor. Gensyn implementa un esquema al estilo de Truebit donde, por defecto, el resultado de un resolutor se acepta, pero un verificador puede desafiarlo dentro de una ventana si sospecha una computación incorrecta. En un desafío, se utiliza una "búsqueda binaria" interactiva a través de los pasos de la computación (un protocolo de prueba de fraude) para señalar cualquier discrepancia. Esto permite que la cadena resuelva disputas realizando solo una parte crítica mínima de la computación en la cadena, en lugar de rehacer toda la costosa tarea.

Crucialmente, Gensyn está diseñado para evitar la redundancia masiva de los enfoques ingenuos. En lugar de tener muchos nodos repitiendo el mismo trabajo de ML (lo que destruiría los ahorros de costos), el enfoque de "prueba de aprendizaje" de Gensyn utiliza metadatos de entrenamiento para verificar que se ha progresado en el aprendizaje. Por ejemplo, un resolutor podría proporcionar hashes criptográficos o puntos de control de los pesos intermedios del modelo y una prueba sucinta de que estos progresaron de acuerdo con las actualizaciones de entrenamiento. Esta prueba probabilística de aprendizaje se puede verificar de manera mucho más económica que volver a ejecutar todo el entrenamiento, lo que permite una verificación sin confianza sin replicación completa. Solo si un verificador detecta una anomalía se activaría una computación más pesada en la cadena como último recurso. Este enfoque reduce drásticamente la sobrecarga en comparación con la verificación por fuerza bruta, haciendo que el entrenamiento de ML descentralizado sea más factible. La arquitectura de Gensyn, por lo tanto, enfatiza fuertemente el diseño de juegos criptoeconómicos: los resolutores depositan una participación o fianza, y si hacen trampa (enviando resultados incorrectos), pierden esa participación a favor de los verificadores honestos que los atrapan. Al combinar la coordinación de la blockchain (para pagos y resolución de disputas) con el cómputo fuera de la cadena y una verificación inteligente, Gensyn crea un mercado para el cómputo de ML que puede aprovechar las GPU inactivas en cualquier lugar mientras mantiene la falta de confianza. El resultado es un "protocolo de cómputo" a hiperescala donde cualquier desarrollador puede acceder a un poder de entrenamiento asequible y distribuido globalmente bajo demanda.

Cuckoo AI: Plataforma de Servicios de IA Descentralizada Full-Stack​

Cuckoo Network (o Cuckoo AI) adopta un enfoque más integrado verticalmente, con el objetivo de proporcionar servicios de IA descentralizados de extremo a extremo en lugar de solo cómputo en bruto. Cuckoo construyó su propia blockchain (inicialmente una Capa 1 llamada Cuckoo Chain en Arbitrum Orbit, un marco de rollup compatible con Ethereum) para orquestar todo: no solo empareja trabajos con GPU, sino que también aloja aplicaciones de IA y maneja pagos en un solo sistema. El diseño es full-stack: combina una blockchain para transacciones y gobernanza, una capa de recursos de GPU/CPU descentralizada y aplicaciones y API de IA orientadas al usuario en la parte superior. En otras palabras, Cuckoo integra las tres capas —blockchain, cómputo y aplicación de IA— dentro de una única plataforma.

Los participantes en Cuckoo se dividen en cuatro grupos:

• Constructores de Aplicaciones de IA (Coordinadores) – son desarrolladores que despliegan modelos o servicios de IA en Cuckoo. Por ejemplo, un desarrollador podría alojar un generador de imágenes Stable Diffusion o un chatbot LLM como servicio. Ejecutan Nodos Coordinadores, que son responsables de gestionar su servicio: aceptar solicitudes de usuarios, dividirlas en tareas y asignar esas tareas a los mineros. Los coordinadores hacen stake del token nativo ($CAI) para unirse a la red y obtener el derecho a utilizar mineros. Esencialmente, actúan como orquestadores de capa 2 que interactúan entre los usuarios y los proveedores de GPU.
• Mineros de GPU/CPU (Nodos de Tarea) – son los proveedores de recursos. Los mineros ejecutan el cliente de tareas de Cuckoo y contribuyen con su hardware para realizar tareas de inferencia para las aplicaciones de IA. Por ejemplo, a un minero se le podría asignar una solicitud de generación de imágenes (con un modelo y prompt dados) por parte de un coordinador y usar su GPU para calcular el resultado. Los mineros también deben hacer stake de $CAI para garantizar el compromiso y el buen comportamiento. Ganan recompensas en tokens por cada tarea que completan correctamente.
• Usuarios Finales – los consumidores de las aplicaciones de IA. Interactúan a través del portal web o las API de Cuckoo (por ejemplo, generando arte a través de CooVerse o chateando con personalidades de IA). Los usuarios pueden pagar con criptomonedas por cada uso o posiblemente contribuir con su propio cómputo (o stake) para compensar los costos de uso. Un aspecto importante es la resistencia a la censura: si un coordinador (proveedor de servicios) es bloqueado o se cae, los usuarios pueden cambiar a otro que sirva la misma aplicación, ya que múltiples coordinadores podrían alojar modelos similares en la red descentralizada.
• Stakers (Delegadores) – los miembros de la comunidad que no ejecutan servicios de IA o hardware de minería aún pueden participar haciendo stake de $CAI en aquellos que sí lo hacen. Al votar con su stake en coordinadores o mineros de confianza, ayudan a señalar la reputación y, a cambio, ganan una parte de las recompensas de la red. Este diseño construye una capa de reputación Web3: los buenos actores atraen más stake (y por lo tanto, confianza y recompensas), mientras que los malos actores pierden stake y reputación. Incluso los usuarios finales pueden hacer stake en algunos casos, alineándolos con el éxito de la red.

La cadena Cuckoo (ahora en proceso de transición de una cadena independiente a un rollup de seguridad compartida) rastrea todas estas interacciones. Cuando un usuario invoca un servicio de IA, el nodo coordinador crea asignaciones de tareas en la cadena para los mineros. Los mineros ejecutan las tareas fuera de la cadena y devuelven los resultados al coordinador, que los valida (por ejemplo, verificando que la imagen o el texto de salida no sean galimatías) y entrega el resultado final al usuario. La blockchain se encarga de la liquidación de pagos: por cada tarea, el contrato inteligente del coordinador paga al minero en $CAI (a menudo agregando micropagos en pagos diarios). Cuckoo enfatiza la falta de confianza y la transparencia – todos los participantes hacen stake de tokens y todas las asignaciones y finalizaciones de tareas se registran, por lo que se desalienta el engaño por la amenaza de perder el stake y por la visibilidad pública del rendimiento. El diseño modular de la red significa que se pueden agregar fácilmente nuevos modelos de IA o casos de uso: aunque comenzó con la generación de texto a imagen como prueba de concepto, su arquitectura es lo suficientemente general como para admitir otras cargas de trabajo de IA (por ejemplo, inferencia de modelos de lenguaje, transcripción de audio, etc.).

Un aspecto notable de la arquitectura de Cuckoo es que inicialmente lanzó su propia blockchain de Capa 1 para maximizar el rendimiento de las transacciones de IA (alcanzando un pico de 300k transacciones diarias durante las pruebas). Esto permitió optimizaciones personalizadas para la programación de tareas de IA. Sin embargo, el equipo encontró que mantener una L1 independiente era costoso y complejo, y a mediados de 2025 decidieron descontinuar la cadena personalizada y migrar a un modelo de rollup/AVS (Servicio Validado Activo) en Ethereum. Esto significa que Cuckoo heredará la seguridad de Ethereum o de una L2 como Arbitrum, en lugar de ejecutar su propio consenso, pero continuará operando su mercado de IA descentralizado en esa capa de seguridad compartida. El cambio tiene como objetivo mejorar la seguridad económica (aprovechando la robustez de Ethereum) y permitir que el equipo de Cuckoo se concentre en el producto en lugar del mantenimiento de la cadena de bajo nivel. En resumen, la arquitectura de Cuckoo crea una plataforma de servicio de IA descentralizada donde cualquiera puede conectar hardware o desplegar un servicio de modelo de IA, y los usuarios de todo el mundo pueden acceder a aplicaciones de IA con un costo menor y menos dependencia de la infraestructura de las grandes tecnológicas.

Mecanismos de Tokenización de Activos​

Un tema común en estas redes es la conversión de cómputo, modelos y datos en activos en la cadena o unidades económicas que pueden ser comercializadas o monetizadas. Sin embargo, cada proyecto se enfoca en tokenizar estos recursos de diferentes maneras:

• Poder de Cómputo: Las tres plataformas convierten el trabajo de cómputo en tokens de recompensa. En Bittensor, la computación útil (inferencia o entrenamiento realizado por un minero) se cuantifica a través de las puntuaciones de los validadores y se recompensa con tokens TAO en cada bloque. Esencialmente, Bittensor "mide" la inteligencia aportada y acuña TAO como una mercancía que representa esa contribución. Gensyn trata explícitamente el cómputo como una mercancía – su protocolo crea un mercado donde el tiempo de GPU es el producto, y el precio se establece por la oferta y la demanda en términos de tokens. Los desarrolladores compran cómputo usando el token, y los proveedores ganan tokens vendiendo los ciclos de su hardware. El equipo de Gensyn señala que cualquier recurso digital (cómputo, datos, algoritmos) puede ser representado y comercializado en un mercado sin confianza similar. Cuckoo tokeniza el cómputo a través de un token ERC-20 $CAI emitido como pago por tareas completadas. Los proveedores de GPU esencialmente "minan" CAI al realizar trabajos de inferencia de IA. El sistema de Cuckoo crea registros en la cadena de las tareas, por lo que se puede pensar en cada tarea de GPU completada como una unidad atómica de trabajo que se paga en tokens. La premisa en los tres es que el poder de cómputo, que de otro modo estaría inactivo o inaccesible, se convierte en un activo tokenizado y líquido, ya sea a través de emisiones de tokens a nivel de protocolo (como en Bittensor y el Cuckoo inicial) o a través de un mercado abierto de órdenes de compra/venta para trabajos de cómputo (como en Gensyn).

• Modelos de IA: Representar los modelos de IA como activos en la cadena (por ejemplo, NFT o tokens) todavía es incipiente. Bittensor no tokeniza los modelos en sí mismos; los modelos permanecen fuera de la cadena bajo la propiedad de los mineros. En cambio, Bittensor valora indirectamente los modelos al recompensar a los que tienen un buen rendimiento. En efecto, la "inteligencia" de un modelo se convierte en ganancias de TAO, pero no hay un NFT que represente los pesos del modelo o permita a otros usarlo. El enfoque de Gensyn está en las transacciones de cómputo, no explícitamente en la creación de tokens para modelos. Un modelo en Gensyn es típicamente proporcionado por un desarrollador fuera de la cadena (quizás de código abierto o propietario), entrenado por resolutores y devuelto; no hay un mecanismo incorporado para crear un token que posea el modelo o su propiedad intelectual. (Dicho esto, el mercado de Gensyn podría facilitar potencialmente el comercio de artefactos o puntos de control de modelos si las partes lo eligen, pero el protocolo en sí ve los modelos como el contenido de la computación en lugar de un activo tokenizado). Cuckoo se encuentra en un punto intermedio: habla de "agentes de IA" y modelos integrados en la red, pero actualmente no hay un token no fungible que represente cada modelo. En cambio, un modelo es desplegado por un constructor de aplicaciones y luego servido a través de la red. Los derechos de uso de ese modelo se tokenizan implícitamente en el sentido de que el modelo puede ganar $CAI cuando se utiliza (a través del coordinador que lo despliega). Las tres plataformas reconocen el concepto de tokenización de modelos —por ejemplo, dar a las comunidades la propiedad de los modelos a través de tokens— pero las implementaciones prácticas son limitadas. Como industria, la tokenización de modelos de IA (por ejemplo, como NFT con derechos de propiedad y participación en los beneficios) todavía se está explorando. El enfoque de Bittensor de que los modelos intercambien valor entre sí es una forma de "mercado de modelos" sin un token explícito por modelo. El equipo de Cuckoo señala que la propiedad descentralizada de modelos es prometedora para reducir las barreras frente a la IA centralizada, pero requiere métodos efectivos para verificar los resultados y el uso de los modelos en la cadena. En resumen, el poder de cómputo se tokeniza inmediatamente (es sencillo pagar tokens por el trabajo realizado), mientras que los modelos se tokenizan indirecta o aspiracionalmente (recompensados por sus resultados, posiblemente representados por stake o reputación, pero aún no tratados como NFT transferibles en estas plataformas).

• Datos: La tokenización de datos sigue siendo lo más difícil. Ninguno de los proyectos, Bittensor, Gensyn o Cuckoo, tiene mercados de datos en la cadena completamente generalizados e integrados (donde los conjuntos de datos se comercializan con derechos de uso exigibles). Los nodos de Bittensor pueden entrenar con varios conjuntos de datos, pero esos conjuntos de datos no forman parte del sistema en la cadena. Gensyn podría permitir que un desarrollador proporcione un conjunto de datos para el entrenamiento, pero el protocolo no tokeniza esos datos; simplemente se proporcionan fuera de la cadena para que el resolutor los use. Cuckoo tampoco tokeniza los datos del usuario; maneja principalmente los datos (como los prompts o resultados del usuario) de manera transitoria para las tareas de inferencia. El blog de Cuckoo declara explícitamente que "los datos descentralizados siguen siendo difíciles de tokenizar" a pesar de ser un recurso crítico. Los datos son sensibles (problemas de privacidad y propiedad) y difíciles de manejar con la tecnología blockchain actual. Por lo tanto, mientras que el cómputo se está mercantilizando y los modelos comienzan a serlo, los datos permanecen en gran medida fuera de la cadena, excepto en casos especiales (algunos proyectos fuera de estos tres están experimentando con uniones de datos y recompensas en tokens por contribuciones de datos, pero eso está fuera de nuestro alcance actual). En resumen, el poder de cómputo es ahora una mercancía en la cadena en estas redes, los modelos se valoran a través de tokens pero aún no se tokenizan individualmente como activos, y la tokenización de datos sigue siendo un problema abierto (más allá de reconocer su importancia).

Gobernanza e Incentivos​

Un diseño robusto de gobernanza e incentivos es crucial para que estas redes de IA descentralizadas funcionen de manera autónoma y justa. Aquí examinamos cómo cada plataforma se gobierna a sí misma (quién toma las decisiones, cómo ocurren las actualizaciones o los cambios de parámetros) y cómo alinean los incentivos de los participantes a través de la economía de tokens.

• Gobernanza de Bittensor: En sus primeras etapas, el desarrollo y los parámetros de las subredes de Bittensor estaban en gran medida controlados por el equipo central y un conjunto de 64 validadores "raíz" en la subred principal. Esto era un punto de centralización: unos pocos validadores poderosos tenían una influencia desproporcionada en la asignación de recompensas, lo que llevó a lo que algunos llamaron un "sistema de votación oligárquico". Para abordar esto, Bittensor introdujo la gobernanza dTAO (TAO descentralizado) en 2025. El sistema dTAO cambió la asignación de recursos para que fuera impulsada por el mercado y controlada por la comunidad. Concretamente, los poseedores de TAO pueden hacer stake de sus tokens en pools de liquidez específicos de subred (esencialmente, "votan" sobre qué subredes deberían obtener más emisiones de la red) y reciben tokens alfa que representan la propiedad en esos pools de subred. Las subredes que atraen más stake tendrán un precio de token alfa más alto y obtendrán una mayor parte de la emisión diaria de TAO, mientras que las subredes impopulares o de bajo rendimiento verán cómo el capital (y por lo tanto las emisiones) se aleja. Esto crea un bucle de retroalimentación: si una subred produce servicios de IA valiosos, más personas hacen stake de TAO en ella (buscando recompensas), lo que le da a esa subred más TAO para recompensar a sus participantes, fomentando el crecimiento. Si una subred se estanca, los stakers se retiran a subredes más lucrativas. En efecto, los poseedores de TAO gobiernan colectivamente el enfoque de la red al señalar financieramente qué dominios de IA merecen más recursos. Esta es una forma de gobernanza en la cadena por peso de token, alineada con los resultados económicos. Aparte de la asignación de recursos, las principales actualizaciones del protocolo o los cambios de parámetros probablemente todavía pasan por propuestas de gobernanza donde los poseedores de TAO votan (Bittensor tiene un mecanismo para propuestas y referendos en la cadena gestionados por la Fundación Bittensor y un consejo electo, similar a la gobernanza de Polkadot). Con el tiempo, se puede esperar que la gobernanza de Bittensor se vuelva cada vez más descentralizada, con la fundación dando un paso atrás a medida que la comunidad (a través del stake de TAO) dirige cosas como la tasa de inflación, la aprobación de nuevas subredes, etc. La transición a dTAO es un gran paso en esa dirección, reemplazando a los tomadores de decisiones centralizados con un mercado de partes interesadas de tokens alineado con incentivos.

• Incentivos de Bittensor: La estructura de incentivos de Bittensor está estrechamente entrelazada con su consenso. Cada bloque (12 segundos), se acuña exactamente 1 TAO nuevo y se divide entre los contribuyentes de cada subred según el rendimiento. La división predeterminada para la recompensa de bloque de cada subred es 41 % para los mineros, 41 % para los validadores y 18 % para el propietario de la subred. Esto asegura que todos los roles sean recompensados: los mineros ganan por hacer el trabajo de inferencia, los validadores ganan por su esfuerzo de evaluación, y los propietarios de subredes (que pueden haber iniciado los datos/tarea para esa subred) ganan un residual por proporcionar el "mercado" o el diseño de la tarea. Esos porcentajes están fijados en el protocolo y tienen como objetivo alinear los incentivos de todos hacia una producción de IA de alta calidad. El mecanismo de consenso Yuma refina aún más los incentivos al ponderar las recompensas según las puntuaciones de calidad: un minero que proporciona mejores respuestas (según el consenso de los validadores) obtiene una porción mayor de ese 41 %, y un validador que sigue de cerca el consenso honesto obtiene más de la porción del validador. Los de bajo rendimiento son eliminados económicamente. Además, los delegadores (stakers) que respaldan a un minero o validador generalmente recibirán una parte de las ganancias de ese nodo (los nodos a menudo establecen una comisión y dan el resto a sus delegadores, similar al staking en redes PoS). Esto permite a los poseedores pasivos de TAO apoyar a los mejores contribuyentes y obtener rendimiento, reforzando aún más la meritocracia. El token de Bittensor (TAO) es, por lo tanto, un token de utilidad: se requiere para el registro de nuevos mineros (los mineros deben gastar una pequeña cantidad de TAO para unirse, lo que combate el spam Sybil) y se puede hacer stake para aumentar la influencia o ganar a través de la delegación. También se prevé como un token de pago si los usuarios externos quieren consumir servicios de la red de Bittensor (por ejemplo, pagando TAO para consultar un modelo de lenguaje en Bittensor), aunque el mecanismo de recompensa interno ha sido la "economía" principal hasta ahora. La filosofía general de incentivos es recompensar la "inteligencia valiosa" —es decir, modelos que ayudan a producir buenos resultados de IA— y crear una competencia que mejore continuamente la calidad de los modelos en la red.

• Gobernanza de Gensyn: El modelo de gobernanza de Gensyn está estructurado para evolucionar desde el control del equipo central al control de la comunidad a medida que la red madura. Inicialmente, Gensyn tendrá una Fundación Gensyn y un consejo electo que supervisarán las actualizaciones del protocolo y las decisiones del tesoro. Se espera que este consejo esté compuesto por miembros del equipo central y líderes comunitarios tempranos al principio. Gensyn planea un Evento de Generación de Tokens (TGE) para su token nativo (a menudo referido como GENS), después del cual el poder de gobernanza estaría cada vez más en manos de los poseedores de tokens a través de la votación en la cadena. El papel de la fundación es representar los intereses del protocolo y asegurar una transición suave hacia la descentralización total. En la práctica, Gensyn probablemente tendrá mecanismos de propuesta en la cadena donde los cambios en los parámetros (por ejemplo, la duración del juego de verificación, las tasas de comisión) o las actualizaciones se votan por la comunidad. Debido a que Gensyn se está implementando como un rollup de Ethereum, la gobernanza también podría vincularse a la seguridad de Ethereum (por ejemplo, usando claves de actualización para el contrato del rollup que eventualmente se entregan a una DAO de poseedores de tokens). La sección de descentralización y gobernanza del litepaper de Gensyn enfatiza que el protocolo debe ser en última instancia de propiedad global, alineándose con el ethos de que la "red para la inteligencia de máquinas" debería pertenecer a sus usuarios y contribuyentes. En resumen, la gobernanza de Gensyn comienza semi-centralizada pero está diseñada para convertirse en una DAO donde los poseedores de tokens GENS (potencialmente ponderados por stake o participación) toman decisiones colectivamente.

• Incentivos de Gensyn: Los incentivos económicos en Gensyn son dinámicas de mercado sencillas complementadas con seguridad criptoeconómica. Los desarrolladores (clientes) pagan por las tareas de ML en el token de Gensyn, y los Resolutores ganan tokens al completar esas tareas correctamente. El precio de los ciclos de cómputo se determina en un mercado abierto; presumiblemente, los desarrolladores pueden publicar tareas con una recompensa y los resolutores pueden pujar o simplemente tomarla si el precio cumple con sus expectativas. Esto asegura que mientras haya oferta de GPU inactivas, la competencia reducirá el costo a una tasa justa (el equipo de Gensyn proyecta una reducción de costos de hasta el 80 % en comparación con los precios de la nube, ya que la red encuentra el hardware disponible más barato a nivel mundial). Por otro lado, los resolutores tienen el incentivo de ganar tokens por su trabajo; su hardware que de otro modo estaría inactivo ahora genera ingresos. Para garantizar la calidad, Gensyn requiere que los resolutores hagan stake de una garantía cuando aceptan un trabajo: si hacen trampa o producen un resultado incorrecto y son atrapados, pierden esa garantía (puede ser recortada y otorgada al verificador honesto). Los verificadores son incentivados por la posibilidad de ganar una recompensa "jackpot" si atrapan a un resolutor fraudulento, similar al diseño de Truebit de recompensar periódicamente a los verificadores que identifican con éxito una computación incorrecta. Esto mantiene a los resolutores honestos y motiva a algunos nodos a actuar como vigilantes. En un escenario óptimo (sin trampas), los resolutores simplemente ganan la tarifa de la tarea y el rol de verificador está mayormente inactivo (o uno de los resolutores participantes podría actuar también como verificador de otros). El token de Gensyn sirve así tanto como moneda de gas para comprar cómputo como garantía de stake que asegura el protocolo. El litepaper menciona una testnet con tokens no permanentes y que los participantes tempranos de la testnet serán recompensados en el TGE con tokens reales. Esto indica que Gensyn asignó parte del suministro de tokens para el arranque —recompensando a los primeros adoptantes, resolutores de prueba y miembros de la comunidad. A largo plazo, las tarifas de los trabajos reales deberían sostener la red. También puede haber una pequeña tarifa de protocolo (un porcentaje de cada pago de tarea) que va a un tesoro o se quema; este detalle aún no está confirmado, pero muchos protocolos de mercado incluyen una tarifa para financiar el desarrollo o la recompra y quema de tokens. En resumen, los incentivos de Gensyn se alinean en torno a la finalización honesta de los trabajos de ML: haz el trabajo, te pagan; intenta hacer trampa, pierdes el stake; verifica a otros, ganas si atrapas a los tramposos. Esto crea un sistema económico de autovigilancia destinado a lograr una computación distribuida confiable.

• Gobernanza de Cuckoo: Cuckoo Network incorporó la gobernanza en su ecosistema desde el primer día, aunque todavía está en fase de desarrollo. El token $CAI es explícitamente un token de gobernanza además de sus roles de utilidad. La filosofía de Cuckoo es que los operadores de nodos de GPU, los desarrolladores de aplicaciones e incluso los usuarios finales deberían tener voz en la evolución de la red, lo que refleja su visión impulsada por la comunidad. En la práctica, las decisiones importantes (como actualizaciones del protocolo o cambios económicos) se decidirían mediante votos ponderados por tokens, presumiblemente a través de un mecanismo de DAO. Por ejemplo, Cuckoo podría realizar votaciones en la cadena para cambiar la distribución de recompensas o adoptar una nueva característica, y los poseedores de$CAI (incluidos mineros, desarrolladores y usuarios) votarían. La votación en la cadena ya se utiliza como un sistema de reputación: Cuckoo requiere que cada rol haga stake de tokens, y luego los miembros de la comunidad pueden votar (quizás delegando stake o a través de módulos de gobernanza) sobre qué coordinadores o mineros son de confianza. Esto afecta las puntuaciones de reputación y podría influir en la programación de tareas (por ejemplo, un coordinador con más votos podría atraer a más usuarios, o un minero con más votos podría recibir más tareas). Es una mezcla de gobernanza e incentivo: usar tokens de gobernanza para establecer la confianza. La Fundación Cuckoo o el equipo central ha guiado la dirección del proyecto hasta ahora (por ejemplo, tomando la reciente decisión de descontinuar la cadena L1), pero su blog indica un compromiso de avanzar hacia la propiedad descentralizada. Identificaron que operar su propia cadena incurría en altos costos generales y que pivotar hacia un rollup permitirá un desarrollo más abierto y la integración con los ecosistemas existentes. Es probable que una vez en una capa compartida (como Ethereum), Cuckoo implemente una DAO más tradicional para las actualizaciones, con la comunidad votando usando CAI.

• Incentivos de Cuckoo: El diseño de incentivos para Cuckoo tiene dos fases: la fase inicial de arranque con asignaciones de tokens fijas, y un estado futuro con reparto de ingresos impulsado por el uso. En su lanzamiento, Cuckoo realizó una distribución de "lanzamiento justo" de 1 mil millones de tokens CAI. El 51 % del suministro se reservó para la comunidad, asignado como:

• Recompensas de Minería: 30 % del suministro total reservado para pagar a los mineros de GPU por realizar tareas de IA.

• Recompensas de Staking: 11 % del suministro para aquellos que hacen stake y ayudan a asegurar la red.

• Airdrops: 5 % para los primeros usuarios y miembros de la comunidad como incentivo de adopción.

• (Otro 5 % fue para subvenciones a desarrolladores para fomentar la construcción en Cuckoo).

Esta gran asignación significa que en la red inicial, los mineros y stakers fueron recompensados de un pool de emisiones, incluso si la demanda real de los usuarios era baja. De hecho, la fase inicial de Cuckoo presentó altos rendimientos APY para el staking y la minería, lo que atrajo con éxito a los participantes, pero también a los "yield farmers" que solo estaban allí por los tokens. El equipo notó que muchos usuarios se fueron una vez que las tasas de recompensa cayeron, lo que indica que esos incentivos no estaban ligados a un uso genuino. Habiendo aprendido de esto, Cuckoo está cambiando a un modelo donde las recompensas se correlacionan directamente con la carga de trabajo real de IA. En el futuro (y parcialmente ya), cuando un usuario final paga por una inferencia de IA, ese pago (en CAI o posiblemente otro token aceptado convertido a CAI) se dividirá entre los contribuyentes:

• Los mineros de GPU recibirán la mayor parte por el cómputo que proporcionaron.
• El Coordinador (desarrollador de la aplicación) tomará una porción como el proveedor de servicios que suministró el modelo y manejó la solicitud.
• Los Stakers que han delegado a esos mineros o coordinadores podrían obtener una pequeña parte o una recompensa inflacionaria, para continuar incentivando el respaldo de nodos confiables.
• La Red/Tesorería podría retener una tarifa para el desarrollo continuo o para financiar futuros incentivos (o la tarifa podría ser cero/nominal para maximizar la asequibilidad para el usuario).

Esencialmente, Cuckoo se está moviendo hacia un modelo de reparto de ingresos: si una aplicación de IA en Cuckoo genera ganancias, esas ganancias se distribuyen a todos los contribuyentes de ese servicio de manera justa. Esto alinea los incentivos para que los participantes se beneficien del uso real en lugar de solo de la inflación. La red ya requería que todas las partes hicieran stake de CAI; esto significa que los mineros y coordinadores no solo ganan una recompensa plana, sino también posiblemente recompensas basadas en el stake (por ejemplo, un coordinador podría ganar mayores recompensas si muchos usuarios hacen stake en ellos o si ellos mismos hacen más stake, similar a cómo ganan los validadores de prueba de participación). En cuanto a los incentivos para los usuarios, Cuckoo también introdujo cosas como un portal de airdrops y faucets (que algunos usuarios explotaron) para sembrar la actividad inicial. En el futuro, los usuarios podrían ser incentivados a través de reembolsos en tokens por usar los servicios o a través de recompensas de gobernanza por participar en la curación (por ejemplo, quizás ganando pequeños tokens por calificar resultados o contribuir con datos). La conclusión es que el token de Cuckoo ($CAI) es multipropósito: es el token de gas/tarifa en la cadena (todas las transacciones y pagos lo usan), se usa para staking y votación, y es la unidad de recompensa por el trabajo realizado. Cuckoo menciona explícitamente que quiere vincular las recompensas de tokens a KPIs a nivel de servicio (indicadores clave de rendimiento) —por ejemplo, tiempo de actividad, rendimiento de consultas, satisfacción del usuario— para evitar incentivos puramente especulativos. Esto refleja una maduración de la economía de tokens desde la simple minería de liquidez a un modelo más sostenible e impulsado por la utilidad.

Propiedad de Modelos y Atribución de PI​

Manejar la propiedad intelectual (PI) y los derechos de propiedad de los modelos de IA es un aspecto complejo de las redes de IA descentralizadas. Cada plataforma ha adoptado una postura ligeramente diferente, y en general esta es un área en evolución sin una solución completa todavía:

• Bittensor: Los modelos en Bittensor son proporcionados por los nodos mineros, y esos mineros retienen el control total sobre los pesos de sus modelos (que nunca se publican en la cadena). Bittensor no rastrea explícitamente quién "posee" un modelo más allá del hecho de que se está ejecutando en una cierta dirección de billetera. Si un minero se va, su modelo se va con él. Por lo tanto, la atribución de PI en Bittensor es fuera de la cadena: si un minero usa un modelo propietario, no hay nada en la cadena que lo haga cumplir o incluso lo sepa. La filosofía de Bittensor fomenta las contribuciones abiertas (muchos mineros podrían usar modelos de código abierto como GPT-J u otros) y la red recompensa el rendimiento de esos modelos. Se podría decir que Bittensor crea una puntuación de reputación para los modelos (a través de las clasificaciones de los validadores), y esa es una forma de reconocer el valor del modelo, pero los derechos sobre el modelo en sí no están tokenizados ni distribuidos. Notablemente, los propietarios de subred en Bittensor podrían ser vistos como dueños de una pieza de PI: definen una tarea (que podría incluir un conjunto de datos o un método). El propietario de la subred acuña un NFT (llamado UID de subred) al crear una subred, y ese NFT les da derecho al 18 % de las recompensas en esa subred. Esto tokeniza efectivamente la creación de un mercado de modelos (la subred), si no las instancias del modelo. Si se considera la definición de la subred (digamos una tarea de reconocimiento de voz con un conjunto de datos particular) como PI, eso al menos se registra y recompensa. Pero los pesos individuales del modelo que los mineros entrenan, no hay un registro de propiedad en la cadena de ellos. La atribución viene en forma de recompensas pagadas a la dirección de ese minero. Bittensor actualmente no implementa un sistema donde, por ejemplo, varias personas puedan poseer conjuntamente un modelo y obtener un reparto automático de ingresos; la persona que ejecuta el modelo (minero) obtiene la recompensa y depende de ellos fuera de la cadena honrar cualquier licencia de PI del modelo que usaron.

• Gensyn: En Gensyn, la propiedad del modelo es sencilla en el sentido de que el solicitante (el que quiere que se entrene un modelo) proporciona la arquitectura del modelo y los datos, y después del entrenamiento, recibe el artefacto del modelo resultante. Los resolutores que realizan el trabajo no tienen derechos sobre el modelo; son como contratistas que reciben un pago por un servicio. El protocolo de Gensyn asume así el modelo de PI tradicional: si tenías derechos legales sobre el modelo y los datos que enviaste, todavía los tienes después de que se entrene; la red de cómputo no reclama ninguna propiedad. Gensyn menciona que el mercado también podría comerciar algoritmos y datos como cualquier otro recurso. Esto sugiere un escenario en el que alguien podría ofrecer un modelo o algoritmo para su uso en la red, posiblemente por una tarifa, tokenizando así el acceso a ese modelo. Por ejemplo, un creador de modelos podría poner su modelo preentrenado en Gensyn y permitir que otros lo ajusten a través de la red por una tarifa (esto monetizaría efectivamente la PI del modelo). Si bien el protocolo no hace cumplir los términos de la licencia, se podrían codificar los requisitos de pago: un contrato inteligente podría requerir una tarifa para desbloquear los pesos del modelo para un resolutor. Sin embargo, estos son casos de uso especulativos; el diseño principal de Gensyn se trata de habilitar trabajos de entrenamiento. En cuanto a la atribución, si varias partes contribuyen a un modelo (digamos que una proporciona datos, otra proporciona cómputo), eso probablemente se manejaría mediante cualquier contrato o acuerdo que establezcan antes de usar Gensyn (por ejemplo, un contrato inteligente podría dividir el pago entre el proveedor de datos y el proveedor de cómputo). Gensyn en sí no rastrea "este modelo fue construido por X, Y, Z" en la cadena más allá del registro de qué direcciones se pagaron por el trabajo. En resumen, la PI del modelo en Gensyn permanece con el solicitante, y cualquier atribución o licencia debe manejarse a través de los acuerdos legales fuera del protocolo o a través de contratos inteligentes personalizados construidos sobre él.

• Cuckoo: En el ecosistema de Cuckoo, los creadores de modelos (constructores de aplicaciones de IA) son participantes de primera clase: ellos despliegan el servicio de IA. Si un constructor de aplicaciones ajusta un modelo de lenguaje o desarrolla un modelo personalizado y lo aloja en Cuckoo, ese modelo es esencialmente su propiedad y actúan como el propietario del servicio. Cuckoo no se apropia de ninguna propiedad; en cambio, proporciona la infraestructura para que moneticen su uso. Por ejemplo, si un desarrollador despliega una IA de chatbot, los usuarios pueden interactuar con ella y el desarrollador (más los mineros) ganan CAI por cada interacción. La plataforma atribuye así los ingresos por uso al creador del modelo, pero no publica explícitamente los pesos del modelo ni los convierte en un NFT. De hecho, para ejecutar el modelo en las GPU de los mineros, el nodo coordinador probablemente tenga que enviar el modelo (o el tiempo de ejecución) al minero de alguna forma. Esto plantea preguntas sobre la PI: ¿podría un minero malicioso copiar los pesos del modelo y distribuirlos? En una red descentralizada, ese riesgo existe si se utilizan modelos propietarios. El enfoque actual de Cuckoo ha sido en modelos bastante abiertos (Stable Diffusion, modelos derivados de LLaMA, etc.) y en construir una comunidad, por lo que aún no hemos visto una aplicación de los derechos de PI a través de contratos inteligentes. La plataforma podría integrar potencialmente herramientas como la ejecución de modelos encriptados o enclaves seguros en el futuro para la protección de la PI, pero no se menciona nada específico en la documentación. Lo que sí rastrea es quién proporcionó el servicio del modelo para cada tarea: dado que el coordinador es una identidad en la cadena, todo el uso de su modelo se le atribuye, y obtienen automáticamente su parte de las recompensas. Si alguien entregara o vendiera un modelo a otra persona, efectivamente transferiría el control del nodo coordinador (quizás incluso simplemente dándoles la clave privada o el NFT si el rol de coordinador estuviera tokenizado). En la actualidad, la propiedad comunitaria de modelos (a través de participaciones en tokens) no está implementada, pero la visión de Cuckoo sugiere una IA descentralizada impulsada por la comunidad, por lo que podrían explorar permitir que las personas financien o gobiernen colectivamente un modelo de IA. La tokenización de modelos más allá de la propiedad individual sigue siendo un área abierta en estas redes; se reconoce como un objetivo (permitir que las comunidades posean modelos de IA en lugar de las corporaciones), pero en la práctica requiere soluciones para los desafíos de PI y verificación mencionados anteriormente.

En resumen, la propiedad de los modelos en Bittensor, Gensyn y Cuckoo se maneja fuera de la cadena por medios tradicionales: la persona o entidad que ejecuta o envía el modelo es efectivamente el propietario. Las redes proporcionan atribución en forma de recompensas económicas (pagando al contribuyente del modelo por su PI o esfuerzo). Ninguno de los tres tiene una licencia incorporada o una aplicación de regalías sobre el uso del modelo a nivel de contrato inteligente todavía. La atribución proviene de la reputación y la recompensa: por ejemplo, los mejores modelos de Bittensor obtienen altas puntuaciones de reputación (que es un registro público) y más TAO, lo que es un crédito implícito para sus creadores. Con el tiempo, podemos ver características como pesos de modelo vinculados a NFT o licencias descentralizadas para rastrear mejor la PI, pero actualmente la prioridad ha sido hacer que las redes funcionen e incentiven las contribuciones. Todos están de acuerdo en que verificar la procedencia y los resultados de los modelos es clave para permitir verdaderos mercados de activos de modelos, y la investigación en esta dirección está en curso.

Estructuras de Reparto de Ingresos​

Las tres plataformas deben decidir cómo dividir el pastel económico cuando varias partes colaboran para producir un resultado de IA valioso. ¿Quién recibe el pago y cuánto, cuando se utiliza un servicio de IA o cuando se emiten tokens? Cada una tiene un modelo de reparto de ingresos distinto:

• Bittensor: Como se mencionó en la sección de incentivos, la distribución de ingresos de Bittensor está definida por el protocolo a nivel de bloque: 41 % para los mineros, 41 % para los validadores, 18 % para el propietario de la subred por cada emisión de TAO del bloque. Esto es efectivamente un reparto de ingresos incorporado para el valor generado en cada subred. La parte del propietario de la subred (18 %) actúa como una regalía por el "diseño del modelo/tarea" o por iniciar el ecosistema de esa subred. El hecho de que mineros y validadores obtengan partes iguales asegura que sin validación, los mineros no son recompensados (y viceversa); son simbióticos y cada uno obtiene una porción igual de las recompensas acuñadas. Si consideramos a un usuario externo que paga TAO para consultar un modelo, el whitepaper de Bittensor prevé que ese pago también se divida de manera similar entre el minero que responde y los validadores que ayudaron a verificar la respuesta (la división exacta podría ser determinada por el protocolo o las fuerzas del mercado). Además, los delegadores que hacen stake en mineros/validadores son efectivamente socios; típicicamente, un minero/validador compartirá un porcentaje de su TAO ganado con sus delegadores (esto es configurable, pero a menudo la mayoría va a los delegadores). Así, si un minero ganó 1 TAO de un bloque, eso podría dividirse 80/20 entre sus delegadores y ellos mismos, por ejemplo, según el stake. Esto significa que incluso los no operadores obtienen una parte de los ingresos de la red proporcional a su apoyo. Con la introducción de dTAO, se agregó otra capa de reparto: aquellos que hacen stake en el pool de una subred obtienen tokens alfa, que les dan derecho a parte de las emisiones de esa subred (como el yield farming). En efecto, cualquiera puede tomar una participación en el éxito de una subred particular y recibir una fracción de las recompensas de mineros/validadores al poseer tokens alfa (los tokens alfa se aprecian a medida que la subred atrae más uso y emisiones). En resumen, el reparto de ingresos de Bittensor está fijado por código para los roles principales, y se comparte aún más mediante acuerdos sociales/de staking. Es una división relativamente transparente y basada en reglas: cada bloque, los participantes saben exactamente cómo se asigna el 1 TAO, y por lo tanto conocen sus "ganancias" por contribución. Esta claridad es una de las razones por las que Bittensor a veces se compara con Bitcoin para la IA: una emisión monetaria determinista donde la recompensa de los participantes se establece matemáticamente.

• Gensyn: El reparto de ingresos en Gensyn es más dinámico e impulsado por el mercado, ya que las tareas tienen un precio individual. Cuando un solicitante crea un trabajo, adjunta una recompensa (digamos X tokens) que está dispuesto a pagar. Un resolutor que completa el trabajo obtiene esa X (menos cualquier tarifa de red). Si un verificador está involucrado, típicamente hay una regla como: si no se detecta fraude, el resolutor se queda con el pago completo; si se detecta fraude, el resolutor es penalizado con slashing —perdiendo parte o la totalidad de su stake— y esa cantidad recortada se le da al verificador como recompensa. Así que los verificadores no ganan de cada tarea, solo cuando atrapan un mal resultado (además de posiblemente una pequeña tarifa base por participar, dependiendo de la implementación). No hay un concepto incorporado de pagar al propietario de un modelo aquí porque se asume que el solicitante es el propietario del modelo o tiene derechos para usarlo. Uno podría imaginar un escenario donde un solicitante está ajustando el modelo preentrenado de otra persona y una porción del pago va al creador original del modelo, pero eso tendría que manejarse fuera del protocolo (por ejemplo, mediante un acuerdo o un contrato inteligente separado que divida el pago del token en consecuencia). El reparto a nivel de protocolo de Gensyn es esencialmente cliente -> resolutor (-> verificador). El modelo de token probablemente incluye alguna asignación para el tesoro o la fundación del protocolo; por ejemplo, un pequeño porcentaje del pago de cada tarea podría ir a una tesorería que podría usarse para financiar el desarrollo o pools de seguros (esto no se indica explícitamente en los documentos disponibles, pero muchos protocolos lo hacen). Además, al principio, Gensyn puede subsidiar a los resolutores a través de la inflación: a los usuarios de la testnet se les prometen recompensas en el TGE, lo que es efectivamente un reparto de ingresos de la distribución inicial de tokens (los primeros resolutores y partidarios obtienen una parte de los tokens por ayudar a arrancar, similar a un airdrop o recompensa de minería). Con el tiempo, a medida que los trabajos reales dominen, las recompensas inflacionarias disminuirían, y los ingresos de los resolutores provendrían principalmente de los pagos de los usuarios. El enfoque de Gensyn se puede resumir como un modelo de ingresos de pago por servicio: la red facilita un pago directo de aquellos que necesitan que se haga un trabajo a aquellos que lo hacen, con los verificadores y posiblemente los stakers de tokens tomando una parte solo cuando desempeñan un papel en la seguridad de ese servicio.

• Cuckoo: El reparto de ingresos de Cuckoo ha evolucionado. Inicialmente, debido a que no había muchos usuarios finales que pagaran, el reparto de ingresos era esencialmente un reparto de inflación: las asignaciones del 30 % para minería y del 11 % para staking del suministro de tokens significaban que los mineros y stakers compartían los tokens emitidos por el pool de lanzamiento justo de la red. En la práctica, Cuckoo realizaba cosas como pagos diarios de CAI a los mineros proporcionales a las tareas completadas. Esos pagos provenían en gran medida de la asignación de recompensas de minería (que es parte del suministro fijo reservado). Esto es similar a cómo muchas blockchains de Capa 1 distribuyen recompensas de bloque a mineros/validadores; no estaba ligado al uso real por parte de usuarios externos, era más para incentivar la participación y el crecimiento. Sin embargo, como se destaca en su blog de julio de 2025, esto llevó a un uso incentivado por el farming de tokens en lugar de la demanda real. La siguiente etapa para Cuckoo es un verdadero modelo de reparto de ingresos basado en tarifas de servicio. En este modelo, cuando un usuario final usa, digamos, el servicio de generación de imágenes y paga $1 (en términos de cripto), ese valor de$1 en tokens se dividiría quizás así: 0.70 para el minero que hizo el trabajo de GPU, 0.20 para el desarrollador de la aplicación (coordinador) que proporcionó el modelo y la interfaz, y 0.10 para los stakers o la tesorería de la red. (Nota: las proporciones exactas son hipotéticas; Cuckoo no las ha especificado públicamente todavía, pero esto ilustra el concepto). De esta manera, todos los contribuyentes a la prestación del servicio obtienen una parte de los ingresos. Esto es análogo, por ejemplo, a una economía de viajes compartidos pero para la IA: el vehículo (minero de GPU) obtiene la mayoría, el conductor o la plataforma (coordinador que construyó el servicio del modelo) obtiene una parte, y quizás la gobernanza/stakers de la plataforma obtienen una pequeña tarifa. La mención de Cuckoo de "modelos de reparto de ingresos y recompensas de tokens vinculados directamente a métricas de uso" sugiere que si un servicio o nodo en particular maneja mucho volumen, sus operadores y partidarios ganarán más. Se están alejando de los rendimientos planos por simplemente bloquear tokens (que era el caso con su APY de staking inicialmente). En términos concretos: si haces stake en un coordinador que termina impulsando una aplicación de IA muy popular, podrías ganar una porción de las tarifas de esa aplicación, un verdadero escenario de staking como inversión en utilidad, en lugar de hacer stake solo por la inflación. Esto alinea los incentivos de todos para atraer a usuarios reales que pagan por los servicios de IA, lo que a su vez devuelve valor a los poseedores de tokens. Vale la pena señalar que la cadena de Cuckoo también tenía tarifas por transacciones (gas), por lo que los mineros que producían bloques (inicialmente los mineros de GPU también contribuían a la producción de bloques en la cadena de Cuckoo) también obtenían tarifas de gas. Con el cierre de la cadena y la migración a un rollup, las tarifas de gas probablemente serán mínimas (o en Ethereum), por lo que los ingresos principales se convierten en las propias tarifas del servicio de IA. En resumen, Cuckoo está en transición de un modelo impulsado por subsidios (la red paga a los participantes de su pool de tokens) a un modelo impulsado por la demanda (los participantes ganan de los pagos reales de los usuarios). El token seguirá desempeñando un papel en el staking y la gobernanza, pero las ganancias diarias de los mineros y los desarrolladores de aplicaciones deberían provenir cada vez más de los usuarios que compran servicios de IA. Este modelo es más sostenible a largo plazo y se asemeja mucho al reparto de ingresos de SaaS de la Web2, pero implementado a través de contratos inteligentes y tokens para mayor transparencia.

Superficies de Ataque y Vulnerabilidades​

La descentralización de la IA introduce varios desafíos de incentivos y seguridad. Ahora analizamos los vectores de ataque clave —ataques Sybil, colusión, parasitismo (freeloading) y envenenamiento de datos/modelos— y cómo cada plataforma los mitiga o permanece vulnerable a ellos:

• Ataques Sybil (identidades falsas): En una red abierta, un atacante podría crear muchas identidades (nodos) para obtener recompensas o influencia desproporcionadas.

• Bittensor: La resistencia a los ataques Sybil se proporciona principalmente por el costo de entrada. Para registrar un nuevo minero o validador en Bittensor, uno debe gastar o hacer stake de TAO; esto podría ser una quema o un requisito de fianza. Esto significa que crear N nodos falsos incurre en N veces el costo, lo que hace que los grandes enjambres Sybil sean caros. Además, el consenso de Bittensor vincula la influencia al stake y al rendimiento; un Sybil sin stake o con bajo rendimiento gana poco. Un atacante tendría que invertir mucho y también hacer que sus nodos Sybil contribuyan con trabajo útil para obtener una recompensa significativa (lo cual no es una estrategia Sybil típica). Dicho esto, si un atacante sí tiene mucho capital, podría adquirir la mayoría de los TAO y registrar muchos validadores o mineros, efectivamente un Sybil por riqueza. Esto se superpone con el escenario de ataque del 51 %: si una sola entidad controla >50 % del TAO en stake en una subred, pueden influir fuertemente en el consenso. La introducción de dTAO por parte de Bittensor ayuda un poco aquí: distribuye la influencia entre las subredes y requiere el apoyo de la comunidad en el staking para que las subredes prosperen, lo que dificulta que una entidad controle todo. Aún así, los ataques Sybil por parte de un adversario bien financiado siguen siendo una preocupación; el análisis de Arxiv señala explícitamente que el stake está bastante concentrado ahora, por lo que la barrera para un ataque mayoritario no es tan alta como se desearía. Para mitigar esto, se han sugerido propuestas como límites de stake por billetera (por ejemplo, limitar el stake efectivo en el percentil 88 para evitar que una billetera domine). En resumen, Bittensor se basa en la identidad ponderada por stake (no se pueden generar identidades baratas sin un stake proporcional) para manejar los Sybils; es razonablemente efectivo excepto bajo un atacante muy ingenioso.

• Gensyn: Los ataques Sybil en Gensyn se manifestarían como un atacante creando muchos nodos de resolutor o verificador para manipular el sistema. La defensa de Gensyn es puramente económica y criptográfica: las identidades en sí no importan, pero hacer el trabajo o depositar una garantía sí. Si un atacante crea 100 nodos de resolutor falsos pero no tienen trabajos ni stake, no logran nada. Para ganar tareas, un nodo Sybil tendría que pujar competitivamente y tener el hardware para hacer el trabajo. Si pujan por debajo sin capacidad, fallarán y perderán el stake. De manera similar, un atacante podría crear muchas identidades de verificador con la esperanza de ser elegido para verificar (si el protocolo selecciona verificadores al azar). Pero si hay demasiados, la red o el solicitante del trabajo podrían limitar el número de verificadores activos. Además, los verificadores necesitan potencialmente realizar la computación para verificarla, lo cual es costoso; tener muchos verificadores falsos no ayuda a menos que realmente puedas verificar los resultados. Un ángulo Sybil más pertinente en Gensyn es si un atacante intenta llenar la red con trabajos o respuestas falsas para hacer perder el tiempo a otros. Eso se mitiga requiriendo también un depósito de los solicitantes (un solicitante malicioso que publica trabajos falsos pierde su pago o depósito). En general, el uso de stakes/fianzas requeridas y la selección aleatoria para la verificación por parte de Gensyn significa que un atacante gana poco al tener múltiples identidades a menos que también traiga recursos proporcionales. Se convierte en un ataque más costoso en lugar de uno barato. El modelo de seguridad optimista asume al menos un verificador honesto; los Sybils tendrían que abrumar y ser todos los verificadores para hacer trampa consistentemente, lo que nuevamente nos lleva a poseer la mayoría del stake o del poder de cómputo. La resistencia Sybil de Gensyn es, por lo tanto, comparable a la de un rollup optimista: mientras haya un actor honesto, los Sybils no pueden causar un daño sistémico fácilmente.

• Cuckoo: La prevención de ataques Sybil en Cuckoo se basa en el staking y la investigación de la comunidad. Cada rol en Cuckoo (minero, coordinador, incluso usuario en algunos casos) requiere hacer stake de $CAI. Esto eleva inmediatamente el costo de las identidades Sybil: un atacante que crea 100 mineros falsos necesitaría adquirir y bloquear stake para cada uno. Además, el diseño de Cuckoo tiene un elemento humano/comunitario: los nuevos nodos necesitan ganar reputación a través de la votación en la cadena. Es poco probable que un ejército Sybil de nodos nuevos sin reputación reciba muchas tareas o la confianza de los usuarios. Los coordinadores en particular tienen que atraer usuarios; un coordinador falso sin historial no obtendría uso. Para los mineros, los coordinadores pueden ver sus estadísticas de rendimiento (tareas exitosas, etc.) en Cuckoo Scan y preferirán mineros confiables. Cuckoo también tenía un número relativamente pequeño de mineros (40 GPU en un momento en la beta), por lo que cualquier afluencia extraña de muchos nodos sería notable. El punto débil potencial es si el atacante también manipula el sistema de reputación, por ejemplo, haciendo un gran stake de CAI en sus nodos Sybil para que parezcan reputables o creando cuentas de "usuario" falsas para votarse a sí mismos. Esto es teóricamente posible, pero como todo está curado por tokens, cuesta tokens hacerlo (esencialmente estarías votando con tu propio stake en tus propios nodos). El equipo de Cuckoo también puede ajustar los parámetros de staking y recompensa si se observa un comportamiento Sybil (especialmente ahora que se está convirtiendo en un servicio de rollup más centralizado; pueden pausar o aplicar slashing a los malos actores). En resumen, los Sybils se mantienen a raya al requerir tener algo en juego (stake) y necesitar la aprobación de la comunidad. Nadie puede simplemente entrar con cientos de GPU falsas y cosechar recompensas sin una inversión significativa que los participantes honestos podrían gastar mejor en hardware real y stake.

• Colusión: Aquí consideramos a múltiples participantes que se confabulan para manipular el sistema, por ejemplo, validadores y mineros que coluden en Bittensor, o resolutores y verificadores que coluden en Gensyn, etc.

• Bittensor: La colusión ha sido identificada como una preocupación real. En el diseño original, un puñado de validadores podía coludir para siempre votar a favor de ciertos mineros o de ellos mismos, sesgando injustamente la distribución de recompensas (esto se observó como una concentración de poder en la subred raíz). El consenso Yuma proporciona cierta defensa: al tomar una mediana de las puntuaciones de los validadores y penalizar a los que se desvían, evita que un pequeño grupo en colusión impulse dramáticamente a un objetivo a menos que sean la mayoría. En otras palabras, si 3 de 10 validadores coluden para dar a un minero una puntuación súper alta pero los otros 7 no lo hacen, las puntuaciones atípicas de los coludidos se recortan y la recompensa del minero se basa en la puntuación mediana (por lo que la colusión no ayuda significativamente). Sin embargo, si los coludidos forman >50 % de los validadores (o >50 % del stake entre los validadores), efectivamente son el consenso: pueden acordar puntuaciones altas falsas y la mediana reflejará su opinión. Este es el clásico escenario de ataque del 51 %. Desafortunadamente, el estudio de Arxiv encontró algunas subredes de Bittensor donde una coalición de solo el 1-2 % de los participantes (en términos de número) controlaba la mayoría del stake, debido a la fuerte concentración de tokens. Esto significa que la colusión de unos pocos grandes poseedores era una amenaza creíble. La mitigación que Bittensor está persiguiendo a través de dTAO es democratizar la influencia: al permitir que cualquier poseedor de TAO dirija el stake a las subredes, diluye el poder de los grupos cerrados de validadores. Además, propuestas como el staking cóncavo (rendimientos decrecientes para un stake desproporcionado) y los límites de stake tienen como objetivo romper la capacidad de una entidad en colusión para acumular demasiado poder de voto. La suposición de seguridad de Bittensor ahora es similar a la prueba de participación: ninguna entidad única (o cartel) controla >50 % del stake activo. Mientras eso se mantenga, la colusión es limitada porque los validadores honestos anularán las malas puntuaciones y los propietarios de subredes en colusión no pueden aumentar arbitrariamente sus propias recompensas. Finalmente, sobre la colusión entre propietarios de subredes y validadores (por ejemplo, un propietario de subred sobornando a los validadores para que califiquen altamente a los mineros de su subred), dTAO elimina el control directo de los validadores, reemplazándolo con decisiones de los poseedores de tokens. Es más difícil coludir con "el mercado" a menos que compres todo el suministro de tokens, en cuyo caso no es realmente colusión, es una toma de control. Así que la principal técnica anti-colusión de Bittensor es el consenso algorítmico (recorte de mediana) y la amplia distribución de tokens.

• Gensyn: La colusión en Gensyn probablemente involucraría a un resolutor y un verificador (o múltiples verificadores) coludiendo para engañar al sistema. Por ejemplo, un resolutor podría producir un resultado falso y un verificador en colusión podría intencionalmente no desafiarlo (o incluso atestiguar que es correcto si el protocolo pidiera a los verificadores que lo aprobaran). Para mitigar esto, el modelo de seguridad de Gensyn requiere al menos un verificador honesto. Si todos los verificadores están en colusión con el resolutor, entonces un mal resultado no es desafiado. Gensyn aborda esto fomentando muchos verificadores independientes (cualquiera puede verificar) y por la teoría de juegos de que un verificador podría ganar una gran recompensa rompiendo la colusión y desafiando (porque obtendrían el stake del resolutor). Esencialmente, incluso si hay un grupo que acuerda coludir, cada miembro tiene un incentivo para desertar y reclamar la recompensa por sí mismo; esta es una configuración clásica del Dilema del Prisionero. La esperanza es que esto mantenga los grupos de colusión pequeños o ineficaces. Otra colusión potencial es entre múltiples resolutores para subir los precios o monopolizar las tareas. Sin embargo, dado que los desarrolladores pueden elegir dónde publicar las tareas (y las tareas no son unidades idénticas que se puedan monopolizar fácilmente), la colusión de resolutores en el precio sería difícil de coordinar globalmente; cualquier resolutor que no esté en colusión podría pujar por debajo para ganar el trabajo. La dinámica del mercado abierto contrarresta la colusión de precios, asumiendo al menos algunos participantes competitivos. Un ángulo más: colusión de verificadores para perjudicar a los resolutores, por ejemplo, verificadores acusando falsamente a resolutores honestos para robar su stake. La prueba de fraude de Gensyn es binaria y en la cadena; una acusación falsa fallaría cuando la re-computación en la cadena no encuentre ningún error, y presumiblemente el verificador malicioso perdería algo (quizás un depósito o reputación). Así que una colusión de verificadores tratando de sabotear a los resolutores sería atrapada por el proceso de verificación del protocolo. En resumen, la arquitectura de Gensyn es robusta siempre que al menos una parte en cualquier conjunto en colusión tenga un incentivo para ser honesta, una propiedad de la verificación optimista similar a requerir un minero honesto en Bitcoin para eventualmente exponer un fraude. La colusión es teóricamente posible si un atacante pudiera controlar a todos los verificadores y resolutores en una tarea (como la mayoría de la red), pero entonces podrían simplemente hacer trampa sin necesidad de colusión per se. Los incentivos criptoeconómicos están dispuestos para hacer que mantener la colusión sea irracional.

• Cuckoo: La colusión en Cuckoo podría ocurrir de varias maneras:

1. Un coordinador coludiendo con mineros: por ejemplo, un coordinador podría asignar siempre tareas a un conjunto de mineros amigos y repartir las recompensas, ignorando a otros mineros honestos. Dado que los coordinadores tienen discreción en la programación de tareas, esto puede suceder. Sin embargo, si los mineros amigos son de baja calidad, los usuarios finales podrían notar un servicio lento o deficiente y marcharse, por lo que el coordinador está desincentivado de un favoritismo puro que perjudique la calidad. Si la colusión es para manipular las recompensas (digamos, enviando tareas falsas para dar tokens a los mineros), eso se detectaría en la cadena (muchas tareas con quizás entradas idénticas o sin un usuario real) y puede ser penalizado. La transparencia en la cadena de Cuckoo significa que cualquier patrón inusual podría ser señalado por la comunidad o el equipo central. Además, debido a que todos los participantes hacen stake, un anillo de coordinador-minero en colusión se arriesga a perder su stake si son atrapados abusando del sistema (por ejemplo, si la gobernanza decide aplicarles slashing por fraude).
2. Mineros coludiendo entre ellos: podrían compartir información o formar un cartel para, digamos, votarse todos entre sí en reputación o todos negarse a servir a un coordinador en particular para extraer tarifas más altas. Estos escenarios son menos probables: la votación de reputación la realizan los stakers (incluidos los usuarios), no los propios mineros votando entre sí. Y negarse a prestar servicio solo llevaría a los coordinadores a encontrar otros mineros o a dar la alarma. Dada la escala relativamente pequeña actual, cualquier colusión sería difícil de ocultar.
3. Colusión para manipular la gobernanza: grandes poseedores de CAI podrían coludir para aprobar propuestas a su favor (como establecer una tarifa exorbitante o redirigir la tesorería). Este es un riesgo en cualquier gobernanza de tokens. La mejor mitigación es distribuir ampliamente el token (el lanzamiento justo de Cuckoo dio el 51 % a la comunidad) y tener una supervisión comunitaria activa. Además, dado que Cuckoo se alejó de la L1, la gobernanza inmediata en la cadena podría ser limitada hasta que se reasienten en una nueva cadena; el equipo probablemente retiene un control multisig en el ínterin, lo que irónicamente previene la colusión de extraños maliciosos a expensas de ser centralizado temporalmente. En general, Cuckoo se apoya en la transparencia y el staking para manejar la colusión. Hay un elemento de confianza en que los coordinadores se comporten porque quieren atraer usuarios en un entorno competitivo. Si la colusión conduce a un servicio más deficiente o a una manipulación obvia de las recompensas, las partes interesadas pueden votar en contra o dejar de hacer stake en los malos actores, y la red puede aplicarles slashing o bloquearlos. La naturaleza bastante abierta (cualquiera puede convertirse en coordinador o minero si hace stake) significa que la colusión requeriría un gran esfuerzo coordinado que sería evidente. No está tan matemáticamente prevenida como en Bittensor o Gensyn, pero la combinación de stake económico y gobernanza comunitaria proporciona un control.

• Freeloading (Problemas de parasitismo): Esto se refiere a los participantes que intentan obtener recompensas sin contribuir con un valor equivalente, por ejemplo, un validador que en realidad no evalúa pero aún así gana, o un minero que copia las respuestas de otros en lugar de computar, o usuarios que farmean recompensas sin proporcionar una entrada útil.

• Bittensor: Un problema conocido de parasitismo en Bittensor es la "copia de pesos" por parte de validadores perezosos. Un validador podría simplemente copiar la opinión de la mayoría (o las puntuaciones de otro validador) en lugar de evaluar independientemente a los mineros. Al hacerlo, evitan el costo de ejecutar consultas de IA pero aún así obtienen recompensas si sus puntuaciones enviadas parecen alineadas con el consenso. Bittensor combate esto midiendo la alineación con el consenso y la contribución informativa de cada validador. Si un validador siempre copia a otros, puede que se alinee bien (por lo que no es penalizado fuertemente), pero no agrega ningún valor único. Los desarrolladores del protocolo han discutido dar mayores recompensas a los validadores que proporcionan evaluaciones precisas pero no puramente redundantes. Técnicas como la infusión de ruido (dar deliberadamente a los validadores consultas ligeramente diferentes) podrían obligarlos a trabajar realmente en lugar de copiar, aunque no está claro si eso está implementado. El artículo de Arxiv sugiere emisiones ponderadas por rendimiento y métodos de puntuación compuesta para vincular mejor el esfuerzo del validador con la recompensa. En cuanto a los mineros, un posible comportamiento de parasitismo sería si un minero consulta a otros mineros y retransmite la respuesta (una forma de plagio). El diseño de Bittensor (con consultas descentralizadas) podría permitir que el modelo de un minero llame a otros a través de su propia dendrita. Si un minero simplemente retransmite la respuesta de otro, un buen validador podría detectarlo porque la respuesta podría no coincidir consistentemente con las capacidades del modelo declaradas por el minero. Es difícil de detectar algorítmicamente, pero un minero que nunca computa resultados originales debería eventualmente obtener una puntuación baja en algunas consultas y perder reputación. Otro escenario de parasitismo eran los delegadores que ganaban recompensas sin hacer trabajo de IA. Eso es intencional (para involucrar a los poseedores de tokens), por lo que no es un ataque, pero sí significa que algunas emisiones de tokens van a personas que solo hicieron stake. Bittensor lo justifica como una alineación de incentivos, no como recompensas desperdiciadas. En resumen, Bittensor reconoce el problema de los validadores parásitos y está ajustando los incentivos (como dar puntuaciones de confianza de validador que impulsan a aquellos que no se desvían ni copian). Su solución es esencialmente recompensar el esfuerzo y la corrección de manera más explícita, para que no hacer nada o copiar ciegamente produzca menos TAO con el tiempo.

• Gensyn: En Gensyn, a los parásitos les resultaría difícil ganar, porque uno debe proporcionar cómputo o atrapar a alguien haciendo trampa para obtener tokens. Un resolutor no puede "fingir" el trabajo; tiene que presentar una prueba válida o arriesgarse al slashing. No hay mecanismo para recibir un pago sin hacer la tarea. Un verificador podría teóricamente permanecer inactivo y esperar que otros atrapen fraudes, pero entonces no ganaría nada (porque solo el que presenta la prueba de fraude obtiene la recompensa). Si demasiados verificadores intentan parasitar (no re-computando realmente las tareas), entonces un resolutor fraudulento podría pasar desapercibido porque nadie está verificando. El diseño de incentivos de Gensyn aborda esto con la recompensa jackpot: solo se necesita un verificador activo para atrapar a un tramposo y obtener un gran pago, por lo que es racional que al menos uno siempre haga el trabajo. Otros que no trabajan no dañan la red, excepto por ser inútiles; tampoco obtienen recompensa. Así que el sistema filtra naturalmente a los parásitos: solo aquellos verificadores que realmente verifican obtendrán ganancias a largo plazo (otros gastan recursos en nodos para nada o muy raramente obtienen una recompensa por casualidad). El protocolo también podría aleatorizar qué verificador tiene la oportunidad de desafiar para desalentar que todos los verificadores asuman que "alguien más lo hará". Dado que las tareas se pagan individualmente, no hay un análogo de "recompensas de staking sin trabajo" aparte de los incentivos de la testnet que son temporales. Un área a observar es la optimización de múltiples tareas: un resolutor podría intentar reutilizar el trabajo entre tareas o subcontratarlo en secreto a alguien más barato (como usar una nube centralizada), pero eso no es realmente un parasitismo dañino; si entregan resultados correctos a tiempo, no importa cómo lo hicieron. Eso es más como arbitraje que un ataque. En resumen, el diseño del mecanismo de Gensyn deja poco espacio para que los parásitos ganen, porque cada token distribuido corresponde a un trabajo hecho o a un tramposo castigado.

• Cuckoo: La fase inicial de Cuckoo creó inadvertidamente un problema de parasitismo: el airdrop y el staking de alto rendimiento atrajeron a usuarios que solo estaban allí para farmear tokens. Estos usuarios ciclaban tokens a través de faucets o manipulaban las tareas del airdrop (por ejemplo, usando continuamente prompts de prueba gratuitos o creando muchas cuentas para reclamar recompensas) sin contribuir al valor a largo plazo de la red. Cuckoo reconoció esto como un problema: esencialmente, la gente estaba "usando" la red no por el resultado de la IA, sino para obtener una ganancia especulativa. La decisión de terminar la cadena L1 y reenfocarse fue en parte para deshacerse de estas desalineaciones de incentivos. Al vincular las futuras recompensas de tokens al uso real (es decir, ganas porque el servicio está siendo utilizado por clientes que pagan), el atractivo del parasitismo disminuye. También existe un escenario de parasitismo por parte de los mineros: un minero podría unirse, recibir tareas y de alguna manera no realizarlas pero aún así reclamar la recompensa. Sin embargo, el coordinador está verificando los resultados; si un minero no devuelve ninguna salida o una salida incorrecta, el coordinador no lo contará como una tarea completada, por lo que el minero no recibiría pago. Los mineros también podrían intentar seleccionar las tareas fáciles y abandonar las difíciles (por ejemplo, si algunos prompts son más lentos, un minero podría desconectarse para evitarlos). Esto podría ser un problema, pero los coordinadores pueden notar la fiabilidad de un minero. Si un minero se desconecta con frecuencia, el coordinador puede dejar de asignarle tareas o aplicar slashing a su stake (si existe tal mecanismo o simplemente no recompensarlo). El parasitismo de los usuarios: dado que muchos servicios de IA tienen pruebas gratuitas, un usuario podría enviar spam de solicitudes para obtener resultados sin pagar (si hay un modelo subsidiado). Eso no es tanto un problema a nivel de protocolo como a nivel de servicio; cada coordinador puede decidir cómo manejar el uso gratuito (por ejemplo, requiriendo un pequeño pago o limitando la velocidad). Debido a que Cuckoo inicialmente regaló cosas (como generaciones de imágenes de IA gratuitas para atraer usuarios), algunos se aprovecharon, pero eso era parte del marketing de crecimiento esperado. A medida que esas promociones terminen, los usuarios tendrán que pagar, por lo que no habrá almuerzo gratis que explotar. En general, la nueva estrategia de Cuckoo de mapear la distribución de tokens a la utilidad real está explícitamente dirigida a eliminar el problema del parasitismo de "minar tokens por hacer bucles sin sentido".

• Envenenamiento de Datos o Modelos: Esto se refiere a la introducción maliciosa de datos o comportamientos incorrectos de tal manera que los modelos de IA se degradan o los resultados se manipulan, así como problemas de contenido dañino o sesgado que se contribuye.

• Bittensor: El envenenamiento de datos en Bittensor significaría que un minero da intencionalmente respuestas incorrectas o dañinas, o que los validadores evalúan a propósito las buenas respuestas como malas. Si un minero produce basura o contenido malicioso de manera consistente, los validadores le darán puntuaciones bajas, y ese minero ganará poco y eventualmente se retirará; el incentivo económico es proporcionar calidad, por lo que "envenenar" a otros no produce ningún beneficio para el atacante (a menos que su objetivo sea puramente el sabotaje a su propio costo). ¿Podría un minero malicioso envenenar a otros? En Bittensor, los mineros no se entrenan directamente entre sí (al menos no por diseño; no hay un modelo global que se esté actualizando que pueda ser envenenado). El modelo de cada minero es independiente. Sí aprenden en el sentido de que un minero podría tomar muestras interesantes de otros para ajustarse, pero eso es completamente opcional y depende de cada uno. Si un actor malicioso enviara spam de respuestas sin sentido, los validadores honestos lo filtrarían (le darían una puntuación baja), por lo que no influiría significativamente en el proceso de entrenamiento de ningún minero honesto (además, un minero probablemente usaría el conocimiento de sus pares con alta puntuación, no de los de baja puntuación). Así que el envenenamiento de datos clásico (inyectar datos de entrenamiento malos para corromper un modelo) es mínimo en la configuración actual de Bittensor. El riesgo más relevante es la manipulación de la respuesta del modelo: por ejemplo, un minero que produce contenido sutilmente sesgado o peligroso que no es obvio para los validadores. Sin embargo, dado que los validadores también son diseñados por humanos o al menos agentes algorítmicos, es probable que se detecte la toxicidad o el error flagrante (algunas subredes incluso podrían tener validadores de IA que verifiquen contenido inseguro). Un escenario del peor de los casos es si un atacante de alguna manera tuviera la mayoría de los validadores y mineros coludiendo para impulsar una cierta salida incorrecta como "correcta"; entonces podrían sesgar el consenso de la red sobre las respuestas (como todos los validadores en colusión votando a favor de una respuesta maliciosa). Pero para que un usuario externo se vea perjudicado por eso, tendría que consultar realmente la red y confiar en la salida. Bittensor todavía está en una fase en la que está construyendo capacidad, no siendo ampliamente utilizado para consultas críticas por parte de los usuarios finales. Para cuando lo sea, se espera que tenga filtrado de contenido y diversidad de validadores para mitigar tales riesgos. Por el lado del validador, un validador malicioso podría alimentar evaluaciones envenenadas, por ejemplo, votando consistentemente en contra de un cierto minero honesto para eliminar la competencia. Con suficiente stake, podrían tener éxito en expulsar a ese minero (si las recompensas del minero caen tan bajo que se van). Este es un ataque al mecanismo de incentivos. Nuevamente, si no son mayoría, el recorte de la mediana frustrará a un validador atípico. Si son mayoría, se fusiona con el escenario de colusión/51 %: cualquier mayoría puede reescribir las reglas. La solución vuelve a la descentralización: evitar que una sola entidad domine. En resumen, el diseño de Bittensor inherentemente penaliza las contribuciones de datos/modelos envenenados a través de su sistema de puntuación: las malas contribuciones obtienen un peso bajo y, por lo tanto, una baja recompensa. No hay un repositorio de modelos permanente que envenenar; todo es dinámico y se evalúa continuamente. Esto proporciona resiliencia: la red puede "olvidar" o ignorar gradualmente a los malos actores a medida que sus contribuciones son filtradas por los validadores.

• Gensyn: Si un resolutor quisiera envenenar un modelo que se está entrenando (como introducir una puerta trasera o un sesgo durante el entrenamiento), podría intentar hacerlo de forma encubierta. El protocolo de Gensyn verificaría que el entrenamiento procedió de acuerdo con el algoritmo especificado (pasos de descenso de gradiente estocástico, etc.), pero no necesariamente detectaría si el resolutor introdujo un sutil activador de puerta trasera que no aparece en las métricas de validación normales. Este es un problema más insidioso: no es un fallo de la computación, es una manipulación dentro de los grados de libertad permitidos del entrenamiento (como ajustar los pesos hacia una frase activadora). Detectar eso es un problema de investigación activo en seguridad de ML. Gensyn no tiene un mecanismo especial para el envenenamiento de modelos más allá del hecho de que el solicitante podría evaluar el modelo final en un conjunto de prueba de su elección. Un solicitante inteligente siempre debería probar el modelo devuelto; si encuentra que falla en algunas entradas o tiene un comportamiento extraño, puede disputar el resultado o negarse a pagar. Quizás el protocolo podría permitir que un solicitante especifique ciertos criterios de aceptación (como "el modelo debe alcanzar al menos una precisión X en este conjunto de prueba secreto") y si el resultado del resolutor falla, el resolutor no recibe el pago completo. Esto disuadiría el envenenamiento porque el atacante no cumpliría los criterios de evaluación. Sin embargo, si el veneno no afecta la precisión en las pruebas normales, podría pasar desapercibido. Los verificadores en Gensyn solo comprueban la integridad de la computación, no la calidad del modelo, por lo que no detectarían un sobreajuste intencional o troyanos siempre que los registros de entrenamiento parezcan válidos. Por lo tanto, esto sigue siendo un problema de confianza a nivel de tarea: el solicitante tiene que confiar en que el resolutor no envenenará el modelo o usar métodos como el ensamblaje de múltiples resultados de entrenamiento de diferentes resolutores para diluir la influencia de un solo resolutor. Otro ángulo es el envenenamiento de datos: si el solicitante proporciona datos de entrenamiento, un resolutor malicioso podría ignorar esos datos y entrenar con otra cosa o agregar datos basura. Pero eso probablemente reduciría la precisión, lo que el solicitante notaría en el rendimiento del modelo de salida. El resolutor entonces no recibiría el pago completo (ya que presumiblemente quieren cumplir un objetivo de rendimiento). Así que el envenenamiento que degrada el rendimiento es contraproducente para la recompensa del resolutor. Solo un veneno que es neutral en rendimiento pero malicioso (una puerta trasera) es un peligro real, y eso está fuera del alcance de la verificación típica de blockchain; es un desafío de seguridad del aprendizaje automático. La mejor mitigación de Gensyn es probablemente social: usar modelos de reputación conocida, tener múltiples ejecuciones de entrenamiento, usar herramientas de código abierto. En tareas de inferencia (si Gensyn también se usa para trabajos de inferencia), un resolutor en colusión podría devolver salidas incorrectas que sesguen una cierta respuesta. Pero los verificadores detectarían las salidas incorrectas si ejecutan el mismo modelo, por lo que eso es menos un envenenamiento y más simplemente hacer trampa, lo que las pruebas de fraude abordan. En resumen, Gensyn asegura el proceso, no la intención. Asegura que el entrenamiento/inferencia se realizó correctamente, pero no que el resultado sea bueno o libre de maldades ocultas. Eso sigue siendo un problema abierto, y el whitepaper de Gensyn probablemente no lo resuelve por completo todavía (pocos lo hacen).

• Cuckoo: Dado que Cuckoo actualmente se enfoca en la inferencia (servir modelos existentes), el riesgo de envenenamiento de datos/modelos se limita relativamente a la manipulación de la salida o al envenenamiento de contenido. Un minero malicioso podría intentar manipular el modelo que se le da para ejecutar; por ejemplo, si se le proporciona un punto de control de Stable Diffusion, podría cambiarlo por un modelo diferente que quizás inserte alguna marca de agua sutil o publicidad en cada imagen. Sin embargo, el coordinador (que es el propietario del modelo) típicamente envía tareas con una expectativa del formato de salida; si un minero devuelve salidas fuera de especificación de manera consistente, el coordinador marcará y prohibirá a ese minero. Además, los mineros no pueden modificar fácilmente un modelo sin afectar notablemente sus salidas. Otro escenario es si Cuckoo introduce modelos entrenados por la comunidad: entonces los mineros o proveedores de datos podrían intentar envenenar los datos de entrenamiento (por ejemplo, introduciendo muchas etiquetas incorrectas o texto sesgado). Cuckoo necesitaría implementar la validación de datos de crowdsourcing o la ponderación de los contribuyentes. Esto aún no es una característica, pero el interés del equipo en la IA personalizada (como su mención de un entrenador de vida de IA o aplicaciones de aprendizaje) significa que eventualmente podrían manejar datos de entrenamiento proporcionados por el usuario, lo que requerirá verificaciones cuidadosas. En cuanto a la seguridad del contenido, dado que los mineros de Cuckoo realizan inferencias, uno podría preocuparse de que produzcan contenido dañino incluso si el modelo normalmente no lo haría. Pero los mineros no tienen un incentivo para alterar las salidas arbitrariamente; se les paga por la computación correcta, no por la creatividad. En todo caso, un minero malicioso podría saltarse la computación completa para ahorrar tiempo (por ejemplo, devolver una imagen borrosa o una respuesta genérica). El coordinador o el usuario verían eso y calificarían negativamente a ese minero (y probablemente no pagarían por esa tarea). La privacidad es otra faceta: un minero malicioso podría filtrar o registrar datos del usuario (como si un usuario ingresara texto o imágenes sensibles). Esto no es envenenamiento, pero es un ataque a la confidencialidad. La postura de privacidad de Cuckoo es que está explorando métodos de preservación de la privacidad (la mención de una VPN que preserva la privacidad en el ecosistema sugiere un enfoque futuro). Podrían incorporar técnicas como enclaves seguros o inferencia dividida para mantener los datos privados de los mineros. Aún no está implementado, pero es una consideración conocida. Finalmente, el blog de Cuckoo enfatiza la verificación efectiva de los resultados del modelo y la garantía de una operación segura del modelo descentralizado como clave para hacer viable la tokenización de modelos. Esto indica que son conscientes de que para descentralizar verdaderamente la IA, uno debe protegerse contra cosas como salidas envenenadas o modelos que funcionan mal. Posiblemente, tienen la intención de usar una combinación de incentivos criptoeconómicos (slashing de stake para malos actores) y sistemas de calificación de usuarios (los usuarios pueden marcar salidas incorrectas, y esos mineros pierden reputación). El sistema de reputación puede ayudar aquí: si un minero devuelve incluso un resultado obviamente malicioso o incorrecto, los usuarios/coordinadores pueden votarlos negativamente, afectando fuertemente su capacidad de ganancia futura. Sabiendo esto, los mineros están incentivados a ser consistentemente correctos y no introducir ningún veneno. En esencia, Cuckoo se basa en la confianza pero verifica: es más tradicional en el sentido de que si alguien se comporta mal, lo identificas y lo eliminas (con la pérdida de stake como castigo). Todavía no tiene defensas especializadas para el envenenamiento sutil de modelos, pero la estructura de tener propietarios de aplicaciones específicos (coordinadores) a cargo agrega una capa de supervisión; esos propietarios estarán motivados para asegurarse de que nada comprometa la integridad de su modelo, ya que sus propios ingresos y reputación dependen de ello.

En conclusión, si bien las redes de IA descentralizadas introducen nuevas superficies de ataque, también despliegan una mezcla de defensas criptográficas, de teoría de juegos y de gobernanza comunitaria: La resistencia Sybil se maneja en gran medida requiriendo una participación económica para la participación. La resistencia a la colusión proviene de la alineación de incentivos (el comportamiento honesto es más rentable) y mecanismos de consenso que limitan el impacto de pequeños grupos en colusión. La prevención del parasitismo (freerider) se logra vinculando estrechamente las recompensas con el trabajo útil real y penalizando o eliminando a aquellos que no contribuyen en nada. El envenenamiento y ataques relacionados siguen siendo desafiantes, pero los sistemas mitigan los casos flagrantes a través de la evaluación continua y la capacidad de aplicar slashing o expulsar a los actores maliciosos. Estas plataformas están investigando e iterando activamente en estos diseños, como lo demuestran los continuos ajustes de Bittensor a Yuma y dTAO, y el cambio de Cuckoo en la economía de sus tokens, para garantizar un ecosistema de IA descentralizado, seguro y autosostenible.

Evaluación Comparativa​

Para resaltar las diferencias y similitudes de Bittensor, Gensyn y Cuckoo AI, la siguiente tabla proporciona una comparación lado a lado a través de dimensiones clave:

Tabla: Comparación de características de Bittensor, Gensyn y Cuckoo AI en arquitectura, enfoque, roles, consenso, tokens, tokenización de activos, gobernanza, incentivos y seguridad.

El Valor Máximo Extraíble (MEV) se refiere al beneficio que un "insider" de la blockchain (minero/validador u otro actor privilegiado) puede obtener al reordenar, incluir o excluir arbitrariamente transacciones en un bloque. La extracción de MEV sin control puede llevar a una ordenación injusta de transacciones, altas comisiones (debido a las subastas de gas prioritarias) y la centralización del poder en la producción de bloques. Han surgido varios protocolos para suprimir el MEV perjudicial o aplicar una ordenación justa de las transacciones. Este informe compara cuatro enfoques prominentes: Flashbots v2 (el sistema MEV-Boost de Flashbots post-Merge para Ethereum), SUAVE (la próxima Subasta Única Unificadora para la Expresión de Valor de Flashbots), Anoma (una arquitectura centrada en intenciones que reimagina cómo se emparejan y ordenan las transacciones) y Skip Protocol (un conjunto de herramientas basado en Cosmos para la gestión soberana de MEV dentro del protocolo). Examinamos cada uno en términos de sus algoritmos de encolado/ordenación de transacciones, mecanismos de mitigación o extracción de MEV, modelos de incentivos, características de cumplimiento y neutralidad, arquitectura técnica (consenso y criptografía) y progreso de desarrollo. Se proporcionan resúmenes estructurados y una tabla comparativa para destacar sus fortalezas y debilidades en la búsqueda de la equidad y la reducción de las externalidades negativas del MEV.

Flashbots v2 (MEV-Boost y BuilderNet en Ethereum)​

Flashbots v2 denota el ecosistema actual de Flashbots en Ethereum después de la transición a Proof-of-Stake, centrado en MEV-Boost e iniciativas recientes como BuilderNet. Flashbots v2 se basa en el paradigma de separación proponente/constructor (PBS) para abrir la construcción de bloques a un mercado competitivo de constructores mientras protege a los usuarios de Ethereum de los ataques de MEV en el mempool público.

• Ordenación de Transacciones (Encolado y Algoritmo): Flashbots MEV-Boost introduce un mercado de construcción de bloques fuera de la cadena. Los validadores (proponentes) externalizan la construcción de bloques a constructores especializados a través de un relay, en lugar de ordenar las transacciones localmente. Múltiples constructores compiten para proporcionar el bloque que más paga, y el validador firma a ciegas la cabecera del bloque con la oferta más alta (un enfoque PBS). Este diseño reemplaza eficazmente la ordenación de 'primero en llegar, primero en ser servido' del mempool público con una subasta a sobre cerrado para bloques enteros. Los constructores determinan internamente la ordenación de las transacciones para maximizar los pagos totales (incluidas las oportunidades de MEV), prefiriendo típicamente bundles con arbitrajes rentables o liquidaciones en la parte superior del bloque. Al usar MEV-Boost, Ethereum evitó las caóticas subastas de gas prioritarias (PGA) que anteriormente determinaban la ordenación; en lugar de que los usuarios y bots pujaran a través de las comisiones de gas en tiempo real (aumentando la congestión), MEV-Boost centraliza la ordenación por bloque al constructor más competitivo. Las colas de transacciones son, por lo tanto, gestionadas de forma privada por los constructores, quienes pueden ver los bundles o transacciones entrantes y organizarlos para obtener el máximo beneficio. Una desventaja es que esta ordenación impulsada por el beneficio no impone inherentemente la "equidad" para los usuarios; por ejemplo, los constructores aún pueden incluir flujos de órdenes tóxicos como los ataques sándwich si son rentables, pero sí optimiza la eficiencia al extraer MEV a través de una subasta controlada en lugar de guerras de gas ad-hoc. Desarrollos recientes han buscado hacer la ordenación más neutral: por ejemplo, la nueva BuilderNet de Flashbots (lanzada a finales de 2024) permite que múltiples constructores colaboradores compartan el flujo de órdenes y construyan bloques colectivamente en un Entorno de Ejecución Confiable (TEE), introduciendo reglas de ordenación verificables para mejorar la equidad. Esto aleja la ordenación de bloques de un único constructor centralizado hacia una red de construcción de bloques descentralizada con reglas que pueden ser auditadas para garantizar la neutralidad.

• Mecanismos de Supresión vs. Extracción de MEV: Flashbots v2 facilita principalmente la extracción de MEV en una forma más benigna en lugar de eliminarlo. El sistema original de Flashbots (v1) en 2021 permitía a los searchers enviar bundles (conjuntos de transacciones preferidas) directamente a los mineros, lo que suprimía las externalidades perjudiciales (sin front-running público, sin transacciones fallidas debido a la competencia) mientras seguía extrayendo MEV. En la era de MEV-Boost, el MEV es extraído por constructores que agrupan transacciones rentables, pero se reduce la competencia de suma negativa: los searchers ya no saturan el mempool con transacciones competidoras y comisiones de gas exorbitantes, lo que mitiga la congestión de la red y las comisiones excesivas para los usuarios. Flashbots v2 también proporciona herramientas de mitigación de MEV para los usuarios: por ejemplo, Flashbots Protect RPC permite a los usuarios enviar transacciones de forma privada a un relay, evitando el front-running en el mempool público (nadie puede ver o reordenar la transacción antes de su inclusión). Otra iniciativa, MEV-Share, permite a los usuarios compartir la información justa sobre sus transacciones para atraer ofertas de MEV mientras capturan una parte del valor para sí mismos. Sin embargo, Flashbots v2 no "previene" el MEV como los sándwiches o el arbitraje; canaliza estas actividades a través de una subasta eficiente que podría decirse que democratiza quién puede extraer el MEV. Recientemente, el diseño de BuilderNet tiene el objetivo explícito de "neutralizar los juegos de flujo de órdenes de suma negativa" y compartir el MEV con la comunidad a través de reglas de reembolso en la cadena. BuilderNet calcula los reembolsos pagados a los proveedores de flujo de órdenes de transacciones (como billeteras o DApps) en proporción al MEV que sus transacciones generaron, redistribuyendo el valor que de otro modo sería puro beneficio para los constructores. En resumen, Flashbots v2 maximiza la eficiencia de la extracción de MEV (asegurando que casi todo el valor extraíble en un bloque sea capturado) mientras introduce medidas para frenar las peores externalidades y devolver algo de valor a los usuarios. No llega a imponer una ordenación justa (las transacciones todavía se ordenan por el beneficio del constructor), pero a través del envío privado, la construcción multipartita y los reembolsos, suprime el daño negativo al usuario (como el slippage por front-running y los efectos de censura) tanto como sea posible dentro del modelo de subasta.

• Estructura de Incentivos Económicos: Flashbots v2 alinea los incentivos entre validadores, constructores y searchers a través de la subasta PBS. Los validadores se benefician al externalizar la producción de bloques: simplemente aceptan la oferta más alta y reciben el monto de la oferta (además de las recompensas de consenso), lo que aumentó drásticamente la parte del MEV que va a los validadores en comparación con la era en la que los mineros no tenían tales subastas. Los constructores están incentivados a competir entre sí encontrando la ordenación más rentable de las transacciones (a menudo incorporando estrategias de los searchers), y se quedan con cualquier beneficio de MEV que quede después de pagar la oferta del validador. En la práctica, la competencia obliga a los constructores a pagar la mayor parte del MEV a los validadores (a menudo >90% del beneficio), quedándose solo con un margen delgado. Los searchers (que ahora interactúan con los constructores a través de bundles o transacciones directas) todavía ganan al descubrir oportunidades de MEV (arbitraje, liquidación, etc.), pero deben ofrecer la mayor parte de su beneficio para ganar la inclusión; en efecto, los beneficios de los searchers se transfieren a los validadores a través de las ofertas de los constructores. Este equilibrio competitivo maximiza los ingresos totales de la red (beneficiando a los validadores/stakers) pero reduce los márgenes de los searchers individuales. Flashbots v2, por lo tanto, desincentiva los acuerdos exclusivos: cualquier searcher o constructor con una estrategia de MEV privada está incentivado a ofertarla a través del relay abierto para evitar ser superado, lo que conduce a un mercado más abierto. La introducción de BuilderNet añade un incentivo para los originadores de flujo de órdenes (como DEXs o billeteras): al darles reembolsos por el MEV que crean sus transacciones, anima a los usuarios y aplicaciones a enviar su flujo de órdenes al ecosistema de BuilderNet. Este mecanismo alinea a los usuarios con el sistema: en lugar de ser adversarios (usuarios vs. extractores de MEV), los usuarios comparten el MEV, por lo que están más dispuestos a participar en la subasta de manera justa. En general, la economía de Flashbots v2 favorece la colaboración sobre la competencia en la construcción de bloques: los validadores obtienen ingresos máximos sin riesgo, los constructores compiten en la calidad de la ejecución, y los searchers innovan para encontrar MEV pero renuncian a la mayoría de los beneficios para ganar las ofertas, mientras que los usuarios obtienen protección y posiblemente reembolsos.

• Cumplimiento y Resistencia a la Censura: El cumplimiento normativo se convirtió en un tema polémico para Flashbots después del Merge de Ethereum. El relay predeterminado de Flashbots implementó inicialmente el cumplimiento de las sanciones de la OFAC (censurando ciertas transacciones como las de Tornado Cash), lo que llevó a que aproximadamente el 80% de los bloques de Ethereum a finales de 2022 fueran "compatibles con la OFAC" y generó preocupaciones sobre centralización/censura en la comunidad. Flashbots v2 abordó esto fomentando un ecosistema de múltiples relays donde los validadores pueden elegir relays no censuradores (por ejemplo, UltraSound, Agnostic) o incluso ejecutar los suyos. Flashbots hizo público el código de su relay a mediados de 2022 para fomentar la competencia global de relays y la transparencia. Además, MEV-Boost v1.4 introdujo características como un ajuste de oferta mínima para que los proponentes pudieran rechazar ofertas bajas de constructores censuradores y recurrir a bloques locales, sacrificando algo de beneficio por la inclusión de todas las transacciones. Esta característica dio explícitamente a los validadores una forma de mejorar la resistencia a la censura de Ethereum a un pequeño costo. A finales de 2024, Flashbots dio un paso más al descontinuar su propio constructor centralizado en favor de BuilderNet, una red colaborativa destinada a ser "incensurable y neutral". BuilderNet utiliza TEEs (Intel SGX) para mantener el flujo de órdenes de transacciones encriptado y se compromete verificablemente a una regla de ordenación, lo que puede ayudar a evitar que los constructores individuales censuren transacciones específicas. Con múltiples participantes construyendo bloques conjuntamente dentro de enclaves seguros, ninguna parte puede excluir fácilmente una transacción sin ser detectada. En resumen, Flashbots v2 ha evolucionado de un único relay (e inicialmente censurador) a una infraestructura más descentralizada con participación abierta y objetivos explícitos de neutralidad. El cumplimiento se deja a las políticas de los relays/constructores individuales (y los validadores pueden elegir), en lugar de ser impuesto por el protocolo. La trayectoria es hacia la neutralidad creíble: eliminar cualquier punto de estrangulamiento controlado por Flashbots que pueda ser presionado por los reguladores. Flashbots se ha comprometido públicamente a eliminarse a sí mismo como operador central y a descentralizar todos los aspectos de la cadena de suministro de MEV a largo plazo.

• Arquitectura Técnica y Criptografía: Flashbots v2 opera de forma híbrida, fuera de la cadena y en el protocolo. La subasta principal (MEV-Boost) ocurre fuera de la cadena a través de la red de constructores y relays, pero se conecta directamente al consenso de Ethereum: los validadores ejecutan un cliente sidecar (mev-boost) que interactúa con los relays utilizando la API de Constructor estandarizada. En cuanto al consenso, Ethereum todavía utiliza PoS estándar (Casper/Hotstuff); MEV-Boost no altera las reglas de consenso de L1, solo cambia quién ensambla el bloque. Inicialmente, la subasta de Flashbots requería confiar en que el relay y el constructor no robarían transacciones ni censurarían; no había garantías criptográficas (el sistema se basaba en el incentivo económico de que los constructores deben entregar una carga útil válida que coincida con su oferta o pierden el espacio). Con el tiempo, Flashbots v2 ha integrado más tecnología de seguridad. La introducción de Entornos de Ejecución Confiable (TEE) a través de BuilderNet es un cambio arquitectónico notable: los constructores se ejecutan dentro de enclaves SGX para que incluso el operador del constructor no pueda ver el flujo de órdenes de transacciones en bruto (evitando que lo filtren o le hagan front-running). Estos enclaves siguen colectivamente un protocolo para producir bloques, lo que puede permitir una equidad verificable (por ejemplo, demostrar que las transacciones se ordenaron según una regla comprometida o que ninguna entidad no autorizada las vio antes de la inclusión). Aunque se utiliza SGX (un enfoque basado en hardware), la investigación de Flashbots también está explorando primitivas criptográficas puras, como el cifrado de umbral para la privacidad del mempool y la computación segura multipartita, para eventualmente reemplazar o complementar los TEEs y reducir aún más la confianza. La pila de software de Flashbots v2 incluye clientes personalizados como MEV-geth (ahora obsoleto) y constructores basados en Rust (por ejemplo, rbuilder), y se adhiere a las especificaciones de constructor de Ethereum para la interoperabilidad. En resumen, la arquitectura es modular: una red de relays, constructores y ahora enclaves, que se sitúa entre los usuarios y los proponentes de Ethereum. Prioriza el rendimiento (ofertas rápidas, entrega de bloques) y está añadiendo gradualmente garantías criptográficas de privacidad y ordenación justa. No se introduce ningún nuevo algoritmo de consenso; en su lugar, Flashbots v2 funciona junto con el consenso de Ethereum, evolucionando el pipeline de producción de bloques en lugar de las reglas de consenso.

• Hoja de Ruta de Desarrollo y Hitos: Flashbots ha progresado a través de fases iterativas. Flashbots v1 (2020–2021) implicó el lanzamiento de MEV-geth y las primeras subastas de bundles fuera de la cadena con mineros. A mediados de 2021, más del 80% del hashrate de Ethereum ejecutaba MEV-geth de Flashbots, confirmando la adopción del enfoque. Flashbots v2 (2022) fue concebido antes del Merge: en noviembre de 2021, Flashbots publicó la arquitectura MEV-Boost para Ethereum PoS. Después de que Ethereum cambiara a PoS (15 de septiembre de 2022), MEV-Boost se activó en cuestión de días y alcanzó rápidamente la adopción mayoritaria por parte de los validadores. Hitos posteriores incluyeron la publicación del código del relay (agosto de 2022) y del constructor de bloques interno de Flashbots (noviembre de 2022) para estimular la competencia. A finales de 2022, Flashbots también añadió características centradas en la resistencia a la censura y la resiliencia (por ejemplo, min-bid para proponentes) y escribió sobre el "Costo de la Resiliencia" para alentar a los validadores a preferir a veces la inclusión sobre el beneficio. A lo largo de 2023, mejorar la descentralización de los constructores se convirtió en un enfoque clave: Flashbots lanzó "rbuilder" (un constructor de Rust de alto rendimiento) en julio de 2024 como una implementación de referencia para reducir la barrera para nuevos constructores. Finalmente, a finales de 2024, Flashbots lanzó BuilderNet (alfa) en colaboración con socios (Beaverbuild, Nethermind). En diciembre de 2024, Flashbots cerró su constructor centralizado y migró todo el flujo de órdenes a BuilderNet, un paso significativo hacia la descentralización. A principios de 2025, se lanzó BuilderNet v1.2 con mejoras de seguridad e incorporación (incluidas compilaciones de enclaves reproducibles). Estos hitos marcan la transición de Flashbots de una solución centralizada conveniente a un protocolo más abierto y gestionado por la comunidad. Mirando hacia el futuro, Flashbots está convergiendo con su visión de próxima generación (SUAVE) para descentralizar completamente la capa de construcción de bloques e incorporar tecnología de privacidad avanzada. Muchas lecciones de Flashbots v2 (por ejemplo, la necesidad de neutralidad, el alcance multicadena y la inclusión de los usuarios en las recompensas de MEV) informan directamente la hoja de ruta de SUAVE.

SUAVE (Subasta Única Unificadora para la Expresión de Valor de Flashbots)​

SUAVE es el ambicioso siguiente protocolo de Flashbots, diseñado como un mercado de MEV descentralizado y multidominio y una capa de secuenciación justa de transacciones. Su objetivo es desvincular los mempools y la construcción de bloques de las blockchains individuales y proporcionar una plataforma unificada donde los usuarios expresan preferencias, una red descentralizada ejecuta transacciones de manera óptima y los constructores de bloques producen bloques para muchas cadenas de una manera creíblemente neutral. En resumen, SUAVE busca maximizar la extracción total de valor mientras devuelve valor a los usuarios y preserva la descentralización de la blockchain. Flashbots introdujo SUAVE a finales de 2022 como "el futuro del MEV" y lo ha estado desarrollando de forma abierta desde entonces.

• Encolado y Ordenación de Transacciones: Desde un alto nivel, SUAVE funciona como una red de blockchain independiente que otras cadenas pueden usar como un mempool y constructor de bloques plug-and-play. En lugar de que las transacciones se pongan en cola en el mempool de cada cadena y sean ordenadas por mineros o validadores locales, los usuarios pueden enviar sus transacciones (o, más generalmente, preferencias) al mempool de la red SUAVE. El mempool de SUAVE sirve entonces como un pool de subasta global de preferencias de todas las cadenas participantes. La ordenación de las transacciones se determina a través de esta subasta y la posterior optimización de la ejecución. Específicamente, SUAVE introduce el concepto de preferencias: el envío de un usuario no es solo una transacción en bruto para una cadena, sino que puede codificar un objetivo o un intercambio condicional (posiblemente abarcando múltiples cadenas) y una oferta asociada que el usuario está dispuesto a pagar por su cumplimiento. El algoritmo de ordenación/encolado en SUAVE tiene múltiples etapas: Primero, los usuarios publican sus preferencias en el mempool de SUAVE (el "Entorno de Preferencia Universal"), que agrega todas las órdenes de forma privada y global. A continuación, nodos especializados llamados ejecutores (análogos a los searchers/solvers) monitorean este mempool y compiten en un Mercado de Ejecución Óptima para cumplir estas preferencias. Efectivamente, "ponen en cola" las transacciones encontrando coincidencias u ordenaciones de ejecución óptimas para ellas. Finalmente, SUAVE produce salidas de bloque para cada cadena conectada a través de una capa de Construcción de Bloques Descentralizada: muchos constructores (o ejecutores de SUAVE actuando como constructores) colaboran para construir bloques utilizando el orden de transacciones (ahora optimizado) derivado de las preferencias de los usuarios. En términos prácticos, la ordenación de SUAVE es flexible y dirigida por el usuario: un usuario puede especificar condiciones como "ejecutar mi operación solo si el precio < X" o incluso expresar una intención abstracta ("intercambiar token A por B a la mejor tasa en 1 minuto") en lugar de una transacción estricta. El sistema pone en cola estas intenciones hasta que un ejecutor encuentra una ordenación o coincidencia óptima (posiblemente agrupándola con otras). Debido a que SUAVE es agnóstico a la blockchain, puede coordinar la ordenación entre cadenas (evitando escenarios donde los arbitrajes entre cadenas se pierden debido a mempools separados y no coordinados). En esencia, SUAVE implementa una subasta global de MEV: todos los participantes comparten una capa de secuenciación, que ordena las transacciones basándose en preferencias y ofertas agregadas en lugar de un simple orden de llegada o precio del gas. Esto tiene el efecto de nivelar el campo de juego: todo el flujo de órdenes pasa por una cola transparente (aunque encriptada para la privacidad, como se discute a continuación) en lugar de acuerdos exclusivos o mempools privados. El algoritmo de ordenación de SUAVE todavía se está refinando, pero es probable que involucre subastas por lotes que preservan la privacidad y algoritmos de emparejamiento para que se puedan lograr resultados "justos" (como el máximo excedente total o precios óptimos para el usuario) en lugar de un puro "primero en llegar, primero en ser servido". Notablemente, SUAVE tiene la intención de evitar que cualquier actor único manipule la ordenación: es nativo de Ethereum y consciente del MEV, con un mempool encriptado que prioriza la privacidad y protege contra cualquier punto central de control. En resumen, la cola de SUAVE es un pool de flujo de órdenes unificado donde la ordenación está determinada por una combinación de ofertas de los usuarios, estrategia de los ejecutores y (eventualmente) restricciones de equidad criptográficas, en lugar de por proponentes de bloques compitiendo por la prioridad.

• Mecanismos de Supresión/Extracción de MEV: La filosofía de SUAVE es que el MEV puede ser aprovechado en beneficio de los usuarios y para la seguridad de la red si se hace de manera cooperativa y descentralizada. En lugar de ignorar el MEV o dejar que se concentre en unas pocas manos, SUAVE explícitamente saca a la luz las oportunidades de MEV y devuelve el valor a quienes lo crean (los usuarios) tanto como sea posible. El mecanismo principal es la subasta de flujo de órdenes: cada vez que la transacción (preferencia) de un usuario tiene MEV —por ejemplo, podría ser objeto de back-running para obtener un beneficio— SUAVE llevará a cabo una subasta entre los ejecutores (searchers) por el derecho a ejecutar esa oportunidad de MEV. Los searchers (ejecutores) pujan prometiendo una parte del beneficio de vuelta al usuario como pago (este es el campo de "oferta" del usuario en su preferencia, que va a quien la cumpla). El resultado es una extracción de MEV competitiva que dirige los ingresos hacia el usuario en lugar del extractor. Por ejemplo, si una gran operación DEX de un usuario crea una oportunidad de arbitraje de 100 $, los searchers en SUAVE podrían reducir el beneficio ofreciendo, digamos, 90$ de vuelta al usuario como reembolso, quedándose solo con 10 $. Esto suprime los aspectos negativos del MEV como la extracción de valor del usuario, y convierte el MEV en un beneficio para el usuario (los usuarios obtienen efectivamente una mejora de precio o reembolsos). El diseño de SUAVE también suprime el front-running y otros MEV maliciosos: las transacciones en el mempool de SUAVE pueden mantenerse encriptadas hasta que se esté construyendo un bloque (usando enclaves SGX inicialmente, y avanzando hacia la criptografía de umbral). Esto significa que ningún actor externo puede ver las transacciones pendientes para hacerles front-running; solo cuando se recopilan suficientes transacciones y se finaliza un bloque, se desencriptan y ejecutan, similar en espíritu a las subastas por lotes o mempools encriptados que eliminan la ventaja de prioridad temporal de los bots. Además, como los ejecutores optimizan la ejecución a través de muchas preferencias, SUAVE puede eliminar la competencia ineficiente (como dos bots luchando por el mismo arbitraje mediante spam). En su lugar, SUAVE selecciona al mejor ejecutor a través de la subasta y ese ejecutor realiza la operación una vez, con el resultado beneficiando al usuario y a la red. SUAVE actúa así como un agregador de MEV y una "hada madrina": no elimina el MEV (las oportunidades rentables todavía se aprovechan), pero esas oportunidades se realizan bajo reglas transparentes y con las ganancias distribuidas en gran medida a los usuarios y validadores (y no desperdiciadas en comisiones de gas o guerras de latencia). Al unificar los mempools, SUAVE también aborda el MEV multidominio de una manera fácil de usar; por ejemplo, un arbitraje entre Uniswap en Ethereum y un DEX en Arbitrum podría ser capturado por un ejecutor de SUAVE y una parte pagada a los usuarios de ambos lados, en lugar de perderse o requerir un arbitrajista centralizado. Es importante destacar que SUAVE suprime las fuerzas centralizadoras del MEV: los acuerdos de flujo de órdenes exclusivos (donde entidades privadas capturan MEV) se vuelven innecesarios si todos usan la subasta común. La visión final de SUAVE es reducir la extracción de MEV perjudicial (como los ataques sándwich que causan slippage) ya sea haciéndolos no rentables o reembolsando el slippage, y usar el "buen MEV" (arbitraje, liquidaciones) para fortalecer las redes (a través del reparto de ingresos y la ejecución óptima). En palabras de Flashbots, el objetivo de SUAVE es asegurar que "los usuarios realicen transacciones con la mejor ejecución y las mínimas comisiones" mientras que "los validadores obtienen los máximos ingresos", es decir, cualquier MEV presente se extrae de la manera más alineada con el usuario.

• Estructura de Incentivos Económicos: SUAVE introduce nuevos roles y flujos de incentivos en la cadena de suministro de MEV. Los principales participantes son los usuarios, los ejecutores, los constructores/validadores de bloques y los operadores de la red SUAVE (validadores de la cadena SUAVE). Los usuarios establecen una oferta (pago) en su preferencia, que se pagará si se cumplen sus condiciones. Esta oferta es el anzuelo para los ejecutores: un ejecutor que cumple la intención del usuario (por ejemplo, hace back-running a su operación para obtener un mejor precio) puede reclamar la oferta como recompensa. Por lo tanto, los usuarios están directamente pagando por la calidad de la ejecución, de forma similar a publicar una recompensa. Los ejecutores (Searchers) están motivados a tomar las preferencias de los usuarios del mempool de SUAVE y optimizarlas porque ganan la oferta del usuario más cualquier beneficio de arbitraje extra inherente a la transacción. Los ejecutores competirán para ofrecer el mejor resultado al usuario porque el usuario puede establecer su oferta de manera que solo pague si el ejecutor realmente logra el resultado deseado (la oferta puede ser condicional a los resultados en la cadena a través de oráculos). Por ejemplo, un usuario podría decir: "Pagaré 0.5 ETH a quien ejecute esta transacción de tal manera que obtenga al menos X de salida; si no, no hay pago". Esto alinea los incentivos de los ejecutores con el éxito del usuario. Validadores/Constructores de SUAVE: La propia cadena SUAVE probablemente será una red Proof-of-Stake (diseño por determinar), por lo que los validadores (que producen bloques en SUAVE) ganan comisiones de transacción en SUAVE (que provienen de los usuarios que publican ofertas y otras operaciones). Dado que SUAVE es una cadena compatible con EVM, también puede haber un token nativo o un sistema de comisiones de gas para esas transacciones. Estos validadores también desempeñan un papel en la secuenciación de bloques multidominio; sin embargo, la inclusión final del bloque en cada L1 todavía la realiza el validador de esa L1. En muchos casos, SUAVE producirá una plantilla de bloque parcial o completa que un proponente de Ethereum u otra cadena puede adoptar. Ese constructor podría pagar a SUAVE (o a los ejecutores de SUAVE) una parte del MEV. Flashbots ha mencionado que los validadores de SUAVE son incentivados por las comisiones normales de la red, mientras que los ejecutores son incentivados por las ofertas. Distribución de Valor: El enfoque de SUAVE tiende a empujar el valor hacia los extremos: los usuarios capturan valor (a través de mejores precios o reembolsos directos), y los validadores capturan valor (a través de mayores comisiones/ofertas). En teoría, si SUAVE cumple su misión, la mayor parte del MEV será devuelta a los usuarios o utilizada para compensar a los validadores por asegurar la red, en lugar de concentrarse en los searchers. Flashbots ha indicado que no planea buscar rentas de SUAVE y no tomará una parte más allá de lo necesario para arrancar; quieren diseñar el mercado, no monopolizarlo. Otra consideración de incentivos son los constructores entre cadenas: SUAVE permite a los constructores de bloques acceder al MEV multidominio, lo que significa que un constructor en una cadena puede ganar comisiones adicionales al incluir transacciones que completan un arbitraje con otra cadena. Esto anima a los constructores/validadores de diferentes cadenas a participar en SUAVE, porque quedarse fuera significa perder ingresos. En esencia, el diseño económico de SUAVE intenta alinear a todos los participantes para que se unan a la subasta común: los usuarios porque obtienen una mejor ejecución (y quizás reembolsos de MEV), los validadores porque obtienen los máximos ingresos, y los searchers porque ahí es donde se agrega el flujo de órdenes. Al concentrar el flujo de órdenes, SUAVE también obtiene una ventaja de información sobre cualquier actor aislado (todas las preferencias en un solo lugar), lo que presiona económicamente a todos a cooperar dentro de SUAVE en lugar de separarse. En resumen, los incentivos de SUAVE promueven un ciclo virtuoso: más flujo de órdenes → mejores oportunidades de MEV combinadas → ofertas más altas para usuarios/validadores → más flujo de órdenes. Esto contrasta con la competencia de suma cero y los acuerdos exclusivos del pasado, apuntando en cambio a la "coopetición" donde el MEV es un valor compartido para crecer y distribuir.

• Cumplimiento y Consideraciones Regulatorias: SUAVE se está construyendo con la neutralidad creíble y la resistencia a la censura como principios fundamentales. Por diseño, SUAVE elimina intermediarios centrales: no hay un único mempool o un único constructor para atacar o regular. Las transacciones (preferencias) en SUAVE pueden ser totalmente encriptadas y privadas hasta que se ejecutan, utilizando enclaves seguros y, eventualmente, técnicas criptográficas. Esto significa que la censura a nivel de contenido de la transacción es impracticable, ya que los validadores/constructores ni siquiera pueden leer los detalles de la transacción antes de finalizar el orden. SUAVE esencialmente fuerza un enfoque de "no confíes, verifica": los participantes no necesitan confiar en que una entidad no censure, porque la propia arquitectura del sistema (red descentralizada + encriptación) asegura que las preferencias de todos se incluyan de manera justa. Además, SUAVE está destinado a ser una red abierta y sin permisos: Flashbots invita explícitamente a todas las partes (usuarios, searchers, billeteras, otras blockchains) a participar. No hay KYC ni barreras de permiso en su diseño. Esto podría plantear preguntas a los reguladores (por ejemplo, el protocolo podría facilitar la extracción de MEV en transacciones sancionadas), pero como SUAVE es solo una plataforma descentralizada, la aplicación sería difícil y análoga a tratar de regular el mempool de una blockchain. El enfoque de SUAVE en la privacidad (a través de SGX y más tarde la criptografía) también protege los datos de los usuarios y el flujo de órdenes de un monitoreo no deseado, lo cual es positivo para la seguridad del usuario pero podría entrar en conflicto con los deseos regulatorios de transparencia. Por otro lado, el enfoque de SUAVE podría verse como más justo y conforme con el espíritu de los mercados abiertos: al crear un campo de juego nivelado y devolver valor a los usuarios, reduce los aspectos explotadores del MEV que podrían atraer la ira regulatoria (como hacer back-running a los usuarios sin su consentimiento). SUAVE también puede ayudar a eliminar los dark pools no regulados: una razón por la que los reguladores podrían estar preocupados por el MEV son las ventas de flujo de órdenes exclusivas (que se asemejan al uso de información privilegiada). SUAVE las reemplaza con una subasta pública transparente, una estructura de mercado posiblemente más compatible. En términos de características de cumplimiento explícitas, SUAVE podría permitir múltiples políticas de ordenación: por ejemplo, las comunidades o jurisdicciones podrían desplegar sus propios ejecutores con ciertos filtros o preferencias. Sin embargo, la base es que SUAVE intentará ser máximamente neutral: "eliminar cualquier punto central de control, incluido Flashbots" y evitar incrustar decisiones de política a nivel de protocolo. Flashbots ha enfatizado que no controlará el mercado de SUAVE a medida que madure, lo que significa que no habrá un interruptor de apagado central o un conmutador de censura. La gobernanza (si la hay) de SUAVE aún no está definida públicamente, pero se puede esperar que involucre a la comunidad en general y posiblemente a un token, en lugar de la decisión de una empresa. En resumen, SUAVE está diseñado para alinearse con los principios descentralizados, lo que por naturaleza resiste cierto control regulatorio (censura), mientras que potencialmente alivia algunas preocupaciones regulatorias al hacer que la extracción de MEV sea más equitativa y transparente.

• Arquitectura Técnica (Consenso y Criptografía): SUAVE operará su propio entorno de blockchain, al menos inicialmente. Se describe como una cadena compatible con EVM especializada en preferencias y MEV. La arquitectura tiene tres componentes principales: (1) el Entorno de Preferencia Universal (la cadena SUAVE + mempool, donde se publican y agregan las preferencias), (2) el Mercado de Ejecución (ejecutores fuera o dentro de la cadena que resuelven/optimizan las preferencias, similar a un "motor de emparejamiento de órdenes" descentralizado), y (3) la Construcción de Bloques Descentralizada (una red de participantes de SUAVE que ensamblan bloques para varios dominios). En su núcleo, el consenso de SUAVE probablemente será un consenso BFT de Prueba de Participación (similar a Ethereum o Cosmos) para operar la propia cadena SUAVE, aunque todavía se está decidiendo si SUAVE se convertirá en una L1, una L2 de Ethereum o un conjunto de contratos de "restaking". Una posibilidad es que SUAVE pueda comenzar como una capa 2 o sidechain que utiliza Ethereum para la finalidad, o aprovechar conjuntos de validadores existentes. El modelo de seguridad está por determinar, pero las discusiones han incluido convertirlo en una L3 de Ethereum o una cadena de Cosmos. Criptográficamente, SUAVE se apoya fuertemente en Hardware Confiable y encriptación en su hoja de ruta inicial. La fase SUAVE Centauri implementa una "subasta de flujo de órdenes consciente de la privacidad" en la que Flashbots (de forma centralizada) opera enclaves SGX para mantener privados los flujos de órdenes de los searchers y usuarios. En SUAVE Andromeda, planean usar subastas y construcción de bloques basadas en SGX sin confiar en Flashbots (los enclaves proporcionan confidencialidad para que ni siquiera Flashbots pueda espiar). Para SUAVE Helios, el objetivo es tener una red de construcción descentralizada basada en SGX, lo que significa que muchas partes independientes ejecutan enclaves que construyen bloques colectivamente, logrando tanto privacidad como descentralización. A largo plazo, Flashbots está investigando enclaves seguros personalizados y reemplazos criptográficos como el descifrado de umbral y la computación multipartita para reducir la dependencia del SGX de Intel. Por ejemplo, podrían usar un esquema de cifrado de umbral donde los validadores de SUAVE mantienen conjuntamente una clave para descifrar transacciones solo después de que se decide la ordenación (asegurando que nadie pueda hacer front-running). Este concepto es similar a Ferveo de Anoma u otras ideas de "ordenación justa a través de cifrado de umbral". Además, SUAVE trata las preferencias del usuario como contratos inteligentes en su cadena. La preferencia de un usuario podría contener un predicado de validez y una condición de pago; esto es esencialmente un fragmento de código que dice "si se logra el resultado X en la cadena Y, entonces paga al ejecutor Z esta cantidad". La cadena SUAVE necesita manejar oráculos y verificación entre cadenas para saber cuándo se ha cumplido una preferencia (por ejemplo, leyendo el estado de Ethereum para ver si ocurrió un intercambio). Esto implica que la arquitectura de SUAVE involucrará clientes ligeros en cadena o sistemas de oráculos para las cadenas conectadas, así como potencialmente liquidación atómica entre cadenas (para asegurar, por ejemplo, que un ejecutor pueda ejecutar en Ethereum y Arbitrum y reclamar la oferta atómicamente). SUAVE planea ser altamente extensible: al ser compatible con EVM, contratos arbitrarios (preferencias nativas de SUAVE o incluso dapps normales) podrían ejecutarse en él, aunque la intención es mantenerlo enfocado en la coordinación del flujo de órdenes. En cuanto al consenso, SUAVE podría innovar al ser una cadena centrada en intenciones en lugar de una centrada en transacciones, pero en última instancia debe ordenar mensajes (preferencias) y producir bloques como cualquier cadena. Uno puede imaginar que SUAVE adopte un algoritmo de consenso optimizado para rendimiento y finalidad de baja latencia, ya que se situará en la ruta crítica de las transacciones para muchas cadenas. Quizás se podría usar una finalidad instantánea al estilo de Tendermint o incluso un consenso basado en DAG para confirmar rápidamente las preferencias. Independientemente, las características distintivas de SUAVE están en la capa de transacción, no en la capa de consenso: el uso de tecnología de privacidad (SGX, cifrado de umbral) para la ordenación, la comunicación multidominio y la lógica de enrutamiento de órdenes inteligentes integrada en el protocolo. Esto lo convierte en una especie de "meta-capa" sobre las blockchains existentes. Técnicamente, cada cadena participante necesitará confiar en las salidas de SUAVE hasta cierto punto (por ejemplo, un proponente de Ethereum necesitaría aceptar un bloque construido por SUAVE o incluir sugerencias de SUAVE). Flashbots ha indicado que SUAVE se introducirá gradualmente y será opcional: los dominios pueden elegir adoptar la secuenciación de SUAVE para sus bloques. Si se adopta ampliamente, SUAVE podría convertirse en una red de enrutamiento de transacciones consciente del MEV de facto para Web3. En resumen, la arquitectura de SUAVE es un matrimonio entre blockchain y subasta fuera de la cadena: una cadena especializada para la coordinación, casada con la computación segura fuera de la cadena entre ejecutores, todo anclado por garantías criptográficas de equidad y privacidad.

• Hoja de Ruta de Desarrollo y Hitos: Flashbots delineó la hoja de ruta de SUAVE en tres hitos principales, nombrados como sistemas estelares: Centauri, Andromeda y Helios. Centauri (la primera fase, en desarrollo en 2023) se enfoca en construir una subasta de flujo de órdenes centralizada pero que preserva la privacidad. En esta fase, Flashbots ejecuta el servicio de subasta (probablemente en SGX) que permite a los searchers pujar para hacer back-running a las transacciones de los usuarios, devolviendo el MEV a los usuarios de forma privada. También incluye el lanzamiento de una devnet de SUAVE para pruebas iniciales. De hecho, en agosto de 2023, Flashbots publicó un cliente temprano de SUAVE (suave-geth) y lanzó Toliman, la primera testnet pública de SUAVE. Esta testnet se ha utilizado para experimentar con la expresión de preferencias y la lógica básica de subastas. Andromeda (la siguiente fase) lanzará la primera mainnet de SUAVE. Aquí, los usuarios podrán expresar preferencias en una red en vivo, y el Mercado de Ejecución operará (ejecutores cumpliendo intenciones). Andromeda también introduce subastas y construcción de bloques basadas en SGX de una manera más distribuida, eliminando la necesidad de confiar en Flashbots como operador y haciendo el sistema verdaderamente sin permisos para searchers y constructores. Un entregable en esta fase es usar SGX para encriptar el flujo de órdenes de manera que incluso los constructores de bloques no puedan espiar pero aún puedan construir bloques (es decir, un flujo de órdenes "abierto pero privado"). Helios es la ambiciosa tercera fase donde SUAVE alcanza la descentralización total y la funcionalidad entre cadenas. En Helios, una red descentralizada de constructores en SGX produce bloques de forma colaborativa (sin dominio de un solo constructor). Además, SUAVE "incorporará un segundo dominio" más allá de Ethereum, lo que significa que manejará el MEV para al menos dos cadenas, demostrando subastas de MEV entre cadenas. Adicionalmente, se habilitará la expresión y ejecución de MEV multidominio (los usuarios pueden publicar intenciones verdaderamente multicadena y hacer que se ejecuten atómicamente). Más allá de Helios, Flashbots anticipa explorar hardware personalizado y criptografía avanzada (como pruebas zk o MPC) para endurecer aún más las garantías de confianza. Actualizaciones y hitos clave hasta ahora: Noviembre de 2022 – se anuncia SUAVE; Agosto de 2023 – primer lanzamiento de código de SUAVE y testnet (Toliman); en curso en 2024 – fase Centauri de subasta de flujo de órdenes en ejecución (Flashbots ha insinuado que esto se está probando con transacciones de usuarios en un entorno cerrado). Un hito notable será el lanzamiento de la mainnet de SUAVE (Andromeda), que a mediados de 2025 está en el horizonte. Flashbots se ha comprometido a construir SUAVE de forma abierta e invitar a la colaboración de todo el ecosistema. Esto se refleja en la investigación y las discusiones del foro, como las publicaciones de la serie "Stargazing" que actualizan sobre la evolución del diseño de SUAVE. El objetivo final de SUAVE es que se convierta en una pieza de infraestructura propiedad de la comunidad: la "capa de secuenciación descentralizada" para todo el mundo cripto. Lograr esto marcará un hito importante en la lucha por la ordenación justa: si SUAVE tiene éxito, el MEV ya no sería un bosque oscuro sino una fuente de valor transparente y compartida, y ninguna cadena tendría que sufrir por sí sola los efectos centralizadores del MEV.

Anoma (Arquitectura Centrada en Intenciones para el Descubrimiento Justo de Contrapartes)​

Anoma es un enfoque radicalmente diferente para permitir la ordenación justa y la mitigación de MEV: es una arquitectura completa para una infraestructura de blockchain basada en intenciones. En lugar de añadir una subasta a las cadenas existentes, Anoma replantea el paradigma de las transacciones desde cero. En Anoma, los usuarios no transmiten transacciones concretas; transmiten intenciones, declaraciones del estado final que desean, y la propia red descubre contrapartes y forma transacciones que cumplen estas intenciones. Al integrar el descubrimiento de contrapartes, la ordenación justa y la privacidad a nivel de protocolo, Anoma tiene como objetivo eliminar virtualmente ciertas formas de MEV (como el front-running) y permitir un intercambio y liquidación descentralizados "libres de front-runners". Anoma es más un marco que una sola cadena: cualquier blockchain puede ser una "instancia fractal" de Anoma adoptando su arquitectura de gossip de intenciones y emparejamiento. Para esta discusión, nos centramos en la primera implementación de Anoma (a veces llamada Anoma L1) y sus características de protocolo principales, en lo que respecta a la equidad y el MEV.

• Encolado y Ordenación de Transacciones: Anoma descarta el mempool convencional de transacciones; en su lugar, tiene una red de gossip de intenciones. Los usuarios transmiten una intención, por ejemplo, "Quiero cambiar 100 DAI por al menos 1 ETH" o "Quiero pedir prestado contra colateral a la mejor tasa". Estas intenciones son órdenes parciales: no especifican rutas de ejecución exactas, solo el resultado deseado y las restricciones. Todas las intenciones se transmiten por toda la red y se recopilan. Ahora, la ordenación en Anoma funciona en dos etapas: (1) Descubrimiento/Emparejamiento de Contrapartes, y (2) Ejecución de Transacciones con Ordenación Justa. En la etapa 1, nodos especializados llamados solvers monitorean continuamente el pool de intenciones e intentan encontrar conjuntos de intenciones que se complementen entre sí para formar una transacción válida. Por ejemplo, si Alice tiene la intención de cambiar DAI por ETH y Bob tiene la intención de cambiar ETH por DAI, un solver puede emparejarlos. Si múltiples intenciones son compatibles (como un libro de órdenes de ofertas y demandas), los solvers pueden encontrar un emparejamiento o precio de compensación óptimo. Es importante destacar que esto sucede fuera de la cadena en la red de solvers, efectivamente un emparejamiento algorítmico. Una vez que un solver (o grupo de solvers) ha construido una transacción completa (o un conjunto de transacciones) que cumple algunas intenciones, la envía a la cadena para su ejecución. Aquí es donde entra la etapa 2: el consenso de Anoma entonces ordenará estas transacciones enviadas por los solvers en bloques. Sin embargo, el consenso de Anoma está diseñado para ser justo en el orden: utiliza técnicas criptográficas (cifrado de umbral) para asegurar que las transacciones se ordenen sin ser influenciadas por su contenido o el momento preciso de su envío. Específicamente, Anoma planea usar Ferveo, un esquema de cifrado de umbral, a nivel de mempool. La forma en que funciona es: los solvers encriptan las transacciones que quieren proponer usando una clave pública colectiva de los validadores. Los validadores incluyen estas transacciones encriptadas en los bloques sin conocer sus detalles. Solo después de que una transacción se finaliza en un bloque, los validadores la desencriptan colectivamente (cada uno contribuyendo con una parte de la clave de descifrado). Esto asegura que ningún validador pueda hacer front-running selectivamente o reordenar basándose en el contenido de una transacción; se comprometen a una ordenación a ciegas. El algoritmo de consenso ordena efectivamente las transacciones (en realidad, las intenciones) de una manera más cercana a un orden de primera vista o por lotes, ya que todas las transacciones en un "lote" dado (bloque) se encriptan y revelan simultáneamente. En la práctica, Anoma puede implementar subastas por lotes para ciertas aplicaciones: por ejemplo, una intención de comerciar puede recopilarse durante N bloques (manteniéndose encriptada), luego todas se desencriptan juntas después de N bloques y son emparejadas por los solvers en un solo lote. Esto evita que los actores rápidos vean las órdenes de otros y reaccionen dentro de ese lote, una gran ventaja para la equidad (esta técnica está inspirada en las Subastas por Lotes Frecuentes y se ha propuesto para eliminar las ventajas del trading de alta frecuencia). Además, los predicados de validez de Anoma (contratos inteligentes a nivel de aplicación) pueden imponer restricciones de equidad en el resultado de la ordenación. Por ejemplo, una aplicación DEX de Anoma podría tener una regla: "todas las operaciones en un lote obtienen el mismo precio de compensación, y los solvers no pueden insertar transacciones adicionales para explotar a los usuarios". Debido a que estas reglas son parte de la validez del estado, cualquier bloque que contenga un emparejamiento injusto (digamos, un solver intentó colar una operación propia a un mejor precio) sería inválido y rechazado por los validadores. En resumen, la ordenación en Anoma ocurre como emparejar y luego encriptar+ordenar: las intenciones se ponen conceptualmente en cola hasta que un solver forma una transacción, y luego esa transacción es ordenada por un consenso de ordenación justa (evitando el MEV típico). Efectivamente, no hay una carrera en el mempool, ya que las intenciones de los usuarios no compiten directamente por el precio del gas o la prioridad temporal. En cambio, la competencia es para que los solvers encuentren coincidencias, y luego esas coincidencias se ejecutan de una manera que nadie puede cambiar el orden o interceptarlas mientras están en tránsito. Esta arquitectura promete neutralizar muchos vectores de MEV: no existe el concepto de hacer front-running a una intención porque las intenciones no son accionables hasta que el solver las ensambla, y para entonces ya están encriptadas en el bloque. Es un modelo de encolado fundamentalmente diferente destinado a eliminar las explotaciones de prioridad basadas en el tiempo.

• Mecanismos de Supresión/Extracción de MEV: Anoma está diseñado para minimizar el "mal MEV" por construcción. Al resolver las operaciones a través de la resolución por lotes y el cifrado de umbral, los ataques de MEV típicos como el sándwich son imposibles: nadie ve una intención y puede insertar la suya antes, porque las intenciones no son transacciones que viven en un mempool transparente. Los solvers solo emiten transacciones emparejadas finales después de que la oportunidad de inserción ha pasado (debido a la encriptación y el procesamiento por lotes). En un DEX basado en Anoma, los usuarios no serían objeto de front-running o back-running en el sentido tradicional, porque todas las operaciones en un lote se ejecutan juntas a un precio uniforme (evitando que un atacante explote el cambio de precio entre ellas). Esto esencialmente suprime el MEV depredador como el arbitraje DEX o el sándwich; el valor que habría sido tomado por un bot es retenido por los usuarios (obtienen un precio justo). El enfoque de Anoma sobre el arbitraje también es notable: en muchos casos, si múltiples intenciones crean una oportunidad de arbitraje, el solver que las empareja incorporará ese beneficio en el emparejamiento (por ejemplo, emparejar diferentes precios y obtener un beneficio neto). Pero como múltiples solvers pueden competir para proporcionar el mejor emparejamiento, la competencia puede forzar a los solvers a devolver la mayor parte de esa ventaja a los usuarios en forma de mejores términos de llenado. Por ejemplo, si un usuario quiere vender al precio A y otro quiere comprar al precio B (B > A implica una brecha), un solver podría cumplir ambos a un precio intermedio y capturar la diferencia como beneficio, pero si otro solver ofrece a los usuarios un precio aún más cercano entre sí (dejando menos beneficio), ganará la intención. Así, los solvers compiten para reducir los márgenes de MEV en beneficio de los usuarios, de manera similar a cómo los searchers en Flashbots compiten a través de las comisiones. La diferencia es que esto sucede algorítmicamente a través del emparejamiento de intenciones en lugar de la puja por el gas. Todavía puede haber "MEV extraído" en Anoma, pero es probable que se limite a que los solvers ganen comisiones modestas por su servicio. Notablemente, Anoma espera que la mayor parte del flujo de órdenes sea internalizado por el protocolo o la lógica de la aplicación. En algunos casos, esto significa que lo que sería una oportunidad de MEV se convierte simplemente en una comisión normal del protocolo. Por ejemplo, la primera instancia fractal de Anoma (Namada) implementa un AMM de curva de enlace en la cadena; el arbitraje en ese AMM es capturado por el mecanismo del AMM (como un reequilibrador incorporado) en lugar de por arbitrajistas externos. Otro ejemplo: una intención de préstamo que ofrece un alto interés podría ser emparejada con una intención de préstamo; no se necesita un liquidador de terceros si el colateral cae, porque las propias intenciones podrían manejar el reequilibrio o el protocolo podría autoliquidar a un precio justo. Al eliminar a los extractores de terceros, Anoma reduce la prevalencia de la extracción de MEV fuera de la cadena. Además, Anoma enfatiza la privacidad (a través del subsistema Taiga de circuitos ZK). Los usuarios pueden optar por mantener sus intenciones parcial o totalmente protegidas (por ejemplo, ocultando cantidades o tipos de activos). Esto suprime aún más el MEV: si los detalles de una orden grande están ocultos, nadie puede apuntar a ella para la extracción de valor. Solo después del emparejamiento y la ejecución podrían surgir los detalles, momento en el cual es demasiado tarde para explotar. En resumen, el mecanismo de Anoma se trata en gran medida de prevenir el MEV en lugar de extraerlo: al agrupar transacciones, encriptar el mempool y incorporar la alineación económica en el emparejamiento, intenta asegurar que haya pocas oportunidades para el arbitraje malicioso o el front-running. El MEV necesario (como el arbitraje para igualar precios entre mercados) es manejado por solvers o la lógica del protocolo de una manera con confianza minimizada. Se podría decir que Anoma apunta a la "minimización del MEV", esforzándose por obtener resultados como si cada usuario tuviera acceso a la contraparte perfecta al instante y sin fugas. Cualquier valor extraído para facilitar eso (la recompensa del solver) es similar a una pequeña comisión de servicio, no una ganancia inesperada por explotar la asimetría.

• Estructura de Incentivos Económicos: En Anoma, los solvers asumen el papel análogo tanto a los intermediarios como a los constructores de bloques. Incurren en costos (computación, quizás depositar colateral) para encontrar coincidencias de intenciones, y son recompensados cuando proponen con éxito transacciones que se incluyen. Los solvers pueden ganar de varias maneras: podrían cobrar una comisión o un diferencial dentro de la transacción que construyen (por ejemplo, dando a los usuarios términos ligeramente menos favorables y quedándose con la diferencia, similar a cómo un agregador de DEX podría tomar una pequeña parte). O bien, ciertas intenciones podrían incluir explícitamente una recompensa para el solver (como "estoy dispuesto a pagar hasta 0.01 ETH para que esto se haga"). El modelo de compensación exacto es flexible, pero la clave es que los solvers compiten. Si un solver intenta tomar una comisión demasiado alta, otro puede proponer una solución con un mejor resultado para el usuario y ganar la inclusión. Esta dinámica competitiva tiene como objetivo mantener los beneficios de los solvers bajo control y alineados con la provisión de valor. Validadores (Productores de Bloques): Los validadores de Anoma ejecutan el consenso que ordena y ejecuta las transacciones. Son incentivados por recompensas de bloque y comisiones, como en cualquier blockchain. Notablemente, si las intenciones se emparejan entre múltiples usuarios, la transacción resultante podría tener múltiples fuentes de comisiones (cada usuario podría contribuir con una comisión o una porción de los activos). Es posible que el modelo de comisiones de Anoma permita la división de comisiones, pero típicicamente los validadores obtendrán las comisiones de gas estándar por procesar transacciones. En fases futuras, Anoma planea un "consenso bajo demanda" y un token nativo. La idea es que muchas instancias de Anoma (o shards) podrían existir, y algunas podrían activarse temporalmente para tareas específicas ("consenso ad-hoc" para necesidades particulares de la aplicación). El token probablemente se usaría para hacer staking y asegurar estas instancias. Los incentivos aquí aseguran que la red tenga suficientes validadores para procesar todas las transacciones emparejadas de manera confiable y que se comporten honestamente en el proceso de descifrado de umbral (quizás con condiciones de slashing si intentan descifrar antes de tiempo o censurar). Usuarios: Los usuarios en Anoma potencialmente ahorran dinero y obtienen mejores resultados en lugar de pagar MEV implícitamente. Por ejemplo, podrían obtener consistentemente mejores precios de operación que en una cadena tradicional, lo que significa que el valor se queda con ellos. En algunos casos, los usuarios también podrían pagar comisiones explícitas para incentivar a los solvers, especialmente para intenciones complejas o cuando desean un emparejamiento más rápido. Pero como los usuarios pueden expresar intenciones sin especificar cómo hacerlo, delegan el trabajo pesado a los solvers y solo pagan si vale la pena. También existe la noción de que "los propietarios de intenciones pueden definir sus propios compromisos de seguridad/rendimiento": por ejemplo, un usuario podría decir "esperaré más tiempo por un mejor precio" o "pagaré más por una ejecución inmediata". Esta flexibilidad permite a los propios usuarios decidir cuánto ofrecer a los solvers o validadores, alineando los incentivos económicos con sus necesidades. Redistribución de MEV: Si ocurre algún MEV (como ARB entre cadenas), la arquitectura de Anoma podría permitir capturarlo en el sistema. Por ejemplo, múltiples shards o instancias de Anoma podrían coordinarse para liquidar un arbitraje atómico multicadena, y el beneficio podría ser compartido o quemado (dependiendo del diseño) en lugar de dejar que un arbitrajista externo se lo quede todo. En general, como Anoma da a las aplicaciones control sobre el flujo de transacciones, es posible implementar estrategias de MEV propiedad del protocolo (similar a la filosofía de Skip) a nivel de aplicación. Por ejemplo, una aplicación DeFi en Anoma podría enrutar automáticamente todas las operaciones de los usuarios a través de un solver dentro del protocolo que garantice la mejor ejecución y comparta cualquier beneficio adicional con los usuarios o los proveedores de liquidez. El efecto neto es que los extractores de MEV de terceros son desintermediados. Económicamente, esto es de suma positiva para los participantes honestos (usuarios, LPs, etc.), pero podría reducir las oportunidades para los searchers clásicos. Sin embargo, surgirán nuevos roles como solvers especializados (quizás uno se centre en el emparejamiento de NFT, otro en swaps de divisas, etc.). Estos solvers son análogos a los searchers de MEV de hoy, pero operan dentro de las reglas del sistema y probablemente tengan márgenes de beneficio menos descabellados debido a la competencia y las restricciones del protocolo. Por último, la visión de la Fundación Anoma sugiere que Anoma será una infraestructura de bien público. Habrá un token nativo, presumiblemente ANOMA, que podría capturar valor a través de comisiones o ser requerido para el staking. Se pueden prever incentivos de token (recompensas inflacionarias, etc.) para validadores y quizás incluso para solvers para impulsar la actividad. En el momento de escribir esto, los detalles sobre la economía del token no son finales, pero la hoja de ruta confirma que un token Anoma y un consenso nativo bajo demanda están planeados en fases futuras. Para resumir, el modelo de incentivos de Anoma fomenta el comportamiento cooperativo: los solvers ganan ayudando a los usuarios a obtener lo que quieren, no explotándolos; los validadores ganan asegurando la red y ordenando de manera justa; y los usuarios "pagan" principalmente cediendo algo de MEV a los solvers o comisiones, pero idealmente mucho menos que el MEV implícito que perderían en otros sistemas.

• Cumplimiento y Neutralidad: Anoma, al ser un marco, no una red única, puede ser instanciado de varias maneras; algunas podrían ser permisionadas, pero la L1 de Anoma y otras instancias similares están destinadas a ser sin permisos y con privacidad mejorada. Al incorporar fuertes características de privacidad (como intenciones protegidas usando pruebas de conocimiento cero en Taiga), Anoma se alinea con la visión de que la privacidad financiera es un derecho. Esto podría ponerlo en conflicto con ciertos regímenes regulatorios que exigen una visibilidad abierta de las transacciones. Sin embargo, el diseño de Anoma también podría evitar ciertos escollos regulatorios. Por ejemplo, si se eliminan el front-running y la selección injusta de órdenes, se mitigan las preocupaciones sobre la manipulación del mercado; un regulador podría apreciar que los usuarios no están siendo explotados sistemáticamente por insiders. Además, el concepto de "modelos de seguridad definidos por el usuario" implica que los usuarios o las comunidades podrían optar por diferentes supuestos de confianza. Potencialmente, una aplicación regulada podría construirse sobre Anoma donde, por ejemplo, el solver o un subconjunto de validadores sean entidades con KYC que garanticen el cumplimiento para ese dominio de intención particular. Anoma como capa base no impondría KYC a todos, pero se podrían implementar predicados de validez que requieran (por ejemplo) una prueba de elegibilidad para ciertas transacciones (como una prueba de no ser una dirección sancionada, o una verificación de credenciales) si una aplicación lo necesitara. La arquitectura es lo suficientemente flexible como para soportar el cumplimiento a nivel de aplicación sin comprometer la neutralidad de la capa base. En cuanto a la censura: el cifrado de umbral de Anoma significa que incluso si los validadores quisieran censurar, no pueden apuntar a intenciones específicas porque no las ven en texto plano. Lo único que podrían hacer es negarse a incluir transacciones encriptadas de ciertos solvers o usuarios, pero eso sería obvio (y en contra de las reglas del protocolo si se hace arbitrariamente). La expectativa es que las reglas de consenso desalienten la censura; por ejemplo, quizás si un bloque no incluye todas las intenciones desencriptadas disponibles del último lote, podría considerarse inválido o menos preferible. En cualquier caso, la descentralización de los validadores y la naturaleza encriptada de las cargas útiles aseguran un alto grado de resistencia a la censura. Sobre la neutralidad: Anoma aspira a ser una plataforma general no controlada por ninguna entidad única. La investigación y el desarrollo están liderados por Heliax (el equipo detrás de Anoma y Namada), pero una vez en vivo, una red Anoma sería gestionada por la comunidad. Es probable que haya una gobernanza en cadena para las actualizaciones, etc., lo que podría plantear cuestiones de cumplimiento (por ejemplo, ¿podría un gobierno subvertir la gobernanza para cambiar las reglas?), pero ese es un problema general de las blockchains. Una característica interesante relacionada con el cumplimiento es que Anoma admite múltiples instancias paralelas, lo que significa que se podría tener un pool de intenciones o shard aislado para ciertos tipos de activos o jurisdicciones. Esto no es explícitamente para la regulación, pero podría permitir, por ejemplo, un pool de intenciones de CBDC donde solo los bancos autorizados ejecuten solvers, coexistiendo con un pool DeFi libre. La modularidad de la arquitectura proporciona flexibilidad para segregar si es necesario, al tiempo que permite la interoperabilidad a través de puentes de intenciones. Finalmente, en términos de compatibilidad legal, todo el concepto de intenciones de Anoma podría evitar algunas clasificaciones que acosan a las criptomonedas tradicionales: dado que una intención no es una transacción vinculante hasta que se empareja, se podría argumentar que los usuarios mantienen más control (es como publicar una orden en un exchange, que tiene un precedente legal más claro, en lugar de ejecutar directamente una operación). Esto podría ayudar con cosas como el tratamiento fiscal (el sistema podría potencialmente dar un recibo unificado de una operación de varios pasos en lugar de muchas transacciones), aunque esto es especulativo. En general, Anoma prioriza la descentralización, la privacidad y la autonomía del usuario, lo que históricamente puede chocar con las expectativas regulatorias, pero las ganancias en equidad y transparencia podrían ganar favor. Esencialmente, trae la sofisticación de los motores de emparejamiento financiero tradicionales a la cadena, pero sin operadores centralizados. Si los reguladores llegan a entender ese modelo, podrían verlo como una estructura de mercado más ordenada y justa que el caos de los mempools.

• Arquitectura Técnica (Consenso y Criptografía): La arquitectura de Anoma es compleja y comprende varios componentes: Typhon (red, mempool, consenso, ejecución) y Taiga (la capa de privacidad de conocimiento cero). El núcleo de Typhon es la capa de gossip de intenciones y un enfoque novedoso para el consenso + emparejamiento combinados. El protocolo de consenso de Anoma extiende el consenso BFT típico con el concepto de "Predicados de Validez" y "Prueba de Emparejamiento de Órdenes". Esencialmente, cada aplicación en Anoma puede definir un predicado de validez que debe satisfacerse para las transacciones (piense en ello como condiciones de contrato inteligente que se aplican a nivel de bloque, no solo a nivel de transacción). Esto permite imponer propiedades como los precios de compensación de subastas por lotes, etc., como se describió. El algoritmo de consenso en sí mismo probablemente se basa en BFT al estilo de Tendermint o HotStuff (ya que Anoma está en el ámbito de Cosmos y admite IBC). De hecho, la testnet inicial de Anoma (Feigenbaum en 2021) y Namada usan un consenso al estilo de Tendermint con modificaciones. Una modificación importante es la integración del cifrado de umbral (Ferveo) en el pipeline del mempool. Típicamente, Tendermint selecciona un proponente que ordena las transacciones. En Anoma, el proponente ordenaría intenciones/transacciones encriptadas. Ferveo probablemente funciona haciendo que los validadores acuerden periódicamente una clave pública de umbral, y cada intención enviada por los solvers se encripta con esa clave. Durante la propuesta de bloque, se incluyen todas las transacciones encriptadas; después de la propuesta, los validadores ejecutan un protocolo para desencriptarlas (quizás el siguiente bloque contiene las salidas desencriptadas o algún esquema similar). Esto añade una fase al consenso pero asegura la equidad en el orden. Criptográficamente, esto utiliza la generación de claves distribuidas y el descifrado de umbral (por lo que se basa en supuestos como que al menos 2/3 de los validadores son honestos para no filtrar o descifrar datos antes de tiempo). En el lado de la privacidad, Taiga proporciona pruebas zkSNARK o zk-STARK que permiten que las intenciones permanezcan parcial o totalmente protegidas. Por ejemplo, un usuario podría enviar una intención de intercambio sin revelar el tipo de activo o la cantidad; proporciona una prueba ZK de que tiene saldo suficiente y que la transacción será válida si se empareja, sin revelar detalles específicos. Esto es análogo a cómo funcionan las transacciones protegidas en Zcash, pero extendido a las intenciones. Se menciona el uso de pruebas recursivas, lo que significa que múltiples pasos de una transacción (o múltiples intenciones) pueden probarse en una sola prueba sucinta para mayor eficiencia. La interacción de Taiga y Typhon significa que algunos solvers y validadores podrían estar operando con texto cifrado o compromisos en lugar de valores en texto plano. Por ejemplo, un solver podría emparejar intenciones que se expresan de manera confidencial, resolviendo una ecuación de compromisos. Esto es criptografía de vanguardia y va más allá de lo que hacen la mayoría de las blockchains actuales. Otra pieza clave es la integración de IBC: las instancias de Anoma pueden comunicarse con otras cadenas (especialmente las cadenas de Cosmos) a través del protocolo de Comunicación Inter-Blockchain. Esto significa que una intención en Anoma podría potencialmente desencadenar una acción en otra cadena (a través de un mensaje IBC) o consumir datos del estado de otra cadena. La Fase 1 de la Mainnet en la hoja de ruta de Anoma menciona específicamente un "adaptador" en Ethereum y rollups para permitir que las intenciones de Anoma aprovechen la liquidez de EVM. Probablemente, un solver de Anoma podría componer una transacción que, por ejemplo, use Uniswap en Ethereum, creando una intención que, al ser emparejada, envíe un mensaje a Ethereum para ejecutar un intercambio (quizás a través de un relayer o algo como un puente IBC). El consenso debe garantizar la atomicidad: presumiblemente, la salida de Anoma podría ser como una única transacción que abarca múltiples cadenas (algo como iniciar una transacción en la cadena A y esperar un resultado en la cadena B). Lograr una liquidación atómica entre cadenas es difícil; posiblemente Anoma comenzará liquidando en una cadena a la vez (la Fase 1 se centra en el ecosistema de Ethereum, lo que probablemente significa que las intenciones de Anoma se liquidarán en la L1 o L2 de Ethereum de una sola vez). Más tarde, las "cadenas Quimera" y el consenso bajo demanda podrían permitir que sidechains personalizadas se activen para manejar emparejamientos particulares entre cadenas. En cuanto al rendimiento, el enfoque de Anoma podría ser más intensivo computacionalmente (solvers resolviendo problemas de emparejamiento NP-difíciles, validadores haciendo criptografía pesada). Pero la compensación es una experiencia de usuario enormemente mejorada (sin transacciones fallidas, mejores precios, etc.). El desarrollo de Anoma requiere construir estos componentes novedosos casi desde cero: Heliax ha estado creando Juvix, un nuevo lenguaje para escribir predicados de validez e intenciones, y mucha investigación (algunas referencias del sitio de Anoma hablan de estos conceptos en detalle). Hitos principales: La primera testnet pública de Anoma, Feigenbaum, se lanzó en noviembre de 2021 como una demostración del gossip básico de intenciones. Posteriormente, Heliax cambió su enfoque al lanzamiento de Namada (una L1 centrada en la privacidad que puede verse como una instancia de Anoma centrada en las transferencias de activos); Namada se lanzó en 2023 e incluye características como transferencias protegidas y cifrado de umbral Ferveo para su mempool. Esto muestra la tecnología en acción en un caso de uso más limitado. Mientras tanto, las testnets de la visión completa de Anoma se han estado implementando por etapas ("testnet de verano de 2023" mencionada en la comunidad también). La hoja de ruta indica que la mainnet de la Fase 1 integrará Ethereum, la Fase 2 añadirá más cadenas y criptografía avanzada, y eventualmente llegarán el consenso nativo y el token. La separación de "consenso y token en una fase futura" sugiere que la mainnet inicial de Anoma podría depender de Ethereum (por ejemplo, aprovechando la seguridad de Ethereum o los tokens existentes en lugar de tener uno propio desde el primer día). Posiblemente lancen una L2 o una sidechain que publique en Ethereum. Y más tarde activen su propia red PoS con un token. Este enfoque por fases es interesante: podría ser para reducir la barrera de adopción (usar el capital existente en Ethereum en lugar de lanzar una nueva moneda inicialmente). En conclusión, la arquitectura de Anoma es novedosa y completa: combina la equidad criptográfica (cifrado de umbral, pruebas ZK) con un nuevo paradigma de transacciones (emparejamiento basado en intenciones) y capacidades entre cadenas. Es posiblemente el intento más agresivo de erradicar el MEV tradicional a nivel de protocolo, haciendo lo que ninguna cadena heredada hace: motores de emparejamiento justo incorporados. La complejidad es alta, pero si tiene éxito, una cadena Anoma podría proporcionar a los usuarios garantías de ejecución casi similares a las de un CEX en un entorno descentralizado, lo cual es un santo grial en la UX y la equidad de la blockchain.

Skip Protocol (Control Soberano de MEV y Conjunto de Herramientas de Ordenación Justa en Cosmos)​

Skip Protocol es una solución líder de MEV en el ecosistema de Cosmos, enfocada en dar a cada blockchain ("app-chain") las herramientas para gestionar la ordenación de transacciones y la captura de MEV en sus propios términos. A diferencia de Flashbots o Anoma, que proponen sistemas que abarcan toda la red, Skip se alinea con la filosofía de soberanía de Cosmos: cada cadena puede integrar los módulos de Skip para aplicar reglas de ordenación justa personalizadas, ejecutar subastas de espacio de bloque dentro del protocolo y capturar MEV para los stakeholders o usuarios de la cadena. Skip puede considerarse como un conjunto de módulos del SDK de Cosmos e infraestructura que juntos permiten la Construcción de Bloques Propiedad del Protocolo (POB) y una secuenciación de transacciones flexible. Ha sido adoptado en cadenas como Osmosis, Juno, Terra y otras en Cosmos, y también está colaborando con proyectos como la próxima cadena de dYdX para la mitigación de MEV. Los elementos clave incluyen un mecanismo de subasta en cadena para transacciones prioritarias, lógica de ordenación de transacciones a nivel de consenso y mecanismos dentro de la aplicación para reciclar el MEV ("buen MEV") en beneficio del protocolo.

• Algoritmos de Encolado y Ordenación de Transacciones: En una cadena típica de Cosmos (usando consenso Tendermint/BFT), el mempool ordena las transacciones aproximadamente por comisión y hora de llegada, y el proponente del bloque puede elegir cualquier ordenación al crear un bloque (sin restricciones algorítmicas más allá de incluir transacciones válidas). Skip cambia esto introduciendo reglas de ordenación impuestas por consenso y mempools de múltiples carriles. Usando la nueva interfaz ABCI++ de Cosmos (que permite personalizar la propuesta y el procesamiento de bloques), el módulo Protocol-Owned Builder (POB) de Skip puede particionar el bloque en carriles distintos con diferentes políticas de ordenación. Por ejemplo, un carril podría ser un carril de subasta de la parte superior del bloque donde las transacciones con la oferta más alta (quizás de bots de arbitraje o operaciones urgentes) se colocan primero en el bloque en un orden fijo, otro carril podría ser un carril gratuito para transacciones de usuarios ordinarios sin comisiones, y un carril predeterminado para transacciones normales con comisiones. El componente BlockBuster del módulo de Skip permite a los desarrolladores definir estos carriles y su lógica de ordenación de manera modular. Crucialmente, estas reglas son impuestas por todos los validadores: cuando un proponente construye un bloque, los otros validadores verificarán que las transacciones del bloque se adhieran a las reglas de ordenación acordadas (a través de las comprobaciones de ProcessProposal ABCI). Si no es así, pueden rechazar el bloque. Esto significa que incluso un proponente malicioso o que busca beneficios no puede desviarse (por ejemplo, no puede colar su propia transacción de front-running antes de un postor ganador de la subasta, porque eso violaría la regla de ordenación). Algunos ejemplos de reglas de ordenación que Skip permite: (a) Ordenar transacciones por precio de gas descendente (comisión), asegurando que la transacción con la comisión más alta siempre tenga prioridad. Esto formaliza un esquema justo de "pago por prioridad" en lugar de uno aleatorio o basado en el tiempo. (b) Debe incluir al menos una transacción de actualización de precios de oráculo antes de cualquier operación, asegurando que las fuentes de datos se actualicen, lo que evita escenarios en los que un proponente podría ignorar las actualizaciones de oráculos para explotar precios obsoletos. (c) Limitar el número de transacciones especiales en la parte superior del bloque, por ejemplo, solo un bundle ganador de la subasta puede ocupar la parte superior, para evitar el spam de muchas pequeñas capturas de MEV. (d) Ninguna transacción que viole una propiedad del estado: Skip permite reglas de ordenación con estado, como "después de construir el bloque, asegurar que ninguna operación DEX se ejecutó a un precio peor que si estuviera al final del bloque" (una forma de asegurar que no ocurrió un ataque sándwich). Una regla concreta descrita es una "condición de cero front-running en todos los DEXs", lo que podría significar que si alguna transacción se hubiera visto afectada por otras posteriores de una manera que indique front-running, el bloque es inválido. Esto es poderoso: es esencialmente hacer que la equidad sea parte de la validez del bloque. Las cadenas de Cosmos pueden implementar tales reglas porque controlan su pila completa. El marco de Skip proporciona una forma estructurada de hacerlo a través del AuctionDecorator en el SDK, que puede verificar cada transacción contra las reglas configuradas. Además, Skip proporciona mejoras en el mempool: el mempool del nodo puede simular bloques con antelación, filtrar transacciones fallidas, etc., para ayudar a los proponentes a seguir las reglas de manera eficiente. Por ejemplo, si el carril de subasta de un bloque debe tener las ofertas más altas, el mempool puede ordenarse por ofertas para ese carril. Si un bloque debe incluir solo transacciones que resulten en una cierta condición de estado, el nodo del proponente puede simular las transacciones a medida que las elige para asegurar que la condición se cumpla. En resumen, Skip permite una ordenación determinista y definida por la cadena en lugar de dejarla completamente al capricho del proponente o a la simple prioridad del precio del gas. Las cadenas adoptan el módulo de constructor de Skip para efectivamente codificar su política de ordenación de transacciones en el protocolo. Esto fomenta la equidad porque todos los validadores imponen las mismas reglas, eliminando la oportunidad de que un solo proponente realice una reordenación arbitraria para MEV a menos que esté dentro del mecanismo permitido (como la subasta, donde es transparente y competitivo). El encolado de transacciones en el modelo de Skip podría implicar colas separadas por carril. Por ejemplo, un carril de subasta podría encolar transacciones de oferta especiales (Skip usa un tipo especial MsgAuctionBid para pujar por la inclusión en la parte superior del bloque). Esas ofertas se recopilan en cada bloque y se selecciona la más alta. Mientras tanto, las transacciones normales se encolan en el mempool predeterminado. Esencialmente, Skip introduce una cola estructurada: una para ofertas prioritarias, otra para gratuitas u otras, etc., cada una con sus propios criterios de ordenación. Este enfoque modular significa que cada cadena puede personalizar cómo equilibra la equidad y los ingresos; por ejemplo, Osmosis podría decir "no queremos ninguna subasta de MEV, pero imponemos la equidad en el orden a través del cifrado de umbral" (implementaron el cifrado de umbral con la ayuda de Skip y otros), mientras que otra cadena podría decir "permitimos subastas para MEV pero requerimos que parte de las ganancias se quemen". Skip admite ambos. Esta configurabilidad de la ordenación es el sello distintivo de Skip.

• Mecanismos de Mitigación y Extracción de MEV: El enfoque de Skip hacia el MEV a menudo se describe como "MEV propiedad del protocolo" y "multiplicidad". El MEV propiedad del protocolo significa que el propio protocolo de la blockchain, a través de su código y gobernanza, captura o redistribuye el MEV en lugar de dejarlo en manos de validadores individuales o externos. La multiplicidad se refiere a asegurar que se incluyan las transacciones "correctas" (múltiples), esencialmente no excluyendo transacciones legítimas de usuarios en favor de solo transacciones de MEV, y quizás incluyendo múltiples oportunidades de MEV en un bloque si es posible (para que ningún searcher monopolice). Concretamente, Skip proporciona herramientas para capturar MEV de maneras que benefician a la red: una es Skip Select, un sistema de subasta de espacio de bloque para la inclusión en la parte superior del bloque. En Skip Select, los searchers (como los bots de arbitraje) envían bundles con propinas a los validadores, de forma similar a los bundles de Flashbots, excepto que se hace de forma nativa en la cadena a través de los módulos de Skip. El bundle (o bundles) que más paga se inserta automáticamente en la parte superior del bloque en el orden especificado. Esto garantiza que esas transacciones se ejecuten como se pretende, y el validador (o la cadena) cobra la propina. Este mecanismo toma lo que era un proceso OTC fuera de la cadena (en Ethereum) y lo convierte en una subasta abierta y en la cadena, mejorando la transparencia y el acceso. Otro mecanismo es ProtoRev (Módulo de Ingresos Prototipo), que Skip desarrolló para Osmosis. ProtoRev es un módulo de arbitraje en la cadena que detecta y ejecuta automáticamente arbitrajes cíclicos (como los que involucran múltiples pools) dentro de la ejecución del bloque y acumula el beneficio en la tesorería de la cadena o en el pool comunitario. Esencialmente, Osmosis decidió que cierto "buen MEV" (como el arbitraje que mantiene los precios alineados) debería seguir ocurriendo (por eficiencia del mercado) pero el propio protocolo realiza el arbitraje y captura el beneficio, para luego distribuirlo (por ejemplo, a los stakers o como incentivos de minería de liquidez). Esto elimina la necesidad de bots de arbitraje externos en esas oportunidades y asegura que el valor permanezca en el ecosistema. ProtoRev fue el primero de su tipo en una cadena importante y demuestra cómo la integración profunda puede mitigar las externalidades del MEV: los usuarios que operan en Osmosis enfrentan menos slippage porque si existe un arbitraje después de su operación, el protocolo lo cerrará y esencialmente reembolsará el valor a Osmosis (lo que podría beneficiar indirectamente a los usuarios a través de comisiones más bajas o recompras de tokens, etc.). Además, Skip capacita a las cadenas para implementar medidas anti-MEV como el cifrado de umbral para el mempool. Por ejemplo, Osmosis, en colaboración con Skip y otros, está implementando la encriptación del mempool donde las transacciones se envían encriptadas y solo se revelan después de un tiempo fijo (similar a la idea de Anoma, pero a nivel de cadena). Aunque no es un producto de Skip per se, la arquitectura de Skip es compatible: la subasta de Skip puede ejecutarse en transacciones encriptadas basando la subasta en las ofertas declaradas en lugar de leer el contenido de la transacción. En términos de suprimir el MEV perjudicial: las reglas de consenso de Skip como "no se permite el front-running" (impuestas por verificaciones de estado) son una medida directa para detener el comportamiento malicioso. Si un validador intenta incluir un ataque sándwich, otros validadores detectarían que el resultado del estado viola la regla de no front-running (por ejemplo, podrían verificar que ninguna operación fue inmediatamente precedida y seguida por otra de la misma dirección de una manera que se aprovechó). Ese bloque sería rechazado. Sabiendo esto, los validadores ni siquiera intentarán incluir tales patrones, por lo que los usuarios están protegidos por la ley del protocolo. Skip también fomenta la quema o redistribución de los ingresos de MEV para evitar incentivos perversos. Por ejemplo, una cadena podría optar por quemar todas las ganancias de la subasta o ponerlas en un fondo comunitario en lugar de dárselas todas al proponente del bloque. Esto reduce el incentivo para que los validadores reordenen las transacciones ellos mismos, ya que podrían no beneficiarse personalmente de ello (dependiendo de la elección de la cadena). En resumen, el conjunto de herramientas de Skip permite a cada cadena extraer quirúrgicamente el MEV donde es beneficioso (por ejemplo, arbitraje para mantener la eficiencia del mercado, liquidaciones para mantener saludables los mercados de préstamos) y asegurar que ese valor sea capturado por el protocolo o los usuarios, mientras prohíbe y previene estrictamente el MEV malicioso (como el front-running perjudicial para el usuario). Es una mezcla pragmática de extracción y supresión, adaptada por la gobernanza: en lugar de una solución única para todos, Skip capacita a las comunidades para decidir qué MEV es "bueno" (y automatizar su captura) y cuál es "malo" (y prohibirlo a través de reglas de consenso). El resultado es un entorno de trading más justo en las cadenas habilitadas por Skip y una fuente de ingresos adicional que puede financiar bienes públicos o reducir costos (una de las publicaciones del blog de Skip señala que la captura justa de MEV puede usarse para "distribuir ingresos de manera justa entre todos los participantes de la red").

• Estructura de Incentivos Económicos: La introducción de Skip cambia fundamentalmente los incentivos, especialmente para los validadores y las comunidades de la cadena en Cosmos. Tradicionalmente, un validador en Cosmos podría extraer MEV reordenando privadamente las transacciones en su bloque (ya que Cosmos carece de una subasta de MEV por defecto). Con Skip, los validadores acuerdan un protocolo donde el MEV se captura a través de subastas o módulos y a menudo se comparte. Los validadores todavía se benefician: pueden recibir una parte de las ganancias de la subasta o comisiones adicionales de los mecanismos de Skip, pero es importante destacar que todos los validadores (no solo el proponente) pueden beneficiarse si se diseña de esa manera. Por ejemplo, algunas subastas de Skip pueden configurarse para que los ingresos se dividan entre todos los stakers o según las decisiones de la gobernanza, en lugar de que el proponente se lo lleve todo. Esto alinea a los validadores colectivamente para ejecutar el software de Skip porque incluso los no proponentes obtienen seguridad (sabiendo que si alguien intenta un bloque inválido, no valdrá la pena) y posiblemente ingresos. Algunas cadenas aún podrían dar al proponente la mayor parte de la comisión de la subasta de MEV (para maximizar el incentivo inmediato de incluirla), pero incluso entonces es transparente y competitivo, lo que podría decirse que reduce la posibilidad de acuerdos bajo la mesa. Cadena/Comunidad: El concepto de MEV propiedad del protocolo significa que la blockchain y sus stakeholders capturan el MEV. Por ejemplo, Osmosis dirige las ganancias de ProtoRev a su pool comunitario, convirtiendo efectivamente el MEV en un ingreso adicional del protocolo que podría financiar el desarrollo o distribuirse a los stakers de OSMO. Esto convierte a la comunidad en general en "propietaria" de ese MEV, alineando el interés de todos en extraer MEV de manera saludable. Si los usuarios saben que el MEV se destina a mejorar la cadena o la tokenómica, podrían aceptarlo más que si va a un bot aleatorio. Searchers: En el modelo de Skip, los searchers/bots independientes pueden tener menos que hacer en la cadena porque algunas oportunidades son tomadas por la lógica del protocolo (como ProtoRev) y otras se canalizan a través de subastas. Sin embargo, Skip no elimina a los searchers, sino que los canaliza para que pujen a través de las rutas adecuadas. Un searcher todavía puede intentar una estrategia compleja, pero para garantizar la inclusión en un lugar particular, debe participar en la subasta de Skip (Skip Select) enviando su bundle con una oferta. Si no lo hacen, corren el riesgo de que un validador los ignore en favor de alguien que sí pujó o que el propio mecanismo de la cadena aproveche la oportunidad. Así que los searchers en Cosmos están evolucionando para trabajar con Skip: por ejemplo, muchos arbitrajistas en Osmosis ahora envían sus arbitrajes a través del sistema de Skip. Pagan una parte a la cadena, quedándose con menos beneficio, pero es el precio a pagar. Con el tiempo, algunos roles de "searcher" podrían ser completamente absorbidos (como el arbitraje de back-running: ProtoRev lo maneja, por lo que ningún searcher externo puede competir). Esto podría reducir el spam y el esfuerzo desperdiciado en la red (no más múltiples bots compitiendo; solo una ejecución del protocolo). Usuarios: Los usuarios finales salen ganando porque tienen un entorno más justo (sin ataques de MEV sorpresa). Además, algunas configuraciones de Skip recompensan explícitamente a los usuarios: la redistribución de MEV a los usuarios es posible. Por ejemplo, una cadena podría decidir reembolsar parte de los ingresos de la subasta de MEV a los usuarios cuyas operaciones crearon ese MEV (similar a la idea de reembolso de Flashbots). Astroport, un DEX en Terra, integró Skip para compartir los ingresos de MEV con los swappers, lo que significa que si la operación de un usuario tenía MEV, parte de ese valor se le devuelve por defecto. Esto se alinea con la ética de que el MEV debe ir a los usuarios. Aunque no todas las cadenas hacen esto, la opción existe a través de la infraestructura de Skip para implementar tales esquemas. El propio Skip Protocol (la empresa/equipo) tiene un modelo de negocio en el que proporcionan estas herramientas a menudo de forma gratuita a los validadores (para fomentar la adopción), y monetizan asociándose con cadenas (B2B). Por ejemplo, Skip podría tomar una pequeña comisión del MEV capturado o cobrar a las cadenas por características avanzadas/soporte. Se menciona que Skip es gratuito para los validadores pero utiliza un modelo B2B con las cadenas. Esto significa que Skip tiene un incentivo para maximizar el MEV capturado por la cadena y la comunidad (para que la cadena esté contenta y quizás comparta una parte según el acuerdo). Pero como la gobernanza está involucrada, cualquier comisión que Skip tome suele ser acordada por la comunidad. El efecto económico es interesante: profesionaliza la extracción de MEV como un servicio proporcionado a las cadenas. Al hacerlo, desincentiva el comportamiento deshonesto: los validadores no necesitan hacer tratos turbios individualmente, pueden simplemente usar Skip y obtener un flujo fiable de ingresos adicionales que es socialmente aceptado. El comportamiento honesto (seguir las reglas del protocolo) rinde casi tanto o más beneficio que intentar hacer trampa, porque si haces trampa, tu bloque podría ser inválido o podrías ser sancionado socialmente, etc. La gobernanza juega un papel significativo: adoptar el módulo de Skip o establecer los parámetros (como el porcentaje de la subasta, la distribución de las ganancias) se hace a través de propuestas en la cadena. Esto significa que los resultados económicos (quién obtiene el MEV) son determinados en última instancia por el voto de la comunidad. Por ejemplo, el Cosmos Hub está debatiendo la adopción del SDK de constructor de Skip para posiblemente redirigir el MEV a la tesorería o a los stakers del Hub. Esta alineación a través de la gobernanza asegura que el uso del MEV sea visto como legítimo por la comunidad. Convierte el MEV de un subproducto tóxico en un recurso público que puede ser asignado (a la seguridad, usuarios, desarrolladores, etc.). En resumen, Skip remodela los incentivos de tal manera que los validadores colectivamente y los usuarios/comunidad se benefician, mientras que los tomadores de MEV oportunistas son cooptados en el sistema (como postores) o eliminados por diseño. En teoría, todos están mejor: los usuarios pierden menos valor por el MEV, los validadores siguen siendo compensados (incluso posiblemente más en total, debido a las subastas), y la red en su conjunto puede usar el MEV para fortalecerse (financieramente o a través de una experiencia más justa). Los únicos perdedores son aquellos que prosperaron con la extracción de suma cero sin devolver valor.

• Compatibilidad con Cumplimiento y Regulaciones: El marco de Skip, al empoderar la gobernanza de la cadena, en realidad facilita que las cadenas aseguren el cumplimiento o políticas específicas si lo desean. Debido a que Skip opera a nivel de protocolo, una cadena podría optar por imponer ciertas reglas de filtrado u ordenación de transacciones para cumplir con las regulaciones. Por ejemplo, si una cadena quisiera bloquear direcciones sancionadas, podría integrar una regla AnteHandler o AuctionDecorator en el módulo de Skip que invalide los bloques que contengan direcciones en la lista negra. Esto es posiblemente más simple que en Ethereum, donde la censura es una elección fuera de la cadena por parte de validadores individuales; en Cosmos con Skip, podría ser una regla para toda la cadena (aunque sería controvertido y va en contra de los ideales de descentralización para muchos). Alternativamente, una cadena podría imponer algo como "las transacciones de rampa de entrada de FIAT deben aparecer antes que otras" si así lo exige alguna ley. El conjunto de herramientas de Skip no viene con reglas de cumplimiento preestablecidas, pero es lo suficientemente flexible como para implementarlas si una comunidad se ve obligada a hacerlo (a través de la gobernanza). Por otro lado, Skip puede reforzar la resistencia a la censura: al distribuir los ingresos de MEV y dar acceso igualitario, reduce la ventaja de cualquier validador único que podría censurar para obtener beneficios. Además, si los mempools con cifrado de umbral (como el que Osmosis está añadiendo) se vuelven estándar con Skip, eso ocultará el contenido de las transacciones, dificultando la censura (como en Anoma). Skip es una infraestructura neutral: puede usarse para cumplir o resistir, dependiendo de la gobernanza. Dado que las cadenas de Cosmos a menudo son específicas de una jurisdicción (la comunidad de Terra podría preocuparse por las leyes coreanas, Kava podría preocuparse por las leyes de EE. UU., etc.), tener la opción de configurar el cumplimiento es valioso. Por ejemplo, una cadena de Cosmos permisionada (como una cadena institucional) aún podría usar el módulo de constructor de Skip, pero quizás requerir que solo las direcciones en la lista blanca puedan pujar en las subastas, etc., alineándose con sus regulaciones. La compatibilidad regulatoria también se trata de transparencia: las subastas en cadena de Skip producen un registro público de las transacciones de MEV y quién pagó qué. Esto podría satisfacer algunas preocupaciones regulatorias sobre la equidad (todos tuvieron la oportunidad de pujar, y es auditable). Es más transparente que los pagos bajo la mesa a los validadores. Además, al capturar el MEV en la cadena, Skip reduce la probabilidad de cárteles fuera de la cadena o dark pools, que los reguladores temen debido a la opacidad. Por ejemplo, sin Skip, los validadores podrían hacer tratos privados con los searchers (como se vio con los problemas de censura de los relays). Con Skip, la expectativa es que uses la subasta oficial, que es abierta y registrada, para obtener prioridad. Esto fomenta un mercado abierto accesible a todos los bots por igual, lo que es posiblemente más justo y menos propenso a la colusión (la colusión es posible, pero existe la supervisión de la gobernanza). Otro ángulo de cumplimiento: dado que Skip se ocupa de la captura de valor, si los ingresos de MEV van a un pool comunitario o tesorería, eso podría plantear preguntas (¿es una comisión, es imponible, etc.?). Pero son similares a cómo se manejan las comisiones de transacción, por lo que no hay nada fundamentalmente nuevo legalmente. En Cosmos, las comunidades de la cadena también pueden decidir cómo usar ese fondo (quemar, distribuir, etc.), lo que pueden alinear con cualquier guía legal si es necesario (por ejemplo, podrían evitar enviarlo a una fundación si eso desencadena problemas fiscales y en su lugar quemarlo). En términos de resistencia a la censura, una nota interesante: al imponer reglas de validez de bloque, Skip evita que los validadores censuren ciertas transacciones si eso rompiera las reglas. Por ejemplo, si una cadena tuviera una regla "debe incluir al menos una actualización de oráculo", un validador censor no podría simplemente omitir todas las transacciones de oráculo (que podrían provenir de ciertas fuentes) porque su bloque sería inválido. Así que, irónicamente, las reglas de Skip pueden forzar la inclusión de transacciones críticas (anti-censura) de la misma manera que podrían usarse para forzar la exclusión de las no permitidas. Todo depende de lo que establezca la comunidad. Neutralidad: La postura predeterminada de Skip es empoderar a las cadenas para "proteger a los usuarios del MEV negativo y mejorar la experiencia del usuario", lo que implica neutralidad y amigabilidad con el usuario. No hay una red central de Skip tomando decisiones; cada cadena es soberana. Skip como empresa podría asesorar o proporcionar valores predeterminados (como un formato de subasta recomendado), pero en última instancia, los poseedores de tokens de la cadena deciden. Esta descentralización de la política de MEV a la gobernanza de cada cadena puede verse como más compatible con la diversidad regulatoria: por ejemplo, una cadena con sede en EE. UU. podría implementar el cumplimiento de la OFAC si se ve presionada legalmente, sin afectar a otras cadenas. No es un solo relay censurando a través de muchas cadenas; es una elección por cadena. Desde la perspectiva de un regulador, Skip no introduce ninguna actividad ilícita adicional, simplemente reorganiza cómo se ordenan las transacciones. En todo caso, podría reducir la volatilidad (menos guerras de gas) y crear una ejecución más predecible, lo que podría ser una ventaja. En resumen, la arquitectura de Skip es altamente adaptable a las necesidades de cumplimiento mientras preserva la opción de una máxima resistencia a la censura si las comunidades priorizan eso. Mantiene el MEV a la luz del día y bajo control colectivo, lo que probablemente hace que los ecosistemas de blockchain sean más robustos contra actores maliciosos y represiones regulatorias, ya que la autogobernanza puede abordar proactivamente los peores abusos.

• Arquitectura Técnica e Implementación: Skip Protocol está estrechamente integrado en la pila del SDK de Cosmos. La entrega principal es un conjunto de módulos (por ejemplo, x/builder) y modificaciones como la implementación del mempool BlockBuster. Las cadenas de Cosmos ejecutan un consenso (Tendermint/CometBFT) que ofrece ganchos ABCI para preparar y procesar propuestas. Skip aprovecha las extensiones ABCI++ que permiten ejecutar código entre la propuesta de bloque y la finalización. Así es como impone la ordenación: PrepareProposal puede reordenar las transacciones del bloque según las reglas de los carriles antes de transmitir la propuesta, y ProcessProposal en los validadores receptores puede verificar que la ordenación y la validez del estado coincidan con las expectativas. Esta es una característica moderna (SDK de Cosmos v0.47+), y el POB de Skip es compatible con las versiones recientes del SDK. Internamente, los módulos de Skip mantienen estructuras de datos para las subastas (por ejemplo, un libro de órdenes en cadena de ofertas para la parte superior del bloque). También es probable que usen tipos de transacciones prioritarias. El README muestra un MsgAuctionBid especial y lógica personalizada para manejarlo. Así que los searchers interactúan enviando estos mensajes a través de transacciones normales de Cosmos, que luego el módulo intercepta y coloca en consecuencia. El AnteHandler del módulo de constructor (el AuctionDecorator) puede consumir ofertas de subasta y decidir los ganadores en la fase de ensamblaje del bloque. Criptográficamente, Skip no añade inherentemente nuevos requisitos criptográficos (aparte de lo que la cadena elija, como la criptografía de umbral para el mempool, que es independiente). Se basa en la honestidad de >2/3 de los validadores para hacer cumplir las reglas y no coludir para romperlas. Si una mayoría coludiera, técnicamente podrían cambiar las reglas a través de la gobernanza o ignorarlas convirtiéndola en la nueva regla de facto. Pero ese es el caso con cualquier lógica de cadena. El diseño de Skip intenta que sea mecánicamente imposible que un solo validador haga trampa a pequeña escala. Por ejemplo, cualquier intento de desviar la ordenación será detectado por otros porque es objetivo. Por lo tanto, reduce la confianza en los proponentes individuales. En términos de rendimiento, ejecutar subastas y verificaciones adicionales añade sobrecarga. Sin embargo, los bloques de Cosmos son relativamente pequeños y el tiempo entre bloques suele ser de un par de segundos, lo que es suficiente para estas operaciones en la mayoría de los casos. La simulación (pre-ejecutar transacciones para asegurar que no fallen y se cumplan las restricciones de ordenación) podría ser la parte más pesada, pero los validadores ya ejecutan los bloques normalmente, por lo que esto es similar. La presencia de múltiples carriles significa la separación del mempool: por ejemplo, una transacción podría necesitar especificar a qué carril se dirige (subasta vs. gratuito vs. predeterminado). El diseño de Skip BlockBuster de hecho tenía carriles separados como lanes/auction, lanes/free, etc., probablemente colas de mempool separadas. Eso asegura, por ejemplo, que las transacciones gratuitas no retrasen ni interfieran con las de la subasta. Es un poco como tener múltiples clases de prioridad en la programación. Otro aspecto es la seguridad y el mal comportamiento: si un proponente intenta manipular la subasta (por ejemplo, incluir su propia transacción pero afirmar que siguió las reglas), otros validadores rechazarán el bloque. El consenso de Cosmos entonces probablemente pasará al siguiente proponente, sancionando al anterior por doble firma o simplemente por fallar (dependiendo del escenario). Así que el modelo de seguridad de la cadena se encarga de eso, no se necesita una sanción especial por parte de Skip más allá del consenso existente. Se podría extender Skip para sancionar por ordenación maliciosa, pero probablemente sea innecesario si el bloque simplemente falla. Desarrollo y Herramientas: El código de Skip ha sido de código abierto (inicialmente en skip-mev/pob y ahora probablemente movido a un nuevo repositorio después de lanzamientos estables). Han pasado por testnets e iteraciones con cadenas asociadas. En la hoja de ruta, hemos visto: la Propuesta 341 de Osmosis (aprobada en otoño de 2022) para integrar ProtoRev y subastas con Skip, entregada a principios de 2023. Astroport de Terra integró el reparto de MEV con Skip en 2023. El Cosmos Hub está evaluando el "Block SDK" de Skip, que traería características similares al Hub. Otra frontera interesante es el MEV entre cadenas a través del Interchain Scheduler: la comunidad del Cosmos Hub está explorando una subasta de MEV entre cadenas donde el MEV de muchas cadenas podría negociarse en el Hub, y Skip está involucrado en esas discusiones (la investigación de Zerocap señaló el planificado programador entre cadenas de IBC). La tecnología de Skip podría servir como la columna vertebral para tales subastas entre cadenas porque ya está haciendo subastas en cadenas individuales. Eso sería análogo al objetivo multidominio de SUAVE pero dentro de Cosmos. En cuanto a las actualizaciones clave: Skip se lanzó a mediados de 2022. A mediados de 2023, tenían un lanzamiento estable de POB para el SDK v0.47+ (al que muchas cadenas se están actualizando). También recaudaron financiación inicial, lo que indica un desarrollo activo. Otro competidor en Cosmos, Mekatek, ofrece una funcionalidad similar. Esto quizás ha acelerado la hoja de ruta de Skip para mantenerse a la vanguardia. Skip continúa refinando características como carriles de transacciones privadas (quizás para ocultar tu transacción hasta que se incluya) y reglas de validez más complejas a medida que surgen casos de uso. Debido a que es modular, una cadena como dYdX (que tendrá un libro de órdenes) podría usar Skip para asegurar la equidad en el emparejamiento de órdenes en la cadena, etc., por lo que las herramientas de Skip podrían adaptarse a diferentes lógicas de aplicación. Técnicamente, la solución de Skip es más simple que construir una cadena completamente nueva: está actualizando las capacidades de las cadenas existentes. Este enfoque incremental y opcional ha permitido una adopción bastante rápida; por ejemplo, habilitar subastas en Osmosis no requirió un nuevo algoritmo de consenso, solo añadir un módulo y coordinar a los validadores para que ejecuten el software actualizado (lo cual hicieron, ya que era beneficioso y fue aprobado por la gobernanza). En resumen, la arquitectura de Skip está incrustada en el software de nodo de cada cadena, personalizando el mempool y el pipeline de propuesta de bloques. Es un enfoque de ingeniería pragmático para la ordenación justa: usar lo que ya existe (Tendermint BFT), añadir lógica para guiarlo. El trabajo pesado (como encontrar arbitrajes) puede incluso ser realizado por el propio módulo de la cadena (ProtoRev usa el código Wasm y Rust incorporado de Osmosis para escanear los pools). Así que gran parte del manejo de MEV se traslada a la cadena. Este enfoque en la cadena debe ser codificado cuidadosamente para la eficiencia y la seguridad, pero está bajo el escrutinio de la comunidad. Si alguna regla es problemática (demasiado estricta, etc.), la gobernanza puede ajustarla. Por lo tanto, técnica y socialmente, Skip convierte el MEV en solo otro parámetro de la cadena para ser optimizado y gobernado, en lugar de un salvaje oeste. Esta es una postura única habilitada por la flexibilidad de Cosmos.

Análisis Comparativo de SUAVE, Anoma, Skip y Flashbots v2​

Estos cuatro protocolos abordan el problema del MEV y la ordenación justa desde diferentes ángulos, adaptados a sus respectivos ecosistemas y filosofías de diseño. Flashbots v2 es una solución incremental y pragmática para la arquitectura actual de Ethereum: adopta las subastas de MEV pero intenta democratizar y suavizar su impacto (a través de la coordinación fuera de la cadena, la privacidad de SGX y los mecanismos de reparto). SUAVE es el plan a futuro de Flashbots para crear una plataforma de MEV entre cadenas que maximice el valor total y los beneficios para el usuario, esencialmente escalando el modelo de subasta a una red global descentralizada y que preserva la privacidad. Anoma es una reimaginación desde cero de cómo se formulan y ejecutan las transacciones, con el objetivo de eliminar las causas raíz de la ordenación injusta mediante el uso de intenciones, emparejamiento mediado por solvers y equidad criptográfica en el consenso. Skip es un enfoque de cadena soberana, que integra la equidad y la captura de MEV a nivel de protocolo por cadena, especialmente en Cosmos, a través de reglas y subastas configurables.

Cada uno tiene fortalezas y debilidades:

• Equidad y Garantías de Ordenación: Anoma ofrece la equidad teórica más fuerte (sin front-running por diseño, lotes encriptados), pero requiere un nuevo paradigma y una tecnología compleja que aún se está probando. Skip puede imponer reglas de equidad concretas en las cadenas existentes (evitando el front-running o imponiendo el primero en entrar, primero en salir dentro de los carriles), pero está limitado por lo que cada comunidad elige imponer. SUAVE y Flashbots v2 mejoran la equidad en términos de acceso (subastas abiertas en lugar de acuerdos secretos, protección contra el sniping en el mempool público), pero no evitan inherentemente que se ejecute una estrategia de MEV determinada; solo se aseguran de que pague a los usuarios o se haga de manera neutral.
• Redistribución de MEV: SUAVE y Flashbots tienen como objetivo explícito devolver el MEV a los usuarios/validadores: SUAVE a través de ofertas/reembolsos de los usuarios, Flashbots a través de competiciones de constructores y reembolsos. Skip puede canalizar el MEV a los usuarios (según se configure, por ejemplo, el caso de Astroport) o a fondos comunitarios. Anoma evita la redistribución explícita porque el objetivo es evitar la extracción en primer lugar; idealmente, los usuarios simplemente obtienen precios justos, lo que equivale a no perder valor por el MEV.
• Alcance (Dominio Único vs. Múltiple): Flashbots v2 y Skip se centran en sus propios dominios (Ethereum y cadenas individuales de Cosmos, respectivamente). SUAVE es inherentemente multidominio: ve el MEV entre cadenas como una motivación principal. Anoma también considera eventualmente intenciones multicadena, pero en las fases iniciales podría ser dentro de una instancia fractal a la vez, y luego conectarse a través de adaptadores. La subasta entre cadenas de SUAVE podría desbloquear arbitrajes y coordinación que otros no pueden hacer tan fácilmente (excepto quizás un Interchain Scheduler con la ayuda de Skip en Cosmos).
• Complejidad y Adopción: Flashbots v2 fue relativamente fácil de adoptar (un sidecar de cliente) y capturó rápidamente la mayoría de los bloques de Ethereum. Skip también aprovecha la tecnología existente y está viendo adopción en Cosmos con propuestas de gobernanza sencillas. SUAVE y Anoma son más revolucionarios: requieren nuevas redes o cambios importantes. El desafío de SUAVE será conseguir que muchas cadenas y usuarios opten por una nueva capa; el desafío de Anoma es crear un nuevo ecosistema y convencer a los desarrolladores de construir en un modelo centrado en intenciones.
• Cumplimiento y Neutralidad: Los cuatro ofrecen mejoras en la transparencia. Flashbots v2/SUAVE eliminan los elementos del bosque oscuro pero han tenido que gestionar problemas de censura; SUAVE se está construyendo explícitamente para evitar esos puntos centrales. Anoma, con privacidad por defecto, protege al máximo a los usuarios (pero podría preocupar a los reguladores debido a la actividad encriptada). El modelo de Skip da a cada cadena autonomía para encontrar un equilibrio en el cumplimiento. Si un regulador exigiera "no subastas de MEV" o "no privacidad", un Ethereum usando Flashbots podría enfrentar un conflicto, mientras que una cadena de Cosmos usando Skip podría simplemente no implementar esas características o ajustarlas. En términos de neutralidad: SUAVE y Anoma aspiran a la neutralidad creíble (todos acceden a un sistema en igualdad de condiciones; ambos son esencialmente redes de bienes públicos). Flashbots v2 es neutral al ofrecer acceso abierto, pero existe cierta centralización en el mercado de constructores (aunque mitigada por los esfuerzos de buildernet). La neutralidad de Skip depende de la gobernanza; idealmente, hace que el MEV no favorezca a ningún insider, pero podría configurarse mal y dañar la neutralidad (aunque es poco probable, ya que requeriría un consenso de gobernanza para hacerlo).
• Diferencias en la Arquitectura Técnica: Flashbots v2 y SUAVE son mercados fuera de la cadena superpuestos a la cadena: introducen roles especializados (constructores, relays, ejecutores) y usan hardware o criptografía para asegurarlos. Anoma y Skip se integran directamente en el consenso o la máquina de estados. Anoma altera el ciclo de vida de la transacción y el propio consenso (con cifrado de umbral e intenciones unificadas). Skip se engancha al consenso de Tendermint a través de ABCI++, pero no cambia el algoritmo fundamental; es un ajuste a nivel de aplicación. Esta diferencia significa que SUAVE/Flashbots pueden teóricamente servir a muchas cadenas sin que cada una se actualice (funcionan en paralelo a ellas), mientras que Anoma/Skip requieren que cada cadena o instancia use el nuevo software. SUAVE está en un punto intermedio: es una cadena separada, pero para usarla eficazmente, otras cadenas necesitan ajustes menores (para aceptar bloques construidos por SUAVE o enviar salidas a SUAVE). La sofisticación criptográfica es más alta en Anoma (ZK, MPC, criptografía de umbral, todo en uno), moderada en SUAVE (criptografía de umbral y SGX, más criptografía normal para puentes), y relativamente baja en Flashbots v2 (SGX, firmas estándar) y Skip (principalmente firmas estándar, más lo que la cadena use, como el descifrado de umbral si se opta por él).
• Etapa de Desarrollo: Flashbots v2 está en producción en Ethereum (desde septiembre de 2022). Skip está en producción en múltiples cadenas de Cosmos (desde 2022-2023 en adelante). SUAVE está en fase de testnet/devnet con partes implementándose (alguna funcionalidad de subasta en pruebas, testnet Toliman en vivo). Anoma también está en fase de testnet (un documento de visión, implementaciones parciales como la mainnet de Namada, y probablemente una testnet de Anoma que requiere códigos de invitación en 2023). Así que, en términos de datos del mundo real: Flashbots v2 y Skip han demostrado resultados (por ejemplo, Flashbots v2 entregó millones a los validadores y redujo los precios promedio del gas durante períodos de alto MEV; ProtoRev de Skip generó fondos significativos para la comunidad de Osmosis y evitó muchos ataques sándwich a medida que comenzó el cifrado de umbral). SUAVE y Anoma son prometedores pero tienen que demostrar su valía operativa y económica.

Para cristalizar estas comparaciones, la siguiente tabla resume los aspectos clave de cada protocolo lado a lado:

Cada solución aborda el problema del MEV desde una capa diferente: Flashbots v2 funciona alrededor del consenso L1, SUAVE propone una nueva capa L1.5, Anoma rediseña la propia L1, y Skip aprovecha la personalización modular de L1. En la práctica, estos enfoques no son mutuamente excluyentes e incluso podrían complementarse (por ejemplo, una cadena de Cosmos podría usar Skip internamente y también enviar intenciones a SUAVE para el MEV entre cadenas, o Ethereum podría implementar alguna equidad de orden tipo Anoma en el futuro mientras sigue usando Flashbots para los mercados de constructores). La tabla ilustra sus propiedades comparativas: Flashbots v2 ya está ofreciendo mejoras en Ethereum pero todavía extrae MEV (solo que de manera más equitativa y eficiente); SUAVE apunta a un resultado de sinergia máxima donde todos cooperan a través de una red; su éxito dependerá de la adopción generalizada y la entrega técnica de la privacidad y descentralización prometidas; Anoma ofrece quizás la represión de MEV más poderosa al cambiar completamente cómo funcionan las transacciones, pero enfrenta el gran desafío de arrancar un nuevo ecosistema y probar su complejo protocolo; Skip logra un equilibrio pragmático para Cosmos, permitiendo a las comunidades gobernar activamente el MEV y la equidad en sus propios términos; es menos radical que Anoma pero más integrado que Flashbots, y ya está mostrando resultados tangibles en Cosmos.

Conclusión y Perspectivas​

La supresión de MEV y la ordenación justa siguen siendo uno de los "Problemas del Milenio de las criptomonedas". Los cuatro protocolos analizados —Flashbots v2, SUAVE, Anoma y Skip— representan un espectro de soluciones: desde mitigaciones inmediatas en marcos existentes hasta cambios de paradigma totales en el procesamiento de transacciones. Flashbots v2 ha demostrado el poder de los mercados de MEV abiertos para reducir el caos y redistribuir el valor, aunque navegando por compromisos como la censura, que se están abordando a través de la descentralización. Muestra que los cambios incrementales (como las subastas PBS y los mempools privados) pueden reducir significativamente el dolor del MEV a corto plazo. SUAVE, el siguiente paso de Flashbots, lleva esa ética hacia un escenario unificado entre cadenas; si tiene éxito, podríamos ver un futuro en el que los usuarios reciban pagos rutinariamente por el MEV que crean sus operaciones y donde la producción de bloques en muchas redes sea colaborativa y encriptada para la equidad. Anoma apunta a una evolución más fundamental: al eliminar el concepto de transacciones prioritarias y reemplazarlo con un sistema de emparejamiento de intenciones, podría eliminar clases enteras de MEV y desbloquear dApps financieras más expresivas. Su ordenación justa a nivel de consenso (a través de cifrado de umbral y subastas por lotes) es un vistazo de cómo las propias blockchains pueden proporcionar garantías de equidad, no solo complementos fuera de la cadena. Skip Protocol, mientras tanto, ejemplifica un término medio en un contexto multicadena: da a las cadenas individuales la agencia para decidir cómo equilibrar los ingresos de MEV y la protección del usuario. Su adopción temprana en Cosmos muestra que muchos de los efectos nocivos del MEV pueden abordarse hoy con una ingeniería de protocolo reflexiva y el consentimiento de la comunidad.

De cara al futuro, podemos esperar una polinización cruzada de ideas: los investigadores de Ethereum están estudiando el consenso de ordenación justa y el cifrado de umbral (inspirados por proyectos como Anoma y el mempool encriptado de Osmo) para su posible inclusión en soluciones L1 o L2. SUAVE de Flashbots podría interactuar con las cadenas de Cosmos (quizás incluso a través de Skip) mientras busca ser agnóstico a la cadena. El concepto de intención de Anoma podría influir en el diseño de aplicaciones incluso en plataformas tradicionales (por ejemplo, CoW Swap en Ethereum ya utiliza un modelo de solver; se puede ver como una dApp "tipo Anoma"). El éxito de Skip puede alentar a otros ecosistemas (Polkadot, Solana, etc.) a adoptar controles de MEV similares dentro del protocolo. Un tema clave es la alineación económica: todos estos protocolos se esfuerzan por alinear los incentivos de quienes aseguran la red con el bienestar de los usuarios, de modo que explotar a los usuarios no sea rentable o no sea posible. Esto es crucial para la salud a largo plazo de los ecosistemas de blockchain y para evitar la centralización.

En resumen, SUAVE, Anoma, Skip y Flashbots v2 contribuyen cada uno con piezas del rompecabezas hacia la ordenación justa y la mitigación de MEV. Flashbots v2 ha establecido una plantilla para las subastas de MEV que otros emulan, Skip ha demostrado que la imposición en la cadena es viable, Anoma ha expandido la imaginación de lo que es posible al reconstruir el modelo de transacción, y SUAVE busca unificar y descentralizar las ganancias de los últimos años. La solución definitiva puede implicar elementos de todos: subastas globales que preservan la privacidad, interfaces de usuario centradas en intenciones, reglas de equidad a nivel de cadena y construcción de bloques colaborativa. A partir de 2025, la lucha contra la injusticia inducida por el MEV está en pleno apogeo: estos protocolos están convirtiendo el MEV de una inevitabilidad oscura en una parte gestionada, incluso productiva, de la economía cripto, mientras se acercan cada vez más al ideal de "la mejor ejecución para los usuarios con la infraestructura más descentralizada".