Kaspa finalise 3 normes pour les jetons natifs et les applications de covenant

Le Forum de Coordination KCC de Kaspa a finalisé trois normes couvrant les interfaces de covenant, l'autorisation et les jetons fongibles, établissant des spécifications partagées pour les développeurs construisant des applications sur le réseau.

Résumé

• KCC-1 définit des interfaces partagées pour les portefeuilles, les compilateurs, les indexeurs et d'autres outils travaillant avec des covenants.
• KCC-2 spécifie cinq schémas d'autorisation standard, y compris les clés publiques, les scripts et les identifiants de covenant.
• KCC-20 établit des règles de transfert de jetons et prend en charge la réception de jetons via une sortie compatible existante.
• La finalisation établit des conventions d'écosystème sans modifier les règles de consensus ni exiger que chaque participant les adopte.

Le Forum de Coordination KCC a déclaré dans une annonce du 21 octobre que KCC-1, KCC-2 et KCC-20 étaient définitifs et prêts à être adoptés dans l'écosystème. Le forum a invité les constructeurs à rejoindre son canal public pour des questions, des discussions sur l'implémentation et du soutien.

Salutations $KAS. KCC-1, KCC-2 et KCC-20 sont maintenant définitifs, ce qui signifie qu'ils sont prêts pour une adoption complète dans l'écosystème.

Nous invitons les constructeurs de Kaspa à rejoindre le canal public KCC pour poser des questions, obtenir du soutien, discuter des implémentations et partager ce que vous construisez.

Venez construire avec nous. --- Forum de Coordination KCC (@kccforum) 21 octobre 2026

Le dépôt de normes canonique de Kaspa répertorie les trois documents comme définitifs. Son index identifie KCC-1 comme la spécification de covenant, KCC-2 comme la spécification d'autorité, et KCC-20 comme la norme d'application pour les covenants de jetons fongibles.

Le dépôt décrit les KCC comme des conventions partagées pour des implémentations indépendantes. Sa documentation sépare ces conventions des changements de consensus ou de comportement de nœud central, qui appartiennent aux propositions d'amélioration de Kaspa.

Les normes Kaspa couvrent différentes parties du développement d'applications

KCC-1 définit des termes communs, des mises en page de données et une interface binaire d'application, ou ABI, pour les covenants. La spécification décrit comment le logiciel encode les informations, appelle des fonctions de programme et identifie l'état transporté entre les transactions.

Ses auteurs, Romain Billot, Michael Sutton et Ori Newman, identifient les compilateurs, portefeuilles, indexeurs et constructeurs de transactions parmi les outils qui doivent s'accorder sur ces détails. Le document indique que les implémentations indépendantes ont besoin de formats communs au-delà de simplement produire des scripts qui passent les vérifications de consensus.

La spécification KCC-1 laisse aux développeurs la liberté de choisir leur langage de programmation, leur compilateur et leur cadre. Son interface partagée couvre les points d'entrée du programme, les modèles d'état et les règles pour gérer les transactions impliquant plusieurs entrées.

Dans le même document, les auteurs distinguent les règles d'interface de base des fonctionnalités qui dépendent des identifiants de covenant. Les programmes sans liaisons de covenant peuvent suivre KCC-1, mais la spécification indique qu'ils ne reçoivent pas les garanties de lignée et d'autorisation fournies par KIP-20.

KCC-2 définit qui peut autoriser une opération

KCC-2, écrit par Billot et Sutton, spécifie comment les programmes identifient une autorité et les vérifications minimales requises pour établir son approbation. Une autorité peut être une clé publique, un engagement à une clé, un script ou une lignée de covenant continue.

La spécification attribue des identifiants standard à cinq schémas d'autorisation. Ses options de clé publique couvrent les signatures Schnorr et ECDSA, tandis que ses autres options permettent à un script ou à une lignée de covenant de participer en tant qu'autorité.

Pour l'autorisation par hachage de clé publique, KCC-2 exige que la transaction révèle la clé publique correspondante, fasse correspondre son hachage à la valeur d'autorité stockée et fournisse une signature valide. Des spécifications de niveau supérieur définissent le message signé et toute condition supplémentaire.

Le registre d'autorité réserve des plages séparées pour les schémas standard et personnalisés. KCC-2 permet aux participants d'adopter des schémas personnalisés sans attendre la normalisation, à condition que leurs définitions spécifient le format, le sens et les vérifications d'approbation.

Sous son schéma d'identification des conventions, l'approbation nécessite une entrée de la lignée de convention identifiée. KCC-2 indique qu'une convention de niveau supérieur peut imposer des contrôles supplémentaires sur le programme et l'état de cette entrée.

KCC-20 établit des règles de transfert et de réception de jetons

KCC-20 s'appuie sur les deux premières normes, définissant les montants de jetons, la propriété et les interfaces de transfert. Le document nomme Sivan Helfer, Sutton, Newman et Billot comme ses auteurs.

Sa spécification exige que chaque convention de jeton publie des informations sur le programme que le logiciel peut utiliser pour décoder l'état et construire des transferts. Les configurations doivent divulguer les schémas de propriété pris en charge et les limites sur les entrées et sorties de jetons.

Une fonctionnalité appelée réception empruntée permet à un expéditeur d'utiliser une sortie de jeton compatible existante d'un destinataire comme destination. KCC-20 indique que la transaction recrée cette sortie avec plus de jetons, préserve sa propriété et son état étendu, et ne peut pas réduire sa valeur KAS.

La section sécurité avertit que le remplacement de la sortie change sa référence de transaction, invalidant les transactions non confirmées dépensant la référence précédente. Un portefeuille doit découvrir le remplacement avant de le dépenser, selon le document.

La norme lie une mise en œuvre de référence Argent avec des contrats SilverScript générés et des tests de conformité Rust.

Le statut final comporte des exigences de mise en œuvre

KCC-0, le document régissant le processus de normes, exige plus que l'achèvement d'une période de révision finale. Il indique qu'une convention sur la voie des normes a besoin de vecteurs de test lisibles par l'homme et lisibles par machine, ainsi que d'au moins une mise en œuvre publique qui réussit les vérifications lisibles par machine.

Les dépendances doivent être Final pour d'autres KCC ou Actives pour les KIPs, selon les mêmes règles. KCC-0 indique que les changements de statut se produisent par le biais de demandes de tirage et que l'index du dépôt doit être mis à jour avec eux.

KCC-0 décrit les vecteurs de test lisibles par machine comme la forme autoritaire pour les tests automatisés lorsqu'ils accompagnent des exemples lisibles par l'homme. Ses règles de soumission exigent que les considérations de sécurité traitent des menaces, des hypothèses de confiance et des problèmes de replay potentiels avant qu'un document sur la voie des normes puisse entrer dans le Dernier Appel.

Le document régissant indique que la finalisation ne nécessite pas que chaque participant de l'écosystème mette en œuvre une convention. Les changements substantiels nécessitent généralement un KCC de remplacement, tandis que les corrections et clarifications suivent les règles d'amendement du document.

Le développement d'applications de Kaspa a précédemment inclus une infrastructure distincte de couche 2. Gate a annoncé une intégration de Kasplex Layer 2 en avril, permettant des dépôts et des retraits KAS via le réseau compatible EVM, comme l'a rapporté crypto.news.

Dans son annonce d'intégration antérieure, Gate a déclaré que les clients pouvaient transférer KAS du réseau de base vers un portefeuille Kasplex. Les matériaux du projet Kasplex décrivent un pont bidirectionnel et indiquent que les développeurs familiers avec les outils Ethereum peuvent déployer des contrats en modifiant leurs points de terminaison d'appel de procédure distante.

Kasplex décrit son design comme un rollup léger qui place le bytecode EVM dans les transactions Kaspa et l'exécute hors chaîne. Sa documentation indique que Kaspa fournit l'ordre des transactions et la disponibilité des données, tandis que le KAS ponté sert de jeton de gaz de couche 2.