Kaspa finaliza 3 padrões para tokens nativos e aplicativos de convenção

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

Resumo

• KCC-1 define interfaces compartilhadas para carteiras, compiladores, indexadores e outras ferramentas que trabalham com convenções.
• KCC-2 especifica cinco esquemas de autorização padrão, incluindo chaves públicas, scripts e identificadores de convenção.
• 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 um comunicado de 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 convenção, KCC-2 como a especificação de autoridade e KCC-20 como o padrão de aplicação para convenções 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ó central, que pertencem às Propostas de Melhoria da Kaspa.

Os padrões da Kaspa cobrem diferentes partes do desenvolvimento de aplicações

KCC-1 define termos comuns, layouts de dados e uma interface binária de aplicação, ou ABI, para convenções. 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 convenção. Programas sem ligações de convenção 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 convenção 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 convenção participe como uma autoridade.

Para autorização de hash de chave pública, o 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 outras condições.

O registro de autoridades reserva intervalos separados para esquemas padrão e personalizados. O 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 o seu esquema de identificação de convenções, a aprovação requer uma entrada da linhagem de convenção 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 para transferência e recepção 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 convenção de token publique informações do programa que o software pode 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 "receber emprestado" permite que um remetente use uma saída de token compatível existente do 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 rege 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 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 pull requests 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 acompanhados por 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 de substituição, enquanto correções e esclarecimentos seguem as regras de emenda do documento.

O desenvolvimento de aplicações da Kaspa incluiu anteriormente 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 finais 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.