What Makes Zen Different

The following is meant to offer a clear breakdown of Zen’s value and differentiators to those of you who are new to the crypto space or just haven’t yet gotten around to reading our white paper. One of the goals of this project is to help make the world of digital coins, blockchain, etc. more digestible and less intimidating for curious newcomers by building an inclusive, supportive community striving to educate about the space.

To understand Zen, you must first be comfortable with Bitcoin, the cryptocurrency, and blockchain, its underlying technology. This is not meant as discouragement: I’m writing this article as someone whose entrance into the crypto space was preceded by a whole lot of diligent self study. If you’re still in the process of seeking proficiency in the space, take a look at some of the resources on blockgeeks and bitsonblocks.

Zen, fundamentally, is the overarching system over which ZenCash tokens disseminate. This framework facilitates the propagation and storage of data, and is designed to be the most secure, privacy-oriented of its kind. On May 18th EST, Zen was formed by a hard fork from ZClassic, which is a more community-oriented version of Zcash (which is an evolution of Bitcoin). On June 13th EST, we upgraded our software to mitigate a recently discovered replay protection vulnerability. Since then, our strong team of developers has been working on the next major items on our road map.

ZenCash will essentially be designed as a more secure, anonymous version of Bitcoin (for those of you who haven’t heard, Bitcoin transactions aren’t anonymous), with further benefits of a devoted, mission-driven leadership team, and a guaranteed pool of resources for the community to mobilize toward initiatives such as outreach, software development, social entrepreneurship, partnerships, etc.

The initial Zen leadership team consists of Rob Viglione, Rolf Versluis, Steven Nerayoff, and myself (Jane Lippencott). Steve has recently joined us, and I will be properly introducing him via another blog post (I’ll be interviewing him, actually). He is an incredible visionary in the tech space, pioneering Ethereum, Classic, Lisk, and CloudParc. Charles Hoskinson, a founder of Ethereum, Ethereum Classic, Bitshares, and IOHK, has already begun to act as our moral conscience and assumption-challenger, above and beyond his day job as a Zen senior advisor.

In later stages of development (we just launched a few weeks ago), Zen will differ from both of its predecessors, Bitcoin and Zcash, in the following ways:

– Decentralized governance model

Zen is designed with a decentralized governance model incorporating multi-stakeholder empowerment and the flexibility to evolve to optimally suit our community. 8.5% of block rewards will be allocated to fund outreach initiatives, project development, and proposals submitted and voted on by our community.

– No Founders’ Reward

Instead of 10% of the coin supply going to repay early investors, our Founders built in a mechanism to direct 12% of coins to a communal pool used to fund development, community proposals, outreach campaigns, & other functions necessary to keeping our system on the cutting edge.

– Secure Nodes

This incentivized system adds on a layer of security that we think will decrease our vulnerability to traffic correlation attacks, and leaves the system architecture open for interesting future development in the privacy space.

– Secure Node rewards

We reward nodes meeting our security requirements with 3.5% of all block rewards. You don’t have to be a miner to make money securing our network, you can also choose to set up a Secure Node!

– Voting & proposal system

Our voting system will serve multiple purposes, the main two being selection of projects to be funded by the community pool, and election of people to administer the system.

– Domain fronting

Domain fronting extends the ability to complete transactions in adversarial network environments, such as in countries implementing strict internet censorship. We’ll be using HTTPS encryption to communicate with a censored host while appearing to communicate with an alternate, permitted host.

… And we’re just getting started. That’s just our tech and structure, can you imagine how beautifully those functions will merge to create unprecedented use cases? Check out some of our ideas on application in our white paper.

Thank you for reading, Zenner (Thoughts on your new nickname? We haven’t decided what to call our community members yet; feel free to weigh in on our slack channel).