That's a really good question, but it's hard to answer in a single tweet because our mission is quite extensive, and it requires a lot of background knowledge to really understand what sets Kaspa apart. Currently, a lot of people see Kaspa as “Bitcoin’s crazy little brother” that improves time-to-finality by leveraging the benefits of DAG-based consensus protocols without accepting their traditional drawbacks, such as decreased decentralization or a limited validator set. This perception is somewhat accurate, but it falls short of conveying the full picture, because Kaspa’s vision extends far beyond just trying to be a better Bitcoin. Anyone willing to study Kaspa and its broader vision will discover similarities to nearly all major existing DLT designs: from Bitcoin, to Ethereum, to Solana, Sui, Celestia, and beyond. My personal view is that “research” in the DLT space is approaching a point of convergence. We increasingly understand how to push distributed systems close to the limits of what physics permits. The frontier is no longer only about raw throughput or faster finality. The attention is shifting toward game theory, incentives, sequencing, MEV, alignment, and how to build systems where the economic incentives of users, builders, miners, validators, applications, and infrastructure providers do not work against each other. That is why debates like based rollups versus arbitrary sequencing, shared sequencing, MEV mitigation, proposer-builder separation, and execution-layer incentives matter so much. These are not niche technical details. They determine whether a network can remain neutral, decentralized, and aligned while scaling to global usage. And this is where I think Kaspa is pushing the boundaries in a very important way. Kaspa is not merely trying to be “fast.” The goal is to build an L1 where speed, decentralization, security, and incentives are aligned at the base layer. A system that does not scale by hiding complexity behind trusted committees, privileged sequencers, centralized validator sets, or opaque coordination mechanisms, but instead tries to preserve the spirit of proof-of-work while extending what an L1 can realistically do. Because Kaspa arrived later than many other major projects, it does not carry the same degree of technological debt. It can absorb lessons from Bitcoin, Ethereum, rollups, modular blockchains, high-throughput monolithic chains, DAG research, MEV research, and the broader history of decentralized systems, and combine those lessons into something more optimal. To me, that is what Kaspa is building: not just a faster blockchain, but a more incentive-aligned decentralized infrastructure layer. But this also creates a different challenge. Kaspa’s biggest problem today is not its technology. It is the lack of centralized coordination around communicating the vision. And because Kaspa is a grass-roots movement, that responsibility does not belong to a marketing department, or a single leadership team. It belongs to the community. That also means the community has a different role to play. There will always be holders who are mainly interested in price, and that is completely fine. But there also need to be people who are here because they want to use the technology to build a different future. People who care about the architecture, the incentives, the open questions, the trade-offs, and the long-term trajectory of decentralized infrastructure. I am one of those people. I am not interested in DLTs merely as a way to generate wealth. I am interested in them because I believe they can change the trajectory of humanity as a whole. For that reason, I want to use this opportunity to announce a regular community hangout where we discuss the current state of development, the open questions, and where we can align our vision together. The first session will be on Tuesday, June 9th, 2026. We will talk about the vProgs framework, how the codebase works, what sets Kaspa apart, where we improve on existing solutions, and what still needs to be done. The goal is for this to become a regular, possibly bi-weekly, event where we as a community come together to discuss the future and understand the technology. Eventually, we can invite people from other projects as well, but the main focus at the beginning will be explaining and communicating how things work under the hood. There is still a lot of work to be done, and I do not want to waste precious time. So the first sessions may feel a little improvised, but we can improve as we go. The important thing is that we start. So mark the date: Tuesday, June 9th, 2026.

Hey @hus_qy I'm very curious of something. How would you answer the question #1 "What are they building?" What is your opinion on what Kaspa is building?

Quick TN10/Toccata update from @michaelsuttonil "As part of the final ZK audit, we found a few Groth16 verifier hardening fixes that should be included before #Toccata is finalized for mainnet. PR #1013 adds this activation-gated hardening: stricter Groth16 input/VK/proof handling, plus per-public-input pricing. Together, these prevent worst-case constructions that could exceed our 10ms-per-block benchmarking target. We are also adding one last SMT polish, suggested by @hus_qy and Max during final review while building the vprogs/based-apps infrastructure. Each seqcommit includes a context hash with block-related info; we want to add an inactivity_shortcut link there to the seqcommit from F-time back. This lets inactivity proofs hop through these shortcuts instead of walking long linear paths, while also avoiding a dependency inside the zk guest on the exact inactivity threshold. Since these changes are consensus-facing, they need to go through a fast TN10 HF/release cycle before we finalize Toccata for mainnet. The work is expected to complete in the next 1-2 days, followed by a fast TN10 activation cycle with up to 24h of prep time. After that, the finalized logic will be PRed back into Toccata without the special TN10 activation scaffolding, and mainnet activation can move forward."

You are absolutely right: tools alone are not enough. What you also need is a unifying mission - a stag worth hunting together - and it cannot just be a product, a memecoin or a financial instrument. It has to point beyond finance and beyond economic settlement. That is why I do not think the real opportunity here is simply to build better tools for coordination. It is to build mission-driven institutions that can coordinate people around questions and goals that existing structures struggle to hold. I think I have already identified the stag I personally want to hunt: properly exploring the possibility that cognition is a scale-free process in our cosmos. A growing number of scientists and researchers are beginning to take this idea seriously. But the work lives in the cracks between established fields - AI, philosophy, physics, cosmology, biology, economics, and perhaps even some form of spirituality - which makes collaboration unusually hard and costly. The people best positioned to push it forward are usually too busy doing the actual work to also build the social infrastructure needed to coordinate the field in a persistent and goal-directed way. There are of course people like Dr. Michael Levin trying to connect the dots by organizing conferences and conversations across disciplines. But efforts like these are still relatively isolated, often revolve around key individuals, and lack a persistent address that others can turn to if they want to follow the work, contribute, or collaborate. And if this movement keeps growing, the coordination burden on those individuals will only increase. That is exactly why I think a distributed institution dedicated to this mission could matter - something like a Cognitive Cosmos Institute: a persistent coordination layer for people working on these questions, and potentially even a new channel for funding outside the established structures of academia. Maybe it fails. Maybe people think the whole idea is nonsense. But I believe we are at a unique moment in the development of our species. We now have tools that are still radically underutilized when it comes to building mission-driven institutions. I think people generally underestimate how much agency they actually have. Sometimes you can just do things. And it is up to us to build the tools that empower people to do exactly that.

What if physics is just the universe learning? Most Theories of Everything episodes are mind‑bending for their math, physics, philosophy, or consciousness implications. This one hits all four simultaneously. Professor Vitaly Vanchurin joins me to argue the cosmos isn't just modeled by neural networks—it literally is one. Learning dynamics aren't a metaphor for physics; they are the physics. Vanchurin shows why we need a three‑way unification: quantum mechanics, general relativity, and observers.

I just wrote a response to a question in Telegram about the role of push / pull based communication in the bridge and I figured I could also post a copy here since it explains some of the rationals behind the bridge design (beware - it's a long text 😅): When you want to receive information from an L1 Kaspa node, then you essentially have two forms of communication: 1. push based communcation (the server calls you and tells you what happened) 2. pull based communication (you call the server and ask it for information) Push based communication is usually better because you don't need to constantly ask if something happened but get notified instead (which reduces the communication overhead). Think of the following example: You planned a surprise dinner for your girlfriend and really need to know if she will make it home in time or if she got stuck in traffic. You could call her every minute to ask if she got stuck or you just negotiate that she will call you as soon as something unexpected happens. The second option is clearly more efficient than the first one because if she never gets stuck in traffic then nobody ever wastes a single call (you only need to react if there is something to react to) and it is usually also faster because you don't have to wait one minute for the next call to learn about updates. So the question was why the bridge uses both push-based and pull-based communication instead of relying purely on push notifications. The core issue is that push-based notifications usually arrive as incremental updates. Going back to the girlfriend example, this would be like her sending messages such as "I turned left", "I accelerated" or "I turned right". On their own, these updates don't mean much unless you already have enough context to interpret them. If you don't know where she started or what route she's on, those messages are essentially meaningless. In theory, that context can be reconstructed by carefully tracking every single update and maintaining a local model of what is happening. In practice, however, this quickly becomes problematic. You would need fairly complex logic on the consuming side to mirror each action and state transition, which effectively forces you to re-implement a large part of the L1 logic just to make sense of the updates. On top of that, updates can get lost. Maybe your phone has no reception for a moment or you're busy and miss a call. Once that happens, your local context is broken. To recover from such situations, you are inevitably forced to also support pull-based communication where you can explicitly ask for the missing information and catch up. But this introduces yet another layer of complexity: if you are requesting historical or missing data at the same time as you are receiving real-time updates, you now need to understand exactly where the two streams meet. You have to decide when to stop relying on pulled data, when to resume trusting pushed updates and how to stitch both views together into one consistent picture. All of this is non-trivial, requires a significant amount of code and makes data ingestion much more complicated. Because following the L1 is such a common use case, Kaspa recently introduced a specialized pull-based API tailored exactly for this purpose. You can think of it as a hotline: you call it, state your request and receive all the information you need in a single, structured response, instead of having to piece together context from many small incremental messages. To avoid reinventing the wheel and to improve maintainability, the bridge makes use of this new pull-based API to retrieve the information it needs for its operation. At the same time, it does not simply poll the server at fixed intervals. Instead, it combines both communication styles: the server notifies the bridge when something relevant changes, and the bridge then calls the hotline to retrieve the corresponding details in a clean and structured way. This approach combines the benefits of both worlds and avoids unnecessary delays. There is, however, one specific drawback. Because Kaspa supports reorgs - where the perceived virtual chain can temporarily oscillate between different states - it can happen that the bridge requests the same information multiple times from the hotline. This is a natural consequence of always asking for the "latest" view, even if parts of that view were already seen before. The claim was that by avoiding the hotline and relying purely on push-based updates, it would be possible to save this ambiguous traffic and reconstruct a valid perception of L1 activity locally. To explain my perspective on this, imagine the bridge as a person sitting in a room with a big window, holding a phone. He receives calls from the server, knows the hotline number and is trained to communicate reliably - he knows what to ask if the phone stops working for a while or if he steps away briefly. This person then abstracts all of that complexity away by holding up clear, readable signs in front of the window for others to observe. From the outside, what really matters is the interface: how the window looks, what the signs look like, and that this room exists at all. Once these interfaces toward L2 are defined, the exact behavior of the person inside the room becomes an implementation detail. We can later update how he operates internally - for example, making him rely more on incremental updates and only call the hotline when absolutely necessary to save bandwidth in the presence of frequent reorgs. That is one possible approach, but in my opinion it is not even the best one. An L2 does not have the same requirements as an L1 node. An L1 node needs to track what might happen in order to reach consensus, whereas an L2 is usually interested in what did happen. Instead of mirroring the L1 as closely as possible - including all the short-lived fluctuations at the tip - it is often far more useful for an L2 to work with a stable perception of reality. This reduces wasted work on events that will later be discarded due to reorgs and avoids inefficient, speculative execution in favor of maximally efficient execution. So rather than turning the worker behind the window into an expert that mirrors the server in every detail, we can teach him something else: how long it typically takes for the perception of the chain to stabilize. Instead of always requesting the full latest history from the hotline, we can instruct him to only request the stable part. This removes the need for ambiguous data transmission just as effectively, but with orders of magnitude less code. At the same time, the bridge naturally becomes a kind of high-pass filter that removes unnecessary noise before it ever reaches the observers in front of the window. TL;DR: Just because we have a functioning room today does not mean we cannot adjust the behavior of the worker tomorrow. Mirroring everything as closely as possible is not necessarily the desired outcome. We should try to leverage existing interfaces and capabilities instead of re-implementing large parts of the logic another time. The real goal is to arrive at a working solution as quickly as possible, with minimal and robust code, without getting lost in micro-optimizations that prevent us from seeing higher-level improvements - such as a worker whose behavior is guided by a self-tuning hysteresis mechanism rather than by raw unstable L1 signals. To tie all of this back to the early example: I see the final role of the bridge as a little intelligent agent that tells me only what is really relevant for me (if my girlfriend will be late) instead of telling me about every turn of the car. PS: This is the kind of stuff I would like to discuss in the hangouts (maybe in a bit more detail).