ETHERLive delivers real-time price and volume data across 16+ exchanges to users in a clear and easy-to-understand package. Users can get up-to-the-second updates for each exchange/currency pair, as well as aggregated market averages for each exchange, currency, and the market as a whole. It also provides a global converted average of all the currency pairs monitored by ETHNews, converted to USD.


24hr ---

The Basics

Learn the basics of Ethereum and various cryptocurrency technologies

Learn More

What is Ethereum?

Understand the underlying principles of the Ethereum Platform

Learn More

The Blockchain

Discover the revolutionizing technology known as the blockchain

Learn More

Press Release

Submit a press release for consideration on ETHNews

Submit Press

Story / Dapp

Submit a story or DAPP to be considered for publication on ETHNews.

Submit Story


Submit "Ethereum Explainer" content for consideration to be featured on ETHNews

Submit Topic
ETHNews Logo
Ether Price Analysis
Contact Us

Smart Contract Architecture And Testing Best Practices




Writing smart contracts isn’t easy. Writing highly secure smart contracts is even harder. Luckily, industry players are compiling standards and best practices for contract design and testing.

Writing secure code for smart contracts starts with the mindset that a developer needs to do more than just write a piece of self-executing code. They need to program with an added awareness of all the things that could potentially go wrong with the code, later on down the road. Simply knowing how to write a smart contract isn’t enough. A developer should be aware of best practices to follow for ensuring adequate security of their code.

Secure code is important because smart contracts run very differently from most programs. Smart contracts don’t traditionally offer simple upgrade paths, especially when it comes to critical components such as code that controls the value in a token contract. Once a smart contract is up and running, changing it becomes complicated and nearly unfeasible.

Unsecure or buggy smart contracts can lead to distrust in the blockchain ecosystem. Thankfully, several interested parties have helped to compile smart contract writing guidelines. Smart contract code isn’t standardized, but these resources are convenient and beneficial for developers: Consensys’ smart contracts best practices, Solidity’s Security Considerations, Zeppelin’s open framework, and Zeppelin’s recently released v1.0.1 open framework consisting of a library for writing secure smart contracts on Ethereum.

Even after a public code audit by Zeppelin,’s HackerGold Token (HKG) was found to have a bug serious enough to warrant a reissue of the token. The code audit recommended changes that would have prevented the bug in the HKG token contract. Clearly there is a difference between due diligence and actually correcting flaws in the code.

This shows how integral quality code architecture is in the Ethereum ecosystem. In a blog post on Medium by ICONOMI’s Daniel Zakrisson, he outlines some best practices for smart contract design and testing. He’s hoping to draw more attention to the issue of buggy code and hopefully magnify discussions surrounding industry best practices.

One of the more significant areas Zakrisson covered is verification and validation testing. Verification makes sure that code meets the design specifications and requirements it’s created to do. This can be achieved in different ways, and the testing can be mostly automated. Further code reviews and security audits are crucial in the later stages of verification. After verification testing comes validation testing. Validation is more about putting a product through its paces and making sure it will function how it’s supposed to once it’s deployed. Both verification and validation testing occur during the alpha and beta phases of a project.

Zakrisson also compiled a quick check-list for smart contract developers, regarding architecture and minimum testing standards. If programmers are thinking about writing a smart contract or are actively working on one, this guideline would be of use:


  • Use and reuse audited open source code as much as possible (such as ERC: 20)
  • Separate token issuance and token control from all other code into separate contracts
  • Implement a safety stop (kill switch) function at the top of the code in case something happens
  • Implement a contract transfer function whenever possible

Minimum testing:

  • Have a testing plan for both verification and validation testing
  • Do code reviews
  • Do verification testing with automated unit, functional and integration tests
  • Do external security audits
  • Do validation testing by extensively testing on the testnet and then
  • After testnet testing, do more testing with limited risk in proof-of-concept or alpha stage on the main net

This is merely a guideline to add to the growing list of industry standard precautions. The best advice any developer can follow is to do their homework and make sure they’ve exhausted every resource available to them. When the whole ecosystem depends on the reliability of smart contracts, a contract’s code security is paramount.

Jim Manning

Jim Manning lives in Los Angeles and has been writing for websites for over five years, with a particular interest in tech and science. His interest in blockchain technology and cryptocurrency stems from his belief that it is the way of the future. Jim is a guest writer for ETHNews. His views and opinions do not necessarily constitute the views and opinions of ETHNews.

ETHNews is committed to its Editorial Policy

Like what you read? Follow us on Twitter @ETHNews_ to receive the latest smart contracts, secure code or other Ethereum technology news.