Heya. In some areas, you are correct, in some ...not quite. I can’t do an in-depth response to this post as it would require an even larger post :) So I’ll just focus on what I consider to be key elements. 1) vProgs paper is really just a set of guidelines. It has been reviewed in detail by me and the developers working with me. It has a number of issues, but nothing a team can’t solve within a day in front of the whiteboard. The key pillar (CDAG structure) is solid (but its implementation is very complex). 2) The way vProgs are designed is that they are basically the same as on-chain SCs. If properly done, the UX would be indistinguishable from traditional high-performance smart-contract-capable chains. (but vProgs bring numerous superior capabilities that TBH wipe the floor with all existing tech). 3) vProgs are absolutely possible and feasible - we have been doing R&D in this domain for 1.5 years now, and I have absolutely no red flags. 4) Adoption-wise, vProgs are just like any other SC system - all they need is a well-harmonized SDK with a bunch of primitives. I am trying to steer the design toward zkVM framework neutrality, which increases the project complexity, but for good reasons. 5) The economics of different system layers are actually well understood by some of the people involved. There is, however, no published material on the subject. Typically, this is addressed once you have a PoC. 6) There is a “one size fits all” solution, and that’s vProgs. It is important to understand that vProgs is a ZK composability layer that turns Kaspa from a global sequencer into a global ZK sequencer - without imposing any limitations or obstructing anything. 7) I have recently published a document called vProgs JAM SESSIONS on the TG R&D channel ( aspectron.org/docs/vprogs-ja… and aspectron.org/docs/EPA.pdf ). This document is meant as a "soft bridge" between the R&D performed by my team (Sparkle) and the Kaspa vProg research team. While the document identifies various subjects and poses suggestions, most of them are well understood and, in many cases, have been prototyped on our end ✨. So none of the questions you are raising (specifically) in relation to vProgs are my concern. The REAL problems are the team communication, project management, and the lack of a holistic software architecture (which I am attempting to solve). This is further aggravated by the lack of properly structured funding and ad-hoc attempts by different developers to tackle the challenge. There is currently “no one in charge”. There are a number of developers “developing”, but no one gave guidance with respect to what they should be developing. It is literally a group of construction workers making a building without any architectural plans. Build a sky-scraper, they said, …and everyone is trying to make one. The problem is the fact that the complexity of the project and layers involved are extremely multidisciplinary, and this is not something that a single developer can construct (neither, as a developer, would I be able to). In my recent comms with @michaelsuttonil I’ve stated that in fact the complexity of this is comparable to KIP-1. It’s a very large and complex project. However, if properly executed, with concise and _coordinated_ efforts, an MVP can be achieved within 6-8 months. (note "coordinated" being bold, italics, and underlined). I am currently trying to steer @hashdag toward a proper project execution structure based on the clearly defined architecture. I have huge respect toward @michaelsuttonil, @hus_qy, @FreshAir08, @Max143672, and everyone else working on this, so I can’t just “barge in” and start telling everyone what to do. I can guide and coordinate everyone, but only if they align behind the effort and adopt the architecture I am proposing. So, at this point, I have helped the team to identify key stress points and problems related to ZK (that took us months to understand), and gave a tentative architectural blueprint to the team that is meant to envelop the vProgs Yellow Paper design. I have suggested to @hashdag that we schedule a few weeks of in-person R&D meetings in front of a whiteboard to solidify the architecture, understand everyone’s proficiencies, understand what code and subsystems already exist and can be reused …and execute.