Kaspa Commons

None of the above, WarpCore on Kaspa $kas, is far superior in almost every metric and much greater in reach terms of feature set. We are nearing full production readiness with some minor tweaks for the upcoming Toccata Fork. Will leave these faux ISO projects in the dust. There is nothing comparable.

In programming, the actor model is a concurrency model that avoids lock-based synchronization. Instead of controlling access to a data element through a mutex or a read-write lock, you define a single owning actor for that element, and only that actor can mutate its state. The actor can receive msgs in a message queue from other actors. Think of it as a single thread waiting for msgs in a loop, processing them through actions, and sending msgs to others as part of those actions. It can also initiate communication with other actors. Synchronization primitives may still appear in the implementation of msg queues, but contention is minimal by design. To illustrate, if several parts of a program want to update the same state, they do not race to acquire its lock. They send msgs to the owning actor, which alone decides how to update its private state and what actions or msgs follow. (By the way, rusty-kaspa’s consensus-processing pipeline was inspired by a similar design: actors/processors communicate through msg queues to provide pipeline concurrency, while each uses a worker pool for inner-task parallelism.) --- UTXO detour In the UTXO model, each UTXO is a one-time data storage point, consumed by the spending tx, which in turn produces new UTXOs. These storage cells carry kas value and an spk (script public key). The spk holds the rules for spending the UTXO. With kaspa covenants, we focused on one type of spk called p2sh (pay to script hash), which is basically a simple 32-byte hash committing to a locking script. The locking script (aka the redeem script) can also hold state fields within it (think of them as constants embedded in this specific script and fed to the script’s “main function” as args upon execution). Recent kaspa Toccata additions allow this script to enforce complex conditions, including inspecting the output spks of the tx and verifying complex rules over them. This means an input can verify that an output follows exactly the same contract/script, and that only the embedded state constants are mutated according to the script rules and embedded in the output. Alternatively, it can verify that control has passed to some other known contract template, with the same or a different state object. eg: Counter { count: 5 } → Counter { count: 8 } or: League { players: n, ... } -- register_new_player → League { players: n+1, ... } + Player { games: 0, ... } --- To get to my point, imo this makes it natural to name such a stateful covenant UTXO an “actor.” It is not an actor with a long-lived process and a msg-queue processing loop, but it is an actor in the sense of state ownership. Only my fixed logic can consume my own state and produce the actor(s) I become next, with updated state. No one else can consume or mutate that state without going through the rules the covenant itself enforces. The tx is the interaction/msg that triggers the actor’s next state transition. A logical actor can therefore continue as a chain of UTXOs: Actor₀ → Actor₁ → Actor₂ → ... Each arrow is a valid tx that respects the actor’s transition rules. A covenant id can also give this evolving UTXO lineage a stable identity across state transitions. --- I argue that this is the right mental model and terminology to establish when discussing covenant state-controlling entities: a piece of code owning a state and exclusively authorizing its mutation/consumption. I think many more details now emerging from eg Argent will be easier to discuss once we establish such jargon.

Yes. But the regulatory landscape has changed and needs clarification, we have several preferred paths to delivery but they are gated by EU regulations in particular. The goal remains as a settlement mechanism for energy industry users with the associated environmental attributes also settled and accounted for. The EU's MiCA regulation (Markets in Crypto-Assets, phased in from 2024 onward) imposes strict rules on stablecoin issuers, authorisation requirements, reserves, consumer protections, and limits on non-EU stablecoins. A MiCA 2.0 has been touted to expand the regulatory reach by the EU to regulate non-EU stables presenting potential for future compliance risk. This has created hurdles for many projects, especially those with cross-border or energy-sector ambitions. Similar dynamics exist with evolving US rules (e.g., GENIUS Act).