The purpose of this post is to update my personal vision of Zeppelin and Zeppelin’s projects, as their founder and CTO. This is my own personal perspective, and some Zeppelin team members may not be aligned with my views. However, several people told me it would be helpful if they could read my understanding of this topic as a base for further discussions, to inform long-term planning and product design. If nothing else, it has been useful to write it as a personal log.

Zeppelin (the Company)

As an organization and team, we work to build technology that helps bring freedom to the world. I believe in the power of technology to change the world by enabling new ways of doing things and opening new doors. I see a unique opportunity today to empower people who have very few resources: writing code is almost free, and it can have a huge impact in the world.

Personally, I don’t agree with how many things in the legacy world are done. Some old traditions, institutions, and ideas are being carried over from the days before we invented the Internet, and they bring injustice and suffering to millions.

• People die of hunger in a world of abundance.
• Nations force people to pick up guns and kill strangers for reasons they don’t understand.
• People are forced to waste time in unnecessary and meaningless processes.
• People are forced to pay for things they don’t want (e.g., war).
• Many have lost trust in the elites that govern us and watch over the “common good”.
• Our education system prepares kids for an industrial world that no longer exists.

These are all consequences of a system that was the most efficient way of doing things at one point in time. A world based in paper, industry, and big institutions that take care of our needs and worries. But the world has changed now, and its systems need an update. We have more efficient technologies and better tools for deciding for ourselves. This will affect how we choose to spend our time, how we grow personally and professionally, and how we create value for others. I think we’ll see many major changes in how the world operates, and I want Zeppelin to be a big part of that, accelerating, leading, shepherding, and enabling the changes we’re most aligned with.

One such change I personally align with strongly is enhancing the empowerment the Internet has brought to humanity. Roughly 1.2 million new users connect to the Internet for the first time every day, instantly gaining access to most of human knowledge and the biggest human tribe. We still haven’t seen the full potential of this wonder realized.

OpenZeppelin

Our flagship and most-loved project, which made us rename the company from Smart Contract Solutions to Zeppelin Solutions — and later Zeppelin, because everyone called us “the Zeppelin guys.”

The vision of this project is to be a community-built standard of secure smart contracts.

We launched the project two years ago, just before DEVCON2 in Shanghai, as a very ambitious and (what at the time seemed crazy) initiative: smart contract development in 2016 was very chaotic and fragmented, and major hacks happened every month. We managed to get initial community support because we were new to the Ethereum space, but brought in some successes from the early Bitcoin days on our shoulders.

After two years of existence, I think we have achieved the original goal of becoming the community standard for smart contract development. We have 150+ contributors from all over the world, independent and working for different companies, 2,000+ forks, ~6000 stars, and we’ve been on top of industry’s needs, so much so that it’s now seen as the place to look for reference implementations of EIPs.

We recently launched the 2.0 release, which stabilizes the API, is audited, and has 100% test coverage. This allows us to maintain our hard-earned position guiding the work of our amazing community.

Zeppelin Research

We started performing security audits as a way to push the industry to grow and mature. By helping key projects achieve their goals without being hacked, we also built our team’s technical understanding of smart contract development and learned valuable lessons to guide OpenZeppelin development.

Audits were a great strategy to achieve profitability as a company (which means ensuring our long-term survival and achievement of goals) and to grow our network of allies in the space. Many big names such as the Ethereum Foundation, Augur, and DFINITY became close with us after we worked with them on audits, because they loved our work style, values, and output.

In general, consulting (audits are a specific form of consulting) is a great way to make a company viable in a nascent industry. Given the uncertainty of the pace at which a new technology will grow, consulting means getting paid to build expertise and ride the wave. In our case, audits were key to making Zeppelin what we are today: technical thought leaders, one of the most respected teams in the industry, and a beloved brand.

ZeppelinOS

The need for and idea of ZeppelinOS originated from our audit and OpenZeppelin work. By working with our clients, we discovered that the fear of being hacked or of contracts being buggy was the main reason they were paying us good money for our audits and using OpenZeppelin’s community-vetted contracts.

By working closely with more than 50 projects (the link reports only the public audits we did) in the space in our audits and developing OpenZeppelin, we found that smart contract development had lots of pain beyond standardization and security (which we tackled quite successfully with OZ). We discovered that all smart contract developers shared the same pain points:

• Smart contract DX is hell.
• Lack of proper development and testing tooling.
• Understanding smart contract tech is hard (few good education resources).
• It’s very hard to maintain and operate a production smart contract.
• Any bugs found in production are very costly to fix (via redeployment and state migrations): see, for example, Augur’s REP token migration, which cost ~$20k in gas and extra money in consulting fees to us, and both teams worked full time on it for 10 days.
• Each contract is built separately and monolithically with no interaction or shared code.

Given that at Zeppelin we’ve been working with smart contracts since they were a nascent technology (early smart contract work we did dates to 2012), we’re not afraid of its rough edges. We’ve been working with smart contracts on different platforms (bitcoin scripting, off-chain bitcoin transactions, and now ethereum) and are ready to work on whatever the industry is using.

Additionally, our experience playing with smart contracts since the early days makes us very well positioned to tackle these problems head-on and as our main focus. That’s why we decided to create ZeppelinOS, an initiative to make secure smart contract development a breeze.

Since we started thinking about it almost a year ago, we announced it, gathered some community interest behind us (in the form of enthusiasm and investment), and launched the MVP version at ETHBuenosAires, which tackled the two most pressing needs: smart contract maintainability through an upgradeability system, and proper code reusability.

The following steps for ZeppelinOS, tackled in v2, which we recently announced at DEVCON4, are decentralizing the trust by which on-chain code is made secure by:

1. supporting multiple dependencies in the form of EVM packages, and
2. paving the road for a secure code ecosystem where experts can share their analysis of existing code.

What Our 2019 Will Look Like

We’re in a privileged position in the blockchain space: we have a strong brand, an amazing team, a healthy business model, and we’re tackling real problems of real people who are willing to pay money for our solutions.

So 2019 will be a very important year for us: the financial downturn of cryptoassets will make many companies in the space go out of business, and the focus of conversations will go back to building. For us, this means focusing even more strongly on working with the best projects in the space (those that will most likely survive) and continuing to be sustainable (profitable) while investing in long-term development of the core technologies that will realize our vision.

• For Zeppelin the company, we’ll stay lean and continue having the highest standards for hiring, both in terms of vision alignment and culture (our work values). Staying lean will make us survive, and keeping our standards high is our long-term investment.
• For OpenZeppelin, we’ll consolidate the project’s community and learning resources for it to become not only the standard in code quality but also in documentation and contributor experience. This will help bring more developers into the space and will serve as an example of how to build other great EVM packages.
• For Zeppelin Research, we’ve recently created a dedicated team (previously, the whole technical team took turns auditing), and we’re looking to find a sustainable working methodology that combines audits and open-ended research. This will allow us to continue working with strategic projects in the space, helping them be safe from errors and attacks, while learning and exploring new technologies that will nurture our other projects.
• For ZeppelinOS, after v2 release, we’re working with our private beta partners to test our initial implementation of the ZEP token mechanics, while giving support to our current users of upgradeability mechanisms and EVM packages, aiming to become the standard in smart contract upgradeability and code reuse. Next, we’ll work on turning ZeppelinOS into the best smart contract development and operation platform out there. This will reduce the barriers of entry to blockchain technology, allowing more people to bring their ideas to production dapps.

It’s going to be fun! If what you just read resonates with you, contact us to explore working together. Thanks for reading!

A Brief History of Computer Innovation

The first such app was bitcoin, the first free currency. Why are the ~20M bitcoin users willing to pay the price of running a currency on top of a costly, slow platform such as a blockchain? Let’s explore the answer by analogy.

In 1982, why did my dad spend $150 at an obscure computer store in Buenos Aires to buy a Timex Sinclair 1000? He wanted to experiment with programming. He was buying the ability to process information quickly and on his own terms.

In 1995, why did nerds spend thousands of dollars to connect to other computers around the globe? They wanted to read and post messages on online bulletin boards. They were buying access to information.

In 2007, why did so many people choose to spend $500 to carry around a small computer with a tiny screen, few apps, and very bad specs? They wanted a computer on-the-go. They were buying mobility.

Each step in the history of computation brought many inefficiencies, but also a new key feature. Early adopters were willing to pay the cost of switching to a new platform in order to get a taste of something different. Most times even they didn’t understand it fully.

So, what are early adopters buying when they use blockchain-based apps? They want to participate in a global, open, permissionless, stateful playground. They are buying access to global coordination. They get to participate in ground-up, large-scale human coordination experiments.

The time was ripe for such doors to open. We saw the world transition from paper-based systems (e.g., nations) to closed machine-based systems (e.g., corporations) to open digital-based systems (e.g., internet communities). A mere 10 years ago, only nation-states and huge multinational corporations such as Exxon, Google, and Apple could coordinate efforts globally. The cost of doing so was simply unbearable for anyone except them, given how slowly information flowed back then. Some such pre-blockchain experiments were the US dollar, capitalism, socialism, feudalism, the World Trade Center, and the International Space Station. Only huge centralized institutions could withstand the costs of such projects. That’s why they control the data, the money, and the terms on which we interact.

However, since Satoshi released a solution to the Byzantine Generals’ Problem to the world in 2008, the internet turned into a global coordination machine. This enabled us to create a global currency without relying on huge institutions as trust anchors. Not only did this enable bitcoin, but it drastically lowered the material barriers to innovation in the global coordination space by bringing it to the digital space. Kids around the world can now run experiments on global coordination from their mom’s basement at almost no cost. What’s best is that when they disagree on which direction the experiments should take, they can part ways and try their different ideas by forking the protocols. Some such experiments have been:

• A globally shared virtual computer, Ethereum.
• Thousands of privately issued application-specific currencies.
• A cheap, fast, and scalable payment network.
• Many globally available financial products such as decentralized exchanges.

Think about how hard it would have been for anyone to create a new stateful global coordination mechanism (such as the USD for global commerce) 10 years ago. It was virtually impossible unless they had a strong physical presence, collaboration agreements with multiple world regions, huge amounts of capital at their disposal, and lots of people to operate those components. Blockchains turned the internet into a digital jurisdiction where we can all run our global coordination experiments by using code and incentives, instead of paper and coercion.

Next Steps in Global Coordination

However, having a global playground for coordination experiments doesn’t come without its challenges. Nation-states and multinational companies have polished their methods over hundreds of years. We’re starting anew. Just like when online content creators had to rethink how to entertain and inform better than mainstream media. Just like when thinkers in the year 1500 reinvented how to express ideas after the Church lost its monopoly on the creation of books. Our challenge today is to achieve global coordination over the internet using a new perspective, not imitating what nation-states and multinationals did.

Some of the pressing challenges that the new playground blockchain technology has created are as follows:

• It’s a new paradigm: few people know how to use the technology, and there are few good tools to work with it.
• Code runs in a public realm, exposing apps to a global community of very incentivized attackers. This makes improving security practices a top priority.
• As happened in the early days of the web or mobile platforms, there are no blockchain-specific UX patterns, jeopardizing user adoption.

As with every new technology, the first ones to use it are the creative individuals whose imagination pushes them to build a better world. For blockchain, this means hackers: those fluent in managing information at scale. Today, the basic components for solving these problems already exist but are not readily available to developers. What’s missing is a polished and integrated experience to bring experimentation to the next level. A sort of “Operating System” for this new playground. A platform that brings network effects to hackers who are building the revolution by sharing tools and code.

This is why at Zeppelin we recently decided to focus on ZeppelinOS. We want to tackle those problems head-on, and we believe we can do it. We’re creating tools for hackers to rethink how a new global society should work. And we believe in the transformative power of giving tools long kept only for a few to the masses to experiment with. We’ve all seen the amazing improvements that opening a space to permissionless innovation brought to biotech, computing, content creation, and the satellite industry. It’s time to take global human coordination projects into our own hands!

Help us build this future together!

Be part of the community

• Continue the discussion on our forum
• Join our Telegram group
• Follow us on Twitter
• Even better, join the team 🚀

Zeppelin is proud to be sponsoring Devcon3. To celebrate, we are releasing a CTF hacking game at the start of the conference, on November 1st.

The contest includes multiple stages consisting of security challenges and puzzles designed to test your smart contract hacking skills. Each consecutive stage increases in difficulty. Prizes totaling $10,000 USD will be distributed equally in ETH to the first five participants who successfully complete all challenges.

These are the kind of challenges our teams work on every day. Because we’re looking to grow the Zeppelin team, anyone who successfully completes all stages will be granted priority review for our current position openings.

How do you participate?

On November 1st, we’ll be tweeting a link from our official Twitter account that you can use to access the competition. Don’t worry if you couldn’t make it to Devcon3, everyone can participate.

Happy hacking!

Be part of the community

• Continue the discussion on our forum
• Join our Telegram group
• Follow us on Twitter
• Even better, join the team 🚀

We highlighted that “the rate of innovation in building decentralized applications is limited by the manual and duplicative efforts developers must make to ensure basic usability and security.”

zeppelinOS aims to solve this problem. Based on our experience working to secure dozens of projects in the space, we are now building an open-source, decentralized platform of tools and services on top of the EVM to help developers rapidly deploy, upgrade and manage secure smart contracts.

We have classified the features of the OS into 4 categories of services:

• the zeppelinOS Kernel Standard Libraries,
• Smart Contract Development Tools,
• Smart Contract Interaction Tools,
• Off-Chain Tools.

Let’s dive into each of these.

Kernel Standard Libraries

The Kernel is the foundational layer of zeppelinOS: an on-chain set of upgradeable standard libraries offering common functionality and services that developers can call from within their smart contracts.

Common Functionality

The goal for the zeppelinOS Kernel is to provide a set of functions for the smart contracts that run on top of it, requesting services from the OS rather than re-implementing them from scratch.

These functions will be available as an on-chain standard library of reusable contracts and functions, heavily inspired by OpenZeppelin, and held to the same security standards.

These libraries will enable developers to do the following (and more):

• Create and customize your own ERC20 Token.
• Create a capped, refundable, and/or whitelisted crowdsale contract.
• Create a trustless bug bounty.
• Create pausable, ownable, and balance-limited contracts.
• Set up a token vesting or token locking contract.

Security Patches and Continuous Improvement

As a secure base layer that smart contracts communicate with on-chain, we open up the possibility of delivering opt-in upgrades to our users. This enables ZeppelinOS core developers to roll out optional security mitigations and patches as soon as a vulnerability is found, instantly protecting all users of the smart contracts that sit atop the OS.Through the same mechanism, zeppelinOS will always be in a state of continuous development and improvement: the OS will be upgraded based on the proxy library pattern, which we’ve developed through experiments with the Aragon team.

This is how it works: users will be incentivized to review patches and vouch for their correctness. This is necessary to avoid the possibility of a single party upgrading (i.e. changing) all contracts in the OS without control from the community, while providing a mechanism of fast response in the event of a critical security issue acknowledged by the majority. Given the sensitivity of upgrades in the context of smart contracts, we will enable developers to choose between automatic upgrades and manually activated ones on a per-contract basis.

Shared bug bounties

Bug bounties have become a standard practice for smart contract development, as a means to attract auditors to inspect critical code. By having a layer of code shared between applications, users of the OS can place collective bounties on common critical kernel modules. This will be implemented by a decentralized governance bounty pooling mechanism, to be explained in a future post. In this way, security researchers are incentivized to look at the code in a cost-effective manner. This won’t require every smart contract developer to individually disburse large prizes or get their own researchers to have their code audited.

Contract Development

Besides a set of common libraries, the OS will also provide tools aimed at making smart contract development and maintenance easier for developers.

Attack Management

Experience has shown that bugs will always be present in a codebase. As smart contracts become more complex, the probability of bugs appearing increases, becoming more attractive targets for attacks.

zeppelinOS will provide an emergency toolbox for dealing with attacks. Triggering an emergency pause, reverting to a previous uncompromised state, or forking a contract are some of the tools we have been working on. This work was part of OpenZeppelin and we’ll continue improving on it for the OS.

Upgrade Management

In addition to having upgrades of the zeppelinOS Kernel itself, the underlying implementation will be made available to users of the OS to enable upgradeability of their own smart contracts. This allows rolling out contract-specific security patches, as well as the progressive deployment of features, using whichever update governance mechanism developers see fit.

Thin Deployments

By enabling the usage of on-chain libraries through proxies instead of repeatedly including common bytecode, deployments will be smaller in size and cost less gas. This will also lead to an improved smart contract development experience.

Smart Contract Interaction Tools

One of the key points of zeppelinOS is to provide a shared environment where distributed applications can easily interact and interchange services. This is akin to an operating system where processes can cooperate by sending and receiving messages, leveraging the power of an ecosystem of shared services. The OS will provide various mechanisms for inter-contract communication and networking, such as publish-subscribe messaging, message queues, and shared storage. This will enable decentralized application developers to plug-and-play third-party building blocks, like IFTTT recipes for smart contracts.

Scheduling

Contract code execution is synchronous and linear, allowing the possibility to call other contracts but restrained to a single execution thread. To support more complex operations, applications require off-chain infrastructure.

As a means to support richer execution models, the OS will provide a smart contract async execution scheduler, where different parties can offer to execute async operations and securely call back into the contract to resume its operations.

Async execution helps solve an inherent problem of the Ethereum execution model: a transaction that spans multiple actions by a smart contract is paid by the user who initiates it. For example, a function execution protected by a multisig contract is funded entirely by the last user to approve it. By allowing anyone else to execute the function in exchange for a bounty, we can decouple the user who requests the action from the one who pays for its gas costs.

The OS will define the required standards and provide reference implementations, for both the scheduler clients and the providers.

Marketplace

Much as traditional mobile app marketplaces act as central hubs for mobile users to browse and purchase available services, one of the central features of zeppelinOS is a marketplace for contracts, where services can be purchased, sold, and integrated into applications.

Developers will be able to register new services in the marketplace, which will be discovered and accessed by client smart contracts. We envision multiple payment models, such as pay-per-call, one-time fees, or subscriptions for fixed periods of time, all of which can be managed through common payment interfaces.

This will be not only a central key in fostering collaboration between smart contracts, but also a way of allowing contracts to have off-chain interactions. Marketplace apps can be a mix between on and off chain implementations, providing services such as file storage, mail sending, push notifications, off-chain intensive computation, or machine-learning services.

State Channel Support

Blockchain transactions are limited by block mining times and fees. This caused the development of alternative off-chain transaction exchange protocols that could be consolidated back to the blockchain after multiple operations. State Channels is one of such proposals, designed specifically for the EVM.

The OS will incorporate state channel support through common protocol specs and reference implementations, plus all the on-chain infrastructure necessary for discovery, arbitration and finalization of state channels. Besides providing a cheaper communication mechanism, this also opens the door for integration with off-chain payment networks in the platform.

Blockchain Information Provider

The OS will provide trusted ways to access information on the blockchain currently unavailable from smart contracts, such as current ETH price, gas price, transaction pool size, average mining block times, etc. This will be implemented either as an oracle providing updated information per request, or as calls to Kernel contracts which are continuously updated by a trusted external source.

Off-Chain Tools

As an addition to the on-chain services offered by zeppelinOS, the platform will provide a set of off-chain tools aimed at simplifying the development, debugging, testing, deployment, and monitoring of decentralized applications.

Analytics & Monitoring

Contract transactions and events provide invaluable insight on the usage of a deployed application, analogous to end-user actions and events performed on a web page. The OS will provide an off-chain analytics dashboard to aggregate on-chain generated contracts events and transactions for insight on their usage. It will also help monitoring the health of each contract, by keeping record of the transaction error rate and failure-associated events, triggering alerts through user-defined rules.

Platform as a Service

One of the current major challenges is not in contract development itself, but in the deployment and management stages that come once the code is ready. The OS will provide an easy to use interface for this, including:

• Triggering automated testing and security analysis of contracts.
• Deploying the contracts to the blockchain, and optionally managing upgrades.
• Providing user-friendly web interfaces for reading data and managing the contracts once deployed.
• Providing secure and reliable connections to the Ethereum network, via infrastructure providers such as Infura.

The Platform as a Service approach also includes acting as a one-stop platform for integration with other contracts, providing a user interface for the discovery and management of marketplace-offered services.

Continuous Integration for Contracts

Automated testing through continuous integration providers has become an industry standard, as a means to increase the confidence on the project health by checking its tests in a separate environment at every stage of development. However, this requires a testing environment with conditions as similar as possible as production. As such, zeppelinOS shall provide the required services, including replaying previous transactions using the updated codebase to compare generated outcomes.

Automated Code Analysis

Static analysis is a long-running research field in academia, with occasional ports to industry-level tools. These techniques can yield enormous benefits towards the identification of potential bugs and vulnerabilities. As such, and given the high security requirements of decentralized applications, applying these strategies to smart contracts code is a must.

Having access to the code powering the smart contracts applications, zeppelinOS will offer automated code analysis services with increasingly powerful rules and techniques, preventing inadvertently deploying unsafe code, and alerting owners of existing running contracts of newly found vulnerabilities.

Developer Tools

Developer experience for smart contract developers is really bad. The tools are immature, break often, and debugging is very frustrating. Part of the off-chain tools the zeppelinOS platform will provide are debugging, testing and infrastructure frameworks to make smart contract developers’ lives happier. We’ll also contribute to existing toolchains such as pyethereum, truffle/testrpc and web3.js.

Next steps

We hope this post has helped clarify some of the more technical questions around the different components of zeppelinOS, and how they will enhance smart contract development and management process. This is an ambitious endeavor and we’ll need your help to make it happen, so please join our Slack and share your feedback with us..

If you are looking for ways to contribute to zeppelinOS, the best starting point is to help with the development of the OpenZeppelin framework, as it will be the basis from which the zeppelinOS Kernel Standard Libraries will be built.

During the upcoming days we’ll be releasing more information about zeppelinOS, stay tuned!

Subscribe to the zeppelinOS newsletter to learn more details about the project, and stay up-to-date with the next stages.

Be part of the community

• Continue the discussion on our forum
• Join our Telegram group
• Follow us on Twitter
• Even better, join the team 🚀

Last week, we saw one of the biggest hacks in the history of smart contract applications. ~30M USD were lost due to a simple programmer error, leaving critical functions open for anyone to call. It’s high time we get serious about writing secure contracts, if we want decentralized applications to reach their full potential.

In the early days of computing, writing code into machines was a difficult and inefficient endeavor. There were few tools and resources available for programmers, and specialized magazines were the main distribution media for software. Major operating systems were not yet available, so each computer model required machine-specific knowledge to be programmed. This is what it feels like to work with smart contracts in 2017.

The State of Smart Contract Programming

Ethereum changed the world by creating a distributed global shared virtual machine known as the EVM. Anyone can now use this virtual machine to run programs that handle real money and formalize contractual relationships via code. The promise is huge: we’re creating a new global and natively-digital economy based on software.

Still, the tools developers are using to build towards this fantastic vision are very rudimentary. Once a contract is deployed, there’s no way to upgrade it, even for security reasons, which means applications can’t easily upgrade with new features and fixes; instead of calling standard libraries, application developers are copy/pasting code with each deployed contract, increasing deployment costs and margin for error; and, last but not least, debugging a contract’s failing function calls is hell with current tools.

Overall, the rate of innovation in building decentralized applications is limited by the manual and duplicative efforts projects must make to ensure basic usability and security.

Much like in the early days of computing, where operating systems enabled the development of feature-rich applications, the same is needed for the development of complex smart contract applications. We need an OS for the EVM.

What is zeppelinOS exactly

zeppelinOS is an open-source, distributed platform of tools and services on top of the EVM to develop and manage smart contract applications securely.

What would an EVM operating system look like? We thought about four main components, but other functions may arise in the future, as the industry evolves:

• zeppelinOS Kernel: an upgradeable and community-governed core of functionality provided by an on-chain smart contract library that developers can call for standard and common functions in their applications. The initial version of this is the current OpenZeppelin framework, migrated to library form. Shared code for smart contract applications to use, with curated opt-in security updates based on the proxy library pattern.
• zeppelinOS Scheduler: Every transaction on the Ethereum network is initiated and paid by a user. This places a limitation on the kinds of things a smart contract can do and sometimes creates unfair situations. For example, when executing a transaction via a standard multisig contract, the last owner to confirm it will trigger the actual call and pay for its gas costs. Or, if a crowdsale has some finalization logic when the cap is reached, the last token buyer will pay the gas cost of executing that. The zeppelinOS Scheduler will enable async execution on the EVM where a contract can request asynchronous execution of a function and anyone can pay the gas costs and be rewarded for it.
• zeppelinOS Marketplace: To catalyze exponential growth among decentralized applications, smart contracts must be able to interact with each other in a standard way. Imagine if Augur could talk to 0x to enable prediction market forecasting in any currency, all done using an Aragon company. This kind of interoperability would accelerate progress across the space, helping developers take the ecosystem mainstream, faster. Our proposed solution is to build a marketplace of inter-contract services natively inside the OS.
• zeppelinOS off-chain tools: As an addition to the on-chain services offered by zeppelinOS, the platform will provide a set of off-chain tools aimed at simplifying the development, debugging, testing, deployment, and monitoring of decentralized applications.

At Zeppelin Solutions, all of our efforts are focused on solving the technical challenges of smart contract application development. We’ve worked with dozens of projects on security audits, smart contract upgradability, contributed to improve and test development tools, and enabled interoperability through our OpenZeppelin standards and security patterns. We are developers ourselves. We believe we know how to make the smart contract development process better, easier and more robust.

We invite you to help us make this happen.

Subscribe to the zeppelinOS newsletter to learn more details about the project, and stay up-to-date with the next stages.

Be part of the community

• Continue the discussion on our forum
• Join our Telegram group
• Follow us on Twitter
• Even better, join the team 🚀

The Storj team asked us to review and audit their new Storj Token (STORJ) code. We looked at their contracts and now publish our results.

The audited contracts can be found in their storj-contracts repo. The version used for this report is commit 2bdeb27c0216d2f0889b6e7363d8a84b54cd7f39.

Code quality is very good. Functionality is properly modularized, and most lines of code and nearly all functions have accompanying comments stating their purpose and/or reasoning.

Here’s our assessment and recommendations, in order of importance.

EDIT: Most problems were addressed in the latest version of the code.

Severe

Problems with PaymentForwarder’s pay function

pay function in line 44 of PaymentForwarder.sol has two severe problems.

1) The pay function accepts zero-valued payments. This is not desirable, per se, but in this case it brings a greater problem.

The code assumes that all payments are nonzero in the calculation of the variable customerCount (see lines 53 to 55). If two calls are made to pay with the same customerId and the first one has msg.value == 0, customerCount will be incremented both times because weiAmount will be 0 in line 57.

Add a precondition to ensure msg.value != 0.

EDIT: Addressed in https://github.com/Storj/storj-contracts/commit/40b8dd82ec58ad795c21b1f37e11ebccdb10a6c8

2) Anyone will be able to call the pay function with arbitrary data. We don’t have access to the rest of the crowdsale code and couldn’t determine what the desired behavior is here. For example, who should be allowed to call the pay function is not clear. Consider making the function only callable from a specific address if that’s the intended behavior.

EDIT: This was intended behavior.

Potential problems

Lack of safeguards in PaymentForwader

For such an important component, PaymentForwarder is lacking in safety measures. All math operations are unchecked for overflows. The comments state: “We trust Ethereum amounts cannot overflow uint256”. Although this seems to be true, it’s better to be safe than sorry. An overflow could leave the contract in an inconsistent state, and removing the possibility is worth the cost. This is part of what we call security in depth. Consider making all math operations safe by using SafeMath as with other contracts.

EDIT: SafeMath added in https://github.com/Storj/storj-contracts/commit/40b8dd82ec58ad795c21b1f37e11ebccdb10a6c8

PaymentForwarder can be unhalted

The Haltable contract is designed for the use case of halting a working contract in case of an emergency. This can be used, for example, to fix something manually before resuming normal operation.

The functionality required by PaymentForwarder (as documented), on the other hand, is to completely finalize the processing of payments at the end of the crowdsale. We recommend to remove the unhalt feature so that the contract can’t resume receiving payments after finalization, and to use more appropriate variable and modifier names.

EDIT: This was intended behavior.

Anyone can burn tokens

CentrallyIssuedToken inherits from BurnableToken, which provides a function allowing anyone to burn a certain token amount, destroying them and reducing totalSupply. Storj needs this to burn part of their token holdings, according to their crowdsale plans, but as a side effect anyone can burn their tokens.

Please make sure this is expected, or consider making the burn function only callable from a Storj address. Note that any ERC20 token allows owners to burn tokens by transferring them to the zero address or any random one, but this doesn’t modify the totalSupply.

EDIT: This was intended behavior.

Discrepancy between comment and code

CentrallyIssedToken has a constructor parameter named _owner, which is used as the upgradeMaster. The comment in line 29 states an intent to allocate the initial balance to the owner; however, the balance is allocated to msg.sender. If it’s an error, use the owner variable; otherwise, update the comment.

Shadowing of inherited state variable

The state variable originalSupply is declared in the UpgradeAgent contract, and redeclared in TestMigrationTarget (which inherits from the former). This is a case of variable shadowing that’ll cause problems: functions implemented in UpgradeAgent will use their own state variable of the same name. Remove the declaration in TestMigrationTarget.

Warnings

Use safe math

There are many unchecked math operations in the code. It’s always better to be safe and perform checked operations. Consider using OpenZeppelin’s safe math library, or performing pre-condition checks on any math operation.

EDIT: SafeMath added in https://github.com/Storj/storj-contracts/commit/40b8dd82ec58ad795c21b1f37e11ebccdb10a6c8

Use the latest version of the Solidity compiler

Current code is written for older versions of solc (some contracts specify 0.4.6, others 0.4.8). We recommend changing the solidity version pragma to the latest version (pragma solidity ^0.4.11) to enforce the use of an up to date compiler.

Undocumented interface of UpgradeAgent

Compared to the rest of the code, UpgradeAgent contract is lacking in documentation and clarity. Since this is intended to be used by future developers, we believe it’s specially important that it be very well documented.

Our understanding is that a future upgraded token contract should implement an upgradeFrom function that receives a token owner and an amount of tokens (within the owner’s balance) as parameters to transfer from the older to the new token. This function is called by the older token as seen in line 72 of UpgradeableToken.sol.

Consider renaming the parameters to owner and amount, which are more representative of their meaning. Also, consider declaring upgradeFrom as an external function, as it seems to be meant only callable from the old token.

Program against interfaces when appropriate

The token state variable in Issuer is declared of type StandardToken, which is a concrete implementation of an ERC20 token. Although it makes no difference in the generated code, consider changing the variable’s type to ERC20.

Overloading of the Transfer event

The BurnableToken contract uses both a Burned event and the Transfer event (with a to field set to the zero address) to log the burning of tokens. The latter is overloading the semantics of the Transfer event of the ERC20 standard, which might not be a good idea as other software (such as wallets or exchanges) could be relying on these semantics. This is an ongoing discussion in the ERC20 standardization process, but our stance on it is that a different event should be used.

A comment in the code says the use of the Transfer event is to “keep exchanges happy”. We’re not aware of any exchange that relies on this behavior, but if this were the case, please note that there are balance modifications not logged as Transfers when upgrading tokens. If Transfer needs to be used in this way, be sure to be consistent about it.

EDIT: This was done for EtherScan.io compatibility. Unfortunately, this could not be addressed very well in a standard-compliant manner, as there is no standard behavior for this.

Types are not checked on runtime

Although the check in line 95 of UpgradeableToken.sol is a good idea, and will potentially catch errors when upgrading a token, we’d like to clarify that it’s not enough to ensure that the upgradeAgent address corresponds to a contract inheriting from UpgradeAgent.

Solidity types are only checked/enforced on compile time. Once the contract is deployed, and transactions are executed, there’s no guarantees that types will be correct. A malicious upgradeMaster could potentially call the setUpgradeAgent function with a contract that has an implementation of isUpgradeAgent and no implementation of upgradeFrom.

We have no recommendations here, but wanted to clarify on the matter.

Additional information and notes

• Good job using OpenZeppelin!
• There are no modifiers defined or used in the code written by Storj, but we think they could be helpful for improved code clarity. At this stage of the development process, however, it might be safer not to undergo such a refactoring.
• The comment in line 77 of UpgradeableToken.sol is incomplete.
• The comment in line 10 of BurnableToken.sol is incomplete.
• The comment in line 124 of UpgradeableToken.sol has a typo: says “begun” instead of “begin”.
• The comment in line 60 of PaymentForwarder.sol explains the rationale for the paymentsByBenefactor state variable: being able to “construct contributions solely based on blockchain data”. It should be noted, though, that events are also “blockchain data”, and the emitted PaymentForwarded event would be sufficient to reconstruct all contributions. Consider removing paymentsByBenefactor.
• The contract Issuer.sol seems to be unnecessary, as it can be implemented in an off-chain script with a database.
• The throwing fallback function in line 41 of TestMigrationTarget.sol is not needed in Solidity ≥0.4.0. If a payable fallback function is not declared, payments to the fallback function are rejected.

Conclusions

One severe security issue was found, along with recommendations on how to fix it. Some additional changes were proposed to follow best practices and reduce potential attack surface.

EDIT: Most problems were addressed in the latest version of the code.

Note that as of the date of publishing, the above review reflects the current understanding of known security patterns as they relate to the STORJ Token contract. We have not reviewed the related Storj project. The above should not be construed as investment advice or an offering of tokens. For general information about smart contract security, check out our thoughts here.

Be part of the community

• Continue the discussion on our forum
• Request a security audit
• Even better, join the team 🚀

The Brave team asked us to review and audit their new BAT Token contract code. We looked at their contracts and now publish our results.

The audited contracts can be found in their basic-attention-token-crowdsale repo. The version used for this report is commit 17a5f8440a256a6dc5d8dd894b9615182c2901b2.

Here’s our assessment and recommendations, in order of importance.

Update: Brave team followed most of our recommendations in the latest version of their code.

Severe

Brave can get an unfair refund if tokenCreationMin is not reached

A fixed 300 million BAT tokens are assigned to Brave (specifically to the batFundDeposit address) when the crowdsale contract is deployed. If the contract doesn’t reach the minimum amount of tokens (tokenCreationMin), though, it goes into a state where investors can request a refund and receive their ether back.

In this situation, Brave would also be able to request a refund for the 300 million tokens it holds, taking ether that should be available for investors.

Fix this by checking that funds aren’t sent to batFundDeposit in the refund function.

Update: fixed in commit 09a1038c2ac0148b93876057fc056ae2a872fb88.

Potential problems

Correctness of start and end block numbers

Brave has decided to use block numbers instead of timestamps to determine the start and end of the crowdsale, which is a good security practice. However, preconditions about them are missing in the contract constructor.

For example, consider checking fundingStartBlock comes before fundingEndBlock, and that both are in the future (greater than block.number).

Use of Transfer event to log token creation

The crowdsale contract uses the Transfer event to log the creation of tokens, with a from field set to the zero address. This is overloading the semantics of the Transfer event of the ERC20 standard, which might not be a good idea as other software (such as wallets or exchanges) could be relying on these semantics. This is an ongoing discussion in the ERC20 standardization process, but our stance on it is that a different event should be used.

Update: fixed in commit 09a1038c2ac0148b93876057fc056ae2a872fb88.

Avoid duplicate code

The contracts Token, StandardToken, and SafeMath are very similar to OpenZeppelin library contracts ERC20Token, StandardToken, and SafeMath, respectively. Consider avoiding code repetition, which can bring regression problems and introduce unexpected bugs. Consider using the standard modules from OpenZeppelin.

Several conditional checks, such as block.number < fundingEndBlock, are repeated throughout the code (line 51, line 68, line 79). Consider extracting these to reusable internal functions with declarative names (for example isWithinFundingPeriod) for better code readability.

Use SafeMath in all math operations

Most math operations are safe, but there’s still a few that are unchecked (these two, for instance). It’s always better to be safe and perform checked operations.

Update: fixed in commit 09a1038c2ac0148b93876057fc056ae2a872fb88.

Burn of token assignment to BAT fund is not implemented

The amount of BAT assigned to Brave is fixed at deploy time. This seems to be inconsistent with the process document we received that states: “In event of a non-sell out, contract will ‘burn’ BAT kept in multisig wallet down to a 3/10 ratio of total BAT.”. Consider implementing this in the contract, as the specification states, so that the Brave team doesn’t have to do this manually after the token sale.

Warnings

Magic constants in token amounts

A few constants in the contract which denote BAT amounts (batFund, tokenCreationCap, tokenCreationMin) are written assuming 18 decimals. This is a hidden case of a magic constant. These amounts should be parameterized by the number of decimals (e.g. batFund = 300 * 10**6 * 10**decimals).

Update: fixed in commit 09a1038c2ac0148b93876057fc056ae2a872fb88.

Refactor confusing finalization precondition

The condition in line 68, is expressed in a very confusing way. It should be split into two conditional expressions: totalSupply < tokenCreationMin and block.number <= fundingEndBlock && totalSupply != tokenCreationCap, each of which throws when true.

Update: fixed in commit 09a1038c2ac0148b93876057fc056ae2a872fb88.

isFunding variable name is not accurate

The variable isFunding declared in line 18 doesn’t really reflect whether the contract is funding or not. This fact depends on other conditions, such as being within the funding period. The variable marks the finalization by the contract owners, so a good name would be isFinalized (note that this new name reverses the meaning: isFinalized == !isFunding).

There’s a comment in line 18 that says the variable is “no longer important”, but it is actually a key part of the crowdsale process. Consider removing that comment.

Update: fixed in commit 09a1038c2ac0148b93876057fc056ae2a872fb88.

Avoid using var to define variables

There’s two uses of var, where the type of the variable is inferred from the expression on the right hand of the definition. We recommend avoiding this feature because in some cases it might infer a smaller integer type than the developer might think. It is best to be explicit regarding types.

Update: fixed in commit 09a1038c2ac0148b93876057fc056ae2a872fb88.

Solidity version

All of the contracts require version 0.4.10 of Solidity. It should also be noted that 0.4.11 was released a few days ago. Consider changing the solidity version pragma to the latest version (pragma solidity ^0.4.11;) to enforce latest compiler version to be used.

As an additional note, since the contracts are compiled with a recent version of Solidity, it’s possible to use the new transfer method instead of send (here, and here).

Additional information and notes

• The comment in line 64 is outdated since the finalize function no longer issues BAT tokens to the User Growth Fund. These tokens seem to be issued in the constructor.
• The state variable batFund in line 21 is only set at deploy time, and never changed, so it could be declared constant.
• Consider being consistent in the use of whitespace for a more polished code style. For example see how whitespace is used differently in lines 78 and 79.
• The operational process document appears to be outdated. The Finalization section states that the finalize function can be called from any account, but this is neither what the code does, nor what the review document says.
• Consider removing commented code in lines 6–10 from SafeMath.sol.
• Very interesting addition of contract version as part of the token contract in line 11.
• Remove excessive condition from SafeMath (see this pull request in OpenZeppelin).
• Use of send is always risky and should be analyzed in detail. These contracts use it safely, by checking the return value, and calling it only at the end of functions.
• Good job using block numbers instead of timestamps.
• Consider choosing a fail-first approach for precondition in line 55: revert the condition and throw in the then branch, instead of the else branch.
• Consider reusing the tmpSupply variable instead of recalculating the sum on line 56.

Conclusions

One severe security issue was found and explained, along with recommendations on how to fix it. Some additional changes were proposed to follow best practices and reduce potential attack surface.

Update: Brave team followed most of our recommendations in the latest version of their code.

Thanks to Francisco Giordano for helping write this report.

Note that as of the date of publishing, the above review reflects the current understanding of known security patterns as they relate to the BAT Token contract. We have not reviewed the related Brave project. The above should not be construed as investment advice or an offering of tokens. For general information about smart contract security, check out our thoughts here.

Be part of the community

• Continue the discussion on our forum
• Request a security audit
• Even better, join the team 🚀

The Moeda team asked us to review and audit their new Moeda Token code. We looked at their contracts and now publish our results.

The audited contracts can be found in their moeda repo. The version used for this report is commit b2bf23119d563e251b6f16b29b642bac43e76a64. The main contracts are MoedaToken.sol and Crowdsale.sol.

Overall the code is good and has only minor issues. Here’s our assessment and recommendations, in order of importance.

Update: The Moeda team implemented most of our recommendations in the latest version of their code.

Severe

We haven’t found any severe security problems with the code.

Potential problems

Unnecessary complexity calculating token amount

The formula used to calculate the token amount in line 116 is unnecessarily complicated. It could be replaced by a multiplication by the amount of tokens bought with one wei for each given tier. Consider making this change by replacing the token creation rates by 1 ether divided by the current values. This has a number of benefits:

1. Numbers are exact and there is no precision lost (current version has loss of precision due to chained integer operations).
2. There is less risk of overflow.
3. It’s simpler, which is always preferable. When code is irreducibly complex, consider using temporary variables to improve readability.

Update: Fixed in https://github.com/erkmos/moeda/commit/a894b2cccef0236e90326b84a0b3dde485e78cd1

Conditions for finalization

The crowdsale can be finalized at any moment, in particular before endBlock is reached. Please double check that this is the desired behavior.

Update: Now requiring that either cap or end block has been reached. Fixed in https://github.com/erkmos/moeda/commit/5eb52c0648d1af0db11f5eb883379d6c8054e2c0 and refactored in https://github.com/erkmos/moeda/commit/9edf6fe6e23aec7f6fcba6d0921436e435336048

Use of Transfer event to log token creation

The crowdsale contract uses the Transfer event to log the creation of tokens, with a from field set to the zero address. This is overloading the semantics of the Transfer event of the ERC20 standard, which might not be a good idea as other software (such as wallets or exchanges) could be relying on these semantics. This is an ongoing discussion in the ERC20 standardization process, but our stance on it is that a different event should be used.

Update: Created a new event, fixed in https://github.com/erkmos/moeda/commit/68ff6544976c2bfa655cae28e69ab09d813dbc46

Warnings

Use latest version of Solidity

The contracts are written for an old version of the Solidity compiler (0.4.8). We recommend changing the solidity version pragma to the latest version (pragma solidity ^0.4.11;) to enforce the use of an up to date compiler. (Please note that there has been a recent update to the Truffle framework to make it compatible with 0.4.11.)

Update: fixed in https://github.com/erkmos/moeda/commit/befe14a5769a7f5c3dcd964c1d042408ba4356e4

Unexpected throw

When the ether received adds up to exactly TIER3_CAP, getLimitAndRate throws when the comment says it shouldn’t. Consider changing all the comparisons in this function to inclusive ones (e.g. totalReceived <= TIER3_CAP), which is the standard behavior in these cases.

Redundant return value

processBuy function in line 126 is declared to return a boolean but never returns false. Instead, it always throws in case of error. Consider sticking to one error signaling convention. We recommend throwing to fail as early and loudly as possible, ensuring the propagation of the error. Same thing with unlock function in line 40 of MoedaToken.sol.

Enforce all preconditions

processBuy function in line 126 has a precondition written in the comments which is not enforced in the code: it’s only usable while the crowdsale is active. In the current state of the contract, the function is internal and only called from the fallback function, which is properly guarded with the onlyDuringSale modifier. However, it’s best to enforce preconditions independently on a function-by-function basis.

Consider using the onlyDuringSale modifier at the beginning of processBuy. Furthermore, since processBuy is only used once, and is the only thing the fallback function does, consider removing it altogether, moving the code inside the fallback function.

Update: The function has merged with the fallback function, was fixed in https://github.com/erkmos/moeda/commit/d4c8f85809ecd33852924aa71b0a233f4dbc2318

Naming suggestions

• The boolean locked variable in line 16 of MoedaToken.sol is not descriptive of its actual use. Consider a name like saleActive.
  Update: Was renamed to saleActive in https://github.com/erkmos/moeda/commit/8e9b6861d7b735c1ef49c7594dfc5e0cc777fbc6
• PRESALE_TOKEN_AMOUNT variable is not really referring to presale amount in line 22. Consider using a name referring to “developer allocation” such as DEVELOPER_TOKEN_ALLOCATION or something similar.
  Update: This has been renamed to PRESALE_TOKEN_ALLOCATION (it is actually referring to an allocation for a previous sale), fixed in https://github.com/erkmos/moeda/commit/7ed3d1d78d8f8da7705e0b93351659f058860a4c
• The word “rate” is ambiguous (lines 28–30). consider calling it “price”. Bear in mind that if the changes suggested in “Unnecessary complexity calculating token amount” are implemented, the name “price” would no longer be correct.
• The Buy event in line 37 of Crowdsale.sol could have a better name. In general, events have nouns or past-tense verbs as names. Consider changing it to Purchase or TokenBought.
  Update: Event renamed to Purchase in https://github.com/erkmos/moeda/commit/4858c60cef148bbbdaed87dbc3965f58a0787ab5

Use SafeMath in all math operations

Most math operations are safe, except a sum in the token contract at line 51. It’s always better to be safe and perform checked operations.
Update: The place it was missing has been fixed in https://github.com/erkmos/moeda/commit/5e1ccfb7b4f934c0588c84196e435e21f46c7de5

Additional Information and Notes

• There are MLO tokens assigned to the wallet address in line 152 of Crowdsale.sol. Please make sure the wallet contract is capable of holding and managing tokens.
  Update: included the wallet contract in https://github.com/erkmos/moeda/commit/86cf3a632b73ba8993c1477b103f760a13a785fc
• Contracts use “ether” units to specify token amounts (see Crowdsale.sol, line 22, MoedaToken.sol, line 13). This is okay but slightly confusing and you should be careful.
  Update: Changed to named constants in https://github.com/erkmos/moeda/commit/ef08e24c44a0f6144d6e41d77f5daae4f6272928
• Good job validating preconditions for the constructor parameters.
• presaleWallet in line 19 of Crowdsale.sol is never used and should be removed.
  Update: Was removed in https://github.com/erkmos/moeda/commit/171959dda8ed7a3ff10d80bbf65044298d06a46d
• getTokenAmount is a recursive function. As far as we can tell it terminates for all valid inputs (the recursion depth is never greater than 3).
• The fallback function is redundant since it only calls the processBuy function.
  Update: Was fixed in https://github.com/erkmos/moeda/commit/d4c8f85809ecd33852924aa71b0a233f4dbc2318
• The totalTokensSold variable is only written to, and never read. Moreover, it’s redundant because the information is already available in the totalSupply state variable of the token contract. Consider removing it; redundancy can be a source of problems.
• A call of send isn’t the last expression in the function (line 129 of Crowdsale.sol). We haven’t found any problem with this, but it has been a source of issues in the past. Consider moving the send call to the end of the function.
  Update: fixed in https://github.com/erkmos/moeda/commit/5a5ec164e6ccb601f4da19d897522e8ca3bcfc01 (along with some more redundant booleans being removed)
• All tests run correctly and pass. ✔

Conclusions

No severe security issues were found. Some additional changes were proposed to follow best practices and reduce potential attack surface.

Update: The Moeda team implemented most of our recommendations in the latest version of their code.

Overall the code is good and has only minor issues.

Thanks to Francisco Giordano for helping write this report.

Note that as of the date of publishing, the above review reflects the current understanding of known security patterns as they relate to the Moeda Token contract. We have not reviewed the related Moeda project. The above should not be construed as investment advice or an offering of tokens. For general information about smart contract security, check out our thoughts here.

Be part of the community

• Continue the discussion on our forum
• Request a security audit
• Even better, join the team 🚀

As you may know from reading our blog, we do lots of security audits for blockchain-based projects. All projects in the space need someone external to take a fresh, unbiased, and skeptic look at their code.

OpenZeppelin is an open repository of reusable smart contract modules. Since we started the project, we committed to the highest standard of security and peer-review. This means performing external audits on our code too. That’s why we asked the New Alchemy team to perform a formal security audit of OpenZeppelin’s codebase, following the 1.0.0 release of the framework.

Projects using OpenZeppelin just need to upgrade to the latest release (v1.0.5) to include the bugfixes coming from this audit. We’re also working on a mechanism for on-chain upgradeability to enable already-deployed projects to receive security fixes.

The full audit can be found on GitHub, but this is a list of the most noteworthy findings and how we addressed them:

• Upgrade to latest Solidity version in all contracts. Fixed here.
• Prefer throw vs return false. This is in line with our fail early and loudly guideline. Fixed here.
• Create a cancellable pull payment helper class. Issue opened here.
• Create a version of PullPayment that checks the contract has enough balance to send. Issue opened here.
• Several problems with Shareable, some fixed here and and an issue opened to improve code quality.
• Recursive Call attack to resetSpentToday in MultisigWallet. Issue opened here.
• ERC20 approve problem, as described in EDCON. Issue opened here.
• Create a simpler version of MultisigWallet. Issue opened here.

Most of the recommendations were implemented in this pull request. Other less urgent things were transformed into GitHub issues.

As always, we’re committed to improving the security standards of the blockchain industry. This is a step forward in consolidating OpenZeppelin as a collection of reusable and secure modules anyone can use and extend.

If you’re interested in discussing smart contract security, follow us on Medium, or apply to work with us! We’re also available for smart contract security development and auditing work.

The Wings team asked us to review and audit their new Token contract code. We looked at their code and now publish our results.

The audited contract is at their contracts GitHub repo. The version used for this report is commit 1b308105a31c5b005c21fbbda3b1ff5b3fac9bae. The main contract file is Token.sol.

Code quality is good. We’re very happy to audit a project using OpenZeppelin.

Here’s our assessment and recommendations, in order of importance:

Update: The Wings team implement most recommendations in their master branch.

Severe

We haven’t found any severe security problems with the code.

Potential problems

Be careful with types

Avoid declaring variables using var if possible. The type-deduction system can bring some surprises if you don’t think about types very carefully. For example, for ints, it will choose the smallest type that is required to hold assigned constants. This can lead to endless loops and gas depletion. Better use the explicit type uint for no surprises and higher limits. Consider replacing all occurrences of var with a specific type.

Fixed: https://github.com/WingsDao/contracts/blob/master/contracts/Token.sol#L222

Timestamp usage

There’s a problem with using timestamps and now (alias for block.timestamp) for contract logic, based on the fact that miners can perform some manipulation. In general, it’s better not to rely on timestamps for contract logic. The solutions is to use block.number instead, and approximate dates with expected block heights and time periods with expected block amounts.

The Token.sol contract uses timestamps in line 212. The risk of miner manipulation, though, is really low. The potential damage is also limited: miners could only slightly manipulate when each preallocation can be done. We recommend the team to consider the potential risk of this manipulation and switch to block.number if necessary.

For more info on this topic, see this stack exchange question.

Warnings

Usage of magic constants

There are several magic constants in the contract code. Some examples are:

• https://github.com/WingsDao/contracts/blob/1b308105a31c5b005c21fbbda3b1ff5b3fac9bae/contracts/Token.sol#L94
• https://github.com/WingsDao/contracts/blob/1b308105a31c5b005c21fbbda3b1ff5b3fac9bae/contracts/Token.sol#L150-L151

Use of magic constants reduces code readability and makes it harder to understand code intention. We recommend extracting magic constants into contract constants.

Fix: https://github.com/WingsDao/contracts/blob/master/contracts/Token.sol#L53

Bug Bounty

Formal security audits are not enough to be safe. We recommend implementing an automated contract-based bug bounty and setting a period of time where security researchers from around the globe can try to break the contract’s invariants. For more info on how to implement automated bug bounties with OpenZeppelin, see this guide.

Avoid duplicated code

Duplicate code makes it harder to understand the code’s intention and thus, auditing the code correctly. It also increases the risk of introducing hidden bugs when modifying one of the copies of some code and not the others.

The logic in transfer, transferFrom, and approve is very similar to the provided methods in StandardToken and could be refactored to avoid repetition. There is no need to rewrite the parent’s contract logic: consider using the super keyword to access StandardToken implementation of methods, like so:

function transfer(address _to, uint _value) whenAllocation(false) returns (bool success) {
  return super.transfer(_to, _value);
}

Fixed in https://github.com/WingsDao/contracts/blob/master/contracts/Token.sol#L131

Naming suggestions

• All references to premine (Preminer, PreminerAdded, PremineAllocationAdded, PremineRelease, etc.) are confusing. There is no mining of these tokens. Consider using another name like “initial assignment”.
• checkUserAllocation and checkPreminerAllocation are not very good names, as they don’t clearly indicate what they are supposed to do. Consider renaming it for example to whenHasntAllocated(user).
• monthlyPayment uint field of Preminer struct is confusing. It’s name implies it’s a monthly payment but there’s nothing enforcing the payment is only done monthly. Consider renaming the field or adding time checks.

Fixed in
https://github.com/WingsDao/contracts/blob/master/contracts/Token.sol#L86

Use latest version of Solidity

Current code is written for old versions of solc (0.4.2). With the storage overwriting vulnerability found on versions of solc prior to 0.4.4, there’s a risk this code can be compiled with vulnerable versions. We recommend changing the solidity version pragma for the latest version (pragma solidity ^0.4.10;) to enforce latest compiler version to be used.

Fixed in https://github.com/WingsDao/contracts/blob/master/contracts/Token.sol#L1

Additional Information and Notes

• Comment on line 8 has a typo: should say “Campaign” instead of “Campagin”.
• Comment on line 27 has a typo: should say “structure” instead of “scturcture”.
• Same in line 39: “perminers”.
• Same in line 202: “monthes”.
• Same in line 140: “functionality”.
• No uses of send and call.value.
• Good work using OpenZeppelin! :)
• Good work using safe math.
• Why is totalSupply assigned a fixed magic number?

Conclusions

No severe security issues were found. Some changes were recommended to follow best practices and reduce potential attack surface.

Code quality is good. We’re very happy to audit a project using OpenZeppelin.

Update: The Wings team implement most recommendations in their master branch.

Note that as of the date of publishing, the above review reflects the current understanding of known security patterns as they relate to the Wings Token contract. We have not reviewed the related Wings project. The above should not be construed as investment advice or an offering of Wings tokens. For general information about smart contract security, check out our thoughts here.

Be part of the community

• Continue the discussion on our forum
• Request a security audit
• Even better, join the team 🚀