OpenZeppelin, formerly ZeppelinOS, is an open source, decentralized platform where software engineers can develop, deploy, and operate smart-contracts and smart-contract based projects.
OpenZeppelin, formerly ZeppelinOS, is an open source, decentralized platform where software engineers can develop, deploy, and operate smart-contracts and smart-contract based projects. Self-styled as an ‘operating system’ for the Ethereum Virtual Machine (EVM), OpenZeppelin sees itself as enabling the development of feature-rich applications—replicating the historic function of operating systems, if not their typical uses in managing a computer’s CPU, memory, storage and other core hardware processes. The project was co-founded by Demian Brener, a former Business Analyst at Quasar Builders, and Manuel Araoz, a former Software Engineer at Bitpay Inc. The project’s token, ZEP, was created to “align incentives where required to create a healthy ecosystem of secure smart contract projects” and is primarily used to publish and maintain EVM software packages.
OpenZeppelin’s EVM ‘operating system’ consists of four components. OpenZeppelin’s Kernel is a community-governed on-chain smart contract library. The library will provide a basic set of curated packages that developers can set applications to call on, facilitating the development of more sophisticated dApps or smart contract based projects. OpenZeppelin’s Scheduler allows smart contracts to be executed asynchronously. The Zeppelin team foresees this functionality being used in several circumstances—it would, for example, avoid the scenario, currently common in executing a transaction via a multisig contract whereby the last signer is burdened with the gas costs, by allowing anyone to pay and (perhaps) be rewarded. OpenZeppelin’s Marketplace is for inter-contract services—the team foresees smart contracts being developed so to interact with other platform’s smart contracts in a standardized manner. Finally, the project released a set of off-chain tools that simplify the process of debugging, testing, monitoring, and deploying decentralized applications, making it easier for developers to build valuable applications and services.
OpenZeppelin’s token, ZEP, was distributed in a private beta that was designed to promote initial EVM package development. Participating organizations, including projects such as CoinFund, Decentraland, Dharma, District0x, Gnosis, LevelK, Livepeer, OpenZeppelin, and Status, gained access to the token as compensation for contributions.
ZEP is primarily used to monetize software packages offered through the platform’s Kernel library: ZEP must be staked (‘vouched’) to publish such packages, with the ZEP holding community maintaining package quality through various contribution and challenge mechanisms, which also utilize the token. ZEP additionally confers holders governance rights and is used as a means of payment: stakeholders votes influence what software changes are made to the entire ZeppelinOS architecture, and users can purchase any Marketplace services—file storage, distributed computing, oracle provision, etc.— in ZEP, allowing users to use a single currency rather than a discrete token for each service. In cases where the ZeppelinOS Scheduler needs to be manually triggered, gas costs will be paid in ZEP.
ZEP’s uses in the community’s governance of the Kernel smart contract library are various. EVM package developers, who create packages offering token, math libraries, data structures, voting, or oracle functionality, must lock tokens to publish packages to the platform. Package developers can monetize such offerings by charging a linking fee, paid by developers who integrate a package. Any user can additionally vouch for a package, earning a small portion of link fees, should the package developer support this in their monetization model.
Vouching is intended to incentivize package development, bug fixes, and good behavior. A contribution system allows any user to submit code to a package and be compensated through vouched tokens, should the package’s developers accept the code. Dishonest developer behavior, such as rejecting then integrating contributor code, is subject to oversight through a challenge system. Additionally, anyone can challenge code thought ‘buggy.’
Challengers stake tokens ‘in correspondence with a challenge’s severity’, and vote is held amongst ZEP holders. Depending on the vote’s outcome, either the developers or the challenger loose vouched tokens, with the majority voters receiving a portion of tokens in either case, and the challenger receiving an additional portion should the challenge prevail. Developers can choose to accept bug reports before the matter goes to vote, compensating challengers for a fraction of the challenge vouch.