(with grok and sol) --- An interesting design tension in state-carrying covenants that require lineage is how you manage a scarce global resource without forcing every update through a single UTXO. A compressed design keeps the allocation map behind one Merkle root inside a single covenant UTXO. The covenant checks every transition against the rules. For a name service that means a sparse Merkle tree over the keyspace: registering a name proves the slot is empty, updates the root, and creates a separate ownership UTXO for that point. U(R₀) → U(R₁) + Point(k) Later transfers of the name can spend the ownership UTXO without touching the root, so they don’t contend with new registrations. Everything that changes the allocation map itself still has to spend the same root-carrying UTXO. Unrelated names serialize on it. The other way is to partition the space. A split hands each range to its own covenant UTXO from the same lineage. The split has to preserve the global invariants: ranges don’t overlap, budgets still sum correctly, and it validates the contracts that receive the pieces. After that, each range can evolve independently for operations that stay inside it. Splits, merges, and transfers between partitions still need coordinated checks across the UTXOs involved. Otherwise the range UTXOs are independent, so updates in different ranges can proceed concurrently in the DAG. Lineage is what keeps the pieces part of the same instance. Covenant IDs make this cheap: consensus already tracks which UTXOs belong to a given covenant, so a script only has to validate the local transition. The live range UTXOs (plus the ownership UTXOs for allocated points) are just the current leaves of that lineage. There’s no separate tree object stored on-chain. @supertypo_kas’s dotk is a pure-partitioning version of this for names. It keeps the invariant that every key is either inside exactly one gap or is exactly one deed. Claiming a name consumes the gap that contains it and emits the remaining gap(s) plus a deed: Gap((a,b]) → Gap((a,k)) + Deed(k) + Gap((k,b]) Releasing a name consumes the deed and adjacent gaps and merges them back together. The gaps and deeds have different rules, but every point stays accounted for exactly once. The cost of the partitioned approach shows up in storage mass. KIP-9 makes creating many small-value outputs expensive, so each new range UTXO needs enough KAS locked in it to keep the mass reasonable. That’s intentional. Growing the live frontier means someone has to put capital behind the extra state. Designs that let users opt in, fund additional range UTXOs while the capacity is useful, and later reclaim the KAS by merging ranges again turn that cost into a controllable design choice. The expand-and-contract frontiers in the kcc20 reference code follow the same principle. A practical middle ground is to start with a chosen number of range UTXOs and put a Merkle root inside each one. Lineage partitions the keyspace; each partition compresses its own allocation state. While that partition count stays fixed, the L1 footprint for the trackers stays constant, registrations in different ranges still don’t contend, and you avoid creating a new range UTXO for every name. You choose how finely to slice the space, how much KAS to lock behind the frontier, and how much residual contention you accept inside each partition. Hashing helps distribute keys across ranges, but it doesn’t eliminate hot spots. If most operations land in one range you’re back to serializing on that root. At that point the app can allow further on-demand splits of a hot range, again costing locked KAS that users can later reclaim by merging, or just accept the serialization for that slice

My prophecy: Kaspa core will keep researching, budling and delivering. Yonatan will continue to lead it in terms of vision, far-reaching long-term research and short-term endless day-to-day brainstorming. Core R&D will continue to scale and expand to wider and wider circles. Builders and developers will keep joining L2 testnets and build dapps which utilize Kaspa’s inherent superiorities. Kaspa’s marketing will decentralize more and more. There will be no central voice. As part of the many voices, core members will find ways to communicate their vision and nuanced discussions to the broader crypto community. Truthfulness will prevail. Kaspa core will identify with people who actively contribute, build, research and think about Kaspa from the moment they wake up until the moment they fall asleep. Educators, pedagogues and evangelizers will do what they do best and communicate at different levels based on their knowledge and expertise. I will keep researching, thinking, developing and posting about Kaspa and speak as directly, accurately and truthfully as I can. I love you all (not a prophecy). We just started.

so it’s also about shared state bottlenecks, but in that regard i actually believe systems should push app designers into partitioned/parallel/replicated state designs and not vice versa (ie forcing the sys design towards shared state). hence i think that the point of computational scalability is the more fundamental point. here too there is a ladder. based zk systems force every event to have L1 DA (at the benefit of L1-degree censorship resistance), while non-based systems allow more scalability but less L1-grade security. obv a lot more to say on this topic.

I’m a core Kaspa dev. What do you need and how can I help?

@CodesXBT i genuinely do my best to tolerate and respect ppl. i never block, and i try to answer any constructive criticism. i’m sorry but sometimes i just don’t understand what ppl even want. how can utility and apps be built without programibility infrastructure and compilers as MUST prerequisites, and why should i not hope for Kaspa’s vibrant community to utilize these fresh tools before or in parallel to myself building apps over this infra

just to be clear, there’s a lot going on across many fronts. it’s just not helpful to talk about things before they happen; they simply need to happen, and serious things take time. some serious efforts also won’t necessarily mature for various reasons, which is another reason ppl don’t always lay out their plans publicly (until they happen). i anticipate something of a “baby boom” in a few months, but teams will simply pursue delivery rather than talk

it’s exciting to watch y’all starting to realize (as well as actually realize/build) what can be built on post-Toccata Kaspa