KTAPEOUT Protocol 0.5.0 Developer Documentation

Status: Developer Preview / English public documentation
Protocol: 0.5.0
Network posture: Testnet-10 oriented; not a Mainnet authorization

KTAPEOUT Protocol 0.5.0 defines deterministic transitions over verified computation Profiles and composable application state on Kaspa. This candidate supports local unsigned contract workflows; it does not execute general application behavior or provide a complete live publishing stack. The protocol model is:

Imagine → Compose → KTAPEOUT

Profile → Artifact → Transition → Persistent State

Start here

• Build a local runtime package — deterministic package output without upload or signing.

• The application platform — the idea-to-address workflow, interaction choices and open ecosystem.
• Overview — the protocol boundary in one page.
• Install and verify — prerequisites and clean-checkout verification.
• Scaffold and inspect a local project — unsigned structural preview; does not execute application behavior.
• TN10 publication boundary and readback — external signer/readback requirements; not a self-contained publish flow.
• Storage, integrity and retention — distinguish content identity, locations, authorization, availability and recovery.
• Plan and verify application storage on TN10 — prepare a storage path and collect evidence within the public-candidate boundary.
• Application discovery images — optional content-bound images, validation and curated directory preview.
• Naming reference — canonical IDs, aliases, versions and URIs.
• Identity, versions and content hashes — how names, revisions and digests stay distinct.
• State topology and composition — bounded transitions, roots and composition boundaries.
• CLI reference — commands and their authority boundaries.
• Composition and locks — reproducible dependency selection.
• Schemas and errors — machine-readable contracts and failure classes.
• Encoding and commitments — canonical bytes, hashes and commitment inputs.
• Author a Profile package — a minimal authoring workflow.
• Design, build and validate — the local development loop.
• Third-party participation and application access — build your own website, gateway, client or ecosystem tools.
• Core and CLI source — the release-shaped Rust implementation.
• Examples — unsigned deterministic fixtures for local inspection.
• Capabilities and status — what is local, external, or unavailable.
• Runtimes and adapters — the client-neutral contract and provider boundary.
• Protocol specification — the English specification map and normative-status notice.
• AI-assisted development — the public KTAPEOUT AI Skill and safe setup guidance for common coding assistants.

Choose documentation by task

• Learn the supported protocol path: start with Install and verify, then Scaffold and inspect a local project.
• Build a Profile or Package: use Author a Profile Package; use Design, Build and Validate for the broader local workflow.
• Understand the model: read Overview first, then Profiles, Packages and Recipes.
• Look up exact behavior: use CLI, Schemas and Errors, and Capabilities and Status; use the Protocol map and Conformance for normative details.
• Prepare a TN10 write: read Plan, publish and verify on Testnet-10. This candidate describes the external boundary; it does not provide a complete live publishing stack.

Tutorials explain a first path, guides solve a task, concepts explain design choices, and reference/protocol pages define lookup and conformance details. If pages disagree, follow the authority order in Document status and the current implementation boundary stated there.

Document status

Engineering contributions follow the code and API standards.

This directory is the English public documentation source for the 0.5.0 candidate. The English protocol text is the sole normative language for the 0.5.0 release; guides and examples are explanatory only. Identifiers, field names, hashes, vectors and command flags are retained exactly. Historical plans and research records are not developer entrypoints.

Scope boundary

The release is a controlled Testnet-10 prototype and reference implementation. Local builds, profiles, artifacts and receipts do not grant signing authority, wallet custody, broadcast authority, Mainnet access, or generic L1 admission. Those boundaries are explicit in the capability table.