Kaspa Timeline: 2025

Yonatan's article:

https://hashdag.medium.com/in-which-we-are-all-faceless-until-we-have-faces-part-i-5f100e0555a4

Summary of Yellow Paper Content:

The vProg protocol is a revolutionary blockchain scaling solution whose core is to solve the dilemma where "sovereignty" and "composability" between applications (vProgs) are difficult to achieve simultaneously without sacrificing underlying decentralized security.

1. The Fundamental Contradiction Solved: Sovereignty vs. Composability

• Traditional Dilemma: If applications want to maintain independent sovereignty (managing their own states without interfering with each other), it is difficult to achieve efficient synchronous interaction (composability); conversely, if they are forcibly put together to achieve composability, they will drag each other down, forming performance bottlenecks and losing sovereignty.

• vProg's Goal: Enable thousands of decentralized applications to interact securely and atomically in real time as if on a single chain, while each application maintains a high degree of independence and anti-censorship capability, thereby forming a powerful and non-fragmented unified economy.

2. Paradigm Shift: From "Global Execution" to "Local Verification"

The core innovation of the protocol lies in role separation and proof mechanisms:

• L1 as "Trust Anchor": The Kaspa mainnet no longer "computes" all programs but retreats to neutral infrastructure, responsible for:

  • Ordering and Data Availability: Determining transaction order and ensuring data is queryable.

  • Dependency Calculation: Like a traffic commander, precisely calculating which vProgs a transaction will "affect" (defining the "computation scope") and performing resource metering to prevent network congestion.

• vProg's "Sovereign Execution": When a vProg (A) needs to interact with another vProg (B), A's nodes will not passively wait for B's response but will actively simulate executing B's code locally. This ensures that A's operation never stops due to B's failure.

• ZK Proofs as "Trust Foundation": Whether the result of local execution is correct is not subjectively judged but cryptographically verified by zero-knowledge proofs. Any node can quickly verify the authenticity of the proof, thereby trusting the result of local execution.

3. Key Mechanisms for Achieving Infinite Scaling

• Shallower State Anchors: The more frequently vProgs submit state proofs to the mainnet, the less historical data other nodes need to trace to verify their current state (the shallower the "anchor"), the smaller the burden of cross-program interaction, and the lighter and more efficient the overall system.

• Incentive-Driven Proof Market: This creates a natural economic demand, spawning a professional, competitive prover service market where they profit by frequently submitting proofs while passively maintaining the high performance and scalability of the entire network.

Ultimate Vision:

The vProg protocol aims to build a "sovereign network effect" system: each application is an independent kingdom (sovereignty), but through a set of cryptography-guaranteed universal rules, these kingdoms can seamlessly and securely trade and cooperate (composability) as if on a continent, while the foundation carrying all this (Kaspa L1) always maintains its decentralized solid nature.

Yonatan's Response to This Matter

Regarding kas.fyi: unfortunately owner was somewhat burnt by previous community interactions around a certain krc20 issue, and is no longer interested in receiving support, instead insists on selling (price is legit, it's his efforts, but we can fund a dev for a full year with same budget).

Our plan B is to fund Alex (KIP16 author) to help fill the gap kas.fyi created - whether he does so via a new platform or through existing ones, we discussed, but I'll leave to him to communicate. There is clear value in redundant explorer infra, and afaik both existing ones use kaspa.org api.

I want to reiterate: if you have created infra for Kaspa that is already used and loved, and serves as a public good, we* will find sources to fund you. Please message me before you are burnt out and want to exit and sell - rather when you are still committed to project and just need some kas support and a nudge of deserved recognition for your efforts. But again pls refer to the beginning of this paragraph and comprehend the context of this.

I want to thank kas.fyi for his enduring contribution. I'm sorry that my offer to support came too late, when you were already looking to exit. I hope you reconsider.

Chinese translation:

关于 kas.fyi 平台：遗憾的是，该平台所有者曾在某起 KRC20 相关事件的社区互动中受挫，如今已无意再接受社区支持，执意要将平台出售。（平心而论，这个报价契合他为平台付出的心血，但我们用同等预算本可以资助一名开发者全职工作一整年。）

我们的备选方案是，资助 KIP16 协议的作者 Alex 来填补 kas.fyi 停运后留下的空白。我们已就此讨论过相关方案 —— 无论是由他开发一个全新平台，还是基于现有平台进行功能拓展，具体细节将由他本人向社区公布。区块链浏览器这类基础设施的冗余性建设具有重要价值，而且据我所知，目前社区现有的两款浏览器均基于 kaspa.org 的官方接口运行。

在此我想重申：如果你为 Kaspa 生态开发的基础设施已投入使用并获得社区认可，且具备公共产品属性，我们定会为你协调资金支持。请务必在你心力交瘁、萌生退意并打算出售项目之前联系我 —— 最好是在你仍对项目满怀热忱、只是需要一些 Kaspa 代币支持，以及希望自己的付出得到应有的认可之时。但再次提醒，请务必结合本段开头的前提条件，理解这一资助承诺的适用场景。

最后，我要感谢 kas.fyi 长期以来为社区做出的贡献。很抱歉，我提出的支持提议来得太迟，彼时你已决心退场。但愿你能重新考虑。

• Source: https://discord.com/channels/599153230659846165/916662870379491328/1449862229158531193

Translation:

In any case, the K network has the following mitigation measures (the K network gives users data autonomy through the following ways):

1. Personal Indexer: You can run your own personal indexer node, and unwanted data will be automatically filtered or deleted locally.

2. Public Indexer: The operators of public indexers manage their own databases. This means that if they wish, they can also clear any unwanted data in their databases.

You can view the community-developed K indexer example repository (https://github.com/thesheepcat/K-indexer/tree/master?tab=readme-ov-file), which already provides related tools.

The key point is: in a decentralized network like K, it's not that "no one manages it," but that "management rights are completely given to users"—you have complete autonomy over your data and nodes.

This is its most important feature!