Kaspa finaliza 3 padrões para tokens nativos e aplicativos de convênios

O Fórum de Coordenação KCC da Kaspa finalizou três padrões que abrangem interfaces de convênios, autorização e tokens fungíveis, estabelecendo especificações compartilhadas para desenvolvedores que constroem aplicativos na rede.

Resumo

• KCC-1 define interfaces compartilhadas para carteiras, compiladores, indexadores e outras ferramentas que trabalham com convênios.
• KCC-2 especifica cinco esquemas de autorização padrão, incluindo chaves públicas, scripts e identificadores de convênios.
• KCC-20 estabelece regras de transferência de tokens e suporta o recebimento de tokens através de uma saída compatível existente.
• A finalização estabelece convenções do ecossistema sem alterar as regras de consenso ou exigir que todos os participantes as adotem.

O Fórum de Coordenação KCC anunciou em 21 de outubro que KCC-1, KCC-2 e KCC-20 estavam finais e prontos para adoção em todo o ecossistema. O fórum convidou os construtores a se juntarem ao seu canal público para perguntas, discussões sobre implementação e suporte.

Saudações $KAS. KCC-1, KCC-2 e KCC-20 agora são Finais, o que significa que estão prontos para adoção total em todo o ecossistema.

Convidamos os construtores da Kaspa a se juntarem ao canal público KCC para fazer perguntas, obter suporte, discutir implementações e compartilhar o que você constrói.

Venha construir conosco. --- Fórum de Coordenação KCC (@kccforum) 21 de outubro de 2026

O repositório de padrões canônicos da Kaspa lista todos os três documentos como Finais. Seu índice identifica KCC-1 como a especificação de convênios, KCC-2 como a especificação de autoridade e KCC-20 como o padrão de aplicação para convênios de tokens fungíveis.

O repositório descreve os KCCs como convenções compartilhadas para implementações independentes. Sua documentação separa essas convenções de mudanças no consenso ou no comportamento do nó principal, que pertencem às Propostas de Melhoria da Kaspa.

Padrões da Kaspa cobrem diferentes partes do desenvolvimento de aplicativos

KCC-1 define termos comuns, layouts de dados e uma interface binária de aplicativo, ou ABI, para convênios. A especificação descreve como o software codifica informações, chama funções de programa e identifica o estado transportado entre transações.

Seus autores, Romain Billot, Michael Sutton e Ori Newman, identificam compiladores, carteiras, indexadores e construtores de transações entre as ferramentas que precisam concordar com esses detalhes. O documento afirma que implementações independentes precisam de formatos comuns além de simplesmente produzir scripts que passam nas verificações de consenso.

A especificação KCC-1 deixa os desenvolvedores livres para escolher sua linguagem de programação, compilador e estrutura. Sua interface compartilhada cobre pontos de entrada do programa, modelos de estado e regras para lidar com transações envolvendo múltiplas entradas.

Dentro do mesmo documento, os autores distinguem regras básicas de interface de recursos que dependem de identificadores de convênios. Programas sem vinculações de convênios podem seguir o KCC-1, mas a especificação afirma que eles não recebem as garantias de linhagem e autorização fornecidas pelo KIP-20.

KCC-2 define quem pode autorizar uma operação

KCC-2, escrito por Billot e Sutton, especifica como os programas identificam uma autoridade e as verificações mínimas necessárias para estabelecer sua aprovação. Uma autoridade pode ser uma chave pública, um compromisso com uma chave, um script ou uma linhagem de convênio contínua.

A especificação atribui identificadores padrão a cinco esquemas de autorização. Suas opções de chave pública cobrem assinaturas Schnorr e ECDSA, enquanto suas outras opções permitem que um script ou linhagem de convênio participe como uma autoridade.

Para autorização de hash de chave pública, KCC-2 exige que a transação revele a chave pública correspondente, combine seu hash com o valor de autoridade armazenado e forneça uma assinatura válida. Especificações de nível superior definem a mensagem assinada e quaisquer condições adicionais.

O registro de autoridades reserva faixas separadas para esquemas padrão e personalizados. KCC-2 permite que os participantes adotem esquemas personalizados sem esperar pela padronização, desde que suas definições especifiquem o formato, significado e verificações de aprovação.

Sob seu esquema de identificador de convênios, a aprovação requer uma entrada da linhagem de convênios identificada. O KCC-2 afirma que uma convenção de nível superior pode impor verificações adicionais sobre o programa e o estado dessa entrada.

KCC-20 estabelece regras de transferência e recebimento de tokens

O KCC-20 baseia-se nos dois primeiros padrões, definindo quantidades de tokens, propriedade e interfaces de transferência. O documento nomeia Sivan Helfer, Sutton, Newman e Billot como seus autores.

Sua especificação exige que cada convênio de token publique informações do programa que o software possa usar para decodificar o estado e construir transferências. As configurações devem divulgar esquemas de propriedade suportados e limites sobre entradas e saídas de tokens.

Um recurso chamado recebimento emprestado permite que um remetente use a saída de token compatível existente de um destinatário como destino. O KCC-20 afirma que a transação recria essa saída com mais tokens, preserva sua propriedade e estado estendido, e não pode reduzir seu valor KAS.

A seção de segurança alerta que substituir a saída altera sua referência de transação, invalidando transações não confirmadas que gastam a referência anterior. Uma carteira deve descobrir a substituição antes de gastá-la, de acordo com o documento.

O padrão vincula uma implementação de referência Argent com contratos SilverScript gerados e testes de conformidade em Rust.

O status final carrega requisitos de implementação

O KCC-0, o documento que governa o processo de padrões, exige mais do que a conclusão de um período de revisão final. Ele afirma que uma convenção em trilha de padrões precisa de vetores de teste legíveis por humanos e legíveis por máquinas, além de pelo menos uma implementação pública que passe nas verificações legíveis por máquinas.

As dependências devem ser Finais para outros KCCs ou Ativas para KIPs, de acordo com as mesmas regras. O KCC-0 afirma que mudanças de status ocorrem através de solicitações de pull e o índice do repositório deve ser atualizado com elas.

O KCC-0 descreve vetores de teste legíveis por máquinas como a forma autoritativa para testes automatizados quando acompanham exemplos legíveis por humanos. Suas regras de submissão exigem que considerações de segurança abordem ameaças, suposições de confiança e potenciais problemas de repetição antes que um documento em trilha de padrões possa entrar na Última Chamada.

O documento governante afirma que a finalização não exige que todos os participantes do ecossistema implementem uma convenção. Mudanças substanciais geralmente requerem um KCC substituto, enquanto correções e esclarecimentos seguem as regras de emenda do documento.

O desenvolvimento de aplicativos da Kaspa já incluiu infraestrutura separada de Camada 2. A Gate anunciou uma integração de Camada 2 Kasplex em abril, permitindo depósitos e retiradas de KAS através da rede compatível com EVM, conforme relatado pela crypto.news.

Em seu anúncio anterior de integração, a Gate disse que os clientes poderiam transferir KAS da rede base para uma carteira Kasplex. Os materiais do projeto Kasplex descrevem uma ponte bidirecional e afirmam que desenvolvedores familiarizados com ferramentas Ethereum podem implantar contratos alterando seus pontos de chamada de procedimento remoto.

Kasplex descreve seu design como um rollup leve que coloca bytecode EVM em transações Kaspa e o executa fora da cadeia. Sua documentação afirma que a Kaspa fornece ordenação de transações e disponibilidade de dados, enquanto o KAS conectado serve como o token de gás da Camada 2.