Race for one slot
Two people reach for the exact same piece of on-chain data at once. Watch what happens, and why a UTXO chain like Kaspa answers differently than an account-based chain like Ethereum.
Kaspa spends a one-time coin. Only one writer can ever land here.
One shared slot. You and a rival both want it right now.
Why this happens, and what it simplifies
Kaspa: UTXO. A payment, a token balance, or an app's data on Kaspa lives in one owned, one-time-spendable cell (a UTXO). Two transactions can both try to spend that same cell at once, the way you and the rival just did. Only one confirms. The network does not compare which one paid more or arrived "more validly"; it resolves by which one lands first. The other is rejected outright and has to rebuild against what is left, not merge with the winner and not wait in line behind it.
Account model. Ethereum and similar chains track a running balance or contract state instead of one-time coins. Two writers to the very same account do not need to reject one another the same way: both operations can apply, one after the other, in whatever order the network settles on. Nobody's write is thrown out just for arriving second; it just lands after the first one instead of in place of it. That ordering-not-rejection behavior is the account-side half of the same question this page asks.
This is a simplified model of outpoint contention and of account-style sequencing, not real network timing (mempool propagation, block ordering, gas and fee markets).
What actually blocks the double-spend. Nothing stops two conflicting spends from being broadcast in the first place: a wallet can sign and send two transactions against the same coin, and the network does not check for that at broadcast time. What cannot happen is both landing in the accepted state. It is not even a single-block rule: a block cannot hold two of its own transactions spending the same coin, rusty-kaspa's consensus rejects that block outright as invalid. But Kaspa is a DAG, so the real race is usually between two different blocks confirming in parallel, not two transactions in one block. GHOSTDAG orders every block into one sequence first, then each block's transactions are replayed in that order against a running UTXO diff; whichever spend lands earlier in that order is accepted, the other block stays valid and stays in the DAG, but its conflicting transaction fails validation against the state it is checked against and never joins the accepted set. That ordering-after-the-fact is also why two operations touching separate coins cannot be made to depend on each other the way two calls into one shared account can: each spend is checked against a snapshot GHOSTDAG fixes later, not against a promise that the other side will also succeed. Sources: rusty-kaspa's block-body double-spend check and the mergeset acceptance loop that orders and replays transactions by GHOSTDAG before applying them to the UTXO diff.
Where the panel below fits. The race above is about two writers hitting one slot inside a single app. Composing several separately built apps into one atomic transaction is a related but different question, and it is possible on Toccata itself: Argent's Inter-Covenant Communication does it, so far only in unaudited offline demos, per its own README. KIP-21's partitioned sequencing lanes (Status: Active) are about scaling that kind of throughput, not about letting apps reach into each other's state. Neither changes the one-slot outcome shown above, and neither is what the panel below is about. Sources: argent-lang/argent, KIP-21.
vProgs, and its status. The gap those two don't close: many different users writing to one shared app's state at once (an exchange pool, say), where L1 composition today tends to be exit-style, settling when someone leaves rather than the instant they act. vProgs is a roadmap proposal aimed at that gap, not a shipped feature: its own repository README opens with "This repository is in early development / prototype phase. APIs and architecture may change significantly," and as of this writing it carries zero releases and zero tags. Its own architect, Kaspa core developer Michael Sutton, frames the actual design tradeoff as a choice between "losing synchronous composability or losing sovereignty," and describes one target as "standalone, non-composable sovereign vprogs" settling back to L1 through their own exit path, which is the tradeoff the panel below shows. Sources: kaspanet/vprogs, Michael Sutton's based-apps design notes.
The race above is about two writers hitting the very same slot. A separate question: can two different apps reach into each other's state at all?
vProgs status: roadmap proposal, not running on mainnet. Its own repository calls itself “early development / prototype phase.” Zero releases, zero tags, as of this writing.
Each app's state lives behind its own wall. Two different apps' data never touches, even though both sit on the same public chain. Moving value between them today means leaving one (an exit) and entering the other, not one live call across the wall.