Kaspa menyelesaikan 3 standar untuk token asli dan aplikasi covenant

Forum Koordinasi KCC Kaspa telah menyelesaikan tiga standar yang mencakup antarmuka covenant, otorisasi, dan token yang dapat dipertukarkan, menetapkan spesifikasi bersama untuk pengembang yang membangun aplikasi di jaringan.

Ringkasan

• KCC-1 mendefinisikan antarmuka bersama untuk dompet, kompiler, pengindeks, dan alat lain yang bekerja dengan covenant.
• KCC-2 menetapkan lima skema otorisasi standar, termasuk kunci publik, skrip, dan pengidentifikasi covenant.
• KCC-20 menetapkan aturan transfer token dan mendukung penerimaan token melalui output yang kompatibel yang sudah ada.
• Penyelesaian ini menetapkan konvensi ekosistem tanpa mengubah aturan konsensus atau mengharuskan setiap peserta untuk mengadopsinya.

Forum Koordinasi KCC mengatakan dalam pengumuman pada 21 Oktober bahwa KCC-1, KCC-2, dan KCC-20 telah final dan siap untuk diadopsi di seluruh ekosistem. Forum mengundang para pembangun untuk bergabung dengan saluran publiknya untuk pertanyaan, diskusi implementasi, dan dukungan.

Salam $KAS. KCC-1, KCC-2, dan KCC-20 sekarang Final, yang berarti mereka siap untuk diadopsi sepenuhnya di seluruh ekosistem.

Kami mengundang para pembangun Kaspa untuk bergabung dengan saluran KCC publik untuk mengajukan pertanyaan, mendapatkan dukungan, mendiskusikan implementasi, dan berbagi apa yang Anda bangun.

Ayo bangun bersama kami. --- Forum Koordinasi KCC (@kccforum) 21 Oktober 2026

Repositori standar kanonik Kaspa mencantumkan ketiga dokumen tersebut sebagai Final. Indeksnya mengidentifikasi KCC-1 sebagai spesifikasi covenant, KCC-2 sebagai spesifikasi otoritas, dan KCC-20 sebagai standar aplikasi untuk covenant token yang dapat dipertukarkan.

Repositori menggambarkan KCC sebagai konvensi bersama untuk implementasi independen. Dokumentasinya memisahkan konvensi tersebut dari perubahan pada konsensus atau perilaku node inti, yang termasuk dalam Proposal Peningkatan Kaspa.

Standar Kaspa mencakup berbagai bagian pengembangan aplikasi

KCC-1 mendefinisikan istilah umum, tata letak data, dan antarmuka biner aplikasi, atau ABI, untuk covenant. Spesifikasi ini menggambarkan bagaimana perangkat lunak mengkodekan informasi, memanggil fungsi program, dan mengidentifikasi status yang dibawa antara transaksi.

Penulisnya, Romain Billot, Michael Sutton, dan Ori Newman, mengidentifikasi kompiler, dompet, pengindeks, dan pembangun transaksi di antara alat yang perlu menyepakati detail tersebut. Dokumen tersebut menyatakan bahwa implementasi independen memerlukan format umum di luar sekadar menghasilkan skrip yang lulus pemeriksaan konsensus.

Spesifikasi KCC-1 membebaskan pengembang untuk memilih bahasa pemrograman, kompiler, dan kerangka kerja mereka. Antarmuka bersama mencakup titik masuk program, template status, dan aturan untuk menangani transaksi yang melibatkan beberapa input.

Di dalam dokumen yang sama, penulis membedakan aturan antarmuka dasar dari fitur yang bergantung pada pengidentifikasi covenant. Program tanpa pengikatan covenant dapat mengikuti KCC-1, tetapi spesifikasi menyatakan bahwa mereka tidak menerima jaminan garis keturunan dan otorisasi yang diberikan oleh KIP-20.

KCC-2 mendefinisikan siapa yang dapat mengotorisasi suatu operasi

KCC-2, yang ditulis oleh Billot dan Sutton, menetapkan bagaimana program mengidentifikasi otoritas dan pemeriksaan minimum yang diperlukan untuk menetapkan persetujuannya. Otoritas dapat berupa kunci publik, komitmen terhadap kunci, skrip, atau garis keturunan covenant yang berkelanjutan.

Spesifikasi ini menetapkan pengidentifikasi standar untuk lima skema otorisasi. Opsi kunci publiknya mencakup tanda tangan Schnorr dan ECDSA, sementara opsi lainnya memungkinkan skrip atau garis keturunan covenant untuk berpartisipasi sebagai otoritas.

Untuk otorisasi hash kunci publik, KCC-2 mengharuskan transaksi untuk mengungkapkan kunci publik yang sesuai, mencocokkan hash-nya dengan nilai otoritas yang disimpan, dan memberikan tanda tangan yang valid. Spesifikasi tingkat yang lebih tinggi mendefinisikan pesan yang ditandatangani dan syarat lebih lanjut.

Registri otoritas menyisihkan rentang terpisah untuk skema standar dan kustom. KCC-2 mengizinkan peserta untuk mengadopsi skema kustom tanpa menunggu standarisasi, asalkan definisi mereka menentukan format, makna, dan pemeriksaan persetujuan.

Di bawah skema pengenal perjanjian, persetujuan memerlukan masukan dari garis keturunan perjanjian yang diidentifikasi. KCC-2 mengatakan bahwa konvensi tingkat lebih tinggi dapat memberlakukan pemeriksaan lebih lanjut pada program dan status masukan tersebut.

KCC-20 menetapkan aturan transfer dan penerimaan token

KCC-20 membangun di atas dua standar pertama, mendefinisikan jumlah token, kepemilikan, dan antarmuka transfer. Dokumen tersebut menyebut Sivan Helfer, Sutton, Newman, dan Billot sebagai penulisnya.

Spesifikasinya mengharuskan setiap perjanjian token untuk menerbitkan informasi program yang dapat digunakan perangkat lunak untuk mendekode status dan membangun transfer. Konfigurasi harus mengungkapkan skema kepemilikan yang didukung dan batasan pada masukan dan keluaran token.

Fitur yang disebut borrowed receive memungkinkan pengirim menggunakan keluaran token kompatibel yang sudah ada dari penerima sebagai tujuan. KCC-20 mengatakan bahwa transaksi tersebut menciptakan kembali keluaran itu dengan lebih banyak token, mempertahankan kepemilikannya dan status yang diperluas, dan tidak dapat mengurangi nilai KAS-nya.

Bagian keamanan memperingatkan bahwa mengganti keluaran mengubah referensi transaksinya, membatalkan transaksi yang belum terkonfirmasi yang menggunakan referensi sebelumnya. Sebuah dompet harus menemukan penggantian tersebut sebelum menggunakannya, menurut dokumen tersebut.

Standar ini menghubungkan implementasi referensi Argent dengan kontrak SilverScript yang dihasilkan dan tes kepatuhan Rust.

Status akhir membawa persyaratan implementasi

KCC-0, dokumen yang mengatur proses standar, memerlukan lebih dari sekadar penyelesaian periode tinjauan akhir. Ia mengatakan bahwa konvensi jalur standar memerlukan vektor uji yang dapat dibaca manusia dan mesin, ditambah setidaknya satu implementasi publik yang lulus pemeriksaan yang dapat dibaca mesin.

Ketergantungan harus Final untuk KCC lainnya atau Aktif untuk KIP, sesuai dengan aturan yang sama. KCC-0 mengatakan perubahan status terjadi melalui permintaan tarik dan indeks repositori harus diperbarui dengannya.

KCC-0 menggambarkan vektor uji yang dapat dibaca mesin sebagai bentuk otoritatif untuk pengujian otomatis ketika disertai dengan contoh yang dapat dibaca manusia. Aturan pengirimannya mengharuskan pertimbangan keamanan untuk menangani ancaman, asumsi kepercayaan, dan potensi masalah pengulangan sebelum dokumen jalur standar dapat memasuki Last Call.

Dokumen pengatur menyatakan bahwa finalisasi tidak memerlukan setiap peserta ekosistem untuk menerapkan konvensi. Perubahan substansial umumnya memerlukan KCC pengganti, sementara koreksi dan klarifikasi mengikuti aturan amandemen dokumen tersebut.

Pengembangan aplikasi Kaspa sebelumnya telah mencakup infrastruktur Layer 2 terpisah. Gate mengumumkan integrasi Kasplex Layer 2 pada bulan April, memungkinkan setoran dan penarikan KAS melalui jaringan yang kompatibel dengan EVM, seperti yang dilaporkan crypto.news.

Dalam pengumuman integrasi sebelumnya, Gate mengatakan pelanggan dapat mentransfer KAS dari jaringan dasar ke dompet Kasplex. Materi proyek Kasplex menggambarkan jembatan dua arah dan mengatakan pengembang yang akrab dengan alat Ethereum dapat menerapkan kontrak dengan mengubah titik akhir panggilan prosedur jarak jauh mereka.

Kasplex menggambarkan desainnya sebagai rollup ringan yang menempatkan bytecode EVM dalam transaksi Kaspa dan mengeksekusinya di luar rantai. Dokumentasinya mengatakan Kaspa menyediakan urutan transaksi dan ketersediaan data, sementara KAS yang dijembatani berfungsi sebagai token gas Layer 2.