Kaspaがネイティブトークンと契約アプリのための3つの標準を確定

KaspaのKCCコーディネーションフォーラムは、契約インターフェース、認証、及び代替可能トークンをカバーする3つの標準を確定し、ネットワーク上でアプリケーションを構築する開発者のための共有仕様を確立しました。

Summary

• KCC-1は、契約と連携するウォレット、コンパイラ、インデクサー、その他のツールのための共有インターフェースを定義します。
• KCC-2は、公開鍵、スクリプト、契約識別子を含む5つの標準認証スキームを指定します。
• KCC-20はトークン転送ルールを設定し、既存の互換性のある出力を通じてトークンを受け取ることをサポートします。
• 確定は、コンセンサスルールを変更することなく、エコシステムの慣習を確立し、すべての参加者がそれを採用することを要求しません。

KCCコーディネーションフォーラムは、10月21日の発表で、KCC-1、KCC-2、およびKCC-20が最終的であり、エコシステム全体での採用の準備が整ったと述べました。フォーラムは、質問、実装の議論、サポートのために、ビルダーが公開チャンネルに参加することを招待しました。

$KASの皆さん、KCC-1、KCC-2、KCC-20は最終的なものであり、エコシステム全体での完全な採用の準備が整いました。

Kaspaのビルダーの皆さん、質問をしたり、サポートを受けたり、実装について議論したり、あなたが構築したものを共有するために、公開KCCチャンネルに参加することをお勧めします。

一緒に構築しましょう。 --- KCCコーディネーションフォーラム (@kccforum) 2026年10月21日

Kaspaの公式標準リポジトリは、すべての3つの文書を最終的なものとしてリストしています。そのインデックスは、KCC-1を契約仕様、KCC-2を権限仕様、KCC-20を代替可能トークン契約のアプリケーション標準として特定しています。

リポジトリは、KCCを独立した実装のための共有慣習として説明しています。その文書は、これらの慣習をコンセンサスやコアノードの動作の変更から分離しており、それはKaspa改善提案に属します。

Kaspaの標準はアプリケーション開発の異なる部分をカバー

KCC-1は、契約のための共通の用語、データレイアウト、およびアプリケーションバイナリインターフェース（ABI）を定義します。この仕様は、ソフトウェアが情報をエンコードし、プログラム関数を呼び出し、トランザクション間で運ばれる状態を特定する方法を説明します。

その著者であるロマン・ビロ、マイケル・サットン、オリ・ニューマンは、コンパイラ、ウォレット、インデクサー、トランザクションビルダーがこれらの詳細に合意する必要があるツールとして特定しています。この文書は、独立した実装が単にコンセンサスチェックを通過するスクリプトを生成するだけでなく、共通のフォーマットを必要とすることを述べています。

KCC-1の仕様は、開発者がプログラミング言語、コンパイラ、およびフレームワークを自由に選択できるようにしています。その共有インターフェースは、プログラムのエントリーポイント、状態テンプレート、および複数の入力を含むトランザクションを処理するためのルールをカバーしています。

同じ文書内で、著者は基本的なインターフェースルールを契約識別子に依存する機能から区別しています。契約バインディングのないプログラムはKCC-1に従うことができますが、仕様はそれらがKIP-20によって提供される系譜と認証の保証を受けないことを述べています。

KCC-2は誰が操作を認可できるかを定義

KCC-2は、ビロとサットンによって書かれ、プログラムが権限を特定する方法と、その承認を確立するために必要な最小チェックを指定します。権限は公開鍵、鍵へのコミットメント、スクリプト、または継続的な契約の系譜である可能性があります。

この仕様は、5つの認証スキームに標準識別子を割り当てます。その公開鍵オプションは、シュノールおよびECDSA署名をカバーし、他のオプションではスクリプトまたは契約の系譜が権限として参加することを許可します。

公開鍵ハッシュ認証の場合、KCC-2はトランザクションが対応する公開鍵を明らかにし、そのハッシュを保存された権限値と一致させ、有効な署名を提供することを要求します。より高レベルの仕様は、署名されたメッセージとその他の条件を定義します。

権限レジストリは、標準スキームとカスタムスキームのために別々の範囲を予約します。KCC-2は、参加者が標準化を待たずにカスタムスキームを採用することを許可しますが、その定義はフォーマット、意味、および承認チェックを指定する必要があります。

その契約識別子スキームの下では、承認には特定された契約系譜からの入力が必要です。KCC-2は、より高いレベルの規約がその入力のプログラムと状態にさらなるチェックを課すことができると述べています。

KCC-20がトークンの転送と受信ルールを設定

KCC-20は最初の二つの標準を基にしており、トークンの量、所有権、転送インターフェースを定義しています。この文書では、Sivan Helfer、Sutton、Newman、Billotが著者として名前が挙げられています。

その仕様では、各トークン契約がソフトウェアが状態をデコードし、転送を構築するために使用できるプログラム情報を公開することを要求しています。設定は、サポートされる所有権スキームとトークンの入力および出力の制限を開示しなければなりません。

「借用受信」と呼ばれる機能により、送信者は受信者の既存の互換性のあるトークン出力を宛先として使用できます。KCC-20は、トランザクションがその出力をより多くのトークンで再作成し、所有権と拡張状態を保持し、KASの価値を減少させることができないと述べています。

セキュリティセクションでは、出力を置き換えることがトランザクションの参照を変更し、以前の参照を使っている未確認のトランザクションを無効にすることを警告しています。文書によると、ウォレットはそれを使う前に置き換えを発見しなければなりません。

この標準は、生成されたSilverScript契約とRust適合テストと共にArgentの参照実装をリンクしています。

最終ステータスには実装要件が伴う

KCC-0、標準プロセスを管理する文書は、最終レビュー期間の完了以上のものを要求します。標準トラックの規約は、人間が読めるテストベクターと機械が読めるテストベクターを必要とし、さらに機械が読めるチェックに合格する少なくとも1つの公開実装が必要です。

依存関係は、同じルールに従って他のKCCに対しては最終的である必要があり、KIPsに対してはアクティブである必要があります。KCC-0は、ステータスの変更がプルリクエストを通じて行われ、リポジトリインデックスがそれらで更新される必要があると述べています。

KCC-0は、機械が読めるテストベクターを、人間が読める例と共に伴う自動テストの権威ある形式として説明しています。その提出ルールは、標準トラックの文書が最終呼び出しに入る前に、脅威、信頼の仮定、および潜在的なリプレイの問題に対処するセキュリティ上の考慮を要求します。

管理文書は、最終化がすべてのエコシステム参加者に規約を実装することを要求しないと述べています。実質的な変更は一般的に置き換えKCCを必要とし、修正や明確化は文書の改正ルールに従います。

Kaspaのアプリケーション開発には以前、別のLayer 2インフラが含まれていました。Gateは4月にKasplex Layer 2統合を発表し、EVM互換ネットワークを通じてKASの入出金を可能にしましたとcrypto.newsが報じました。

以前の統合発表で、Gateは顧客が基盤ネットワークからKasplexウォレットにKASを転送できると述べました。Kasplexのプロジェクト資料は双方向ブリッジを説明し、Ethereumツールに精通した開発者がリモートプロシージャコールエンドポイントを変更することで契約を展開できると述べています。

Kasplexは、その設計を軽量ロールアップとして説明し、EVMバイトコードをKaspaトランザクションに配置し、オフチェーンで実行します。その文書は、Kaspaがトランザクションの順序付けとデータの可用性を提供し、ブリッジされたKASがLayer 2のガス・トークンとして機能することを述べています。