Polkadot

Polkadot est un protocole réseau multi-chaînes qui connecte de nombreuses blockchains spécialisées (« parachains ») à une chaîne centrale appelée Relay Chain. La Relay Chain fournit une sécurité partagée, un consensus et une interopérabilité cross-chain, tandis que les parachains fonctionnent en parallèle et communiquent via la messagerie cross-consensus (XCM) de Polkadot. Cette conception vise la scalabilité et la composabilité entre les chaînes au sein d’un seul réseau.

Dans l’architecture de Polkadot, les parachains sont des chaînes applicatives dont les blocs sont produits par des collators et validés par les validateurs de la Relay Chain. En se connectant à la Relay Chain, les parachains héritent de la sécurité économique de l’ensemble des validateurs et peuvent échanger des messages avec d’autres chaînes via XCM. Des bridges peuvent aussi relier Polkadot à des réseaux externes—par exemple, Ethereum via Snowbridge ; la connectivité avec Bitcoin s’effectue via des parachains comme Interlay plutôt qu’un bridge light-client natif. Pour le détail opérationnel de la messagerie cross-chain, voir la section dédiée au XCM.

DOT est le jeton natif du réseau sur la Relay Chain. Il sous-tend trois fonctions principales : la gouvernance du protocole, le staking pour la sécurité du réseau, et le bonding (le mécanisme historiquement utilisé pour ajouter des chaînes).

Le modèle de ressources de Polkadot évolue avec « Polkadot 2.0 ». Plutôt que de louer des slots longue durée, les projets accèdent à la puissance de calcul de la Relay Chain via le coretime (temps sur les virtual cores). Le coretime est alloué aux chaînes système par la gouvernance et acquis par les autres chaînes sur un marché ouvert.

DOT est le jeton natif de la Relay Chain de Polkadot. Il est le socle des fonctions clés du réseau :

Sécurisation du réseau via le staking (NPoS) : Les détenteurs de DOT peuvent nommer des validateurs ou opérer un validateur pour contribuer à la finalisation des blocs et l’intégrité du système. Les DOT stakés garantissent le comportement des validateurs et donnent droit à des récompenses, tandis que les comportements fautifs sont sanctionnés (slashing). Voir : Nominated Proof-of-Stake et Slashing pour les mécanismes et risques.

Gouvernance on-chain (OpenGov) : DOT sert à proposer et voter des référendums sur divers « tracks », déléguer des pouvoirs de vote, et participer aux mises à jour du protocole et aux décisions relatives aux chaînes système. Voir : OpenGov et Comment participer à la gouvernance… pour les détails sur les tracks, les dépôts et la délégation.

Frais de réseau et dépôts exigés : Les transactions sur la Relay Chain s’acquittent de frais en DOT, et les comptes doivent maintenir un solde minimum (dépôt existentiel) pour rester actifs. Certaines actions on-chain nécessitent aussi des dépôts en DOT remboursables (ex : identité). Voir : Quelles sont les utilités on-chain du DOT… pour les types de frais et de dépôts.

Acquisition du coretime de la Relay Chain (“coretime”) dans Polkadot 2.0 : Les projets obtiennent du temps d’exécution sur les cores de la Relay Chain par l’achat de coretime en DOT ; ces DOT sont brûlés. Ce modèle remplace la location de slot longue durée/crowdloans. Voir : Qu’est-ce qui change avec Polkadot 2.0… et Comment lancer une chaîne… pour l’économie et les possibilités de déploiement.

Financement système via le Trésor on-chain : Les entrées du Trésor (part des récompenses de blocs, frais, tips, slashing) sont en DOT et peuvent être utilisées—via la gouvernance—pour financer des propositions approuvées. Voir : Comment fonctionne le Trésor on-chain… pour le processus et le périmètre.

Mouvements cross-chain et utilisation dans l’écosystème : DOT peut être téléporté entre la Relay Chain et les parachains système comme Asset Hub via XCM ; les transferts cross-chain peuvent entraîner des frais sur la chaîne source comme sur la destination. Certaines parachains/applications acceptent le DOT nativement ; d’autres requièrent une version bridgée/wrappée. Voir : Asset Hub et Comment DOT interopère avec d’autres réseaux… pour les spécificités et les mises en garde.

Si vous cherchez le modèle précis de frais, les minimums, les dépôts et les flux de staking, poursuivez avec « Quelles sont les utilités on-chain du DOT (staking, frais, gouvernance et dépôts) ? »

DOT utilise une émission annuelle fixe démarrée à ~8 % de l’offre d’origine, se stabilisant à ~120 millions de DOT émis chaque année, ce qui fait décroître le taux d’inflation au fil du temps à mesure que l’offre totale augmente. De chaque émission annuelle, 15 % sont frappés directement pour le Trésor, 85 % financent les récompenses de staking (versées à chaque ère). Ces paramètres ont été introduits par OpenGov (Référendum #1139) et implémentés dans le code runtime.

Cadence et distribution des émissions : De nouveaux DOT sont créés en continu et comptabilisés en fin de chaque ère (~24h sur Polkadot), puis distribués aux validateurs et nominateurs selon le mécanisme de récompense de staking ; la part Trésor (15 %) est directement créditée sur son compte système. Avec le modèle à émission fixe, cette répartition n’est plus ajustée selon la participation au staking, simplifiant la distribution par rapport à l’ancien design.

Burns compensant l’émission brute : Deux sources réduisent la croissance nette de l’offre : les achats de coretime (Polkadot 2.0) sont brûlés, et le Trésor peut aussi brûler des fonds par la gouvernance. Ainsi, l’inflation annuelle effective correspond à l’émission fixe (~120M DOT) moins la quantité brûlée sur l’année.

En quoi cela diffère-t-il de l’ancien modèle : Avant le changement de 2024, Polkadot visait environ 10 % d’inflation annuelle, avec les récompenses ajustées autour d’un taux de staking « idéal », tout écart alimentant le Trésor (« inefficience de staking »). Le nouveau modèle supprime cet ajustement et le remplace par la part fixe de 15 % pour le Trésor mentionnée ci-dessus.

Pas de plafonnement dur (sous réserve de gouvernance) : DOT n’a pas d’offre maximale inscrite dans le protocole. Les paramètres d’émission peuvent changer via la gouvernance on-chain ; les ajustements 2024–2025 sont passés par ce processus. Pour la configuration courante et les éventuelles propositions actives, consultez les référendums OpenGov concernés.

Redenomination de 2020 (changement d’unité uniquement) : Le 21 août 2020 (« Denomination Day, » bloc #1 248 328), le DOT a été redenominé à 1 ancien DOT = 100 nouveaux DOT. Il s’agit d’un changement d’unité, sans effet sur la valeur ou la propriété : les soldes et les prix ont été multipliés par 100, et l’unité de base (Planck) par DOT est passée de 10¹² à 10¹⁰ Plancks. L’économie du réseau est restée inchangée.

Staking (sécurisation du réseau) : Le DOT peut être bonded pour sécuriser le réseau selon le Nominated Proof-of-Stake (NPoS). Les détenteurs peuvent nominer des validateurs ou opérer un validateur ; les récompenses sont versées à chaque ère, les comportements fautifs sont sanctionnés (slashing). L’ensemble des validateurs de Polkadot est élu à l’aide d’algorithmes basés sur Phragmén et les utilisateurs peuvent aussi participer via des pools de nomination, permettant un accès plus simple et avec des montants moindres. Les détails techniques (délais de débonding, conditions de slashing, modalités d’élection) sont abordés dans les sections NPoS et Slashing.

Frais (paiement des transactions) : Sur la Relay Chain, les transactions paient des frais en DOT prélevés sur le solde transférable (pas sur les fonds bonded). Les frais comprennent une base, un frais de longueur, un composant proportionnel au poids, plus un tip optionnel pour augmenter la priorité d’inclusion ; un multiplicateur de congestion peut ajuster les frais selon le remplissage récent des blocs. En pratique, les portefeuilles affichent le montant prévisionnel avant signature.

Les actions cross-chain peuvent entraîner des frais sur la source comme la destination. Par exemple, téléporter du DOT entre la Relay Chain et Asset Hub implique un frais à l’arrivée, sans le garde-fou “keep-alive” : il faut donc maintenir un solde suffisant sur la chaîne de destination pour éviter la suppression du compte.

Gouvernance (OpenGov) : Le DOT sert à proposer et voter des référendums dans OpenGov. Les propositions requièrent un dépôt de décision ; le vote utilise des soldes pondérés par conviction (tokens bloqués dans le temps pour augmenter la puissance de vote). Les utilisateurs peuvent aussi déléguer leur pouvoir de vote, y compris par track. Les explications pratiques (vote, délégation, gestion des locks) sont détaillées dans les sections OpenGov.

Dépôts et soldes minimums : Polkadot impose un dépôt existentiel (ED)—un solde minimum pour maintenir un compte actif. Si le solde libre passe sous l’ED, le compte peut être supprimé (reaped) et toute poussière brûlée. La valeur courante est : 1 DOT sur la Relay Chain, 0,01 DOT sur Asset Hub (valeurs propres à chaque chaîne et susceptibles d’évolution). Des contrôles “keep-alive” préviennent la suppression accidentelle durant les transferts classiques ; les téléportations ne bénéficient pas de ce garde-fou.

Certaines fonctionnalités requièrent des dépôts réservés qui sont bloqués tant que la fonctionnalité est active, puis restitués quand elle est supprimée. Exemple : l’identité on-chain, maintenant gérée sur la parachain People, nécessite un dépôt remboursable et un frais de registraire ; libérer l’identité annule le dépôt (les fonds restent sur People jusqu’à téléportation retour). Les dépôts liés à la gouvernance (ex : decision deposit) sont détaillés dans Gouvernance.

La Relay Chain est la chaîne centrale de Polkadot. Elle apporte la sécurité partagée et le consensus global du réseau, tout en restant minimale dans la logique applicative : elle existe pour accueillir et coordonner de multiples chaînes parallèles plutôt que fournir directement des fonctionnalités utilisateur. Selon la conception de Polkadot, la Relay Chain garantit une vision unique et cohérente de l’état global entre les différents shards connectés (« parachains »).

Les parachains sont des chaînes applicatives spécialisées qui tournent en parallèle et se connectent à la Relay Chain. Elles maintiennent leur état et leur logique propres mais héritent la sécurité du set de validateurs de la Relay Chain. Les collators de parachain recueillent les transactions et produisent des blocs candidats avec preuves ; les validateurs de la Relay Chain vérifient ensuite la disponibilité et la validité avant que les transitions d’état de la parachain ne soient acceptées dans l’état partagé. Cette séparation permet aux parachains de se spécialiser tandis que la Relay Chain assure le consensus, la finalité et la coordination.

Les parachains peuvent communiquer entre elles via la messagerie cross-consensus (XCM) de Polkadot, la Relay Chain assurant la couche de routage/vérification pour un échange sécurisé des données et des actifs. Les mécanismes profonds du XCM sont traités dans la section XCM.

Polkadot comprend aussi des parachains système (system chains) pour des fonctions cœur du protocole—ex : Asset Hub pour les actifs fongibles et non fongibles—déplaçant ainsi des fonctionnalités hors de la Relay Chain tout en conservant la sécurité partagée. Ces chaînes système sont attribuées via la gouvernance on-chain.

Avec Polkadot 2.0, les projets accèdent aux ressources de la Relay Chain via les cores (coretime). Les chaînes système reçoivent des cores par la gouvernance, les autres chaînes les obtiennent sur le marché ouvert ; la relation fondamentale reste : les parachains exécutent leur logique, la Relay Chain valide et finalise leurs transitions d’état.

XCM (Cross-Consensus Messaging) est le langage de Polkadot pour transmettre des messages d’intention entre systèmes de consensus (Relay Chain, parachains, et—via bridges—autres réseaux). Il spécifie ce qui doit se passer, indépendamment de tout runtime pallet particulier. XCMP (Cross-Chain Message Passing) est le protocole de transport des messages parachain↔parachain ; les flux relay↔parachain utilisent UMP (upward) et DMP (downward). Les messages sont asynchrones.

Transferts : deux modèles XCM natifs

• Téléportation (Teleport) : le jeton est déplacé directement entre deux locations de confiance sans garde de réserve. Cas typique : DOT entre la Relay Chain et Asset Hub. Les téléports nécessitent une configuration de confiance mutuelle sur les deux chaînes.
• Transfert basé sur la réserve : la chaîne de réserve de l’actif suit l’offre totale ; l’origine verrouille/brûle une représentation, la réserve ajuste les soldes, et la destination crédite une nouvelle représentation. C’est le modèle courant pour le déplacement d’actifs vers des parachains qui ne sont pas la réserve.

En pratique, beaucoup d’équipes préfèrent les transferts par réserve pour la sécurité et la clarté comptable ; les téléports sont généralement activés uniquement pour des routes de confiance forte (pour DOT : Relay Chain ↔ Asset Hub).

Canaux et routage : Les messages parachain↔parachain circulent sur des canaux. Actuellement, la plupart des réseaux utilisent HRMP (“Horizontal Relay-routed Message Passing”), qui propose la même interface que XCMP mais stocke les messages sur la Relay Chain ; XCMP est le but final plus efficace. Les canaux HRMP sont unidirectionnels ; une interconnexion complète bidirectionnelle requiert un canal dans chaque sens, devant être ouverts/acceptés par les deux chaînes.

Frais, poids et exécution : Un XCM doit « acheter du temps d’exécution » sur la chaîne de destination (payer pour le poids, c’est-à-dire les ressources de calcul). Les actifs acceptés pour paiement des frais, et le poids exigé, dépendent des politiques de la chaîne cible. Les extrinsics standards incluent teleport_assets et reserve_transfer_assets, qui précisent la destination, le bénéficiaire, l’actif et l’item de frais.

Pour l’utilisateur, les points d’attention :

• Dépôt existentiel & keep-alive : les téléports ne garantissent pas le “keep-alive”. Assurez-vous que votre solde, après les frais, reste au-dessus du dépôt existentiel de la chaîne de destination, sinon le compte peut être supprimé. Les téléports impliquent aussi un frais sur la chaîne de destination.
• Asynchronie & ordre : la livraison n’est pas instantanée ; l’ordre n’est garanti qu’à l’intérieur d’un même canal.

Pour les ponts vers des réseaux externes et les DOT wrappés, voir la section interopérabilité plus loin.

Asset Hub est la parachain système de Polkadot (anciennement « Statemint ») dédiée à l’émission, la détention et le transfert d’actifs, dont les tokens fongibles et les NFT. Conçue comme une chaîne « bien public », elle propose des frais plus bas et un dépôt existentiel plus petit que la Relay Chain, et utilise le DOT comme jeton natif pour frais et dépôts. Sur Polkadot Asset Hub, le dépôt existentiel est de 0,01 DOT (dix fois moins que la Relay Chain) ; les actifs peuvent être déclarés suffisants (pas besoin de DOT pour les détenir) ou non suffisants (le compte doit avoir le dépôt en DOT).

Concrètement, Asset Hub permet aux utilisateurs/équipes de créer des actifs, gérer des métadonnées et réaliser des transferts ; les guides officiels la recommandent aussi pour la gestion des tokens non natifs et des NFT. (Sur Kusama, Asset Hub permet l’exécution de smart contracts ; sur Polkadot, les smart contracts natifs EVM/PVM sont prévus sur la chaîne système Polkadot Hub, pas sur Asset Hub.)

Dans quels cas téléporter du DOT est pertinent ?

La téléportation est la route XCM de confiance configurée entre Relay Chain ↔ Asset Hub pour le DOT. Elle est utile lorsque vous avez besoin de DOT spécifiquement sur Asset Hub, par exemple pour :

• Payer des frais réduits ou satisfaire au dépôt existentiel de 0,01 DOT pour détenir des actifs non suffisants sur Asset Hub ;
• Utiliser des fonctionnalités et applications présentes directement sur Asset Hub.

À connaître avant de téléporter :

• Un frais sur la chaîne de destination est déduit du montant téléporté ; le reste doit toujours être ≥ au dépôt existentiel cible, sinon les fonds sont perdus.
• Les téléports n’appliquent pas le “keep-alive”, donc vous devez vérifier, après frais, que le solde sur chaque chaîne reste au-dessus du dépôt existentiel si vous souhaitez garder le compte actif.
• Ne téléportez pas directement vers une adresse d’échange (la plupart des exchanges ne détectent pas les téléports).

Pour les mécaniques téléports vs réserve et le routage cross-chain plus large, voir la section XCM/XCMP. En cas de migration ou de maintenance planifiée sur Asset Hub, les téléports et transferts XCM peuvent être temporairement indisponibles ; vérifiez les avis Support pour le statut.

But et positionnement : Polkadot et Kusama sont deux réseaux indépendants avec tokens distincts (DOT, KSM) et code similaire. Kusama est le « canary network » : environnement réel où arrivent d’abord les nouveautés, avec un rythme plus rapide ; Polkadot privilégie la stabilité et la fiabilité pour les déploiements en production.

Cadence de gouvernance : Tous deux utilisent OpenGov, mais Kusama a généralement des délais plus courts (dépendants du track) de décision à confirmation/mise en œuvre, facilitant les upgrades rapides ; sur Polkadot, les délais sont plus longs. Ces paramètres sont propres à chaque track et modifiables par la gouvernance.

Délais de staking : La période de débonding est ~28 jours sur Polkadot vs ~7 jours sur Kusama. Les ères—pour les paiements aux validateurs—durent ~24h sur Polkadot, ~6h sur Kusama. Cela influe sur la fréquence des récompenses et la durée de blocage des fonds après débonding.

Solde minimum par compte (dépôt existentiel) : Pour un compte actif : 1 DOT requis sur Polkadot, 0,000333333 KSM sur Kusama (valeurs évolutives via gouvernance). Les parachains Asset Hub ont des minimums inférieurs.

Parcours d’upgrade : Les changements/protocoles majeurs sont testés sur Kusama d’abord, puis déployés sur Polkadot une fois éprouvés. Cela favorise l’agilité de Kusama tout en maintenant la prudence sur Polkadot.

Tous deux partagent le même modèle d’architecture (Relay Chain + parachains) et les outils OpenGov ; les différences ci-dessus reflètent les objectifs (vitesse vs stabilité) et paramètres d’exploitation (timers, minimums), pas la conception fondamentale.

NPoS est le modèle de staking de Polkadot : deux rôles sécurisent le réseau : les validateurs, qui produisent et valident les blocs, et les nominateurs, qui soutiennent les validateurs avec leurs DOT. Récompenses et risques de sanction (slashing) sont partagés si un validateur soutenu agit mal. Des élections composent le set de validateurs actifs et assignent le stake à chaque ère.

Cycle et timing des élections : Sur Polkadot, une ère dure ~24h. Le set de validateurs actifs de la prochaine ère est calculé vers la fin de l’ère courante, puis appliqué au changement d’ère ; les récompenses sont alors calculées.

Participation des nominateurs : Un nominateur peut soutenir jusqu’à 16 validateurs. L’algorithme d’élection peut n’allouer le stake d’un nominateur qu’à une partie de ces choix pour obtenir un ensemble équilibré et bien soutenu ; tous les validateurs nommés ne sont pas nécessairement soutenus in fine.

Élection des validateurs (objectif et algo) : Les élections optimisent trois objectifs : (1) maximiser le stake total du set, (2) maximiser le minimum par validateur élu, (3) minimiser la variance de stake entre les validateurs. Polkadot calcule les solutions off-chain et les soumet on-chain via l’Election Provider (multi-phase), avec des phases signées/non signées et une solution de secours on-chain si besoin. Le réseau utilise les règles proportionnelles issues de la recherche Phragmén, résolues off-chain par l’Election Provider multistage, remplaçant les précédents modèles séquentiels.

Assignment du stake et paiements (en résumé) : Une fois les élus désignés, la solution d’élection détermine comment chaque stake nominé est distribué entre les validateurs retenus. Les validateurs sont payés par ère selon leur activité, et les nominateurs via leurs validateurs soutenus. Les détails sur la distribution des récompenses figurent dans les sections staking.

Responsabilité : Les nominateurs encourent le slashing s’ils soutiennent activement un validateur fautif. Pour les conditions et pourcentages, voir la section dédiée au Slashing.

Pour débonding, pools et récompenses, voir les sections staking ; ici seul le modèle électoral est traité.

Le slashing est une pénalité on-chain lorsque qu’un validateur enfreint les règles du consensus. Un pourcentage du stake associé à son slot (bond propre et celui des nominateurs) est brûlé. Le taux dépend de la faute ; les fonds slashed vont au Trésor Polkadot. Les nominateurs sont impactés uniquement si leur stake soutenait le validateur sanctionné.

Exemples de fautes sanctionnées :

• Équivocation (BABE/GRANDPA/BEEFY) : double-signature de bloc/vote. Slash de 0,01% à 100% selon gravité et nombre de validateurs impliqués ; le validateur est désactivé.
• Backing d’un bloc parachain invalide : 100% slash ; désactivation on-chain.
• ForInvalid vote : secondary checker a validé un bloc invalide. Slash à 2% ; désactivation.
• AgainstValid vote : vote contre un bloc valide. 0% slash (pas de perte de stake), mais désactivation.

Indisponibilité vs slashing : Les indisponibilités sont en général sanctionnées par le chilling (arrêt du validateur) et non du slashing. Sur Polkadot, un slashing « offline » n’est envisagé que lors d’un événement réseau (≥10% du set de validateurs actifs offline simultanément). Les guides précisent que des outages « prolongées » (environ 4h) mènent en général au chilling, pas au slashing.

Qui paie, combien ? Les slashing sont un pourcentage du stake exposé du slot (bond propre + part du bond de chaque nominateur alloué à ce validateur). Les nominateurs perdent au prorata de leur exposition ; le stake soutenant d’autres validateurs n’est pas impacté. Cette approche favorise la diversification.

Application, délai et annulation : Polkadot différé souvent les slashing d’environ une période de débonding (~28 jours). Pendant ce délai, la gouvernance peut annuler un slashing si dû à un bug protocolaire ou cas avéré non fautif ; sinon il est appliqué avant retrait possible des fonds après débonding.

Utilisation des fonds slashed : Tous les DOT récupérés sont crédités au Trésor on-chain pour financer des initiatives via OpenGov.

Pour la sélection des validateurs et assignment du stake, voir la section NPoS ; pour le débonding et les pools voir les parties staking.

Quand vous arrêtez de staker, vos DOT bonded deviennent « en unlocking » et ne sont transférables qu’après la période d’unbonding de 28 jours. Il faut ensuite exécuter Retirer les DOT débondés (Withdraw Unbonded). (Kusama : 7 jours.)

Exception : Fast Unstake. Si votre compte n’a pas été exposé à un validateur actif durant les 28 dernières ères, vous pouvez utiliser Fast Unstake pour éviter les 28 jours d’attente. Si vous étiez exposé, la période classique s’applique.

**Pools de staking vs nomination directe **

Accès & éligibilité aux récompenses :

• Nomination directe (solo) : pour recevoir des récompenses, le montant bonded doit dépasser le seuil dynamique d’activation, qui évolue dans le temps.
• Pools de nomination : conçus pour l’accessibilité aux petits détenteurs ; les docs officielles indiquent qu’1 DOT suffit (sous réserve d’activité/pool).

Contrôle & conservation :

• Direct : vous choisissez vos validateurs.
• Pool : vos DOT restent sur votre compte (bonded), mais le nominator du pool choisit les validateurs ; des mauvais choix peuvent impacter vos récompenses et vous encourez toujours le slashing.

Opérations (rejoindre, changer, sortir) :

• Uniquement : les deux suivent la même période d’unbonding de 28 jours sur Polkadot. Les sorties de pool attendent aussi 28 jours avant retrait.
• Changement de pool : il faut d’abord unbond (28 jours sur Polkadot ; pas de récompense durant cette période).
• Rebonding en période de débonding : les nominateurs directs peuvent rebond à tout moment avant la fin ; les membres de pool ne le peuvent pas pendant.
• Gestion des récompenses : un membre de pool qui unbond voit ses récompenses en attente automatiquement transférées sur son solde transférable au retrait. Certains pools proposent auto-compound ; c’est en option.

Les guides précisent que vous pouvez voter dans OpenGov pendant un staking via pool, et aussi rejoindre un pool avec des tokens déjà verrouillés pour la gouvernance. (Ceci a changé par rapport aux limitations initiales.)

Pour les pénalités liées au comportement du validateur, voir la section Slashing.

Dépôt existentiel (ED) et minimums de compte :

• Relay Chain : il faut 1 DOT pour maintenir un compte actif sur Polkadot. Si le solde libre chute sous 1 DOT, le compte peut être supprimé et toute poussière perdue.
• Asset Hub : 0,01 DOT sur Asset Hub Polkadot (spécifique à la chaîne/au paramètre de gouvernance). Les actifs peuvent être suffisants (pas besoin de DOT pour les posséder) ou non suffisants (dépôt DOT requis).

Protection keep-alive : Les portefeuilles comme Polkadot-JS activent keep-alive par défaut : un transfert qui réduirait le solde sous l’ED est bloqué. Vous pouvez le désactiver pour vider un compte et le supprimer.

Modèle de frais sur la Relay Chain :

Polkadot utilise un système de frais pondérés. Le coût d’une transaction est la somme des :

• Composant de base (pour toute extrinsic)
• Frais de longueur (proportionnel à la taille du message)
• Frais de poids (proportionnel à la complexité d’exécution)
• Tip optionnel (pour prioriser l’inclusion)
• Un multiplicateur dynamique ajuste les frais à la hausse ou à la baisse selon le degré de congestion récent.

Visualisation/estimation des frais : Les portefeuilles/SDK affichent l’estimation avant signature (ex : paymentInfo dans polkadot.js). Les frais sont prélevés du solde transférable (pas sur les fonds bonded).

En pratique :

• Réactiver un compte supprimé : il suffit de transférer au moins l’ED de la chaîne (ex : 1 DOT sur la Relay Chain).
• ED par chaîne : l’ED varie selon la chaîne ; sur Asset Hub il est plus bas que sur la Relay Chain. Consultez les docs de support officielles pour les valeurs actuelles.
• Transferts cross-chain : Les opérations XCM (ex : téléportation) débloquent aussi un frais sur la chaîne de destination et ne protègent pas via keep-alive ; veillez à ce que le solde, après frais, respecte l’ED de la destination. Voir la section XCM pour les détails.

Pour les minimums du staking et délais d’unbonding, voir les parties staking ; ici seuls les frais/minimums compte sont couverts.

OpenGov est le système de gouvernance on-chain de Polkadot. Les propositions (« référendums ») sont contraignantes : une fois accepté, un référendum est mis en œuvre automatiquement sur la chaîne après son délai d’Enactment. Plusieurs référendums peuvent être actifs en parallèle.

Tracks et origines : Chaque référendum est soumis sur un « track » lié à une origine (le privilège nécessaire). Chaque track définit : le dépôt de décision demandé, des fenêtres de temps (prepare/décision/confirmation/enactment), des courbes d’approbation/support (seuils à atteindre), et rarement une capacité sur le nombre de référendums en phase de décision simultanée. Les tracks haut-privilege (Root, etc.) ont des seuils plus élevés et des délais plus longs que les tracks mineurs (Small Tipper, etc.).

Certains appels peuvent être whitelisted (« liste blanche ») par le Polkadot Fellowship, puis exécutés via le track Whitelisted Caller qui recourt à des paramètres accélérés après validation du référendum. Le comportement des tracks et leurs exemples figurent dans le guide OpenGov sur les « origines ».

Vote et conviction : Les détenteurs votent Aye/Nay/Abstain avec leurs DOT. Ils peuvent appliquer la conviction (multiplicateur d’immobilisation) pour augmenter leur pouvoir de vote en bloquant la durée plus longtemps ; le lock commence à la fin du référendum et expire après la conviction choisie. OpenGov permet plusieurs convictions sur différents référendums simultanés.

Délégation et multi-délégations : Au lieu de voter vous-même, vous pouvez déléguer. OpenGov autorise la délégation par track (« multi-délégation ») : vous pouvez déléguer différents montants (et convictions) à différents délégués selon les tracks. Vous ne pouvez déléguer un track où vous avez déjà des votes actifs ou une délégation en place avant suppression. Les interfaces officielles affichent tous les choix de track et conviction pour configurer une délégation.

Cycle de vie d’un référendum (en résumé) :

• Soumission & période de préparation – le référendum est soumis à un track ; le vote peut ouvrir, mais les votes ne sont pris en compte qu’après la période de préparation. Dépôt de décision exigé pour entrer en décision.
• Période de décision – l’item passe en décision active. Le passage réclame de satisfaire les courbes de threshold du track.
• Période de confirmation – les seuils validés doivent rester atteints un minimum de temps.
• Période d’enactment – une fois confirmé, l’appel est mis en file et exécuté automatiquement on-chain après le delay du track.

Tout détenteur de DOT peut participer à OpenGov : proposer, voter, déléguer. Les actions se font sur des « tracks » définissant l’origine (privilège), le dépôt de décision, les seuils et fenêtres temporelles. Les paramètres varient selon le track et sont fixés par la gouvernance.

Proposer (créer un référendum) :

1. Choisir le bon track selon l’action à exécuter (ex : Root pour les appels critiques, Tippers/Spenders pour le Trésor, etc.).
2. Soumettre le référendum et veiller au dépôt de décision ; ce dépôt est traçable on-chain et exigé pour l’entrée en phase de décision après la lead-in period. Les dépôts sont visibles par référendum en UI et remboursés selon les règles du track.

Pré-requis : un compte Polkadot avec assez de DOT pour les frais et le dépôt exigé par le track. L’identité on-chain est optionnelle mais conseillée pour la crédibilité ; elle requiert un dépôt remboursable et un frais de registraire sur la parachain People.

Voter (participation directe) :

• Choix : Aye, Nay, Abstain, Split (ventiler entre Aye/Nay), ou SplitAbstain (Aye/Nay/Abstain).
• Conviction voting : possibilité de multiplier le pouvoir de vote en bloquant les DOT plus longtemps ; le lock débute après le référendum et s’expire selon la conviction. Les locks se cumulent, donc le même solde peut servir pour plusieurs votes ou être staké. On peut retirer son vote durant le référendum pour éviter le lock ; sinon, il faut supprimer les locks expirés après la période.

Les DOT stakés ou en pool peuvent toujours voter : OpenGov autorise la participation même via pools, depuis une mise à jour du runtime qui a ouvert le droit aux comptes poolés.

Délégation (par track, multi-délégation) : Vous pouvez déléguer pour chaque track à un ou plusieurs délégués, avec montants et convictions séparés. Impossible de déléguer là où vous avez déjà voté (ou une délégation active) avant de les révoquer. Les délégations se gèrent via les UIs officielles (Polkadot-JS, Polkassembly, Nova, PolkaGate).

Outils pratiques :

• Polkadot-JS UI : proposer, voter, déléguer, supprimer les locks référendum.
• Polkassembly/Subsquare/Nova/PolkaGate : rechercher des référendums, voter (y compris Split/Abstain), configurer les délégations par track.

Pour les seuils, fenêtres et dépôts, consultez le track spécifique lors de la proposition ou la délégation ; ils diffèrent selon le track et peuvent évoluer via gouvernance.

Le Trésor est une réserve de fonds on-chain contrôlée par OpenGov. Il reçoit des flux entrants automatiquement et ne décaisse qu’en validant des actions approuvées par la gouvernance. Les fonds sont sur un compte système ; aucun compte externe ne peut les mouvoir directement.

Sources du Trésor (entrées) :

• Frais de transaction : 80 % de chaque frais extrinsic au Trésor, 20 % aux producteurs de blocs.
• Émission DOT : 15 % de l’inflation annuelle vers le Trésor.
• Slashing : part des fonds perdus par infraction des validateurs.
• Virements directs : utilisateurs pouvant déposer au Trésor (rare, ex : remboursements).

Dépenses (sorties) :

• Propositions de dépenses du Trésor : la gouvernance valide des référendums transférant à un bénéficiaire. Les paiements suivent le calendrier de la spend period ; à chaque fin de période, une fraction des fonds non dépensés est brûlée.
• Tips : petits paiements accélérés via les tracks Small/Big Tipper.
• Bounties & child bounties : « parent » bounty réservant des fonds à distribuer via des child bounties pour plusieurs tâches/événements. Les curateurs déposent un cautionnement, peuvent percevoir des frais de curateur, et gèrent les paiements pendant la durée de la bounty.

Tracks de gouvernance utilisés pour la dépense du Trésor : OpenGov gère les sorties via six tracks avec origines et paramètres propres : Treasurer, Big/Medium/Small Spender, Big/Small Tipper. Les grosses dépenses ont des tracks plus strictes et des limites de capacité ; les tips visent les montants modestes.

Trésor multi-actif : Le Trésor peut détenir/dépenser d’autres actifs que DOT (ex : USDT/USDC) via Asset Hub, à condition qu’un taux de conversion soit voté par la gouvernance (sur le track Treasurer). Les dépenses multi-actif doivent spécifier l’actif, la chaîne et le montant ; dépenses par jalon (milestone) et fenêtres de claims manuelles possibles.

Sous-trésors (délégation budgétaire) : La gouvernance peut allouer une partie du Trésor principal à des sous-trésors liés à une collective ou un système chain. Chacun applique ses propres règles, évitant la multiplication des référendums sur les tracks principaux.

Pour la procédure de proposition, vote ou délégation sur une dépense du Trésor, voir la section OpenGov.

Le Polkadot Fellowship est un collectif technique on-chain qui pilote le runtime et les standards techniques du protocole. Il opère sur la chaîne système Collectives de Polkadot et coordonne ses travaux on-chain et via des dépôts publics (ex : RFC pour les changements proposés). Le Fellowship maintient les runtimes Polkadot & Kusama, mais ne verrouille pas les upgrades—tout détenteur de DOT peut proposer un upgrade runtime sur le track Root d’OpenGov.

Membres et rangs : Les membres ont un rang, utilisé pour pondérer la responsabilité au sein du vote du collectif et signaler le niveau de revue technique. Les dashboards publics de la Collectives Chain exposent les rangs et l’activité du Fellowship.

Whitelisting & track Whitelisted Caller : Pour des opérations critiques ou à faible risque bien auditées (souvent des releases runtime), le Fellowship peut mettre sur liste blanche un call hash. Cela active le track Whitelisted Caller dans OpenGov, permettant de l’exécuter avec les droits Root après validation du référendum. Ce track utilise des délais et thresholds accélérés, fournissant une voie rapide pour les items vérifiés.

Comment les upgrades sont actés : Sur Polkadot, les upgrades runtime ne sont exécutés que via les référendums Root ou Whitelisted Caller. Le Fellowship valide, puis whiteliste le cas échéant, pour accélérer via la voie rapide ; sinon l’upgrade suit le process Root classique.

Processus ouvert : Les RFC, signaux, décisions on-chain sont publics et visibles des détenteurs et électeurs.

Agile Coretime (blockspace en tant que marché)

Polkadot 2.0 remplace la location de slot/crowdloan par un marché de coretime. Les projets obtiennent du temps d’exécution sur les « cores » de la Relay Chain de deux manières :

• Bulk Coretime : une « région » mensuelle (~28 jours, 5040 time slices) vendue sur une chaîne spécialisée Coretime. La propriété est enregistrée en tant qu’actif non fongible et peut être réassignée ou revendue.
• Instantaneous Coretime : de brèves périodes achetées au besoin à partir d’un pool (paiement à l’usage).

Les ventes se font en « lead-in » à prix décroissant type Dutch auction ; le prix régulier s’ajuste à la demande selon des règles validées par la gouvernance. Un marché secondaire pour les régions fait partie du design. Le revenu des ventes de coretime est brûlé (RFC approuvé par le Fellowship). L’émission nette équivaut donc à l’émission brute moins les burns.

Impact coût : les équipes planifient leur budget en achetant la capacité exacte voulue, avec des signaux de prix clairs et aucun verrouillage pluriannuel. Les auctions/crowdloans disparaissent depuis Agile Coretime.

Async Backing (débit/latence améliorés)

Async Backing découple la production de blocs parachain de celle des blocs Relay Chain, permettant aux collators de préparer plusieurs blocs en pipeline, la validation se faisant en parallèle. Concrètement cela :

• permet aux parachains d’émettre un bloc tous les ~6s (au lieu de 12s)
• allonge la fenêtre d’exécution (de ~0,5s à ~2s) donc des blocs ~4× plus gros
• offre un débit ~8× supérieur et ~10× avec PoV-reclaim (qui compte la taille des proofs)

Ces évolutions ont été livrées en 2024 (Kusama d’abord, puis Polkadot).

Impact performance : TPS durablement augmentées, inclusion plus rapide pour les chaînes qui l’activent ; les autres peuvent opter plus tard.

Elastic Scaling (plusieurs cores par chaîne)

Elastic Scaling permet à une même chaîne d’utiliser plusieurs cores en parallèle (scalabilité verticale) au lieu de 1 core/parachain. Il fonctionne avec async backing et nouveaux paramètres collator/validateur pour un débit rehaussé et une latence réduite. Août 2025 : Elastic Scaling est finalisé pour activation mainnet via OpenGov (Kusama d’abord).

Impact : les rollups/parachains très sollicités répartissent la charge sur plusieurs cores, augmentant la capacité sans démultiplier les chaînes.

Résumé des effets :

• Coût/planification : coretime prédictible/remplaçant les leases longue durée ; achat à la région mensuelle ou par tranche ; burn partiel du revenu coretime réduit l’émission.
• Débit/latence : async backing accélère cadence des blocs et leur taille ; elastic scaling ajoute l’exécution multi-core. L’ensemble hausse le débit sans changer le modèle de sécurité partagée.

1. Construire votre chaîne :

   • Utiliser le Polkadot SDK (Substrate + Cumulus) et partir du template parachain. Cela fournit un runtime FRAME, node collator et hooks XCM prêts à l’adaptation.
   • Connecter en local à une Relay Chain pour valider la production de blocs et les bases XCM ; voir le tutoriel officiel pour brancher une parachain locale.

2. Testnet/provings & ParaID :

   • Tester upgrades/XCM sur Paseo (testnet communautaire avec coretime).
   • Réserver un ParaID sur la chaîne cible via le registrar : d’abord reserve (dépôt configurable), puis plus tard register avec votre code de validation (WASM) et genesis head. Les dépôts varient selon la chaîne/registrar. (Sur testnet, voir la doc des constantes exactes ; sur mainnet, valeurs fixées par la gouvernance.)

3. Acquérir Coretime (Polkadot 2.0) :

   • Bulk Coretime (« Région ») : achat d’une région d’environ 28 jours (5040 time slices) sur un core, vendue sur la chaîne Coretime. La propriété est traçable on-chain, transfer/disponible à la revente, ventes à prix décroissant.
   • Instantaneous Coretime : capacité ponctuelle achetée à la demande.
   • Comptabilité : le revenu des ventes de coretime est brûlé (RFC-0010 Fellowship), donc budgéter en DOT ; aucun lockup/crowdloan.

4. Enregistrement et activation sur la Relay Chain :

   • Avec ParaID, runtime WASM et genesis head prêts, soumettez l’enregistrement et l’activation. Sur Polkadot, l’onboarding standard se fait via le registrar ; les system chains (ex : Coretime, Asset Hub) s’enregistrent via OpenGov (souvent le track Whitelisted Caller), cf. le référendum d’enregistrement Coretime de référence.

5. Exploiter votre réseau :

   • Collators : minimum deux collators fiables ; scalabilité et distribution géographique si charge. (Les validateurs sont sur la Relay Chain ; les parachains fournissent les collators.)
   • XCM & HRMP : ouvrir des canaux HRMP vers des pairs (ex : Asset Hub) et configurer XCM (actifs de frais acceptés, localisations de réserves). Pour le DOT, noter que la réserve DOT migre vers Asset Hub.
   • Upgrades : upgrades du runtime via la gouvernance de la chaîne ; la Relay Chain les valide à l’inclusion. (Pour les paramètres niveau relais et OpenGov, voir la section gouvernance.)

6. Rollups vs parachains (où s’inscrit le “rollup”) :

   • Les « rollups » sont souvent des parachains SDK vérifiées/settled par la Relay Chain (héritant de la disponibilité/validité et XCM). Pour un rollup-as-a-service hébergé sur une parachain existante, tout se fait via l’hôte, pas d’achat de coretime direct ; l’architecture dépend du projet.

Pré-requis minimum (checklist)

Technique :

• Runtime Polkadot SDK (WASM) + chain spec, genesis head, ParaID.
• Nœuds collators, endpoints RPC, télémétrie/monitoring.
• Configuration XCM et au moins un canal HRMP pour intégration.

Économique :

• Budget DOT pour coretime (Bulk ou Instantané), frais de transaction ; tous les coretime achetés sont brûlés.
• Dépôt au registrar pour réserver/enregistrer le ParaID (montant spécifique selon la chaîne).

Gouvernance :

• Aucun besoin spécifique pour l’onboarding via le registrar, hormis la gouvernance de la chaîne cible ; les chaînes système sont onboardées par OpenGov (ex : enregistrement Coretime).

DOT natif vs DOT wrappé/dérivé :

• DOT natif existe sur Polkadot même (Relay Chain, Asset Hub, etc.). Dans Polkadot, le DOT circule par XCM, via téléport (Relay ↔ Asset Hub pour DOT) ou transferts par réserve si DOT sur d’autres parachains. La réserve DOT en XCM migre de la Relay Chain à Asset Hub : les parachains doivent dorénavant traiter Asset Hub comme réserve du DOT.
• DOT wrappé/dérivé existe hors Polkadot (ex : sur Ethereum) ou sous forme ERC-20 sur une parachain EVM. Sur Moonbeam, le DOT apparaît comme xcDOT, un XC-20 (équivalent ERC-20 avec DOT natif locké sur sa chaîne de réserve et interface ERC-20 locale).

XCM à l’intérieur de Polkadot vs bridges externes :

• XCM : format/protocoles de transferts intra-Polkadot (Relay–parachains). Pour le DOT, téléport entre Relay ↔ Asset Hub ; pour les autres parachains, transferts-réserve : la chaîne réserve tient la comptabilité de l’offre.
• Bridges : vers Ethereum & co, un bridge sur Bridge Hub. Snowbridge est le pont light-client officiel Polkadot↔Ethereum. Il émet des ERC-20 bridgés via le pallet ForeignAssets d’Asset Hub, puis un XCM transfère l’actif bridgé vers la parachain cible : XCM et bridge sont combinés.

Compatibilité EVM via Moonbeam (XC-20s) :

• Standard XC-20 : sur Moonbeam, les assets cross-chain sont exposés comme XC-20s implémentant l’ERC-20 (et Permit). Pour DOT = xcDOT. Les développeurs interagissent avec les XC-20 comme sur Ethereum, Polkadot manage la réserve via le account souverain.
• XC-20 locaux vs externes : Si l’actif a sa réserve sur Moonbeam, c’est un XC-20 local ; pour des actifs comme DOT, c’est un XC-20 externe, la valeur restant sur la chaîne réserve (Relay/Asset Hub) avec une interface ERC-20 sur Moonbeam.

Points pratiques :

• À utiliser selon le besoin : XCM pour les mouvements intra-Polkadot (DOT entre Asset Hub et parachains). Utiliser un bridge (ex : Snowbridge) pour les transferts vers/depuis des externes (Ethereum…)—les tokens bridgés sont des représentations distinctes, modèles de confiance/différents risques que le DOT natif.
• Mise à jour en cours : La migration du reserve-location DOT (Asset Hub) est active ; les parachains/apps doivent adapter leur XCM pour assurer le routage et la comptabilité canoniques. Les guides sont publiés via le Support Polkadot et forum.

Polkadot a été initié par la Web3 Foundation (W3F), organisation suisse à but non lucratif dont le projet phare est Polkadot. W3F a été fondée par Dr Gavin Wood, auteur du whitepaper Polkadot de 2016 sur le design multi-chaîne hétérogène.

Le développement du protocole et du runtime a été mené par Parity Technologies, l’équipe d’ingénierie ayant collaboré avec W3F pour amener Polkadot en mainnet en 2020.

L’équipe fondatrice regroupe couramment Gavin Wood, Robert Habermeier et Peter Czaban. L’annonce officielle W3F cite Robert Habermeier comme cofondateur et core developer de Polkadot, Peter Czaban comme co-fondateur de Polkadot et Web3 Foundation.

W3F a enclenché le lancement du réseau Polkadot le 26 mai 2020, après plusieurs années de développement ; les phases successives ont remis le contrôle aux détenteurs et activé l’émission on-chain de DOT. La gestion de l’offre et la redenomination sont abordées dans les sections précédentes.