no timline

join discord for discussion https://discord.gg/wte5YWyf

or contribute directly

https://github.com/drbommel/zensia/discussions/1

Hi MarkM,

Thank you for the excellent and insightful question. It’s a crucial point, and it gets right to the heart of why we believe the Zensia project is a necessary endeavor.

You are absolutely right to draw a parallel with Diamond (DMD). We have a great deal of respect for the DMD project, particularly for its incredible resilience and its long-standing, community-driven ethos, which has been its hallmark since it was founded back in 2013. Its ability to survive and adapt is a testament to its community's strength.

The core of your question—"wouldn't it make sense to add zk-SNARK stuff to Diamond DMD?"—is where our foundational philosophies diverge. The difference can be best described as iteration vs. inception.
Diamond's strength lies in its successful history of iteration. It has pragmatically evolved over the years by integrating proven, successful technologies from across the industry. Its most recent major upgrade to DMDv4, which made it fully compatible with the Ethereum Virtual Machine (EVM), is a perfect example of this. This has made DMD a powerful and interoperable platform for transparent smart contracts, and its entire ecosystem is built upon that transparent, account-based ledger.

Zensia, on the other hand, is a project of inception. Our guiding principle is to explore "how Satoshi would design Bitcoin in 2025," which means starting from a blank slate with privacy as the primary, non-negotiable foundation. We believe that for privacy to be truly robust and the default for all users, it cannot be an optional layer or an added feature. It must be woven into the very fabric of the protocol from the first line of code.
This brings us to the technical challenge of simply "adding zk-SNARKs." True, protocol-level privacy of the kind Zensia envisions requires a fundamentally different architecture—a shielded ledger where transaction amounts, senders, and receivers are not public by default. DMD is built on a transparent ledger, which is essential for its EVM compatibility and current dApps.

Attempting to retrofit a native privacy model onto DMD would not be a simple "addition." It would require a fundamental, breaking change to its core architecture. This would not only be an immense technical challenge but would also invalidate the entire existing ecosystem of tools, smart contracts, and applications that the DMD community has worked for years to build.
So, while we share the goal of a community-driven project, our architectural destination is completely different. We believe that trying to force DMD down a path of native privacy would be a disservice to its own unique strengths and accomplishments.

Instead, Zensia is charting a new course to see what is possible when a system is designed for privacy from day one. We see these two approaches not as competitive, but as complementary and vital to a healthy, diverse decentralized ecosystem.
Thanks again for the thoughtful engagement. It’s exactly this kind of critical thinking that helps push open-source projects forward.

All the best.

The Zensia cryptocurrency project is currently in an early development phase with prototype/reference implementation code. There’s no specific timeline mentioned in any of the documentation about when mainnet would launch. Here’s what I can determine about the project’s trajectory toward mainnet:

Current status:

    Core implementation files exist but appear to be reference implementations
    Documentation is relatively comprehensive but theoretical
    Test coverage is moderate (~28%)
    The project is preparing for a GitHub open-source launch to attract contributors

I would be happy if somebody launch a discord. I don´t want to do it because I have already done documentation and prototype and I don´t want to act as centralized authority. Zensia shall be a community driven project. If it is not picked up by people, the experiment failed.

While coding the basics, I‘ve added a feasability report with core technology assassment. https://github.com/drbommel/zensia/blob/main/docs/research/feasibility_report.md


 Quote:

„The good news is that all core technologies required for Zensia are already invented and proven in various production systems. There are no fundamental technological barriers preventing implementation of the features described in the roadmap. However, there are several areas where developers will face significant challenges:

Zero-Knowledge Proof Implementation Status: Exists but complex • ZKP frameworks like zk-SNARKs and zk-STARKs are well-established • Libraries like libsnark, bellman, and arkworks exist
Challenge Level: High • Implementing ZKPs correctly is mathematically complex • Security vulnerabilities can be subtle and catastrophic • Performance optimization requires specialized knowledge

Recommendation: GitHub contributors should leverage existing ZKP libraries rather than implementing from scratch, and arrange for academic review of the implementation.

Privacy-Preserving Consensus
Status:  Conceptually sound but implementation challenges • Combining privacy features with PoS consensus is theoretically possible • No major cryptocurrency has fully implemented this combination yet

Challenge Level: High • Validating transactions without full visibility is complex • Preventing double-spending while maintaining privacy requires careful design • Governance and staking reward distributions with privacy add complexity

Recommendation: Create a detailed specification for the consensus mechanism and undergo extensive peer review before implementation.

Network Layer with Privacy Status: Exists but integration challenges • Onion routing (Tor), mixnets, and I2P exist and work • Integration with blockchain P2P networks has precedents (e.g., Monero) Challenge Level: Medium • Network-level leaks can compromise transaction privacy • Performance trade-offs are significant • Bootstrapping a decentralized network with privacy is challenging R ecommendation: Adopt and adapt existing privacy network protocols rather than creating new ones.

Scalability Solutions Status: Partially solved • Layer 2 solutions, sharding, and state channels exist • Combining these with strong privacy remains challenging

Challenge Level: Very High • This is the area where developers will likely struggle most • Privacy features typically increase computational and storage requirements • Maintaining privacy across scaling solutions is an open research area

Recommendation: Start with a well-functioning but limited throughput system, then incrementally add scaling solutions with careful testing.

What Might Cause the Project to Fail?

The project is unlikely to fail due to missing technology, but rather from:

Implementation Complexity o The integration of multiple complex systems could lead to security vulnerabilities o Developers might underestimate the challenge of correctly implementing cryptographic primitives
Resource Constraints o Privacy features increase computational overhead o Without sufficient resources for development and security audits, implementations may be flawed
Regulatory Challenges o Privacy-focused cryptocurrencies face increasing regulatory scrutiny o Legal uncertainties could impact adoption and development
Community Coordination o The community-driven approach requires effective coordination o Without strong technical leadership, implementation quality may suffer
Will GitHub Developers Struggle with Implementation?

Yes, in certain areas:

Areas of Likely Struggle:

Cryptographic Implementation o Correctly implementing zero-knowledge proofs o Ensuring cryptographic assumptions are valid o Optimizing performance of cryptographic operations
Distributed Systems Design o Maintaining network consistency with privacy constraints o Handling edge cases in consensus with incomplete information
Testing and Verification o Creating comprehensive test suites for privacy-preserving systems o Formal verification of critical components
Areas of Lower Difficulty:

Web and API Development o Wallet interfaces and explorers o API services for blockchain interaction
Documentation and Tooling o Development tools and environments o User and developer documentation
Recommendations to Mitigate Challenges

Phased Implementation Approach o Begin with core functionality, then add privacy features incrementally o Allow extensive testing between implementation phases

Leverage Existing Libraries o Use established, audited cryptographic libraries o Adapt proven privacy techniques from existing projects

Academic Collaboration o Partner with academic researchers in cryptography o Submit implementations for peer review before deployment

Security Focus o Allocate significant resources to security audits o Implement bug bounty programs early o Create formal verification for critical components

Reference Implementations o Provide detailed reference implementations for complex components o Include extensive documentation and test cases

Conclusion The Zensia project is technically feasible with current technology. There are no “missing inventions” that would prevent its implementation. However, the integration of multiple complex privacy and consensus technologies presents significant challenges that will require disciplined engineering, extensive testing, and potentially academic collaboration. The most critical areas for focused attention are the correct implementation of zero-knowledge proofs, the integration of privacy features with consensus mechanisms, and the development of scalability solutions that maintain privacy guarantees. With proper technical leadership, phased implementation, and rigorous security practices, the GitHub community should be able to successfully implement the Zensia roadmap, though certain advanced features will require significant expertise and resources.“

Of course! That would be great. The more people we can excite about this idea, the more likely Zensia’s final implementation will become.

What about a discord group?

Very gladly. It’s your turn. I’ve already made too many decisions on my own :-)

Exactly. Communication channels and voting systems should be created for this purpose. I didn’t want to do it myself, as I’ve already proposed the idea and prefer not to appear as a central authority.

I appreciate your concern about keeping things simple and ensuring censorship-resistance above all else. However, Zensia’s hybrid model isn’t just about reducing energy consumption for its own sake—it aims to address several core challenges simultaneously:

   1.   Fair Initial Distribution
A brief Proof-of-Work (PoW) phase helps distribute the stake among a broader group of participants early on, emulating the open, neutral launch that made Bitcoin special. This approach prevents a small set of insiders from accumulating an unfair proportion of tokens at the outset.
   2.   Long-Term Security & Finality

After that initial window, switching to a Proof-of-Stake (PoS) mechanism with Byzantine Fault Tolerance isn’t purely for energy efficiency. It also provides fast transaction finality and protection against certain double-spend or chain-reorg attacks that can happen in slow-block PoW systems. In other words, it’s not just about “green credentials,” but about robust security and user experience.

   3.   Censorship-Resistance Is Not Sacrificed
While PoW has historically proven resilient against censorship, a well-designed PoS system—especially one that embraces decentralized governance and a wide, fair distribution—can be equally censorship-resistant. If validators are geographically and ideologically diverse, no single entity has the leverage to block transactions effectively. Add to that Zensia’s privacy features (zk-proofs and stealth-like addresses), and it becomes even harder to single out or censor individual users or transactions.

   4.   System Simplicity vs. Real-World Constraints
Simplicity is always appealing, but real-world adoption calls for solutions that address energy usage, scalability, and convenience alongside censorship-resistance. Sticking purely to PoW might sidestep complexity in the consensus design, yet it can introduce other complexities—like concentration of mining due to specialized hardware, or network fragmentation if block times/fees become prohibitive.

   5.   Balancing Ideals and Practicalities
Bitcoin’s original design is brilliant, but it also emerged in a different era. Zensia’s hybrid approach takes the best of both worlds—ensuring a fair, open launch (PoW) and then using a more advanced, efficient, and finality-focused mechanism (PoS) once the token distribution is diverse enough to mitigate centralization risks.

In short, “energy efficiency” is not the sole driver of Zensia’s hybrid consensus. We aim to preserve censorship-resistance, achieve equitable distribution, and offer faster, more secure transaction finality. While simplicity is valuable, so is evolving to meet today’s requirements without abandoning the cypherpunk ethos of decentralized, permissionless finance.

You are right. It is very complex, and the goals proposed in the preprint are ambitious. On the other hand, such a project seems necessary. Technology has evolved significantly in the 15 years since Bitcoin’s inception, and I’ve often wondered how Satoshi would design it today. No question—my love and respect for Bitcoin will always remain unwavering. At the same time, the early development creates inherent limitations. For example, it will be challenging to achieve a fair transition to a quantum-resistant network (https://blog.lopp.net/against-quantum-recovery-of-bitcoin/). I also think pure peer-to-peer is no longer unique. The next technological battle will take place at the intersection of privacy and authenticity (DID).

I’m pleased to have found a fellow supporter, and it would make me even happier if more people joined us. My proposal in the preprint requires many talents in cryptography and programming. Additionally, a communication infrastructure for the community still needs to be established. I intentionally did not take on this task myself, as I hold high standards for Zensia as a purely community-driven project. My role should remain that of a normal contributor.

Hello everyone,

I’d like to share Zensia, an early stage open-source cryptocurrency project with a privacy-focused design and no centralized authority or pre-mine. We’re releasing Zensia under the MIT License, and we welcome critical reviews and contributions from the community.

Key points:

Privacy & Cryptography
Zensia integrates a zero-knowledge proof layer (zkSNARK-based) to allow confidential transactions while preserving verifiability.
Our aim is to ensure fungibility and user privacy without sacrificing scalability or security.
Consensus Mechanics
Zensia uses a hybrid approach: an initial short Proof-of-Work “fair launch” window to distribute the stake widely, followed by a long-term Proof-of-Stake model (BFT-style) for energy efficiency and fast finality.
We invite scrutiny of our staking logic and block validation flow—particularly regarding potential centralization or game-theory exploits.
Governance
All protocol changes are proposed and evaluated openly via on-chain signaling and community discussion (GitHub + public forums). There is no foundation or core team with override privileges.
We rely on community-driven development: if you spot improvements or security vulnerabilities, please open an issue or pull request.
Open Collaboration
The Zensia repository (source code + specs) is here:
https://github.com/drbommel/zensia
(Please note: the repository is brand new)
We are particularly interested in participation and further development
We are especially interested in in-depth reviews of the cryptographic routines
 
We believe in the cypherpunk principle of open scrutiny. Zensia is not backed by VCs or corporations; it’s purely a community experiment in fair-launch tokenomics and robust privacy. If you find any design flaws or improvements, we’d appreciate your expertise.

How to Participate:

Read README.md, Preprint docs/research/preprint and feasibility report docs/research/feasibility_report on Github
Review or fork the code on GitHub.
Propose protocol changes if you see possible pitfalls (issues or PRs welcome).
If there’s interest, feel free to discuss https://github.com/drbommel/zensia/discussions/1
Disclosure:
Zensia is still in early development. We don’t promise financial returns or brand endorsements; we simply hope to foster a resilient, censorship-resistant payment and contract platform driven by open collaboration.

Thanks for reading—and we look forward to your feedback. If you have cryptographic expertise, your input on our ZK privacy layer is especially appreciated.

Best regards,
The (Unofficial) Zensia Contributors