Clés de paiement, clés de stake, et pourquoi vous avez de nombreuses adresses
Une adresse Cardano contient généralement deux parties : un identifiant de paiement, qui contrôle la dépense, et un identifiant de stake, qui contrôle la délégation.
La conséquence est qu’un portefeuille génère de nombreuses adresses de paiement qui partagent toutes une seule clé de stake. Vos fonds sont répartis entre elles ; votre staking est unifié. Recherchez une adresse et vous voyez une fraction de vos avoirs, ce qui est alarmant si vous ne savez pas à quoi vous attendre.
Cardanoscan gère cela correctement : recherchez une adresse de stake et vous obtenez la position agrégée, la délégation et l’historique complet des récompenses. C’est la vue qui correspond à ce qu’un portefeuille vous montre, et c’est celle à utiliser.
Cela permet aussi quelque chose de véritablement utile — un staking liquide sans blocage. Comme la délégation est contrôlée par une clé séparée de celle de la dépense, vos fonds restent librement dépensables pendant qu’ils sont délégués. Il n’y a pas de période de déverrouillage, contrairement aux vingt-huit jours de Polkadot ou à la file d’attente de sortie d’Ethereum. C’est l’une des meilleures décisions de conception de Cardano et elle découle directement de la séparation des clés.
Les epochs, et pourquoi les récompenses arrivent en retard
Cardano fonctionne par epochs de cinq jours, et les récompenses de staking suivent un calendrier qui surprend presque tout nouveau délégant : vous déléguez, et les premières récompenses apparaissent environ quinze à vingt jours plus tard.
La raison est le mécanisme de snapshot. Votre délégation est enregistrée dans un snapshot à la fin d’un epoch, devient active à l’epoch suivant, produit des récompenses à celui d’après, et est payée à celui d’après encore. Rien ne va mal ; le pipeline a simplement de la profondeur.
Cardanoscan montre où vous en êtes dans ce cycle, ce qui est la seule façon de distinguer « fonctionne normalement » de « mal configuré ». Vu le nombre de questions de support que cela génère, c’est une chose véritablement précieuse pour un explorateur à mettre en avant.
Une conséquence qui vaut la peine d’être connue : comme la délégation est capturée en snapshot, changer de pool n’interrompt pas les récompenses. Vous continuez à gagner de l’ancien pool à travers le pipeline pendant que la nouvelle délégation prend effet. Il n’y a ni pénalité ni interruption.
Choisir un pool de stake, factuellement
Les pages de pool de Cardanoscan portent les données qui déterminent réellement les rendements, et il vaut la peine de savoir quels champs comptent.
La saturation est le champ important. Au-dessus d’un seuil défini par le protocole, les récompenses d’un pool cessent d’augmenter avec un stake supplémentaire, donc déléguer à un pool saturé réduit le rendement de tous, vous y compris. Le mécanisme existe pour pousser le stake vers la décentralisation, et il fonctionne — mais seulement si les délégants regardent.
Les frais se composent de deux parties : un minimum fixe par epoch et une marge en pourcentage. Sur un petit pool, le frais fixe représente une plus grande proportion d’une cagnotte de récompenses plus petite, ce qui compte plus que la marge affichée.
Les blocs produits face aux blocs attendus est le signal de qualité opérationnelle. Un pool produisant systématiquement moins de blocs que ce que son stake implique a des problèmes techniques, ce qui se traduit directement par des récompenses plus faibles.
Nous décrivons comment le mécanisme fonctionne, pas où déléguer — c’est une décision aux conséquences financières et elle vous appartient.
| Champ | Pourquoi cela compte |
|---|---|
| Saturation | Au-delà du seuil, un stake supplémentaire ne rapporte rien de plus. Le champ le plus lourd de conséquences. |
| Frais fixe | Facturé par epoch quelle que soit la taille. Proportionnellement plus lourd sur les petits pools. |
| Marge | Pourcentage que l’opérateur prend après le frais fixe. |
| Mise (pledge) | Le propre stake de l’opérateur. Un engagement réel, et cela affecte le calcul des récompenses. |
| Blocs vs attendus | Fiabilité opérationnelle. Une sous-performance persistante signale des problèmes techniques. |
UTXO étendu et actifs natifs
Cardano utilise l’UTXO étendu — comme le modèle de Bitcoin, mais les sorties peuvent porter des données arbitraires (un datum) et être protégées par des scripts. C’est un modèle computationnel véritablement différent des comptes d’Ethereum, avec des propriétés différentes : les résultats de transaction sont prévisibles avant soumission, et la concurrence doit être conçue plutôt que supposée.
La conséquence la plus immédiatement visible est les actifs natifs. Les tokens Cardano ne sont pas des smart contracts. Ce sont des objets au niveau du registre, portés dans les sorties aux côtés de l’ADA, transférés par le même mécanisme.
Cela élimine toute une classe de problèmes. Il n’y a pas de contrat de token pouvant être mis à niveau pour bloquer les transferts, pas de mécanisme d’approbation à exploiter, pas de logique de transfert sur mesure à auditer. Le risque d’approbation de tokens qui domine les conseils de sécurité EVM n’existe tout simplement pas ici.
Cela signifie aussi qu’une sortie portant des tokens doit porter un montant minimum d’ADA à leurs côtés, ce qui explique pourquoi vous ne pouvez pas envoyer de tokens depuis une adresse ne détenant aucun ADA. Cardanoscan montre la composition de chaque sortie, c’est là que cela devient visible.
Ce que nos tests de référence ont montré
Nos éléments de test Cardano étaient un simple paiement en ADA, un transfert d’actif natif, une adresse de stake avec historique de délégation, une page de pool, et une sortie portant des tokens avec le minimum d’ADA attaché.
Rechercher l’adresse de paiement a renvoyé une image partielle, comme le dicte le modèle de clés. Rechercher l’adresse de stake a renvoyé la position agrégée et l’historique complet de délégation et de récompenses, qui est la vue correspondant à ce que montre un portefeuille et celle que nous recommanderions à quiconque.
L’historique des récompenses se réconciliait epoch par epoch, et le pipeline de snapshot était visible dans les données — la première récompense est apparue le nombre d’epochs plus tard que le mécanisme prédit, plutôt qu’immédiatement.
La page de pool montrait la saturation, la mise, le frais fixe, la marge et les blocs produits face aux blocs attendus. Nous avons délibérément examiné un pool saturé, et le chiffre était assez proéminent pour qu’un délégant le remarque avant de s’engager, ce qui est tout l’intérêt de le mettre en avant.
Le test de sortie de token montrait l’ADA et l’actif natif comme des composantes séparées de la même sortie, ce qui est la seule présentation qui explique pourquoi un transfert de token nécessite de l’ADA pour l’accompagner.