Kaspa finalizza 3 standard per token nativi e app covenant

Il Forum di Coordinamento KCC di Kaspa ha finalizzato tre standard che coprono interfacce di covenant, autorizzazione e token fungibili, stabilendo specifiche condivise per gli sviluppatori che costruiscono applicazioni sulla rete.

Riepilogo

• KCC-1 definisce interfacce condivise per portafogli, compilatori, indicizzatori e altri strumenti che lavorano con i covenant.
• KCC-2 specifica cinque schemi di autorizzazione standard, inclusi chiavi pubbliche, script e identificatori di covenant.
• KCC-20 stabilisce regole per il trasferimento di token e supporta la ricezione di token tramite un output compatibile esistente.
• La finalizzazione stabilisce convenzioni ecosistemiche senza modificare le regole di consenso o richiedere a ogni partecipante di adottarle.

Il Forum di Coordinamento KCC ha dichiarato in un annuncio del 21 ottobre che KCC-1, KCC-2 e KCC-20 erano finali e pronti per l'adozione in tutto l'ecosistema. Il forum ha invitato i costruttori a unirsi al suo canale pubblico per domande, discussioni sull'implementazione e supporto.

Saluti $KAS. KCC-1, KCC-2 e KCC-20 sono ora finali, il che significa che sono pronti per l'adozione completa in tutto l'ecosistema.

Invitiamo i costruttori di Kaspa a unirsi al canale pubblico KCC per porre domande, ricevere supporto, discutere implementazioni e condividere ciò che costruite.

Venite a costruire con noi. --- Forum di Coordinamento KCC (@kccforum) 21 ottobre 2026

Il repository degli standard canonici di Kaspa elenca tutti e tre i documenti come finali. Il suo indice identifica KCC-1 come la specifica del covenant, KCC-2 come la specifica dell'autorità e KCC-20 come lo standard applicativo per i covenant di token fungibili.

Il repository descrive i KCC come convenzioni condivise per implementazioni indipendenti. La sua documentazione separa quelle convenzioni dalle modifiche al consenso o al comportamento del nodo centrale, che appartengono alle Proposte di Miglioramento di Kaspa.

Gli standard Kaspa coprono diverse parti dello sviluppo delle applicazioni

KCC-1 definisce termini comuni, layout dei dati e un'interfaccia binaria dell'applicazione, o ABI, per i covenant. La specifica descrive come il software codifica le informazioni, chiama le funzioni del programma e identifica lo stato trasportato tra le transazioni.

I suoi autori, Romain Billot, Michael Sutton e Ori Newman, identificano compilatori, portafogli, indicizzatori e costruttori di transazioni tra gli strumenti che devono concordare su quei dettagli. Il documento afferma che le implementazioni indipendenti necessitano di formati comuni oltre a semplicemente produrre script che superano i controlli di consenso.

La specifica KCC-1 lascia liberi gli sviluppatori di scegliere il proprio linguaggio di programmazione, compilatore e framework. La sua interfaccia condivisa copre i punti di ingresso del programma, i modelli di stato e le regole per gestire transazioni che coinvolgono più input.

All'interno dello stesso documento, gli autori distinguono le regole di interfaccia di base dalle funzionalità che dipendono dagli identificatori di covenant. I programmi senza legami di covenant possono seguire KCC-1, ma la specifica afferma che non ricevono le garanzie di parentela e autorizzazione fornite da KIP-20.

KCC-2 definisce chi può autorizzare un'operazione

KCC-2, scritto da Billot e Sutton, specifica come i programmi identificano un'autorità e i controlli minimi richiesti per stabilire la sua approvazione. Un'autorità può essere una chiave pubblica, un impegno a una chiave, uno script o una linea di covenant continuativa.

La specifica assegna identificatori standard a cinque schemi di autorizzazione. Le sue opzioni di chiave pubblica coprono le firme Schnorr e ECDSA, mentre le altre opzioni consentono a uno script o a una linea di covenant di partecipare come autorità.

Per l'autorizzazione tramite hash di chiave pubblica, KCC-2 richiede che la transazione riveli la corrispondente chiave pubblica, confronti il suo hash con il valore di autorità memorizzato e fornisca una firma valida. Specifiche di livello superiore definiscono il messaggio firmato e eventuali ulteriori condizioni.

Il registro delle autorità riserva intervalli separati per schemi standard e personalizzati. KCC-2 consente ai partecipanti di adottare schemi personalizzati senza attendere la standardizzazione, a condizione che le loro definizioni specifichino il formato, il significato e i controlli di approvazione.

Sotto il suo schema di identificazione dei covenant, l'approvazione richiede un input dalla linea di covenant identificata. KCC-2 afferma che una convenzione di livello superiore può imporre ulteriori controlli sul programma e sullo stato di quell'input.

KCC-20 stabilisce regole per il trasferimento e la ricezione dei token

KCC-20 si basa sui primi due standard, definendo le quantità di token, la proprietà e le interfacce di trasferimento. Il documento nomina Sivan Helfer, Sutton, Newman e Billot come autori.

La sua specifica richiede che ogni covenant di token pubblichi informazioni sul programma che il software può utilizzare per decodificare lo stato e costruire trasferimenti. Le configurazioni devono rivelare gli schemi di proprietà supportati e i limiti sugli input e output dei token.

Una funzione chiamata "ricezione in prestito" consente a un mittente di utilizzare l'output di token compatibile esistente di un destinatario come destinazione. KCC-20 afferma che la transazione ricrea quell'output con più token, preserva la sua proprietà e stato esteso, e non può ridurre il suo valore KAS.

La sezione di sicurezza avverte che la sostituzione dell'output cambia il riferimento della transazione, invalidando le transazioni non confermate che spendono il riferimento precedente. Un portafoglio deve scoprire la sostituzione prima di spenderlo, secondo il documento.

Lo standard collega un'implementazione di riferimento Argent con contratti SilverScript generati e test di conformità Rust.

Lo stato finale comporta requisiti di implementazione

KCC-0, il documento che governa il processo degli standard, richiede più della semplice conclusione di un periodo di revisione finale. Affirma che una convenzione in fase di standardizzazione ha bisogno di vettori di test leggibili da esseri umani e leggibili da macchina, oltre a almeno un'implementazione pubblica che superi i controlli leggibili da macchina.

Le dipendenze devono essere Final per altri KCC o Active per KIPs, secondo le stesse regole. KCC-0 afferma che i cambiamenti di stato avvengono tramite pull request e l'indice del repository deve essere aggiornato con essi.

KCC-0 descrive i vettori di test leggibili da macchina come la forma autorevole per il testing automatizzato quando accompagnati da esempi leggibili da esseri umani. Le sue regole di sottomissione richiedono che le considerazioni di sicurezza affrontino minacce, assunzioni di fiducia e potenziali problemi di replay prima che un documento in fase di standardizzazione possa entrare in Last Call.

Il documento di governo afferma che la finalizzazione non richiede che ogni partecipante all'ecosistema implementi una convenzione. Cambiamenti sostanziali richiedono generalmente un KCC di sostituzione, mentre correzioni e chiarimenti seguono le regole di emendamento del documento.

Lo sviluppo dell'applicazione di Kaspa ha precedentemente incluso un'infrastruttura Layer 2 separata. Gate ha annunciato un'integrazione Layer 2 di Kasplex ad aprile, consentendo depositi e prelievi di KAS attraverso la rete compatibile con EVM, come riportato da crypto.news.

Nell'annuncio di integrazione precedente, Gate ha affermato che i clienti potevano trasferire KAS dalla rete di base a un portafoglio Kasplex. I materiali del progetto di Kasplex descrivono un ponte bidirezionale e affermano che gli sviluppatori familiari con gli strumenti di Ethereum possono distribuire contratti modificando i loro endpoint di chiamata a procedura remota.

Kasplex descrive il suo design come un rollup leggero che colloca il bytecode EVM nelle transazioni di Kaspa ed esegue il codice off-chain. La sua documentazione afferma che Kaspa fornisce l'ordinamento delle transazioni e la disponibilità dei dati, mentre il KAS collegato funge da token di gas Layer 2.