2 min read - Posted 06 Jun 19

SecurEth Guidelines Introduction

About the Guidelines

These guidelines are a community resource. They are meant to help guide and inform you through your development process and ensure the highest quality results in your smart contract system and your end product. The original version of these guidelines lives on the Gitbook at SecurEth Guidelines. The version there will always be the most up to date, but I will work to keep both versions the same.

The Guidelines are constantly evolving with expert feedback. All suggestions made here are managed by expert members of our community, who have experience with the best practices and common pitfalls of secure smart contract development. Their wisdom is meant to help you on your journey.

Reading the Guidelines

The Guidelines are meant to aid you in formulating your own software engineering process by giving a complete picture of all the different concerns and expectations in your software projects. Each section of the process has several articles about different topics you should understand during that step of the process. It covers the entire development cycle from planning to production support.

The Guidelines often do not tell you exactly how something should be done, but give you an understanding of what each concept is, why you should do it, who are the major parties involved, and some suggestions on how you can incorporate into your project. There are often multiple suggestions on how to do this, typically because the scale of your project and development team will dictate exactly how much structure you will need to be successful.

Giving Feedback

We encourage feedback. This is just getting started and we want to be sure we are meeting peoples needs. At a minimum, please hit one of the happy/sad faces.

For a more detailed response, please report an issue on our GitHub.


For the moment, if you wish to contribute, please submit an issue as above. We will add a more formal contribution section with a style guide, etc in the near future.


As Kauri does not yet have an index pane, like GitBook I will put the index here and link to it on all pages.

  1. Getting Started
  2. Examples ### Project Planning
  3. System Description

Got a comment? Check out our Gitter Channel!

Copyright and related rights waived via CC0

Created with Sketch.Content is"CC-BY-SA 4.0" licensed
Article On-chain
Article Author

Rex Hygate

SecurEth Guideline Curator




Related Articles
System Description Document

System Description The System Description Document \\(SDD\\) is a top level informal document that describes what the system will do. It should describe the “System” or “Product” from a users’ perspective. This is the first document that any auditor or contractor would read. From it they should understand what the system does. Why do a System Description Document? This is the first document any outside auditor will read. It gives them context and perspective. Who reads the System Description Doc

Rex Hygate

13 Mar 19

Ethereum 101 - Part 7 - Decentralized Apps

Developing on the Ethereum Platform It is relatively easy to establish an Ethereum node, send and receive transactions, trade cryptocurrencies, and bring test environments online, though understanding the moving parts and complexities of such a fledgling technology is a formidable task. It takes time. This section will introduce consumers and developers to the decentralized app ecosystem. Basic Decentralized Infrastructure Stack (non-exhaustive) How an End-User Interacts with Your Decentralized

Wil Barnes

13 Feb 19