Cynthia Petion y Eddie Petion Audio de Kusama (KSM): Análisis Profundo de la red canaria de Polkadot explicada a fondo — arquitectura, OpenGov, XCM, Agile Coretime, tokenomics, staking
Kusama es la “red canaria” de Polkadot: un entorno soberano, público y sin permisos donde se prueba —con menos conservadurismo y más velocidad— lo que luego (quizá) se consolida en Polkadot. No es un testnet; es una red mainnet con valor real, gobernanza propia, treasury y una cultura “move fast & break things” que prioriza la experimentación y la iteración rápida sobre nuevas piezas del stack —desde runtime y gobernanza hasta modelos de ejecución y mercados de recursos.
ADN técnico: Substrate, NPoS, BABE/GRANDPA y BEEFY
Kusama comparte base tecnológica con Polkadot: Substrate (marco modular para construir blockchains), NPoS (Nominated Proof-of-Stake) para selección de validadores y GRANDPA para finalidad rápida de bloques. Para puentes con cadenas externas, el protocolo BEEFY aporta finalización eficiente hacia redes que no comparten el modelo de Polkadot/Kusama, como Ethereum. En conjunto, la red combina producción de bloques (BABE), finalidad (GRANDPA) y primitivas de puente (BEEFY) para un equilibrio entre seguridad y throughput.
Clave: Kusama no es “una copia barata” de Polkadot; es prima de Polkadot, con parecido ADN técnico pero prioridades distintas: Kusama favorece agilidad y riesgo controlado; Polkadot, estabilidad y conservadurismo.
Interoperabilidad con XCM: más allá de los bridges
XCM (Cross-Consensus Messaging) es el lenguaje de mensajería entre consensos (redes) del ecosistema. No es un “puente” único, sino una capa de comunicación para pasar activos, llamadas y señales entre parachains, system chains y otras capas. La documentación de Kusama describe al detalle el ejecutor XCM, la máquina virtual XCM (XCVM) y el formato de instrucciones, que permiten diseñar flujos multi-cadena robustos. Esta base ha dado lugar a tooling como ParaSpell, que simplifica las integraciones XCM para desarrolladores.
De subastas a Agile Coretime: el nuevo mercado de recursos
Entre 2024 y 2025, el mayor cambio de paradigma fue el paso de subastas de parachains a Agile Coretime. En lugar de competir por slots de meses/años, los equipos compran “tiempo de núcleo” (capacidad de cómputo) en mercados con descubrimiento de precio (p. ej., subasta holandesa seguida de etapas a precio fijo). El objetivo: eficiencia y elasticidad en el uso de recursos, alineando coste con demanda real. Kusama fue la primera en experimentar con ventas y trading de Coretime, marcando un hito para la arquitectura *multi-*threaded de la “Polkadot Cloud”.
Los primeros lotes vendidos en Kusama fijaron un precedente: reportes públicos señalan que se adjudicaron tres cores por un total de 70 KSM (≈ USD 1.980 al tipo de cambio de entonces), a un promedio de 23,4 KSM por core. Más que el número, importa el mensaje: el mercado de recursos funciona y puede iterar sobre reglas, plazos y market design para ganar eficiencia.
Idea de fondo: Agile Coretime es una pieza económica y técnica. Económica, porque crea mercados de capacidad; técnica, porque habilita multi-threading y programabilidad de recursos. Kusama prueba los límites antes que nadie.
OpenGov: gobernanza on-chain a máxima velocidad
La gobernanza de Kusama se articula en tracks (pistas) con orígenes y umbrales específicos (aprobación/soporte, depósitos, tiempos de preparación, decisión y confirmación). Polkadot OpenGov —adoptado también en Kusama— acelera los ciclos y delegan ciertas funciones a la Technical Fellowship: por ejemplo, el track Whitelisted-Root permite que, si la Fellowship “blanquea” (autoriza) una llamada concreta, esa llamada pueda ejecutarse con origen Root una vez aprobada en referéndum, acortando tiempos en cambios urgentes y críticos.
Los dashboards públicos (como Subsquare o Polkassembly) muestran en vivo propuestas, parámetros de cada track y discusiones de la comunidad. Por ejemplo, el track 13 (FellowshipAdmin) expone períodos típicos (preparación, decisión, confirmación, etc.) y depósito de decisión (≈ 166,67 KSM al momento de la captura), ilustrando la granularidad con que se gestiona cada flujo. A la vez, los foros y referenda feed recogen debates tan “kusamescos” como añadir un track trivial para publicar en X (Twitter) desde la cuenta @kusamanetwork —porque en Kusama todo puede gobernarse on-chain.
También hay deliberaciones sobre modelo de ingresos y quemas en la era Coretime: el feed de Subsquare incluye propuestas como la #548 (“Wish For Change”) que cuestionan si Coretime es un buen modelo de ingresos y sugieren alternativas (p. ej., quemas de KSM). No se trata de un “manual perfecto”, sino de gobernanza viva y explícita.
Tokenomics y staking de KSM: lo esencial
KSM es el token nativo de Kusama. Su caso de uso principal es participar en la seguridad de la red vía NPoS (como validador o nominador) y gobernar (OpenGov). El diseño de staking permite nominación directa o vía nomination pools, que bajan la barrera de entrada y agregan capital para nominar validadores, compartiendo recompensas. La guía oficial de Kusama sobre Nomination Pools explica la mecánica y restricciones (p. ej., el pool necesita suficiente bond para entrar en la “bags list” y optar a recompensas).
Ritmo de la red: en Kusama, una era (unidad para el cálculo de recompensas) dura ~6 horas —dato práctico para entender cuándo comienzas a percibir recompensas al unirte a un pool. Herramientas como Nova Wallet recuerdan además que, si stakeas por debajo del mínimo para direct staking, te redirigirán a pool staking.
Seguridad vs. UX: stakear en Kusama implica gestionar llaves y entender comisiones, bloqueos y riesgos de desalineación (elegir malos validadores). Si no tienes tiempo para una due diligence técnica, pool staking suele ser la vía más amigable.
¿Qué construyen hoy los builders en Kusama?
- Parachains y app-chains que compran Coretime (en lugar de slots rígidos) para desplegar lógica especializada y ajustar su consumo de recursos.
- Integraciones XCM para mover activos y llamadas entre dominios (p. ej., escrows, remote execution, asset teleports), apoyándose en ParaSpell y documentación XCM.
- Gobernanza programable: tooling que automatiza propuestas, signaling y whitelisting con la Fellowship —el repositorio de runtimes custodiado por la Fellowship deja ver el flujo de código → referéndum → enactment.
Para quien viene del mundo EVM, Kusama ofrece un modelo mental distinto: más que un L1 monolítico, es un sistema multi-cadena/multi-hilo donde recursos (Coretime), mensajería (XCM) y gobernanza (OpenGov+Fellowship) se combinan como piezas de Lego.
Cómo empezar (usuario)
1) Wallet & on-ramp
- Instala una wallet del ecosistema Polkadot/Kusama (p. ej., SubWallet, Nova, Polkadot{.js}).
- Adquiere KSM en un exchange de tu preferencia y mueve una cantidad inicial a tu autocustodia (deja un margen para fees).
2) Staking (bajo tu riesgo)
- Si dominas la parte técnica, nominación directa: elige un conjunto de validadores con buen track record.
- Si prefieres simplicidad, Nomination Pools: únete a un pool con bond suficiente; recuerda que las recompensas empiezan a contabilizar a partir de la era siguiente (~6 h).
3) Gobernanza
- Crea una identidad on-chain (opcional) y participa en referenda. Lee el track correspondiente: depósito, periodos, umbrales y si interviene la Fellowship (p. ej., Whitelisted-Root). Utiliza paneles como Subsquare/Polkassembly para seguir propuestas.
Cómo empezar (desarrollador/empresa)
1) Entiende Agile Coretime
Lee el índice de Agile Coretime (conceptos, marketplaces, guías) y diseña un plan de capacidad acorde a tu demanda esperada (picos, estacionalidad, despliegues).
2) Interoperabilidad desde el diseño
Construye tu app-chain o pallet pensando en XCM (entradas/salidas, fee payment, autorización, remote execution). Toolkits como ParaSpell reducen el tiempo a producción.
3) Gobernanza y runtime
Si tu upgrade requiere origen Root, evalúa el track adecuado y, cuando aplique, busca señal positiva de la Fellowship para whitelisting antes de lanzar el referéndum (ahorra tiempo y fricciones).
Métricas, dashboards y estado de red
- Guías oficiales: la Kusama Guide centraliza capítulos de consenso, XCM, OpenGov y Coretime —ideal para alinear lenguaje con tu equipo.
- Gobernanza: Subsquare y Polkassembly listan tracks, parámetros, referenda (abiertas, aprobadas, rechazadas), comentarios y off-chain signals.
- XCM: Subscan dispone de dashboards para mensajes/transferencias entre dominios; útil para auditar canales y flujo de activos.
Riesgos (léelos antes de asignar capital o lanzar producto)
- Riesgo de ejecución/experimento
Kusama apuesta por la velocidad. Cambios de runtime, parámetros de Coretime o ajustes en gobernanza pueden moverse rápido. Como builder o staker, mantente al día en feeds y guías. - Riesgo de mercado de recursos
Agile Coretime está vivo: precios, fases y dinámica de marketplaces pueden variar. Asegura capacidad y presupuesto con margen ante picos de demanda. - Riesgo de gobernanza
OpenGov da poder a la comunidad, pero también exposición a propuestas polémicas o poco ortodoxas (desde tracks triviales hasta debates sobre quemas o ingresos). Participa y vota: es parte del trato Kusama. - Riesgo técnico/interoperabilidad
XCM reduce fricción, pero diseñar mal las rutas (permisos, fees, liquidación) puede ser costoso. Audita tus instrucciones XCM y usa herramientas probadas. - Riesgo de staking
Nominadores dependen del comportamiento de validadores/pools y de umbrales de inclusión. Elige con criterio, diversifica nominaciones y entiende eras y rewards.
Si te atrae probar antes que nadie lo que puede definir el futuro del stack de Polkadot, Kusama es el lugar. Aquí Agile Coretime convierte la capacidad en un mercado, XCM hace que las cadenas se hablen con un lenguaje común, y OpenGov permite que todo —desde upgrades a memes tracks— se decida on-chain. El coste de esa libertad es mayor volatilidad (técnica y económica). A cambio, obtienes velocidad para iterar productos, exposición a los últimos cambios y una comunidad que vive la gobernanza como un deporte.