Tldr: 

• vProgs research opens to the public: Kaspa developer Hans Moog open-sourced an early vProgs repository, outlining a research-driven execution framework focused on inter-block parallelism, minimal logic, and linear scalability beyond traditional execution limits.

• Execution roadmap gains clarity: Michael Sutton explained how vProgs connects to Kaspa’s broader roadmap, describing two parallel efforts, a high-concurrency runtime and L1 covenants plus zk opcodes, designed to meet first through a narrow, production-ready interface.

• Covenants++ timeline emerges: Sutton indicated a target of roughly 40–50 days for a fully featured, mainnet-ready covenants++ testnet, with further details expected as milestones are finalized.

• Independent analysis reinforces vProgs' framing: Kaspa researcher Wolfie characterized vProgs as an execution architecture rather than a standalone codebase, emphasizing off-chain execution with on-chain verification and a DAG-based compute model that avoids global VM bottlenecks.

• Broader visibility and tooling progress: BSCNews published multiple Kaspa explainers for its 1M+ audience, while new developer and ecosystem tools shipped across analytics, SDKs, infrastructure, and block explorers.

KASmedia Analytics Charts

KASmedia continues to expand its suite of Kaspa on-chain analytics, with recent additions including the MVRV Z-Score, a widely used valuation framework that compares market value to realized value to contextualize broader network conditions.

Rather than focusing on short-term price movements, the MVRV Z-Score measures how far current market valuation has diverged from the network's aggregate on-chain cost basis. Across proof-of-work systems, sustained deviations have historically coincided with distinct market regimes, making the metric useful for structural context rather than narrative interpretation.

Hans Moog Releases Vprogs on GitHub 

Kaspa developer Hans Moog this week open-sourced an early, work-in-progress repository for vProgs, a research-driven execution framework aimed at rethinking how blockchains scale computation.

Moog framed the effort around a broader observation about the crypto space, noting that many distributed ledger projects are increasingly converging on the same ideas, often under different terminology. In his view, the core breakthrough was the invention of blockchains themselves, while much of the subsequent innovation has focused on incremental optimization layered on top of existing designs. Kaspa’s later entry into the space, he argues, provides an opportunity to directly incorporate lessons from prior research without inheriting accumulated design complexity.

Verifiable programs (vProgs) are the mechanism Kaspa plans to use to bring programmable execution functionality to its Layer 1 through zero-knowledge proofs. The stated goal of the vProgs repository is to consolidate years of academic and applied research into a single, minimal framework. Moog describes the objective as creating “a concrete instantiation of all existing research directions condensed into a singular, maximally performant type framework that gets away with almost no logic.”

At its core, vProgs is presented as “a post-Amdahl execution engine that enables inter-block parallelism and linear scaling beyond boundaries traditionally assumed to be possible in the context of DLT execution.”

“Post-Amdahl” refers to designing a system so that no single sequential bottleneck limits performance. By encoding dependencies up front, vProgs allows independent work to be executed simultaneously across hardware, rather than forcing all activity through a global choke point.

Instead of guessing what should run next or coordinating execution through locks and shared state, the design encodes how tasks relate to one another ahead of time. This lets the system map work directly to available hardware resources, avoiding the single slow execution line common in traditional blockchain runtimes.

Moog summarized the guiding principles behind the architecture as follows:

“No fsync or write-ahead-log flush boundaries

No mutexes or locks

Versioned, append-only data with efficient rollback

Maximal parallelism, including inter-block execution

No wasted CPU cycles on speculative execution.”

Summarizing the philosophy behind the work, Moog wrote: “The holy grail of blockchain execution isn't more complex but orders of magnitude less complex than anything that exists today!”

Shortly after the initial release, Moog shared a follow-up noting that early rough edges were already being addressed. Two pull requests were merged into the vProgs repository, adding eviction and pruning support, introducing basic mechanisms for state cleanup and resource management, while the framework remains in active development.

Michael Sutton outlines how vProgs connects to Kaspa L1 

Kaspa core developer Michael Sutton added context this week on how the newly published vProgs repository fits into Kaspa’s broader execution roadmap, describing it as “two efforts digging a mountain from both directions and seeking to meet.”

On one side, Hans Moog and contributors are building a high-concurrency, sequencer-fed execution runtime designed to process transactions at scale. This runtime is the system that actually runs application logic, taking ordered transactions and executing them efficiently in parallel rather than forcing all activity through a single execution bottleneck.

On the other hand, the “covenants++ taskforce” is working from the Layer 1 side to develop covenant infrastructure and zero-knowledge opcodes that allow this runtime to settle to and bridge from Kaspa’s base layer. These components enable advanced applications to anchor results securely on L1 using cryptographic proofs, supporting high-throughput financial, settlement, and transaction-intensive workflows without increasing base-layer complexity or introducing centralization risk.

Sutton explained that the near-term objective is to connect these efforts through a narrow, production-ready interface before gradually expanding composability, meaning that cross-application interaction will be introduced incrementally, only after the core execution and settlement paths are proven correct and secure. “We aim to reach each other first through a narrow tunnel, and only then widen the pathway together,” he wrote.

He emphasized that the priority is correctness and sovereignty rather than breadth of features. By linking a minimal, standalone application-level runtime to L1-anchored zk covenants, the teams aim to support large-scale, compute-intensive applications without compromising Kaspa’s security model.

Wolfie thoughts on vProgs:

Following Hans Moog’s publication of the vProgs repository, Kaspa BD, Wolfie offered a technical interpretation of the release, framing vProgs as an execution architecture rather than simply a new codebase.

Wolfie describes vProgs as Kaspa’s approach to off-chain execution with on-chain verification, where complex logic runs outside the base layer and submits zero-knowledge proofs to L1 for validation, rather than full instruction-by-instruction execution. Each verifiable program maintains its own state, gas model, and rules, while anchoring its commitments to Kaspa’s BlockDAG to inherit base-layer security.

He notes that the public repository, written in Rust, reflects this design directly through a layered monorepo structure that separates core primitives, storage, state modeling, scheduling, the transaction runtime, and node integration. Dependencies flow in a single direction, allowing individual components such as schedulers or proof systems to evolve independently without forcing changes across the entire stack.

According to Wolfie, this architecture underpins Moog’s references to Amdahl’s law. Rather than relying on a shared global virtual machine with serialized execution, vProgs models computation as a directed acyclic graph, enabling independent programs to be proven and scheduled in parallel while explicitly tracking dependencies. This approach is intended to preserve atomic cross-application composability without introducing a global execution bottleneck.

Wolfie also contrasts vProgs with conventional smart-contract platforms, emphasizing that Kaspa avoids a shared global execution environment. Full nodes verify proofs and manage commitments rather than replaying execution, aligning the model with Kaspa’s high-throughput, proof-of-work design goals.

Finally, he stresses that the framework remains early-stage and exploratory. Interfaces, module boundaries, and proof backends are expected to change, with testnet deployments, security review, and performance validation positioned as prerequisites before any mainnet rollout.

BSCNews Shares Multiple Posts on Kaspa to their 1M+ Followers

Crypto publication BSCNews, with an audience of over 1 million followers, published an explainer this week on Kaspa Improvement Proposals (KIPs), the formal process for proposing and adopting changes to the Kaspa protocol.

The article highlights KIPs as Kaspa’s mechanism for coordinating protocol upgrades through open, permissionless review, where changes to consensus, security, and incentives are evaluated publicly rather than dictated by a central authority.

In a separate feature, BSCNews examined the Kaspa Industrial Initiative (KII), a non-profit effort focused on advancing Kaspa’s adoption in industrial and enterprise environments. The article frames KII as positioning Kaspa not as a speculative asset, but as neutral infrastructure designed to integrate with regulated sectors such as finance, energy, supply chains, and public systems.

The coverage emphasizes KII’s role in standards development, documentation, pilot deployments, regulatory alignment, and education, presenting the initiative as a coordinating body rather than a product or commercial entity. Within this context, BSCNews highlights WarpCore as one technical pillar enabling integration with existing financial systems, and KII Academy as the educational arm aimed at developing enterprise-ready builders and institutions.

Taken together, the piece presents KII as an effort to bridge Kaspa’s technical architecture with real-world operational requirements, reinforcing its positioning as a settlement and data-integrity layer suited for long-term, institutional use.

Kaspa Python SDK adds VSPC v2 access for on-chain analysis

Kaspa contributor smartgoo (@smartgoo_) highlighted a new capability in the Kaspa Python SDK with the pre-release of version 1.1.0rc2, which adds support for the VSPC v2 RPC method get_virtual_chain_from_block_v2.

The update gives developers a clearer, more reliable view of what is actually happening on the Kaspa network in real time. In practice, this makes it easier to build explorers, analytics dashboards, and research tools that accurately track transactions, activity, and network behavior as Kaspa scales, without relying on third-party data providers. 

XXIM Podcast: KaspaCom 

On a recent episode of the XXIM Podcast, host Ankit spoke with Sione from KaspaCom about KaspaCom’s product roadmap, recent platform metrics, and fundraising plans, framing the current moment as a mix of internal ecosystem momentum and the need to expand beyond the “Kaspa bubble.”

Sion argued that while Kaspa’s builder and core developer activity continues to grow, market conditions and the rollout dynamics around Kasplex have contributed to lower recent volumes across Kaspa-adjacent DeFi. He pointed to usage data across Kaspacom’s products, including its DEX and “LFG” token launchpad, citing roughly 30M KAS in all-time volume over about 3.5 months on the newer stack versus about 60M KAS over a year on the legacy platform. He also described the platform’s UI and UX redesign as an effort to consolidate core DeFi functions in one place, with a longer-term goal of a mobile experience and reduced user friction.

Kaspa Commons and Chad Post About Kaspa Marketing 

This week, Kaspa Commons published a commentary addressing recurring calls for increased Kaspa marketing, arguing that the network is being evaluated through metrics misaligned with its purpose. The post emphasizes that Kaspa is not designed to compete on speculation-driven indicators such as short-term price action or influencer narratives, but rather as an open-source settlement infrastructure intended for real-world, high-throughput use cases where decentralization, auditability, and latency are functional requirements.

The commentary frames Kaspa not as an organization with centralized marketing budgets, but as a protocol whose adoption is driven through builders, tooling, education, integrations, and usage. While acknowledging that traditional marketing can play a role, the post draws a distinction between paid attention and adoption-led visibility, arguing that long-term credibility emerges from deployed systems, not promotional campaigns.

In a follow-up discussion, Kaspa Commons contributor Chad expanded on this position from his personal account, clarifying that the original post was not anti-marketing but a rejection of hype-driven, short-term narrative management. Chad noted that much of what appears “grassroots” has in fact involved coordinated, professional effort over several years, including community resourcing, ambassador support, event coordination, and brand development.

Chad argued that Kaspa’s strategy has historically leaned toward pull marketing rather than push marketing, prioritizing clear positioning, technical proof, and demonstrable outcomes over paid amplification. In this framing, enterprise and infrastructure markets respond not to belief or slogans, but to evidence such as demos, proofs of concept, and repeatable results. Advertising, he suggested, is most effective once the product narrative has been validated by real-world use.

Across both posts, the shared message is that Kaspa’s path to broader recognition is expected to follow adoption rather than precede it, with marketing serving to document and amplify demonstrated utility rather than manufacture attention in advance.

S-Curve Adoption 

Kaspa community member moose.kas (@Themooseisloose) shared a post challenging the assumption that Bitcoin and similar proof-of-work networks follow a traditional “S-curve” adoption pattern. It argues that fixed supply and rising production costs create recurring cycles of liquidity and reserves, not a one-time growth arc followed by forever-diminishing returns.

The post argues that this model does not apply well to proof-of-work monetary networks. Unlike consumer technologies, where production costs fall over time and efficiency gains drive saturation, Bitcoin-like systems have a fixed supply and rising production costs. As a result, adoption is framed not as a single growth arc, but as a recurring process in which coins cycle between active liquidity and long-term reserves across market cycles.

Rather than a one-time supply shock followed by diminishing relevance, the author describes adoption as structurally ongoing. Network value and usage fluctuate as economic conditions change, with periods of distribution and consolidation repeating over time. The post is intended as a conceptual explanation for why monetary networks may not conform to familiar technology adoption curves.

BankQuote Contrasts Bitcoin’s fee-driven Model with Kaspa’s volume-based Security

Research account BankQuote (@BankQuote) published an analysis this week arguing that Bitcoin’s primary limitation is structural rather than incremental. In a single-chain blockchain, increasing block frequency or capacity leads to a higher rate of stale or orphaned blocks, which weakens the effective security of the canonical chain and reinforces incentives for conservative, low-throughput operation. As block subsidies decline, this dynamic pushes Bitcoin toward a “low-velocity” equilibrium that depends on high transaction fees to sustain miner incentives.

The analysis contrasts this with Kaspa’s use of the GHOSTDAG protocol and BlockDAG architecture, which allows blocks to be produced and ordered in parallel rather than discarded. By incorporating all valid blocks into consensus, Kaspa avoids the security trade-off that forces Bitcoin to choose between speed and safety. BankQuote points to Kaspa’s current 10 blocks-per-second operation and longer-term scaling targets as materially altering the network’s economic assumptions.

Rather than relying on a small number of high-fee transactions, the post frames Kaspa’s model as volume-driven. Miners are compensated through many low-cost transactions instead of scarce, expensive block space, creating what BankQuote describes as a “velocity-driven” security model. In this view, continuous transaction flow supports long-term network security without requiring ever-increasing prices or fee pressure to sustain incentives.

Kaspa Hub on How Kaspa Solved the Trilemma 

This week, Kaspa Hub published a comprehensive explainer revisiting why Kaspa is widely viewed as having resolved the blockchain trilemma. For long-time followers, the piece serves as a clear refresher on the architectural choices that differentiate Kaspa; for newcomers, it provides a single, shareable reference that ties those choices together without requiring deep protocol background.

The article frames Kaspa’s approach as preserving Bitcoin’s core proof-of-work principles while extending them through a BlockDAG data structure and the GHOSTDAG consensus protocol. By allowing parallel block production and ordering blocks based on the heaviest observed subtree rather than a single chain, Kaspa increases throughput and reduces confirmation times without sacrificing security or decentralization.

Beyond the traditional trilemma dimensions, the post emphasizes sustainability as a necessary fourth pillar. It points to pruned nodes, low hardware requirements, predictable resource costs, and long-term fee viability as factors that help prevent gradual centralization over time, particularly as transaction volume grows.

Rather than presenting new claims, the Kaspa Hub article consolidates known design decisions, performance data, and consensus research into a cohesive narrative. The result is less a technical deep dive than a reminder of the original thesis behind Kaspa’s design, and why its scaling path differs materially from proof-of-stake systems, sharding approaches, or layered execution models.

FluxCloud offers free compute sandboxes to Kaspathon builders

Decentralized cloud provider Flux, which runs applications across a globally distributed network of independently operated servers rather than a single centralized data center, announced it is providing free FluxCloud compute credits to all registered Kaspathon participants, giving teams an open sandbox to deploy and test applications during the hackathon.

The offer includes access to FluxCloud’s decentralized infrastructure for frontend or backend deployments via Docker or Git, allowing builders to focus on development rather than provisioning servers. Flux stated the initiative is not a partnership, but a commitment to supporting ecosystem builders with censorship-resistant compute during Kaspathon.

Y Stan Shares a Kaspa  Adoption Theory 

Kaspa community member Y Stan outlines a framework for how Kaspa could reach global relevance, arguing that adoption emerges when multiple independent forces align over time rather than from any single catalyst such as price, narratives, or institutional endorsement.

The post describes how Kaspa’s technical architecture, proof-of-work incentives, market infrastructure, community credibility, institutional access, and regulatory neutrality can reinforce one another. The central argument is that Kaspa’s adoption path is driven by structure rather than narratives, with progress depending on measurable developments across infrastructure, incentives, market access, and regulatory resilience.

Introducing K Notes – A Community-led Review Initiative 

K Notes was introduced this week as a new, community-driven project focused on transparency and open review within the Kaspa ecosystem. Currently in active development, the initiative plans to publish conservative, evidence-based observations on Kaspa-related projects, tools, and activity, without price targets or market forecasts.

According to its introduction, all reviews will be conducted independently, with the longer-term goal of evolving toward community governance. Media distribution and visibility for K Notes will be supported by KaspaDaily. Follow @kaspa_notes for updates. 

KasMaps Updates – Infrastructure Upgrade 

KasMap released a set of updates this week alongside the deployment of its new backend infrastructure, with account migrations now in progress and support available for users who need assistance completing the transition.

The update introduces several new features, including a Marketing Hub designed to help coordinate local and global Kaspa community campaigns, as well as expanded event tooling. Event listings now support paid events, with a built-in calculator that displays pricing in KAS and optional conversions to USD, EUR, and local currencies.

According to the team, missing assets, such as images or text, can be recovered from stored data, and users are encouraged to re-upload content directly where possible to speed up the process. The changes position KasMap as a more comprehensive coordination layer for Kaspa-related events, campaigns, and community activity. Congrats KasMap!

Kaspa.stream Adds Blue-score Navigation and Genesis Search 

Kaspa.stream creator SuperTypo released an update to Kaspa.stream that adds navigation by blue score to the block details page, making it easier to move forward and backward through Kaspa’s history.

Users can now browse blocks sequentially starting from the Kaspa genesis block, with “Genesis” also supported as a searchable term. The update improves historical exploration and makes early network data more accessible for researchers, developers, and users.

Following the update, Chris Hutchinson of Rock the Kaspa commented: “SuperTypo is an underrated hero in the Kaspa space.”

Kaspa Lens adds Performance Comparison Tooling

Analytics site Kaspa Lens this week introduced new performance comparison charts designed to contextualize Kaspa’s market performance against nearby high-volume assets. The tool compares KAS to the three highest-volume non-stablecoins, as well as the assets ranked immediately above and below it by trading volume.

Comparisons are normalized across multiple timeframes (24h, 7d, 30d, 1y) and regenerate daily as market rankings change. The feature is presented as a data-only reference, offering relative performance context without embedded interpretation or commentary.