¿Qué es Polkadot (DOT)?

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.

¿Para qué se utiliza DOT?

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)?”*

¿Cómo funciona la emisión de DOT (inflación, emisiones y la redenominación de 2020)?

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.

¿Cuáles son las utilidades en cadena de DOT (staking, comisiones, gobernanza y depósitos)?

**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í.

¿Qué es la Cadena de Relevo y cómo se relaciona con las parachains?

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.

¿Qué es XCM/XCMP y cómo funcionan las transferencias entre cadenas en Polkadot?

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.*

¿Qué es Asset Hub (antes Statemint) y cuándo tiene sentido “teleportar” DOT?

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.

¿En qué se diferencia Polkadot de Kusama en objetivos y parámetros?

**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.

¿Qué es Nominated Proof-of-Stake (NPoS) y cómo son elegidos los validadores?

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.

¿Qué es slashing y cuándo pueden ser penalizados validadores y nominadores?

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.*

¿Cuál es el periodo de unbonding de DOT y cómo se compara el staking en pools con la nominación directa?

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.*

¿Cuáles son las comisiones típicas, mínimos y depósito existencial para las cuentas DOT?

**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.*

¿Qué es OpenGov y cómo funcionan los tracks, multi-delegaciones y referéndums?

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.

¿Cómo puede participar el usuario en la gobernanza (proponer, votar, delegar) y cuáles son los requisitos?

**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.

¿Cómo opera el Tesoro en cadena y qué tipos de gasto cubre?

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.*

¿Qué es la Polkadot Fellowship y qué rol juega en las actualizaciones?

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.

¿Qué cambia con Polkadot 2.0 (Agile Coretime, Async Backing, Elastic Scaling) y cómo afecta a costes y rendimiento?

**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.

¿Cómo puede un equipo lanzar una cadena o rollup en el ecosistema Polkadot usando Coretime y cuáles son los requisitos?

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).

¿Cómo interoperan los DOT con otras redes (DOT nativo vs DOT envuelto, XCM vs puentes, compatibilidad EVM vía Moonbeam)?

**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.

¿Quién creó Polkadot (DOT)?

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.*

Polkadot (DOT) Mercados

#	Instrumento	Intercambio	Puntuación de Referencia	Precio	Cambio 24h	Volumen 24h	Operaciones 24h	Apertura 24h	Máximo 24h
1	DOT-USDT DOTUSDT	binance	AA	1,19USDT	6,92%	8.736.552,58DOT	80.400	1,11USDT	1,20USDT
2	DOT-USDT DOT-USDT	kucoin	BB	1,19USDT	6,93%	7.606.948,49DOT	27.812	1,11USDT	1,20USDT
3	DOT-USDT DOT-USDT	okex	A	1,19USDT	7,00%	3.768.151,54DOT	77.213	1,11USDT	1,20USDT
4	DOT-USD DOT-USD	coinbase	AA	1,19USD	6,96%	2.909.122,26DOT	12.736	1,11USD	1,20USD
5	DOT-USD DOTUSD	kraken	AA	1,19USD	6,89%	1.879.476,86DOT	16.480	1,11USD	1,20USD
6	DOT-USDT DOTUSDT	bybit	A	1,19USDT	6,98%	1.878.286,85DOT	46.094	1,11USDT	1,20USDT
7	DOT-USDT DOT_USDT	gateio	A	1,19USDT	6,97%	1.850.588,40DOT	36.903	1,11USDT	1,20USDT
8	DOT-USDT DOT_USDT	whitebit	BB	1,19USDT	6,96%	1.812.889,37DOT	10.601	1,11USDT	1,20USDT
9	DOT-USDC DOTUSDC	binance	AA	1,19USDC	6,84%	1.532.609,52DOT	12.857	1,11USDC	1,20USDC
10	DOT-USDT DOTUSDT_SPBL	bitget	BB	1,19USDT	7,06%	779.841,14DOT	11.512	1,11USDT	1,20USDT
11	DOT-WBT DOT_WBT	whitebit	BB	0.01497WBT	7,08%	728.591,12DOT	4901	0.01398WBT	0.01513WBT
12	DOT-EUR DOTEUR	kraken	AA	1,06EUR	7,28%	670.980,56DOT	2341	0.9887EUR	1,07EUR
13	DOT-USDC DOT_USDC	whitebit	BB	1,19USDC	7,14%	611.523,36DOT	1620	1,11USDC	1,20USDC
14	DOT-USDT DOT_USDT	cryptodotcom	AA	1,19USDT	7,02%	507.367,11DOT	5595	1,11USDT	1,20USDT
15	DOT-USD DOT_USD	cryptodotcom	AA	1,19USD	6,91%	377.189,55DOT	4222	1,11USD	1,20USD
16	DOT-USDC DOT-USDC	okex	A	1,19USDC	6,98%	332.838,55DOT	3245	1,11USDC	1,20USDC
17	DOT-USDT DOTUSDT	kraken	AA	1,19USDT	7,02%	308.373,17DOT	1869	1,11USDT	1,20USDT
18	DOT-USD dotusd	bitstamp	AA	1,19USD	7,35%	301.016,40DOT	680	1,11USD	1,20USD
19	DOT-EUR DOT_EUR	whitebit	BB	1,06EUR	7,37%	288.928,10DOT	810	0.9883EUR	1,07EUR
20	DOT-TRY DOT_TRY	whitebit	BB	59,32TRY	7,44%	297.329,15DOT	357	55,21TRY	59,75TRY
21	DOT-EUR DOT-EUR	coinbase	AA	1,06EUR	6,93%	271.748,48DOT	2030	0.9892EUR	1,07EUR
22	DOT-TRY DOTTRY	binance	AA	58,90TRY	6,90%	256.486,56DOT	1528	55,10TRY	59,70TRY
23	DOT-GBP DOT-GBP	coinbase	AA	0.8878GBP	7,12%	197.260,32DOT	1425	0.8288GBP	0.8972GBP
24	DOT-USD DOTUSD	bitfinex	BB	1,19USD	6,72%	176.805,26DOT	889	1,11USD	1,20USD
25	DOT-USDC DOTUSDC	kraken	AA	1,19USDC	6,84%	148.152,27DOT	721	1,11USDC	1,20USDC
26	DOT-BTC DOTBTC	binance	AA	0.0₄1461BTC	7,58%	122.160,40DOT	525	0.0₄1358BTC	0.0₄1469BTC
27	DOT-BTC DOT_BTC	whitebit	BB	0.0₄1452BTC	7,00%	101.803,40DOT	592	0.0₄1357BTC	0.0₄1470BTC
28	DOT-USDT DOTUST	bitfinex	BB	1,19USDT	7,01%	91.488,28DOT	321	1,11USDT	1,20USDT
29	DOT-FDUSD DOTFDUSD	binance	AA	1,19FDUSD	6,92%	63.463,27DOT	680	1,11FDUSD	1,20FDUSD
30	DOT-USDC DOT-USDC	kucoin	BB	1,19USDC	6,56%	51.283,75DOT	433	1,11USDC	1,20USDC
31	DOT-EUR DOTEUR	binance	AA	1,06EUR	7,28%	31.273,95DOT	344	0.9890EUR	1,07EUR
32	DOT-GBP DOTGBP	kraken	AA	0.8839GBP	6,71%	28.433,52DOT	140	0.8283GBP	0.8930GBP
33	DOT-USD dotusd	gemini	A	1,18USD	7,02%	27.985,07DOT	168	1,11USD	1,20USD
34	DOT-USD DOTUSD	cexio	BB	1,19USD	7,07%	27.148,10DOT	9	1,11USD	1,19USD
35	DOT-BTC DOT-BTC	coinbase	AA	0.0₄1454BTC	7,07%	24.637,49DOT	570	0.0₄1358BTC	0.0₄1469BTC
36	DOT-EUR DOT-EUR	okex	A	1,06EUR	6,98%	20.288,18DOT	242	0.9895EUR	1,07EUR
37	DOT-USDC DOT_USDC	gateio	A	1,18USDC	6,53%	19.275,50DOT	198	1,11USDC	1,20USDC
38	DOT-USDT DOT-USDT	coinbase	AA	1,20USDT	7,68%	16.482,34DOT	145	1,11USDT	1,20USDT
39	DOT-EUR doteur	bitstamp	AA	1,06EUR	7,67%	15.545,33DOT	61	0.9852EUR	1,07EUR
40	DOT-USDC DOTUSDC	bybit	A	1,19USDC	7,27%	11.931,40DOT	263	1,11USDC	1,20USDC
41	DOT-BTC DOTXBT	kraken	AA	0.0₄1461BTC	7,95%	9933,67DOT	109	0.0₄1353BTC	0.0₄1467BTC
42	DOT-BTC DOT-BTC	kucoin	BB	0.0₄1454BTC	7,07%	8443,56DOT	854	0.0₄1358BTC	0.0₄1469BTC
43	DOT-ETH DOTETH	kraken	AA	0.0₃4949ETH	8,01%	5016,18DOT	61	0.0₃4582ETH	0.0₃4985ETH
44	DOT-TRY DOT-TRY	okex	A	59,53TRY	8,08%	3645,44DOT	31	55,08TRY	59,53TRY
45	DOT-USDC DOTUSDC	bullish	AA	1,20USDC	1,13%	2537,36DOT	21	1,18USDC	1,20USDC
46	DOT-JPY DOTJPY	kraken	AA	173,81JPY	-0,44%	0DOT	0	174,58JPY	174,58JPY
47	DOT-BTC DOT_BTC	gateio	A	0.0₄1398BTC	-0,21%	795,36DOT	6	0.0₄1401BTC	0.0₄1401BTC
48	DOT-USDT DOTUSDT	cexio	BB	1,20USDT	6,46%	310,16DOT	5	1,12USDT	1,20USDT
49	DOT-USDC DOTUSDC	cexio	BB	1,19USDC	3,02%	72,38DOT	3	1,16USDC	1,19USDC
50	DOT-EUR DOTEUR	cexio	BB	1,01EUR	-4,35%	23,96DOT	1	1,05EUR	1,05EUR

PrevPage 1 of 3Next