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

just admit to yourself you’ve invested in the wrong tech/ppl and move on. we’re not going to change for you 😘

I want, perhaps for the first time ever on this platform, to write a post from a personal perspective. This post isn’t going to address any other person, and as such, I would appreciate not receiving any sharp-tongued comments or personal remarks about any particular case. Read the post as it is, or ignore it. Please respect my personal request, at least in this one instance, even if every fiber of your being rebels against what you perceive as an injustice. For the last three years, my entire sphere of activity, the one that consumes all my time and energy, has been Kaspa. The development of Kaspa. The research of Kaspa. Where the coin is today. And which line of code will run tomorrow. I don’t work on Kaspa to become a rich man. My life’s goal is not to make a lot of money and retire. I enjoy fundamental, deep research in computer science, and I am especially thrilled when I have the privilege of applying it at scale in the real world. I believe I have the right to claim that I care about Kaspa as a collective. I care about the whole that is greater than the sum of its parts. As a person of faith, I believe I have been granted the privilege of being a conduit for some of the science that constitutes Kaspa. For the discovery of this science in the world. And for its complete implementation. Along with this privilege comes great responsibility. In Kaspa’s first year, I was under constant stress. Returning from any weekend or period of disconnection was met with the feeling that anything could happen. All hell could break loose. The pounding of my heart at the crescendo moment didn’t subside for weeks. At a certain point, as a lead developer and researcher, you discover that your responsibility extends beyond the technical domain. That as a creator and, in effect, a continuous founder of the technology, you have a growing responsibility for the proper communication of this thing you are an essential part of creating. We are, admittedly, in a decentralized open-source community, but the creation process ultimately comes from specific people, and no one else can authentically reflect the essence of the creation and its strengths more than those who continuously forge the path itself. This responsibility is both a community and a project-level one. You find yourself in a situation for which your academic degrees did not prepare you. Luckily for me, if you were to tell people who know me in my personal life that I only understand zeros and ones, they would find it deeply amusing. Until a few years ago, I actively managed a social media community of thousands of people that led and was part of a social change. Anyone who knows me or has even worked closely with me will tell you that my emotional intelligence is no less than my intellectual one. With great responsibility comes the capacity for error. I can be wrong. Like any human being. But I ask here for the right to a minimum of respect and appreciation for my integrity and the purity of my intentions. I have no ego when it comes to Kaspa and its creation. And I am happy (and actively working) to share in its future creation and to give credit for the past to all who deserve it. Every action I take within the Kaspa space stems from my belief that it is for the good of the project. And from my belief that although I am primarily a researcher and developer, I have an angle and a complete perspective on the project that is nearly unrivaled. Sometimes, you are deeply and intuitively convinced of something, but it takes time to clearly articulate the crux of the problem and the argument. And still, the urgency mounts, and so you are forced to act. And when you try to explain your reasoning to people without the full context, you only manage to reflect fragments of ideas that don’t always connect for the perplexed observer and sometimes even seem contradictory. If, for example, I wrote a line about Kaspa’s market value and you believe it could be interpreted in a personal, unfair manner, do not attack and sting me based on your wrong assumption. Ask honestly what I meant, and you might be surprised by the answer. (In that specific case, I was speaking about my assessment, and that of others smarter than me, that a fundamental change in Kaspa’s social media presence is required for us to break through in the market cap rankings towards the top ten. I wasn’t referring to the price noise of the past year, nor am I influenced by it. I operate under the complete belief (a kind of knowing) that Kaspa will reach its rightful place in terms of market weight. I also didn’t blame any individual. I spoke of a perception and an approach that, in my view, have a glass ceiling. And I prioritized the common good, as I thought and felt that this truth needed to be heard, even if there are individuals for whom it could be interpreted as criticism.) In the same vein, and as in the example above, so it is with every community and social action I’ve taken recently. You can, of course, argue and believe that I was mistaken; that is certainly a possibility. But I ask to be given the credit that I, at least, believe I am doing the right and critical thing for the Kaspa community and project as a whole. And that I have a basic social and philosophical analytical ability that grants me the right to my own opinion in these areas as well, even if I am mainly a developer and researcher who deals with abstract combinatorial ideas and code. I don’t have to be a marketing expert to express a crypto-philosophical opinion on the source and authority of core ideas for something that I am a continuous part of creating. Thank you for reading this far. I sincerely appreciate it. My next post will be out tomorrow, and it will discuss something cool and immediately relevant to Kaspa that myself and others have been working on these past few days. After that, or at least in the near future, Yonatan or I, or both of us, will try to outline Kaspa’s roadmap for the next one to two years, up to the achievement of zk/dk.

i believe we can get to a stable (and secure) testnet this year

we’re all in on it and doing our best. it’s a white/yellow/black (research/specs/code) effort happening in parallel with various relationships

(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

composability between native covenants is ready (and is the key for eg all the dexs you’ll see over kcc20 tokens soon). sync composability between vprogs isn’t