Kaspa presents its history as a continuation of research into proof-of-work ledgers, with roots in GHOST, SPECTRE and PHANTOM. Its public identity combines that academic lineage with a November 2021 mining launch that allocated no coins through a premine or presale. Those two features explain much of its appeal: supporters want an engineering argument for faster settlement without abandoning open mining. Neither feature proves that ownership is evenly distributed today.

The project’s own history page calls the resulting community broad and loyal, which is a statement of self-understanding rather than a survey. A useful history preserves that ambition while leaving room to examine who runs infrastructure, who funds development and how applications actually use the network.

The PHANTOM and GHOSTDAG paper addresses the difficulty of producing blocks faster than they can reliably reach every participant. Rather than discarding every competing branch, the design lets blocks reference multiple predecessors and derives an agreed order from the resulting graph. GHOSTDAG is the practical greedy algorithm developed from the more expensive PHANTOM formulation. The security argument depends on an honest majority of computational power and explicit network assumptions.

It does not say that parallel blocks make double spending irrelevant or that every observed transaction becomes irreversible instantly. For a newcomer, the important distinction is between allowing concurrent block production and agreeing which conflicting transaction is accepted. Kaspa still needs the latter, even though the ledger is not organized as a simple line.

The tokenomics reference identifies KAS as a mined coin and describes a monetary schedule that changes from an initial phase into monthly geometric reductions. The declining phase began in May 2022, with reductions designed to approximate a yearly halving. The familiar maximum of roughly 28.7 billion KAS is an approximation; the reference explains small differences caused by discrete units and the way parallel blocks meet transition boundaries. It is therefore better to state the scale than invent precision from an old chart.

The policy makes future subsidy declines visible to miners and holders. It does not promise that falling issuance creates enough transaction fees to replace that subsidy or that scarcity by itself will sustain market demand.

KIP-14 describes the Crescendo change from one to ten blocks per second, along with adjustments to difficulty sampling, storage rules, script introspection and other consensus parameters. The reward calculation was adapted so that a higher number of blocks did not multiply the intended per-second emission. This is an important distinction when a network advertises a tenfold increase: block frequency is a protocol setting, not a tenfold increase in coin issuance or proof that applications have ten times as many users.

The specification also discusses bandwidth, storage and pruning consequences. Faster blocks offer more opportunities for inclusion, but they impose real engineering obligations on nodes. The Rust implementation and related parameter changes were part of making that transition operationally possible.

The March 2025 Crescendo node release explained that the default pruning period would become shorter as the block rate increased and offered a configurable retention period for operators needing more history. A pruned node is not the same service as an archive or a business indexer retaining every application event. Builders who need historical records must decide where those records live and how they are recovered. The release also required a new peer-to-peer protocol version before the fork. These operational details show why an upgrade is more than a headline about speed.

Wallet providers, exchanges, miners and data services have to update compatible software and plan storage together, even when the user-facing act of sending KAS looks unchanged.

The mining reference says that specialized ASIC hardware now accounts for the practical mining environment, after an earlier period of CPU and GPU participation. It distinguishes running one’s own node and mining independently from joining a pool that distributes work and accounts for rewards. It also explains that ASIC connections generally need a Stratum adapter rather than speaking the node’s native protocol directly. These details matter to the culture of participation: buying KAS, operating a node and owning a profitable miner are different activities.

A pool can smooth payout variability, while an independent operator takes on more infrastructure and variance. None of the documented methods guarantees profitability as hardware prices, electricity costs, difficulty and the subsidy change.

Kaspa’s integration guide tells services to follow accepted transactions, keep durable checkpoints and handle blocks removed from the virtual chain. Near the active tips, ordering can still change. The guide recommends a confirmation buffer and explains how a consumer should undo data associated with a removed accepting block before applying its replacement. This is concrete evidence against treating the first visible block as universal final settlement. A wallet notification and a merchant’s irreversible credit decision need not use the same threshold.

The API supports both polling and live subscriptions, but a disconnected subscription must recover from stored state. Fast updates are useful only when the system recording them can reconcile what was ultimately accepted.

The current developer guide explicitly states that Toccata activated on mainnet on June 30, 2026. It adds transaction fields, covenant identity, introspection, execution metering and proof-verification facilities. The model remains based on unspent transaction outputs. Applications express valid transitions between outputs instead of assuming a global mutable contract account. That difference affects both design and review: a programmer needs to explain which output carries state and what the next spend must recreate.

The guide also separates live consensus features from younger development tools.

The covenant-state guide follows a simple stateful output through a spend. The spending transaction reveals the old script and state, checks the transition and must create an output committing to the permitted successor. Because the script commitment changes with state, covenant identifiers provide a way to track a continuing family. Identity alone is not sufficient: the script still has to establish that the new output has the right policy and state.

This gives builders tools for vaults, conditional transfers and other asset rules, while placing a clear obligation on transaction construction. A design that checks a signature but forgets the authorized successor can fail to preserve the very restriction its users expected.

Silverscript is the documented authoring path for Toccata covenants. It lets developers describe state and transition policies while the compiler produces stack encoding, interface layout and repeated successor checks. That makes the intended rule easier to inspect than a long hand-written sequence of low-level operations. The documentation nevertheless says that its audited release interface is still developing and directs builders to current repository releases before deploying value. A compiler is part of the application’s trust and review surface.

A readable source contract does not by itself establish that the generated transaction validates every necessary output. The practical benefit is a clearer expression of intent, accompanied by a continuing need for testing and review of the emitted behavior.

Argent is described more cautiously as an early prototype above Silverscript, using actors, roles and typed transitions to express systems involving several contracts. The documentation is explicit that this is a design direction rather than a stable production interface. Its proposed tooling would preserve routing information and make relationships between contract families less dependent on repeated manual code. That may help developers build applications with several interacting kinds of state, but it should not be counted as an already mature alternative virtual machine.

Keeping this distinction visible helps users read development updates: a promising language prototype, a released compiler and an audited application are different achievements with different evidence.

The based-app model uses ordinary Kaspa transactions to carry application operations in designated lanes. Kaspa orders the data, an external runtime executes the application rules, and a settlement covenant later checks a proof of the state transition. Lane commitments let a proof focus on the relevant application activity rather than reconstructing every unrelated transaction. This divides responsibilities instead of making computation disappear. A working service still needs execution, proof generation, state storage and a defined exit process.

The documentation describes vprogs as an evolving reference runtime. Its existence is evidence of a development path, not proof that every application using the label has the same availability, upgrade policy or user protections.

Inline zero-knowledge verification lets a covenant check a computation performed elsewhere while committing to the resulting state. The guide insists on binding the proof to the expected program, verification material and public inputs. The transaction must also install the successor that was actually proved. These are separate checks. A mathematically valid proof about an unrelated program does not authorize a useful state transition.

This capability can support private or expensive checks without publishing every intermediate detail, but it does not automatically make ordinary KAS transfers private. Privacy depends on the application’s construction and information exposure. The primary documentation is especially useful here because it describes both what verification enables and the mistakes a contract must avoid.

Toccata’s pricing guide replaces a narrow signature-count view with metering for runtime work such as hashing, stack growth and proof verification. A transaction commits an execution budget, and validation fails if a script exceeds it. An unnecessarily large budget can instead increase transaction mass and fees. This makes estimation part of a usable application. Users should not have to guess how much computation a contract needs, and a developer cannot assume that a logically correct transition is guaranteed admission regardless of its resource cost.

The model provides a reason to examine actual transaction construction and measured costs. A fast block schedule is compatible with finite capacity, and the pricing rules are one way the protocol accounts for that limit.

Rusty Kaspa 2.1.0 was released on September 22, 2026. Its notes describe peer-to-peer hardening, chunked initial synchronization, arithmetic-safety work, Stratum fixes and a standalone proof SDK. They also describe removing transitional branches in favor of post-Toccata behavior. This is evidence of continuing maintenance after activation, not simply another distant feature promise. It is also a reminder that software security depends on updates: the release contains concrete fixes rather than claiming an architecture makes implementation errors impossible.

Operators need to read compatibility guidance and update their own deployments. Publication of a release does not prove that every public endpoint or mining service has adopted it.

DAGKnight must be tracked separately. A September 2026 pull request introduced dedicated test-network parameters and explicit activation wiring; its stated scope kept other networks off and acknowledged that further work could remain. The change was merged on September 6. A merged test configuration is not a mainnet activation announcement. This distinction is important because community roadmaps often place DAGKnight beside Toccata and newer application tools in a single list. Their names do not imply an identical release stage.

The useful questions are which network a change targets, what rule is activated, and whether users can verify the resulting behavior in deployed software. This review does not present DAGKnight as the consensus currently activated on mainnet.