I'll respond here as I'm not on the $kas Discord server. Q: "I have found Shai's reviews of Igra lacking in [...] A: I never once reviewed Igra Q: "his outright dismissal of Kasplex lacking in specifics" A: I don't think that's unreasonable of me to lack in specific given that the core of my criticism is that they don't publish the specifics of their design to public scrutiny. Q: "Based on discussions here, it's not plausible that a SC platform lacking zk proofs could be considered decentralized." A: I have not read said discussions, and I definitely do not consider them an irrefutable scientific source. I don't have the full details about Igra's design, and what trust model it will have eventually. I am working with what I have. There isn't enough information to make definitive statements about either technology. That's why the discussion is about conduct. On the one hand, I see Kasplex, who have a track record of releasing centralized protocols, having poor quality control, being obtuse about the details, and setting near-term launch dates before the community has had the chance to review and comment on their network. On the other hand, I see Igra, who are constantly consulting with the community, go out of their way to answer any questions, and already provided infinitely more information about their product than Kasplex, despite not having anything near a mainnet launch date. Now here is the thing: conduct is something only the community can enforce, especially in a fair-launch project. Neither Kasplex nor Igra owes it to the community to share anything at all. But on the other hand, the community doesn't owe any of them their trust and support. That has to be earned. It is the community's responsibility to keep builders straight by constant scrutiny and pushback. And those who engage (like Igra) should be rewarded, while those who constantly avoid and deflect it (like Kasplex) should be penalized. Rallying up behind any project just because "it is building on Kaspa", completely disregarding its work ethics, business culture, or ulterior motivations, is just asking to be exploited. It is not Kasplex's responsibility, neither it is Igra's responsibility. It is your responsibility. Or even more directly: Ask. Everyone. Everything. Air out all the hard questions. Press until you get answers. Don't let up. Don't let them lie to you, sell you dreams to make you apathetic, or deflect to other subjects. Take them up on their promises. Make every builder and investor eyeing Kaspa from outside see that the Kaspa community has a compass for quality. Make it having the community approval be a badge of honor that has to be earned, not something that can be bought with some cash and a lot of compelling but unsubstantiated promises. Here's a great opportunity to demand answers from Kasplex: I already pointed out some key question: What is the trust model? How will bridging work? When will they publish it? Will the community have enough time to scrutinize it? Didn't you announce that you are getting a security audit? When is it due? How does it make sense to announce a launch date before the audit was even published? Will it be published before launch? What about the source code and documentation? You can also get more technical: what kind of ZK proof system are you using? Are you going to use a prover network? If so, how are you going to fund it? Will it be possible to trustlessly sync full nodes, or only light nodes based on trusted snapshots? Etc. etc.. I have no intention to participate myself. As I said, this is a Kaspa community thing, and I don't see myself as a part of this community. But if you agree with me, you will take advantage of this (and any) opportunity to demand answers, and not let them get away with part-answers, deflections or excuses. Q: "Short of true L1 decentralization via zk proofs, if the builder wants to rug you, they will find a way." A: That observation is pretty flawed. It doesn't even claim that ZK are essential for decentralization, it claims they are essential for security. That without them, all money is stealable? What? I mean, say Igra does go for MPC bridging, how will they "rug" you? Even if they control 95% of the validators, they can't fake a proof. The best they can do is withhold your funds indefinitely, but there are solutions for that too (timelocks that allows you to withdraw the money once the expire, etc.). This statement is just way too generalizing and unrealiztic. Q: "A novel quasi-decentalized system would seem to be more difficult to implement than something off-the-shelf, well-tested, and quite centralized. The former would seem more liable to break down or get exploited." A: Do you know many "off-the-shelf" based rollup systems? Why bother with based rollups at all? Heck, why bother with Kaspa? Use Tron instead. It might be more centralized but it is "less liable to break down or get exploited" (or at least it was in 2021 when Kaspa was just born) and it is "well-tested", so according to your standards, it's "better". Guys, I don't know what about you, but I was on this ride for disruptive, groundbreaking tech. Not to create the best sequencer in the world just to promote centralized crap over it because "it is battle tested". That being said, what exactly makes Kasplex more battle-tested or less likely to break down? Q: "One thing I feel I have the skills to evaluate is Igra's tokenomics, which seems weirdly complicated for no good reason." A: Did you try asking @Igra_Labs about it? Unlike Kasplex, they will actually answer. Q: "I'm concerned this mentality could be carried over to product design." A: Seriously? Q: "It was suggested by @Buddhini that the security level of Polygon was the closest equivalent to the EVMs without zkproofs" A1: You keep shifting between security and decentralization/trust, which (along with some other stuff I already pointed out) makes me suspicious that you didn't really make an honest effort to understand the core of the discussion and criticism here. That being said, you cannot put a bound on "the security" (or "the trust model") of all possible designs. The comparison to Polygon is, to say the least, weird. I mean, here is an example of a design that requires no zk op codes and is as decentralized as Kaspa: do MPC bridging, but instead of using PoS for bridging, use a GHOSTDAG based proof-of-work network. If it has the same hashrate distribution as Kaspa, it provides the same security. Now, this example obviously not practical, but it's not meant to be. It shows that you can't just mathematically bound the "possible security" without making implicit assumptions about the protocols you are allowing, making the entire point moot. A2: You keep saying "with ZK" while pointing out to the trust ZK removes, but not to the trust ZK requires. Ya'll seem to think that once there are ZK opcodes, you can just create and validate proofs, and this removes all trust, and voila. But that's not quite true. Yes, ZK removes trust assumptions, but it also introduces some. Who creates the proof? Who validates that they are actually proofs of the circuit you wanted? (This is not the same as validating that the proof is correct. It is actually much harder.) Ever heard about prover networks? Do you understand their necessity? And if you rely on a PoS-like prover network, how is this any better than trusting a PoS-based bridging? One could even argue that MPC-bridging is more decentralized in a sense, as being a prover almost surely requires specialized hardware. Q: "I wonder what bearing this matter of bridging vs natively issues stables has on Shai's concern about stables on Kasplex" If you think the point is about Kasplex or stablecoins, then you missed the point.