Kaspa finaliza três padrões KCC para tokens nativos e covenants

A KCC Coordination Forum anunciou em 21 de outubro que os padrões KCC-1, KCC-2 e KCC-20 estão finais e prontos para adoção no ecossistema da Kaspa, segundo o repositório canônico de normas da rede, que lista os três documentos como Final.

KCC-1 define termos comuns, camadas de dados e a interface binária de aplicação (ABI) dos covenants, os contratos que carregam estado entre transações. A especificação, escrita por Romain Billot, Michael Sutton e Ori Newman, cobre pontos de entrada de programa, modelos de estado e regras para transações com múltiplas entradas, e deixa o desenvolvedor livre para escolher linguagem, compilador e framework. Programas sem vínculo de covenant podem seguir o KCC-1, mas a norma diz que eles não recebem as garantias de linhagem e autorização do KIP-20.

KCC-2 descreve quem pode autorizar uma operação. Cinco esquemas de autorização recebem identificadores padrão, cobrindo assinaturas Schnorr e ECDSA, compromissos de chave, scripts e linhagens de covenant. Para autorização por hash de chave pública, a transação precisa revelar a chave pública correspondente, conferir o hash contra o valor armazenado e apresentar assinatura válida. O registro de autoridades reserva faixas separadas para esquemas padrão e personalizados, e estes podem ser adotados sem esperar padronização, desde que suas definições especifiquem formato, significado e verificações de aprovação.

KCC-20 estabelece as regras de transferência e recebimento de tokens fungíveis sobre os dois primeiros, com autores Sivan Helfer, Sutton, Newman e Billot. Cada covenant de token precisa publicar informação de programa que o software use para decodificar o estado e montar transferências, revelando os esquemas de propriedade aceitos e os limites de entradas e saídas. O padrão inclui a função borrowed receive, em que o remetente usa uma saída de token compatível já existente do destinatário: a transação recria essa saída com mais tokens, preserva a propriedade e o estado estendido e não pode reduzir o valor em KAS.

A seção de segurança do KCC-20 avisa que substituir a saída muda a referência da transação e invalida transações não confirmadas que gastam a referência anterior, razão pela qual a carteira precisa descobrir a substituição antes de gastar. O status final não exige que todo participante do ecossistema adote a convenção, mas o processo KCC-0 exige vetores de teste legíveis por humano e por máquina e ao menos uma implementação pública que passe nos testes, com dependências em status Final ou Active. Mudanças de substância exigem um KCC de substituição. A finalização não altera regras de consenso nem comportamento do nó, que mudam por propostas de melhoria (KIPs).

A Kaspa já tem infraestrutura de aplicação fora do protocolo base: a Gate anunciou em abril a integração do Kasplex, rollup leve compatível com EVM que executa bytecode fora da cadeia usando a Kaspa para ordenação e disponibilidade de dados, com KAS em ponte como token de gás da segunda camada.