Kaspa France
À la UneCe que les développeurs livrent, semaine après semaine.
10blocs par seconde sur le réseau principal
1 078covenants actifs au 6 octobre
3standards KCC finalisés le 21 octobre
118jours depuis l'activation de Toccata
À la Une · les avancées du développement

À la Une : où en est le réseau Kaspa ?

Chaque élément est classé selon ce qui est vérifiable aujourd'hui, pas selon ce qui est annoncé.

En production

Toccata

Mise à jour activée le 30 juin 2026 (DAA 474 165 565). Apporte les covenants et la vérification de preuves ZK.

Covenants

Environ 1 078 covenants actifs le 6 octobre, et quelques petits marchés de tokens.

KIP-16, 17, 20, 21

Les propositions de Toccata, toutes au statut « Active ». KIP-20 définit les identifiants de covenants.

10 blocs par seconde

En service depuis Crescendo, en mai 2025.

KCC-1, KCC-2 et KCC-20

Finalisés le 21 octobre : les règles communes des covenants, des autorisations et des tokens fongibles sont prêtes à être adoptées par les portefeuilles et les applications.

En chantier

Clés publiques masquées

Ori Newman propose une convention de portefeuille qui garde la clé publique cachée jusqu'à la dépense, une précaution face aux futurs ordinateurs quantiques. D'abord déposée comme KIP-22, elle est désormais étudiée comme KCC.

vProgs

Premier vProg en fonctionnement sur le testnet depuis le 24 septembre : un morpion avec exécution et règlement réels, annoncé par le développeur Maksim Biriukov. Pas encore de version publiée pour le réseau principal.

Kaspa Privacy Initiative

Expérience de paiements privés sur le testnet, suivie d'un test de récupération réussi : les portefeuilles ont été restaurés et le solde de test entièrement retiré. Le projet reste expérimental.

KCC-23

Brouillon d'un format commun de métadonnées en JSON pour les applications construites sur les covenants, après la finalisation de KCC-0, 1, 2 et 20.

KIP-24 et KIP-25

Déjà actives en pratique sur le réseau, mais pas encore formellement validées.

Recherche

DAGKnight

KIP-2 toujours « proposée ». Le réseau tourne sur GHOSTDAG. Branche de développement active jusqu'au 8 septembre.

100 blocs par seconde

Objectif de feuille de route, sans KIP ni version derrière.

Registre des KIP

Les propositions d'amélioration du protocole qui comptent aujourd'hui, avec leur statut officiel dans le dépôt kaspanet/kips.

KIPObjetCe que ça changeStatut
2DAGKnightConsensus sans paramètre de latence fixe, sûr tant que les attaquants détiennent moins de la moitié de la puissance de calcul.Proposée
9Formule de masse étendueFait payer l'occupation de l'état pour limiter son gonflement.Active
10Nouveaux opcodesIntrospection des transactions dans les scripts.Active
14CrescendoPassage de 1 à 10 blocs par seconde (mai 2025).Active
15Ordre canonique et engagements de séquençageOrdre des transactions vérifiable, base des couches 2 fondées sur Kaspa.Active
16Opcode de précompilation ZKVérification de preuves à divulgation nulle de connaissance directement en script.Active
17Covenants et scripts améliorésLe cœur de Toccata : règles de dépense programmables.Active
20Identifiants de covenantsSuivre un covenant d'une transaction à l'autre, base des tokens natifs.Active
21Engagement de séquençage partitionnéPreuves dont le coût dépend de l'activité réelle, pas de toute la chaîne.Active
22Pay-to-Public-Key-Hash via P2SHGarder la clé publique cachée jusqu'à la dépense, par précaution face aux ordinateurs quantiques. Désormais étudiée comme convention KCC.PR ouverte
24Transactions version 1Déjà utilisée sur le réseau, en attente de validation formelle.PR ouverte
25Budget de calculPlafond de calcul par transaction, déjà appliqué en pratique.PR ouverte

Registre des KCC

Les KCC sont les conventions construites au-dessus des covenants : elles ne changent pas le consensus, mais permettent aux portefeuilles, aux applications et aux indexeurs de parler la même langue. Statuts relevés dans le dépôt kaspanet/kccs le 28 octobre 2026.

KCCObjetCe que ça changeStatut
0Objectifs et règles des KCCLe processus de rédaction et de validation des standards, avec jeux de tests et implémentation publique obligatoires.Final
1Concepts, données et interface des covenantsUn vocabulaire et une interface communs pour que compilateurs, portefeuilles et indexeurs lisent un covenant de la même façon.Final
2Schémas d'autorisationQui a le droit d'agir : une clé, un script ou une lignée de covenants, avec cinq schémas standard.Final
20Token fongibleLe standard des tokens natifs de Kaspa : montants, propriété et transferts vérifiés par chaque nœud.Final
21Métadonnées des tokensDécrire un token (nom, symbole, informations) de façon standard.PR ouverte
23Métadonnées en JSON (MJ)Un format JSON commun pour les métadonnées des applications construites sur les covenants.Brouillon
402Canaux de paiement par covenantDes paiements rapides et répétés entre deux parties, réglés sur Kaspa à la fin, utiles aux micropaiements et aux agents IA.PR ouverte
—Clés publiques masquéesGarder la clé publique cachée jusqu'à la dépense, par précaution face aux ordinateurs quantiques. Proposée d'abord comme KIP-22.En étude

Ce qui se construit sur GitHub

Tout le code de Kaspa est public. Voici les dépôts qui comptent, du nœud officiel aux projets expérimentaux. Les étoiles et les dates de mise à jour sont relevées le 8 octobre 2026.

Dernière version du nœud

rusty-kaspa v2.1.0 · 22 septembre 2026

  • Protocole P2P version 11 : la synchronisation initiale d'un nouveau nœud se fait par morceaux de 20 Mo, ce qui évite les blocages. Compatible avec les nœuds en version 10.
  • Réseau durci : taille maximale des messages abaissée de 1 Go à 256 Mo, limite de 2 Mo par bloc appliquée dès la réception, rejet immédiat des pairs bannis.
  • Pont Stratum pour les mineurs : correction d'une faille d'accès aux fichiers du tableau de bord et de fuites de connexions.
  • SDK de preuves ZK séparé : la génération de scripts pour les preuves RISC Zero (Groth16 et STARK) devient une bibliothèque autonome.
  • Audit de sécurité arithmétique sur tout le code, et simplification du consensus après Toccata.
Notes de version complètes

Le cœur du protocole

Le dépôt officiel kaspanet : le nœud, les propositions d'amélioration et les nouveaux chantiers.

Programmer sur Kaspa

Les langages qui rendent les covenants accessibles aux développeurs.

Portefeuilles

Les outils que les utilisateurs ont entre les mains.

Infrastructure et SDK

Ce qu'il faut pour construire des explorateurs, des services et des applications.

Expérimental

Des projets jeunes qui explorent de nouveaux usages.

Analyse · Numéro 4

KCC-20 est finalisé : Kaspa a désormais sa langue commune pour les tokens

26 octobre 2026 · 4 min de lecture

Le 21 octobre 2026, le forum de coordination des KCC a annoncé la finalisation de trois standards d'un coup : KCC-1, KCC-2 et KCC-20. Une semaine après son passage en dernière consultation, le standard de token de Kaspa n'est plus un projet : c'est une référence stable, sur laquelle portefeuilles, plateformes et applications peuvent bâtir.

Trois briques qui s'emboîtent

KCC-1 fixe le vocabulaire, la disposition des données et l'interface binaire des covenants : c'est ce qui permet à un compilateur, un portefeuille et un indexeur de lire un même programme de la même façon. KCC-2 décrit qui a le droit d'agir : une clé publique, un script ou toute une lignée de covenants, avec cinq schémas d'autorisation standard. KCC-20, enfin, s'appuie sur les deux premiers pour définir les montants, la propriété et les transferts des tokens fongibles.

Ce que « finalisé » veut dire

Pour passer au statut « Final », les règles des KCC exigent des jeux de tests lisibles par les humains et par les machines, et au moins une implémentation publique qui les réussit. Un développeur peut donc vérifier automatiquement que son portefeuille ou son application respecte le standard. Les auteurs sont des bâtisseurs du protocole, dont Michael Sutton et Ori Newman, aux côtés de Romain Billot et Sivan Helfer.

Ce qui ne change pas

Les KCC sont des conventions entre développeurs : ils ne modifient pas le consensus de Kaspa et personne n'est obligé de les adopter. Mais ils reposent sur les covenants arrivés avec Toccata : la règle qui garantit que le total d'un token reste constant est vérifiée par le script, donc par chaque nœud, et non par un indexeur externe comme pour les tokens KRC-20.

La suite à surveiller

Le chantier passe maintenant du côté des produits : l'intégration de KCC-20 dans les portefeuilles, les plateformes d'échange décentralisées et les outils de création de tokens. Les premières idées circulent déjà, comme le projet KaspaDollar, un stablecoin surcollatéralisé dont le développement et l'audit restent à faire. Côté convention, un brouillon KCC-23 propose déjà un format commun de métadonnées.

À retenir : avec KCC-20 finalisé, Kaspa dispose d'un standard de token vérifié par la couche de base. Le prochain jalon sera son adoption par les portefeuilles et les applications.
Cette analyse vous a été utile ?Soutenir Kaspa France
Analyse · Numéro 3

KCC-20 en dernière consultation : les tokens natifs de Kaspa prennent forme

19 octobre 2026 · 4 min de lecture

Mi-octobre, la proposition KCC-20 est passée au statut « Last Call » dans le dépôt officiel kaspanet/kccs. C'est la dernière ligne droite avant qu'elle devienne un standard finalisé. Son objet : définir une façon commune de créer des tokens fongibles, comme des jetons de projet ou des stablecoins, directement sur la couche de base de Kaspa, grâce aux covenants arrivés avec Toccata.

Pourquoi un standard compte autant

Un token n'a d'utilité que si les portefeuilles, les plateformes d'échange et les applications savent le lire de la même manière. Sans convention commune, chaque projet invente son format et chaque portefeuille doit s'adapter au cas par cas. KCC-20 joue pour Kaspa le rôle qu'ERC-20 a joué pour Ethereum : une langue partagée. Il est signé par quatre auteurs, dont Michael Sutton et Ori Newman, deux des développeurs principaux du protocole.

Comment ça marche

Chaque morceau de token est une pièce gardée par un covenant, qui retient un montant et un propriétaire. Lors d'un transfert, une entrée « meneuse » vérifie l'ensemble de l'opération et s'assure que le total de tokens reste exactement le même ; les autres entrées vérifient seulement que leur propriétaire a bien signé. Le propriétaire peut être une simple clé, un script ou même un autre covenant, ce qui ouvre la porte aux coffres, aux échanges automatiques et aux budgets confiés à des agents IA. La spécification prévoit aussi de pouvoir créditer un compte existant sans l'intervention de son propriétaire, selon des règles choisies à l'avance, et de rattacher des propriétés propres à chaque application.

Ce que KCC-20 ne fixe pas

Le standard décrit les transferts, pas la création des tokens : il n'impose ni règle d'émission ni plafond d'offre. Chaque projet garde la main sur sa politique monétaire, écrite dans son propre covenant et publiée avec une description de son interface. KCC-20 reste aussi une convention entre développeurs : il ne modifie pas le consensus de Kaspa.

Ce qui change par rapport à KRC-20

Les tokens KRC-20 actuels reposent sur des inscriptions que le réseau ne comprend pas : ce sont des indexeurs externes qui tiennent les soldes. Avec KCC-20, la règle de conservation du total est vérifiée par le script, donc par chaque nœud du réseau.

À retenir : KCC-20 est proche de sa version finale. La prochaine étape à suivre sera son statut « Final », puis son adoption par les portefeuilles et les applications.
Cette analyse vous a été utile ?Soutenir Kaspa France