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

(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