Kaspa finaliza 3 estándares para tokens nativos y aplicaciones de pacto

El Foro de Coordinación KCC de Kaspa ha finalizado tres estándares que cubren interfaces de pacto, autorización y tokens fungibles, estableciendo especificaciones compartidas para los desarrolladores que construyen aplicaciones en la red.

Resumen

• KCC-1 define interfaces compartidas para billeteras, compiladores, indexadores y otras herramientas que trabajan con pactos.
• KCC-2 especifica cinco esquemas de autorización estándar, incluidos claves públicas, scripts e identificadores de pacto.
• KCC-20 establece reglas de transferencia de tokens y admite la recepción de tokens a través de una salida compatible existente.
• La finalización establece convenciones del ecosistema sin cambiar las reglas de consenso ni requerir que cada participante las adopte.

El Foro de Coordinación KCC dijo en un anuncio del 21 de octubre que KCC-1, KCC-2 y KCC-20 eran finales y estaban listos para su adopción en todo el ecosistema. El foro invitó a los constructores a unirse a su canal público para preguntas, discusiones sobre implementación y soporte.

Saludos $KAS. KCC-1, KCC-2 y KCC-20 son ahora finales, lo que significa que están listos para la adopción total en todo el ecosistema.

Invitamos a los constructores de Kaspa a unirse al canal público de KCC para hacer preguntas, obtener apoyo, discutir implementaciones y compartir lo que construyen.

Ven a construir con nosotros. --- Foro de Coordinación KCC (@kccforum) 21 de octubre de 2026

El repositorio de estándares canónicos de Kaspa enumera los tres documentos como finales. Su índice identifica KCC-1 como la especificación de pacto, KCC-2 como la especificación de autoridad y KCC-20 como el estándar de aplicación para pactos de tokens fungibles.

El repositorio describe los KCC como convenciones compartidas para implementaciones independientes. Su documentación separa esas convenciones de los cambios en el consenso o el comportamiento del nodo central, que pertenecen a las Propuestas de Mejora de Kaspa.

Los estándares de Kaspa cubren diferentes partes del desarrollo de aplicaciones

KCC-1 define términos comunes, diseños de datos y una interfaz binaria de aplicación, o ABI, para pactos. La especificación describe cómo el software codifica información, llama funciones de programa e identifica el estado que se transporta entre transacciones.

Sus autores, Romain Billot, Michael Sutton y Ori Newman, identifican compiladores, billeteras, indexadores y constructores de transacciones entre las herramientas que necesitan acordar esos detalles. El documento dice que las implementaciones independientes necesitan formatos comunes más allá de simplemente producir scripts que pasen las verificaciones de consenso.

La especificación KCC-1 deja a los desarrolladores libres para elegir su lenguaje de programación, compilador y marco. Su interfaz compartida cubre puntos de entrada del programa, plantillas de estado y reglas para manejar transacciones que involucren múltiples entradas.

Dentro del mismo documento, los autores distinguen las reglas básicas de la interfaz de las características que dependen de los identificadores de pacto. Los programas sin enlaces de pacto pueden seguir KCC-1, pero la especificación dice que no reciben las garantías de linaje y autorización proporcionadas por KIP-20.

KCC-2 define quién puede autorizar una operación

KCC-2, escrito por Billot y Sutton, especifica cómo los programas identifican una autoridad y las verificaciones mínimas requeridas para establecer su aprobación. Una autoridad puede ser una clave pública, un compromiso a una clave, un script o un linaje de pacto continuo.

La especificación asigna identificadores estándar a cinco esquemas de autorización. Sus opciones de clave pública cubren firmas de Schnorr y ECDSA, mientras que sus otras opciones permiten que un script o linaje de pacto participe como autoridad.

Para la autorización de hash de clave pública, KCC-2 requiere que la transacción revele la clave pública correspondiente, coincida su hash con el valor de autoridad almacenado y proporcione una firma válida. Especificaciones de nivel superior definen el mensaje firmado y cualquier condición adicional.

El registro de autoridades reserva rangos separados para esquemas estándar y personalizados. KCC-2 permite a los participantes adoptar esquemas personalizados sin esperar la estandarización, siempre que sus definiciones especifiquen el formato, significado y verificaciones de aprobación.

Bajo su esquema de identificador de convenios, la aprobación requiere una entrada de la línea de convenios identificada. KCC-2 dice que una convención de nivel superior puede imponer más controles sobre el programa y el estado de esa entrada.

KCC-20 establece reglas para la transferencia y recepción de tokens

KCC-20 se basa en los dos primeros estándares, definiendo cantidades de tokens, propiedad e interfaces de transferencia. El documento nombra a Sivan Helfer, Sutton, Newman y Billot como sus autores.

Su especificación requiere que cada convenio de token publique información del programa que el software pueda usar para decodificar el estado y construir transferencias. Las configuraciones deben revelar los esquemas de propiedad soportados y los límites en las entradas y salidas de tokens.

Una característica llamada "recepción prestada" permite a un remitente usar una salida de token compatible existente del destinatario como destino. KCC-20 dice que la transacción recrea esa salida con más tokens, preserva su propiedad y estado extendido, y no puede reducir su valor KAS.

La sección de seguridad advierte que reemplazar la salida cambia su referencia de transacción, invalidando las transacciones no confirmadas que gastan la referencia anterior. Una billetera debe descubrir el reemplazo antes de gastarlo, según el documento.

El estándar vincula una implementación de referencia de Argent con contratos generados de SilverScript y pruebas de conformidad de Rust.

El estado final conlleva requisitos de implementación

KCC-0, el documento que rige el proceso de estándares, requiere más que la finalización de un período de revisión final. Dice que una convención en la pista de estándares necesita vectores de prueba legibles por humanos y máquinas, además de al menos una implementación pública que pase las verificaciones legibles por máquina.

Las dependencias deben ser Final para otros KCC o Activas para KIPs, de acuerdo con las mismas reglas. KCC-0 dice que los cambios de estado ocurren a través de solicitudes de extracción y el índice del repositorio debe actualizarse con ellos.

KCC-0 describe los vectores de prueba legibles por máquina como la forma autoritativa para pruebas automatizadas cuando acompañan ejemplos legibles por humanos. Sus reglas de presentación requieren que las consideraciones de seguridad aborden amenazas, suposiciones de confianza y problemas de repetición potenciales antes de que un documento en la pista de estándares pueda entrar en Última Llamada.

El documento rector establece que la finalización no requiere que cada participante del ecosistema implemente una convención. Los cambios sustantivos generalmente requieren un KCC de reemplazo, mientras que las correcciones y aclaraciones siguen las reglas de enmienda del documento.

El desarrollo de aplicaciones de Kaspa ha incluido previamente infraestructura separada de Capa 2. Gate anunció una integración de Capa 2 de Kasplex en abril, permitiendo depósitos y retiros de KAS a través de la red compatible con EVM, como informó crypto.news.

En su anuncio de integración anterior, Gate dijo que los clientes podían transferir KAS de la red base a una billetera Kasplex. Los materiales del proyecto de Kasplex describen un puente bidireccional y dicen que los desarrolladores familiarizados con las herramientas de Ethereum pueden implementar contratos cambiando sus puntos finales de llamada a procedimiento remoto.

Kasplex describe su diseño como un rollup ligero que coloca bytecode de EVM en transacciones de Kaspa y lo ejecuta fuera de la cadena. Su documentación dice que Kaspa suministra el orden de las transacciones y la disponibilidad de datos, mientras que el KAS puenteado sirve como el token de gas de Capa 2.