Polkadot

Polkadot es un protocolo de red multichain que conecta muchas blockchains especializadas ("parachains") a una Cadena de Relevo central (Relay Chain). La Cadena de Relevo proporciona seguridad compartida, consenso e interoperabilidad entre cadenas, mientras que las parachains se ejecutan en paralelo y se comunican usando la mensajería de consenso cruzado (XCM) de Polkadot. El diseño apunta a la escalabilidad y composabilidad entre cadenas dentro de una misma red.

En la arquitectura de Polkadot, las parachains son cadenas específicas para aplicaciones cuyos bloques son producidos por collators y verificados por los validadores de la Cadena de Relevo. Al unirse a la Cadena de Relevo, las parachains heredan la seguridad económica del conjunto de validadores y pueden intercambiar mensajes con otras cadenas a través de XCM. Los puentes también pueden conectar Polkadot con redes externas—for ejemplo, Ethereum mediante Snowbridge; la conectividad con Bitcoin es proporcionada por parachains como Interlay, en vez de un puente ligero nativo. Para detalles operativos sobre la mensajería entre cadenas, véase la sección dedicada a XCM.

DOT es el token nativo de la red en la Cadena de Relevo. En la especificación de Polkadot sustenta tres funciones clave: gobernanza del protocolo, staking para la seguridad de la red y bonding (el mecanismo históricamente usado para añadir cadenas).

El modelo de recursos de Polkadot está evolucionando con “Polkadot 2.0”. En vez de arrendar espacios a largo plazo, los proyectos acceden a cómputo de la Cadena de Relevo a través de coretime (tiempo en núcleos virtuales). El coretime es asignado a las cadenas del sistema por la gobernanza y adquirido por otras cadenas en el mercado abierto.

DOT es el token nativo de la Cadena de Relevo de Polkadot. Sustenta las funciones principales de la red:

Seguridad de la red mediante staking (NPoS): Los titulares de DOT pueden nominar validadores o ejecutar un validador para ayudar a finalizar bloques y mantener la honestidad del sistema. Los DOT apostados respaldan el comportamiento de los validadores y ganan recompensas de staking; el mal comportamiento puede ser penalizado (slashing). Ver: Prueba de Nominación por Participación y Slashing para funcionamiento y riesgos.

Gobernanza en cadena (OpenGov): DOT se usa para proponer y votar referéndums a través de múltiples "tracks", delegar poder de voto y participar en actualizaciones del protocolo y decisiones de cadenas del sistema. Ver: OpenGov y ¿Cómo pueden los usuarios participar en la gobernanza… para detalles sobre tracks, depósitos y delegaciones.

Comisiones de red y depósitos necesarios: Las transacciones en la Cadena de Relevo pagan comisiones en DOT, y las cuentas deben mantener un saldo mínimo (depósito existencial) para seguir activas. Algunas acciones en cadena también requieren depósitos retornables de DOT (por ejemplo, identidad). Ver: ¿Cuáles son las utilidades en cadena de DOT... para tipos de comisiones y depósitos.

Adquisición de cómputo en la Cadena de Relevo (“coretime”) en Polkadot 2.0: Los proyectos obtienen tiempo de ejecución en los núcleos de la Cadena de Relevo comprando coretime con DOT; estos DOT son quemados. Este modelo reemplaza los arrendamientos/crowdloans de espacio a largo plazo. Ver: ¿Qué cambia con Polkadot 2.0... y ¿Cómo puede un equipo lanzar una cadena... para aspectos económicos y rutas de despliegue.

Financiación del sistema a través del Tesoro en cadena: Los ingresos del Tesoro (parte de recompensas de bloque, comisiones, propinas, slashing) se denominan en DOT y pueden gastarse—mediante gobernanza—en propuestas aprobadas. Ver: ¿Cómo funciona el Tesoro en cadena… para proceso y alcance.

Movimiento entre cadenas y uso en el ecosistema: DOT puede ser teletransportado (“teleported”) entre la Cadena de Relevo y parachains del sistema como Asset Hub usando XCM; las transferencias entre cadenas pueden incurrir comisiones en ambas cadenas (origen y destino). Algunas parachains/apps aceptan DOT nativamente; otras requieren representaciones puenteadas/envueltas. Ver: Asset Hub y ¿Cómo interoperan los DOT con otras redes… para detalles y advertencias.

Si buscas el modelo de comisiones concreto, mínimos, depósitos y flujos de staking, continúa con “¿Cuáles son las utilidades en cadena de DOT (staking, comisiones, gobernanza y depósitos)?”

DOT utiliza una emisión anual fija que comenzó en ~8% del suministro al inicio y ahora es constante, ~120 millones de DOT por año, lo que provoca que el porcentaje de inflación disminuya con el crecimiento del suministro total. De cada emisión anual, el 15% se acuña directamente para el Tesoro y el 85% financia las recompensas de staking (repartidas por era). Estos parámetros fueron introducidos por OpenGov (Referéndum #1139) e implementados en el código de ejecución.

Cadencia y distribución de emisiones: Los nuevos DOT se crean de forma continua y se contabilizan al final de cada era (~24 horas en Polkadot), repartidos a validadores y nominadores mediante el mecanismo de recompensas de staking; la parte del 15% del Tesoro se acuña directamente en su cuenta del sistema. Con el modelo de emisión fija, esta repartición ya no se ajusta según la participación en staking, simplificando las recompensas respecto al diseño anterior.

Burns que compensan la emisión bruta: Dos fuentes reducen el crecimiento neto de la oferta: las compras de coretime (en Polkadot 2.0) son quemadas, y el Tesoro puede quemar fondos mediante gobernanza. Por tanto, la inflación anual efectiva es la emisión fija (~120M DOT) menos los importes quemados ese año.

Diferencias con el modelo anterior: Antes del cambio de 2024, Polkadot apuntaba a ~10% de inflación anual, con recompensas moduladas en torno a una tasa “ideal” de staking y el resto asignado al Tesoro (“ineficiencia de staking”). El nuevo modelo elimina ese ajuste y lo reemplaza por el fijo del 15% para el Tesoro arriba mencionado.

Sin límite máximo (sujeto a gobernanza): DOT no tiene un suministro máximo programado en el protocolo. Los parámetros de emisión pueden cambiarse por gobernanza en cadena; las actualizaciones 2024–2025 se aplicaron así. Para ver configuraciones actuales y propuestas activas, consulta los referéndums relevantes en OpenGov.

Redenominación de 2020 (sólo cambio de unidad): El 21 de agosto de 2020 (“Denomination Day," bloque #1,248,328), DOT fue redenominado en una proporción de 1 DOT antiguo = 100 DOT nuevos. Fue un cambio de unidad, no de valor o propiedad: saldos y precios se escalaron por 100×, y la unidad base (Planck) por DOT se movió de 10¹² a 10¹⁰ Planck. La economía de la red no cambió en lo esencial.

Staking (asegurar la red): Los DOT pueden ser “bonded” para asegurar la red bajo el sistema Nominated Proof-of-Stake (NPoS). Los titulares pueden nominar validadores o ejecutar un validador; las recompensas se distribuyen por era y el mal comportamiento puede ser penalizado (slashing). El conjunto de validadores se elige mediante algoritmos basados en Phragmén, y los usuarios pueden participar mediante pools de nominación si prefieren una vía más sencilla con cantidades menores. Detalles como periodos de desbloqueo, condiciones de slashing y características de elecciones están en las secciones de NPoS y Slashing.

Comisiones (pago por transacciones): En la Cadena de Relevo, las transacciones pagan comisiones en DOT descontadas del saldo transferible (no de fondos bondados). Las comisiones constan de una comisión base, comisión por longitud, y comisión por peso, más una propina opcional para priorizar inclusión; un multiplicador de congestión puede ajustar las comisiones según la saturación de bloques reciente. Las wallets muestran la comisión estimada antes de firmar.

Las acciones entre cadenas pueden involucrar comisiones en ambas cadenas (origen y destino). Por ejemplo, teletransportar DOT entre la Cadena de Relevo y Asset Hub incurre una comisión de destino y no aplica la protección “keep-alive”, por lo que los saldos deben permanecer encima del mínimo para evitar el reaping.

Gobernanza (OpenGov): DOT se utiliza para proponer y votar referéndums en OpenGov. Las propuestas requieren un depósito de decisión; la votación utiliza balances ponderados por convicción (tokens bloqueados por tiempo para más peso). Los usuarios también pueden delegar poder de voto, incluyendo delegaciones por track. La operativa (votar, delegar, gestionar locks) se detalla en las secciones de OpenGov.

Depósitos y saldos mínimos: Polkadot exige un depósito existencial (existential deposit, ED), un saldo libre mínimo para mantener la cuenta activa. Si el saldo libre cae por debajo del ED, la cuenta puede ser eliminada y cualquier saldo residual se quema. Actualmente se recomienda 1 DOT de ED en la Cadena de Relevo y 0,01 DOT en Asset Hub (valores por cadena y sujetos a cambios). La protección “keep-alive” ayuda a evitar reaping accidental en transferencias normales; los teleports no aplican esta protección.

Algunas funciones requieren depósitos reservados (bonds) retenidos mientras la función esté activa y típicamente devueltos cuando se elimina. Ejemplo: la identidad en cadena ahora gestionada en la parachain People requiere un depósito retornable y una tasa de registro; borrar la identidad libera el depósito (los fondos residen en People hasta ser teletransportados de vuelta). Los depósitos ligados a gobernanza están detallados allí.

La Cadena de Relevo es la cadena central de Polkadot. Proporciona seguridad compartida y consenso global, y es intencionadamente mínima en lógica de aplicación: existe para coordinar múltiples cadenas paralelas en vez de ejecutar funciones de usuario final. En el diseño de Polkadot, la Cadena de Relevo garantiza una visión única y consistente del estado en todas las shards conectadas ("parachains").

Parachains son cadenas específicas para aplicaciones que operan en paralelo y se conectan a la Cadena de Relevo. Mantienen su propio estado y lógica, pero heredan la seguridad del conjunto de validadores de la Cadena de Relevo. Los nodos parachain llamados collators recopilan transacciones y producen bloques candidatos con pruebas; los validadores de la Cadena de Relevo verifican disponibilidad y validez antes de que las transiciones de estado sean aceptadas al estado compartido. Esta separación permite especialización de parachains mientras que la Cadena de Relevo gestiona consenso, finalidad y coordinación.

Las parachains pueden comunicarse entre sí usando la mensajería de consenso cruzado de Polkadot (XCM), siendo la Cadena de Relevo la coordinadora del enrutamiento y verificación para que las cadenas intercambien datos y activos de forma segura. La mecánica interna de XCM se detalla en la sección XCM.

Polkadot, además, incluye parachains de sistema para funciones centrales del protocolo—por ejemplo, Asset Hub para activos fungibles y no fungibles—trasladando funcionalidad fuera de la Cadena de Relevo pero manteniendo la seguridad compartida. Estas cadenas de sistema son asignadas por gobernanza en cadena.

Con Polkadot 2.0, los proyectos acceden al cómputo de la Cadena de Relevo mediante cores ("coretime"). Las cadenas de sistema reciben cores por gobernanza y otras cadenas obtienen coretime en el mercado abierto; la relación sigue siendo: las parachains ejecutan su lógica, la Cadena de Relevo valida y finaliza sus transiciones de estado.

XCM (Cross-Consensus Messaging) es el lenguaje de Polkadot para enviar mensajes basados en intención entre sistemas de consenso (Cadena de Relevo, parachains y, vía puentes, otras redes). Define lo que debe ocurrir, independiente de cualquier pallet del runtime. XCMP (Cross-Chain Message Passing) es el protocolo de transporte para mensajes parachain↔parachain; el tráfico relay↔parachain usa UMP (ascendente) y DMP (descendente). Los mensajes son asíncronos.

Transferencias: los dos patrones nativos de XCM

• Teleport: el saldo se mueve directamente entre ubicaciones de confianza sin un reservador. Uso típico: DOT entre la Cadena de Relevo y Asset Hub. Los teleports requieren configuración de confianza mutua entre ambas cadenas.
• Transferencia basada en reserva: la cadena de reserva del activo registra el suministro total; el origen bloquea/quema una representación, la reserva ajusta saldos y el destino acuña/credite una representación. Es el patrón común para mover activos hacia parachains que no son la reserva.

En la práctica, muchos equipos prefieren transferencias de reserva por seguridad y claridad; los teleports suelen activarse solo en rutas de alta confianza (para DOT: Relay Chain ↔ Asset Hub).

Canales y enrutamiento: Los mensajes entre parachains viajan por canales. Actualmente la mayoría de las redes usan HRMP (Horizontal Relay-routed Message Passing), que ofrece la misma interfaz que XCMP pero almacena los mensajes en la Cadena de Relevo; XCMP es el objetivo eficiente a largo plazo. Los canales HRMP son unidireccionales; la conectividad bidireccional requiere un canal por sentido y debe abrirse/aceptarse por ambas cadenas.

Comisiones, peso y ejecución: Un XCM debe “comprar ejecución” en la cadena destino (pagar por peso, es decir, cómputo). Qué activos se aceptan para pagar comisiones y cuánto peso requiere depende de la política de la cadena de destino. Los extrinsics estándar incluyen teleport_assets y reserve_transfer_assets, que especifican destino, beneficiario, activos y elemento de comisión.

Comportamiento y salvaguardas para el usuario:

• Depósitos existenciales & keep-alive: los teleports no aplican la protección “keep-alive”. Asegura que tras la comisión tu saldo en destino quede por encima del depósito existencial de esa cadena o la cuenta será reaped. Los teleports también incluyen una comisión de destino.
• Asincronía & orden: la entrega no es instantánea; el orden solo se garantiza dentro de un canal.

Para puentes hacia redes externas y DOT envueltos, ver la sección de interoperabilidad más adelante.

Asset Hub es la parachain de sistema de Polkadot (antes “Statemint”) destinada a emitir, almacenar y transferir activos, incluyendo tokens fungibles y NFTs. Está diseñada como una cadena de bien común con comisiones más bajas y un depósito existencial menor que la Cadena de Relevo, y usa DOT como token nativo para comisiones y depósitos. En Asset Hub el depósito existencial es 0,01 DOT (diez veces menor que en la Cadena de Relevo), y los activos pueden marcarse como suficientes (no se requiere saldo en DOT para poseerlos) o no suficientes (la cuenta debe tener el ED de DOT).

En la operativa, Asset Hub es donde usuarios y equipos pueden crear activos, gestionar metadatos y realizar transferencias; las guías oficiales la recomiendan como lugar conveniente para gestionar tokens no nativos y NFTs. (En Asset Hub de Kusama hay contratos inteligentes nativos; en Polkadot los contratos inteligentes EVM/PVM están planificados para la cadena de sistema Polkadot Hub, no en Asset Hub.)

¿Cuándo tiene sentido teleportar DOT?

Teleportar es la ruta XCM de confianza configurada entre la Cadena de Relevo ↔ Asset Hub para DOT. Es útil cuando específicamente necesitas DOT en Asset Hub, por ejemplo para:

• Pagar comisiones menores o cumplir el depósito existencial de 0,01 DOT para custodiar activos no suficientes en Asset Hub, o
• Usar funciones y aplicaciones que se ejecutan en Asset Hub.

Comportamientos clave a conocer antes de teleportar:

• Una comisión de destino se deduce de la cantidad teleportada; el resto debe ser ≥ al depósito existencial de la cadena destino o los fondos se pierden.
• Los teleports no aplican “keep-alive”, así que debes asegurarte de que tras la comisión los saldos estén por encima del depósito existencial en ambos lados si quieres mantener las cuentas activas.
• No teletransportes directamente a una dirección de depósito en un exchange (la mayoría no reconoce teleports).

Para la mecánica de teleports frente a transferencias basadas en reserva y el enrutamiento cross-chain, ver la sección XCM/XCMP. Si hay una migración o mantenimiento planificado en Asset Hub, los teleports y transferencias XCM pueden estar temporalmente inhabilitados; revisa los avisos de Soporte para ver el estado.

Propósito y rol: Polkadot y Kusama son redes independientes con tokens separados (DOT, KSM) construidas sobre código similar. Kusama es la “red canario”: un entorno real, económico y vivo donde las nuevas funciones llegan primero y avanzan más rápido; Polkadot prioriza estabilidad y fiabilidad para despliegues de producción.

Cadencia de gobernanza: Ambas usan OpenGov, pero Kusama generalmente tiene ventanas más cortas (según track) desde la decisión hasta la confirmación/entrada en vigor, permitiendo actualizaciones rápidas; Polkadot tiene ventanas más conservadoras. Los parámetros son por track y pueden cambiar por gobernanza.

Tiempos de staking: El periodo de desbloqueo es de ~28 días en Polkadot y ~7 días en Kusama. Las eras—períodos para pagos a validadores—duran ~24 horas en Polkadot y ~6 horas en Kusama. Estas diferencias afectan el ritmo de recompensas y cuánto tiempo permanecen bloqueados los fondos tras el unbonding.

Saldo mínimo de cuenta (depósito existencial): Para mantener una cuenta activa, Polkadot requiere 1 DOT y Kusama 0,000333333 KSM (los valores pueden cambiar por gobernanza). Las parachain Asset Hub usan ED aún menores.

Ruta de actualización: Los cambios y funciones importantes de protocolo se prueban primero en Kusama bajo condiciones reales; una vez validadas, se despliegan en Polkadot. Esto mantiene agilidad en Kusama y conservadurismo en Polkadot para la operación a largo plazo.

Ambas redes comparten el mismo modelo arquitectónico (Relay Chain + parachains) y herramientas OpenGov; las diferencias reflejan objetivos (velocidad vs estabilidad) y parámetros operativos (cronometrajes, mínimos), no de diseño fundamental.

NPoS es el modelo de staking de Polkadot en el que dos roles aseguran la red: los validadores operan nodos que producen y validan bloques; los nominadores respaldan validadores seleccionados con sus DOT. Ambos comparten recompensas y riesgo de penalizaciones si el validador respaldado incurre en faltas. Las elecciones determinan el conjunto activo de validadores y asignan stake nominador en cada era.

Ciclo de elección y tiempos: En Polkadot, una era dura ~24 horas. El conjunto activo de validadores para la siguiente era se calcula en la fase final de la era actual y se activa al cambio; las recompensas se calculan por era.

Participación de nominadores: Un nominador puede apoyar hasta 16 validadores. El algoritmo puede asignar el stake de un nominador solo a un subconjunto, buscando un conjunto bien respaldado; no todos los validadores nominados reciben respaldo en la solución final.

Cómo se eligen los validadores (objetivo y algoritmo): Las elecciones de validadores optimizan tres metas: (1) maximizar stake total que asegura el conjunto, (2) maximizar el stake mínimo de cualquier validador electo y (3) minimizar la varianza de stake en el conjunto. Polkadot computa soluciones off-chain y las envía en cadena mediante el Election Provider (multi-fase), con fases firmadas y no firmadas y un fallback en cadena si es necesario. El algoritmo implementa reglas proporcionales derivadas de Phragmén, resueltas off-chain mediante el Election Provider multiphase.

Asignación de stake y recompensas (en resumen): Una vez elegidos los ganadores, la solución detalla cómo se distribuye el stake de los nominadores entre los validadores. Los validadores son pagados por era según actividad, y los nominadores vía su(s) validador(es) respaldado(s). Los detalles operativos están en la sección de staking.

Responsabilidad: Como los nominadores activamente respaldan validadores, pueden ser “slashed” si el validador al que ayudaron a entrar en el conjunto activo comete ciertas faltas. Para condiciones y porcentajes, ver la sección dedicada a Slashing.

Para tiempos de desbloqueo, pools y mecánica de recompensas, continuar en las secciones de staking; aquí nos centramos en el modelo de elección y selección de validadores.

Slashing es una penalización on-chain aplicada cuando un validador viola las reglas de consenso. Quema un porcentaje del stake asignado a ese slot (self-bond del validador más cualquier stake de nominadores asignado). El tamaño depende de la ofensa; los fondos slasheados van al Tesoro de Polkadot. Los nominadores son penalizados solo si su stake respaldó al validador infractor en ese momento.

Faltas que pueden activar slashing (ejemplos): Polkadot enumera las ofensas de los validadores y asocia una respuesta típica: Algunas representativas:

• Equivocación (BABE/GRANDPA/BEEFY): doble firma de bloques o votos. Slashing entre 0.01%–100% según severidad y número de validadores implicados; el validador es deshabilitado.
• Avalar bloque de parachain inválido: un para-validador avaló un bloque inválido. Slashing 100%; deshabilitación.
• Voto ForInvalid: “secondary checker” votó por un bloque inválido. Slashing 2%; deshabilitación.
• Voto AgainstValid: votó en contra de un bloque válido. 0% slashing (sin pérdida de stake) pero se aplica deshabilitación.

No disponibilidad vs slashing: Fallos rutinarios suelen llevar a chilling forzado (validador detenido), no slashing. En Polkadot, un slashing por “offline” solo se da si ocurre un evento a nivel de red—por ejemplo, ≥10% del conjunto activo desconectado simultáneamente. La guía de soporte señala que el “offline” prolongado (alrededor de 4h) normalmente produce chilling, no slashing.

Quién paga y cuánto: El slashing es un porcentaje sobre el stake expuesto en el slot del validador (self-bond + parte de cada nominador asignada a ese validador). Las pérdidas de los nominadores son proporcionales a la exposición con el validador sancionado; el stake con otros validadores no se ve afectado. Este modelo busca incentivar la diversificación.

Aplicación, demora y reversos: Polkadot aplaza muchas penalizaciones por aproximadamente un periodo de desbloqueo (~28 días). Durante esa ventana, la gobernanza puede cancelar un slashing si deriva de un bug o similar; de lo contrario, se aplica antes de poder retirar fondos al hacer unbond.

Destino de los fondos slasheados: Todos los DOT slasheados se acreditan al Tesoro en cadena, que financia iniciativas vía OpenGov.

Relación: ver la sección NPoS para selección de validadores y asignación de stake; para unbonding y pools, ver staking.

Al dejar de hacer staking, los DOT bonded pasan a "desbloqueando" y serán retirables solo después de pasar el periodo de unbonding de 28 días. Debes ejecutar Withdraw Unbonded para hacerlos transferibles. (Kusama usa 7 días.)

Excepción: Fast Unstake. Si tu cuenta no estuvo expuesta a ningún validador activo durante las últimas 28 eras, puedes usar Fast Unstake y saltarte la espera de 28 días. Si estuviste expuesto, aplicará el periodo normal.

Pools de staking vs nominación directa

Requisitos de entrada & elegibilidad para recompensas:

• Nominación directa (solo): para ganar recompensas, el monto en staking debe superar el umbral dinámico de nominación activa; éste varía con el tiempo.
• Pools de nominación: diseñados para permitir la participación de pequeños holders; las guías oficiales indican que desde 1 DOT puedes ganar en pools (sujeto a tamaño y actividad del pool).

Control & custodia:

• Directo: eliges los validadores tú mismo.
• Pool: tus DOT permanecen en tu cuenta (bonded), pero el nominador del pool elige validadores; una mala selección afecta recompensas y compartes riesgo de slashing.

Operación (ingreso, cambio, salida):

• Tiempo de unbonding: ambos respetan 28 días de desbloqueo en Polkadot. La salida del pool también espera 28 días antes de poder retirar.
• Cambiar de pool: primero hay que hacer unbond (28 días en Polkadot; sin recompensas durante este tiempo).
• Rebond durante unbonding: nominadores directos pueden rebond en cualquier momento antes de que finalicen los 28 días; los miembros de pools no pueden rebond durante el periodo.
• Gestión de recompensas: al deshacer el bonding en un pool, las recompensas pendientes se reclaman automáticamente a tu balance transferible al retirar. Algunos pools ofrecen auto-compound; es opcional.

Actualmente se puede votar en OpenGov mientras se tiene staking en un pool, y también se puede ingresar a un pool con tokens ya bloqueados para gobernanza. (Esto cambió respecto a limitaciones previas.)

Para penalizaciones por comportamiento de validadores, ver Slashing.

Depósito existencial (ED) y mínimos de cuenta:

• ED en Relay Chain: 1 DOT para mantener una cuenta activa en Polkadot. Si el saldo libre cae por debajo, la cuenta puede ser eliminada (“reaped”) y el saldo residual se pierde.
• ED en Asset Hub: 0.01 DOT (cadena específica y establecida por gobernanza). Los activos allí pueden ser suficientes (no se requiere DOT) o no suficientes (la cuenta debe cumplir el ED de DOT).

Protección keep-alive: Wallets como Polkadot-JS activan "keep alive" por defecto: una transferencia que deje tu cuenta por debajo del ED se bloquea. Puedes desactivar esta protección para enviar el saldo completo y eliminar (“reap”) la cuenta emisora.

Modelo de comisiones en la Cadena de Relevo:

Polkadot utiliza un sistema de comisiones basado en peso. La comisión de una transacción es:

• Componente base (sobrecarga para cualquier extrinsic)
• Comisión por longitud (según el tamaño en bytes)
• Comisión por peso (según la carga de ejecución de la llamada)
• Propina opcional (definida por el usuario para prioridad de inclusión)
• Un multiplicador dinámico ajusta las comisiones ligeramente según la saturación reciente (congestión).

Cómo ver/estimar comisiones: Wallets y SDKs muestran una estimación antes de firmar (por ejemplo, paymentInfo en polkadot.js). Las comisiones se deducen del saldo transferible (no de fondos bondados).

Notas prácticas:

• Reactivar una cuenta eliminada: basta transferir al menos el ED de la cadena (por ejemplo, 1 DOT en Relay Chain).
• ED por cadena: el ED varía según la cadena; el de Asset Hub es menor que el de la Cadena de Relevo. Consulta valores actuales en la documentación oficial.
• Movimientos entre cadenas: operaciones XCM (teleports, por ejemplo) también cobran una comisión de destino y no aplican keep-alive; asegúrate de que tu saldo tras la comisión cumple el ED en la cadena de destino. Ver la sección XCM para mecánica.

Para mínimos de staking y tiempos de unbonding, ver staking; aquí nos centramos en comisiones y mínimos a nivel de cuenta.

OpenGov es el sistema de gobernanza en cadena de Polkadot. Las propuestas (“referendos”) son vinculantes: una vez que un referendo es aprobado, se ejecuta automáticamente en cadena tras su periodo de implantación. Pueden correr múltiples referendos en paralelo.

Tracks y orígenes: Cada referendo se presenta en un track que corresponde a un origen (nivel de privilegio necesario para la acción). Cada track define: el depósito de decisión requerido, ventanas temporales (preparar/decidir/confirmar/implantar), curvas de aprobación/soporte (umbrales a cumplir) y normalmente una capacidad para cuántos pueden estar decidiéndose a la vez. Los tracks de alto privilegio (como Root) tienen umbrales y ventanas mayores que los de bajo impacto (ej. Pequeño Tipper).

Algunas llamadas pueden ser incluidas por la Polkadot Fellowship y ejecutadas por el track Whitelisted Caller, que usa parámetros más rápidos una vez aprobado el referendo. Los comportamientos de tracks y ejemplos se documentan en la guía “origin” de OpenGov.

Voto y convicción: Los titulares votan A Favor/En Contra/Abstención con DOT. Pueden aplicar convicción (un multiplicador por tiempo bloqueado) para aumentar el poder de voto; los locks empiezan al acabar el referendo y terminan tras el periodo elegido. OpenGov permite diferentes convicciones en referendos simultáneos.

Delegación y multi-delegación: Si no se quiere votar directamente, se puede delegar el poder de voto. OpenGov admite delegación por track: puedes delegar distintos montos (y convicciones) a diferentes delegados en diferentes tracks. No puedes delegar en un track donde ya tienes votos activos (o una delegación) hasta liberarlos. Las interfaces oficiales permiten elegir track y convicción al configurar delegaciones.

Ciclo de vida de un referendo (en resumen):

• Presentación & periodo de preparación – el referendo se presenta a un track; votación puede abrirse, pero los votos no cuentan hasta después del periodo de preparación. Debe hacerse el depósito de decisión para que entre en la etapa de decisión.
• Periodo de decisión – el ítem está en decisión activa. Para aprobarse deben cumplirse las curvas de aprobación y soporte del track.
• Periodo de confirmación – los umbrales deben mantenerse un mínimo periodo de confirmación.
• Periodo de implantación – una vez confirmado, la llamada se cola y ejecuta en cadena según el retraso de implantación del track.

Cualquier titular de DOT puede participar en OpenGov: puedes proponer referendos, votar directamente o delegar poder de voto. Las actividades suceden en “tracks” que definen el origen (privilegio), depósito de decisión requerido, umbrales y ventanas temporales. Los parámetros varían y los define la gobernanza.

Proponer (crear un referendo):

1. Elige el track adecuado según la acción que desees (Root para acciones de alto impacto, Tippers/Spenders para temas del tesoro, etc).
2. Presenta el referendo y asegúrate de depositar el monto de decisión; el depósito se registra en cadena y es necesario para que el ítem entre en decisión tras el periodo de entrada. Los depósitos aparecen por referendo en UIs y suelen ser retornables según las reglas del track.

Requisitos: una cuenta Polkadot con DOT suficiente para pagar la comisión y el depósito de decisión del track. La identidad en cadena es opcional pero aporta credibilidad; establecerla requiere depósito retornable y tasa de registro en la parachain People.

Votar (participación directa):

• Opciones: A Favor, En Contra, Abstención, Split (reparto entre A Favor/En Contra), o SplitAbstain (entre todos).
• Voto con convicción: se pueden bloquear DOT más tiempo para multiplicar el peso; los locks comienzan tras finalizar el referendo y expiran según la convicción. Los locks pueden solaparse, permitiendo que el mismo saldo asegure varios votos o sea usado en staking. También puedes retirar tu voto mientras el referendo esté activo para liberar el lock al momento; si no, limpia los locks caducados tras expirar.

DOT en staking o en pools también puede votar: OpenGov permite votar mientras se tiene staking directo o en pools, tras actualizaciones que lo permitieron.

Delegar (por track, multi-delegación): Si prefieres no votar en cada ítem, puedes delegar poder de voto. OpenGov admite multi-delegación por track: elige diferentes delegados para distintos tracks, con montos y convicciones propios. No puedes delegar un track donde tengas votos activos (o una delegación) hasta eliminarlos. Las delegaciones se gestionan en interfaces oficiales (Polkadot-JS, Polkassembly, Nova, PolkaGate).

Herramientas prácticas:

• Polkadot-JS UI: proponer, votar, delegar y limpiar locks caducados.
• Polkassembly/Subsquare/Nova/PolkaGate: explorar referendos, votar (incluido Split/Abstención), y configurar delegaciones por track.

Para umbrales, ventanas y montos de depósito, consulta el track específico al proponer o delegar; estos parámetros difieren y pueden variar por gobernanza.

El Tesoro es un fondo en cadena, controlado por OpenGov. Recibe entradas de forma automática y solo puede gastar mediante acciones aprobadas por gobernanza. Los fondos residen en una cuenta del sistema; ninguna cuenta externa puede moverlos directamente.

Cómo se financia el Tesoro (entradas):

• Comisiones por transacciones: 80% de la comisión de cada extrinsic va al Tesoro; 20% a los productores de bloques.
• Emisión de DOT: 15% de la inflación anual va al Tesoro.
• Slashing: una parte de los fondos slasheados por faltas de validadores va al Tesoro.
• Transferencias directas: usuarios pueden transferir activos al Tesoro (raro, ej. reembolsos).

Cómo se gasta (salidas):

• Propuestas de Tesoro (spends): la gobernanza aprueba referendos que transfieren fondos a un beneficiario. Los pagos se efectúan por periodos definidos; al final de cada periodo, una fracción de fondos no gastados se quema.
• Propinas (Tips): pagos pequeños y rápidos vía tracks Small/Big Tipper.
• Bounties & child bounties: un “bounty” reserva un fondo que los curadores reparten vía child bounties a tareas/eventos; útil cuando se requieren varios pagos. Los curadores depositan garantía, pueden recibir una comisión y gestionan los pagos dentro de la duración del bounty.

Tracks de gobernanza para Tesoro: OpenGov gestiona los fondos del Tesoro vía seis tracks, cada uno con su origen y parámetros: Treasurer, Big/Medium/Small Spender, y Big/Small Tipper. Los gastos grandes usan tracks más estrictos; las propinas son para premios menores.

Soporte para multi-activos: El Tesoro puede poseer y gastar activos distintos a DOT (ej. USDT/USDC) cuando estén en Asset Hub y la tasa de conversión sea definida por gobernanza en el track Treasurer. Los gastos multi-activos aprobados especifican activo, cadena y monto; se admiten gastos por hitos y ventanas manuales de retiro.

Sub-tesoros (delegación de presupuesto): El gobierno puede asignar parte del Tesoro a sub-tesoros ligados a colectivos o cadenas de sistema. Cada sub-tesoro sigue su propio reglamento, reduciendo la necesidad de muchos referendos en los tracks principales.

Para crear, votar u operar propuestas de Tesoro, véase OpenGov.

La Polkadot Fellowship es un colectivo en cadena de contribuidores técnicos que tutela los estándares técnicos y el runtime del protocolo. Opera en la cadena system Collectives y coordina tareas tanto en cadena como en repositorios públicos (ej. RFCs para cambios propuestos). La Fellowship mantiene el runtime de Polkadot y Kusama, pero no bloquea cambios de protocolo—cualquier titular de DOT puede proponer una actualización del runtime mediante Root en OpenGov.

Membresía y rangos: Los miembros de la Fellowship tienen rangos y las votaciones internas usan estos rangos para ponderar responsabilidad y revisión técnica. Hay dashboards públicos para ver rangos y actividad de la Fellowship.

Whitelisting & track Whitelisted Caller: Para acciones urgentes o de bajo riesgo (típicamente releases de runtime), la Fellowship puede whitelistear un hash de llamada. Así el track Whitelisted Caller en OpenGov puede despachar esa llamada con autoridad Root al pasar el referendo, usando tiempos más breves y curvas de aprobación/soporte diferentes a Root para proporcionar una vía rápida controlada a ítems auditados.

Cómo se aplican actualizaciones: En Polkadot, las actualizaciones del runtime solo se ejecutan mediante referendos Root o Whitelisted Caller. La Fellowship revisa y, donde proceda, whitelistea releases para ir por el track rápido; si no, pasan por Root estándar.

Proceso de desarrollo abierto: Propuestas y diseños técnicos se rastrean en el repositorio RFC público de la Fellowship; las señales Fellowship (aprobado/declinado) y decisiones en cadena están visibles para titulares y votantes.

Agile Coretime (blockspace como mercado)

Polkadot 2.0 reemplaza arrendamientos y crowdloans a largo plazo por un mercado de coretime. Los proyectos obtienen tiempo de ejecución en “cores” de la Cadena de Relevo vía dos vías:

• Bulk Coretime: una “región” mensual (~28 días, 5,040 fragmentos) vendida en la cadena especializada Coretime. La titularidad se registra como un activo no fungible y puede reasignarse o revenderse.
• Coretime instantáneo: ráfagas cortas que se compran de un pool cuando se necesitan (pago por uso).

Las ventas usan una “entrada descendente” (tipo holandés) en cada periodo; el precio regular lo ajusta la gobernanza hasta que refleje la demanda. Se prevé un mercado secundario para regiones. Los ingresos de coretime se queman según RFC de la Fellowship, así que la emisión neta es la emisión bruta menos lo quemado.

Impacto en costes: los equipos planifican gastos comprando solo la capacidad necesaria, con señales de precios claras y sin bloqueos de varios años. Las subastas/crowdloans se han retirado desde Agile Coretime.

Async Backing (mejoras de rendimiento y latencia)

Async Backing desacopla la producción de bloques de parachain del bloque más reciente en la Cadena de Relevo, permitiendo que los collators elaboren varios candidatos y solapen respaldo e inclusión. En la práctica esto:

• permite a las parachains crear bloques cada ~6s (vs 12s previo)
• aumenta la ventana de ejecución (~0.5s → ~2s), permitiendo bloques ~4× mayores
• produce hasta ~8× mayor capacidad y ~10× con PoV-reclaim (que ajusta el tamaño real de pruebas)

Estos cambios llegaron en 2024 (primero Kusama, luego Polkadot).

Impacto en rendimiento: mayor TPS sostenido e inclusión más rápida para parachains que lo habiliten; las cadenas que no necesitan la capacidad extra pueden sumarse más tarde.

Elastic Scaling (uso de varios cores por cadena)

Elastic Scaling permite a una sola cadena utilizar varios cores en paralelo (escalado vertical) en lugar de uno por parachain. Funciona con async backing y nuevos parámetros para collators/validadores, logrando así más rendimiento y menor latencia. A agosto de 2025, Elastic Scaling está finalizando para habilitación en mainnet vía OpenGov (primero Kusama, luego Polkadot).

Impacto en rendimiento: rollups/parachains con gran carga pueden distribuir trabajo en varios cores, mejorando el margen sin fragmentarse en varias cadenas.

Resumen de efectos:

• Costes & planificación: coretime predecible y de mercado reemplaza los arrendamientos largos; los equipos compran regiones mensuales o fragmentos instantáneos; los ingresos de coretime quemados compensan parte de la emisión.
• Rendimiento & latencia: async backing aumenta frecuencia y capacidad de bloque; elastic scaling agrega ejecución multi-core para incrementos adicionales. Juntos aumentan el throughput sostenido sin cambiar el modelo de seguridad compartida de Polkadot.

1. Construye tu cadena:

   • Usa el Polkadot SDK (Substrate + Cumulus) partiendo del template de parachain. Esto te da runtime basado en FRAME, nodo collator y hooks XCM listos para adaptar.
   • Conéctate localmente a una Cadena de Relevo y valida producción de bloques y XCM básicos; el tutorial oficial muestra cómo conectar una parachain local.

2. Demuestra en testnet y obtén un ParaID:

   • Prueba upgrades y XCM en Paseo (testnet comunitario con coretime).
   • Reserva un ParaID en la relay deseada vía el registro: primero reserve (con depósito según cadena), luego register tu código de validación (WASM) y genesis head. Los depósitos se configuran por cadena en el pallet registrar. (En testnet los docs dan los valores exactos; en mainnet los fija la gobernanza.)

3. Adquiere Coretime (Polkadot 2.0):

   • Bulk Coretime (“Región”): compra una región de ~28 días (5,040 fragmentos en un core), vendida en la cadena Coretime. La titularidad se rastrea on-chain y es transferible/revendible; ventas con entrada descendente hasta el “precio regular”.
   • Coretime instantáneo: capacidad breve y bajo demanda extraída de un pool si se necesitan ráfagas.
   • Contabilidad: los ingresos de coretime se queman (RFC-0010 Fellowship), así que los equipos presupuestan DOT; no hay lockup/crowdloan.

4. Regístrate y activa en la Relay Chain:

   • Con ParaID, runtime WASM y genesis head preparados, presenta el registro y activa tu cadena. En Polkadot, el onboarding rutinario usa el registrar; las cadenas del sistema (ej. Coretime, Asset Hub) se registran vía OpenGov (a menudo track Whitelisted Caller), como en el referendo de registro de Coretime.

5. Opera tu red:

   • Collators: ejecuta al menos dos collators fiables; escala y distribuye geográficamente según crezca la carga. (Los validadores están en la Relay Chain; las parachains aportan collators.)
   • XCM & HRMP: abre canales HRMP a tus pares (ej. Asset Hub) y configura XCM (activos aceptados para comisiones, ubicaciones de reserva). Para enrutamiento de DOT, consulta la guía sobre Asset Hub como reserva de DOT durante la migración.
   • Upgrades: lanza upgrades del runtime a través del gobierno de tu cadena; la Relay Chain los valida al ser incluidos. (Para parámetros de Relay y OpenGov, ver gobernanza.)

6. Rollup vs parachain (“rollup” aquí):

   • Los equipos suelen implementar “rollups” como parachains usando el SDK (liquidando y verificando en la Relay Chain) para heredar disponibilidad/validez y XCM. Si ofreces rollup-as-a-service en una parachain ya existente, coordinarás con el host en vez de comprar coretime tú; la ruta conectada a la Relay sigue los pasos señalados. (La arquitectura depende del proyecto.)

Requisitos mínimos (checklist)

Técnico:

• Runtime Polkadot SDK (WASM) + spec de cadena, genesis head, y ParaID.
• Nodos collator, endpoints RPC, telemetría/monitorización.
• Configuración XCM y mínimo un canal HRMP para integraciones.

Económico:

• Presupuesto en DOT para coretime (Bulk o Instantáneo) y comisiones por transacción; entiende que el gasto en coretime se quema.
• Depósito de registro para ParaID (el monto depende de la cadena).

Gobernanza:

• Ninguno para onboarding por registro más allá de la propia gobernanza de tu cadena; las chains de sistema se habilitan por OpenGov (ejemplo: registro Coretime).

DOT nativo vs DOT envuelto/derivado:

• DOT nativo reside en Polkadot (Relay Chain y chains de sistema como Asset Hub). Dentro de Polkadot, DOT se mueve vía XCM, sea por teleport (Relay ↔ Asset Hub para DOT) o mediante transferencias de reserva cuando DOT aparece en otras parachains. La gobernanza está migrando la localización de reserva de DOT usada en XCM de la Relay Chain a Asset Hub, así que las parachains deben tratar Asset Hub como reserva de DOT de ahora en adelante.
• DOT envuelto/derivado existe fuera de Polkadot (ej. en Ethereum) o como formas compatibles ERC-20 en un parachain EVM. En Moonbeam, DOT aparece como xcDOT, un XC-20: representación ERC-20 compatible cuyo DOT subyacente permanece bloqueado en una cuenta soberana en la cadena de reserva, y se usa la interfaz ERC-20 localmente.

XCM en Polkadot vs puentes a redes externas:

• XCM (ecosistema): formato de mensaje y patrones para mover activos entre Relay y parachains. Para DOT, los teleports están habilitados en la ruta Relay ↔ Asset Hub; los movimientos a otras parachains suelen usar transferencias de reserva, con la cadena reserva registrando el suministro total.
• Puentes (fuera de ecosistema): para llegar a redes como Ethereum, Polkadot usa puentes en Bridge Hub. Snowbridge es el puente oficial Polkadot↔Ethereum (con light-client). Actualmente acuña ERC-20 puenteados en el pallet ForeignAssets de Asset Hub y luego usa una transferencia de reserva XCM para enviar tokens a una parachain destino; así XCM y el puente colaboran.

Compatibilidad EVM en Moonbeam (XC-20s):

• Estándar XC-20: en Moonbeam, los activos cross-chain se exponen como XC-20s que implementan la interfaz ERC-20 (y Permit). Para DOT esto es xcDOT. Los desarrolladores usan XC-20s con herramientas Ethereum mientras Polkadot gestiona la reserva real vía cuentas soberanas.
• XC-20 local vs externo: los tokens cuya reserva es Moonbeam son XC-20 locales; activos como DOT son XC-20s externos cuyo saldo se mantiene canónicamente en su cadena de reserva (Relay/Asset Hub), con la representación ERC-20 circulando en Moonbeam.

Notas prácticas:

• Cuándo usar cada vía: usa XCM para movimientos internos (DOT entre Asset Hub y parachains). Usa un puente (ej. Snowbridge) para mover activos hacia/desde redes externas como Ethereum; los tokens puenteados son representaciones distintas, con modelos de confianza/riesgo diferentes al DOT nativo.
• Actualizaciones en marcha: la migración del DOT a Asset Hub como reserva está activa; parachains y apps deben actualizar configuraciones XCM para que los transfer y el registro sean canónicos. Las guías al usuario final se publican por Soporte y el foro de Polkadot.

Polkadot fue iniciado por la Web3 Foundation (W3F), una entidad sin ánimo de lucro suiza cuyo proyecto principal es Polkadot. El fundador de W3F es el Dr. Gavin Wood, quien escribió el whitepaper original de Polkadot en 2016 que describe el diseño multi-cadena heterogéneo.

El desarrollo del protocolo y runtime fue liderado por Parity Technologies, el equipo de ingeniería que trabajó con W3F para lanzar Polkadot a mainnet en 2020.

El equipo fundador de Polkadot se cita habitualmente como Gavin Wood, Robert Habermeier y Peter Czaban. El comunicado de lanzamiento de W3F nombra a Robert Habermeier como cofundador y desarrollador principal de Polkadot, y a Peter Czaban como cofundador de Polkadot y Web3 Foundation.

W3F inició el rollout de la red en vivo de Polkadot el 26 de mayo de 2020, tras varios años de desarrollo; las fases siguientes dieron el control a los tenedores de tokens y habilitaron la emisión de DOT en cadena. El funcionamiento de la oferta y la redenominación están explicados en secciones previas.