Las dos migraciones de la propuesta de Akash a Solana

La elección de destino llega a votación

El 26 de octubre de 2026, Greg Osuri anunció que el equipo central de Akash había elegido Solana como destino propuesto para la red. El plan sustituiría la cadena soberana de Cosmos por programas del mercado en Solana. Sin embargo, el texto sometido a voto separa dos decisiones que un titular sobre una migración de cadena puede confundir: lanzar SPL AKT y trasladar el mercado de cómputo.^[1][2]

A las 00:12 UTC del 27 de octubre, la respuesta REST oficial de Akash mostraba la propuesta 346 como PROPOSAL_STATUS_VOTING_PERIOD en el bloque 29.244.551. La votación comenzó el 26 de octubre a las 15:02:58 UTC y su cierre figuraba para el 2 de noviembre a las 15:02:58 UTC. Es el registro de una votación abierta, no de una aprobación. La propuesta dice expresamente que no fija la fecha de corte del mercado ni lo traslada.^[2]

La parte del token trata sobre registros de propiedad

El diseño del token trata sobre qué cadena registra el AKT de un titular. Propone un portal de un solo sentido: el AKT retirado de circulación en akashnet-2 se representaría con el mismo número de unidades mínimas de SPL AKT en Solana. La condición contable central es que la nueva representación corresponda a retiradas verificadas, sin crear una segunda copia gastable de las mismas unidades. Es un mecanismo propuesto, no un portal operativo verificado.^[2][3]

Ese cambio no trasladaría por sí solo la carga de trabajo de un usuario ni sustituiría el contrato de un proveedor. La propuesta mantiene sin cambios los contratos activos, el staking y la gobernanza en akashnet-2 hasta el corte. La cadena anterior conserva así una función mientras el token y el mercado cumplen condiciones de preparación distintas.^[2][4]

El mercado aún tiene operaciones que liquidar

Un mercado contiene más que saldos de tokens de usuarios. El diseño distingue las cuentas de usuario de los fondos en módulos del protocolo, incluido el depósito en garantía que se atribuye conforme se liquidan los contratos. También señala que parte de la contabilidad del cierre sigue en revisión. Mover un saldo no determina por sí mismo qué proveedor ha devengado un pago o a qué usuario corresponde un reembolso.^[3]

El corte posterior llevaría los nuevos despliegues a Solana después de las auditorías del mercado, los ensayos de migración y la aprobación de otra propuesta en cadena. El plan contempla entonces 90 días de cierre gradual para los contratos existentes antes de detener la cadena anterior. Son condiciones y etapas del plan; ni su publicación ni la votación actual demuestran que se hayan realizado las auditorías, el corte o el cierre gradual.^[2][4]

Tres documentos no forman un solo calendario

Los plazos exigen especial cuidado. El anuncio del 26 de octubre sitúa el lanzamiento del token dos semanas después de la aprobación, condicionado a dos auditorías independientes. Los documentos de token y transición, identificados como v0.10, borrador para revisión del 20 de octubre, lo definen en cambio a los siete días de aprobarse la migración. El texto presentado como propuesta 346 prevé de dos a tres semanas después de la aprobación, una vez terminadas las auditorías del token y del portal. Una previsión condicionada a auditorías no establece una fecha de calendario.^[1][2][3][4]

Otras cifras del borrador también difieren de la cadena actual. El borrador recoge 14 días de desvinculación del staking, un cuórum del 20% y tres días de votación. En el bloque observado, los endpoints oficiales devolvieron 1.814.400 segundos para la desvinculación, es decir, 21 días, y parámetros de gobernanza del 33,4% de cuórum y 604.800 segundos, o siete días. Es una comparación fechada de documentos y estado de la cadena, no una instrucción para retirar el staking ni una garantía de parámetros futuros.^[3][4][5][6]

El borrador de transición también exige superar una fase de preparación del token antes de presentar la propuesta, mientras que el texto presentado condiciona el lanzamiento a las auditorías completas. La presentación por sí sola no demuestra que se haya superado esa fase del borrador. La propuesta presentada remite a un commit concreto del plan. Los archivos de token y transición de ese commit son idénticos a los de la revisión actual de main comprobada para este artículo. La discrepancia no puede descartarse como una simple lectura de otra rama. El texto presentado establece qué se pide aprobar, pero no concilia todos los detalles técnicos ni demuestra que la implementación esté lista. Aquí no convertimos ninguno de esos plazos relativos en una fecha límite de migración.^[2][3][4]

Qué permitiría confirmar la siguiente etapa

Conviene distinguir autorización, preparación y ejecución. El resultado de la votación establecería la decisión de la comunidad sobre esta propuesta. Las pruebas publicadas de auditorías y ensayos permitirían evaluar la preparación. Un calendario de corte aprobado después y las pruebas de su ejecución establecerían la transición del mercado. Un anuncio de un token en Solana no responde por sí solo a las tres cuestiones.^[2][4]