the project

• Blockchain is growing up. Gone are the early days of loosely connected individuals and the absence of established actors, companies and brands. Today, we are on the path to a wholesome ecosystem of services, providers, and solutions that are native to the scene.

• One of these players is Gnosis. We met the prediction market provider at EthCC in Paris last year and were thrilled to learn about their plans to grow the Blockchain ecosystem beyond their specific field of business. Recently, we helped them secure their Solidity code for an ambitious project, for which flawless smart contracts are definitely crucial. Together we documented the successful and pleasant collaboration.

Hi Nadja, hi Chris. Thanks for doing this case study with us. Tell us something about Gnosis.

• Nadja: Gnosis builds new market mechanisms to enable more informed decision-making and distribution of resources at individual, societal, and global scales. Gnosis was founded as part of ConsenSys, the globally leading Ethereum venture production studio, in 2015 by Martin Köppelmann and Stefan George.

  We became a fully - fledged company early 2017, and were able to raise sufficient funding for the next years to come. Our Berlin team members recently moved into our brand new co - working space Full Node in the heart of Berlin Kreuzberg.

• 

• Chris: While our prediction market platform allows anyone to build customized forecasting applications, the DutchX contributes to a fair price finding of tokens.

  The DutchX is a decentralized exchange for ERC20 tokens, based on the Dutch auction principle. The mechanism design of the DutchX implies that sellers submit their tokens ahead of an auction. Then, the auction starts with a high price which falls until the market for the specific token-pairing clears. Bidders submit their bids during the auction, but pay the same final price. Hence, the dominant strategy for bidders to reveal their true willingness to pay will result in fair market prices.

  We are super excited to launch the exchange fairly soon! Our next blog post in the DutchX series will shed some more light on our vision and how we see the DutchX as an open platform for the fair price finding of tokens.

• 

Did you use any tools/tactics/practices to secure the code before starting the audit?

• Alex: We actually did quite a bit: Firstly, we spent a lot of time to get the game mechanics of the smart contract right. It sounds all easy, but we designed the exchange in several iterations to make sure it is secure. Secondly, we tried to apply strict security standards to prevent bugs. Also, we formally verified that no tokens could ever get stuck in the exchange. A particularly interesting part are all the proxy contract constructions. They were analyzed in byte code to ensure their safety and gas efficiency. Of course, we also took a look at the catalogue of known weaknesses and tried to spot them in our contracts. But most importantly, we wrote a ton of tests. From very general system tests, state flow tests to very specific unit tests. We also did a prior internal review of the code before handing it over to Solidified.

• 

How did you find out about Solidified and what made you choose them?

• Chris: We were actively searching for an auditor. Highly competent auditors are not that common in the blockchain space and often booked out in advance, or even too busy to respond.

  Back in early March, we went to the Ethereum Community Conference in Paris and by sheer luck, Stefan, our CTO, stumbled across some auditors that are part of the Solidified community. They even listened to my DutchX presentation and asked some great, yet tough questions at the end. We only realized later that those came from Solidified auditors! It’s really fantastic that they are not only Solidity and smart contract experts, but also very knowledgeable in game theoretical design, which is a big part of the DutchX.

• 

Hi Adam, as one of the experts conducting the audit: What is Solidified?

• Adam: Solidified is a full-audit service for Ethereum based smart contracts. We started in early 2017 and managed to establish ourselves as the leading platform for high-quality code audits. This is mainly due to our excellent community of 200+ Solidity experts and our platform that makes the whole process of finding and conducting a smart contract audit easy for everyone involved.

• 

Hi Adam, as one of the experts conducting the audit: What is Solidified?

• Adam: It’s a multi-step process. First, several of our experts perform an isolated review of the contract. After each auditor finishes their individual report, they enter into a group debrief. They compare their findings and come to a group consensus. The final combined report is prepared and delivered to the client. This report discloses issues in different categories and provides recommendations on how to fix each issue.

• The client is asked to fix the issues found and submits the updated version of the contract which is then verified by the same auditors.

  At this stage, the code is already fairly secure. Still — and we can’t stress this enough — a bug bounty should be issued. We then publish the contract on our bounty platform where the entire verified expert community searches for bugs.

  Finally, the contract goes live on public bug bounty and is recommended to stay there for at least 2 weeks.

• The Gnosis contracts — just like any other gig?

  Adam: Gnosis DutchX audit was a standout job in multiple ways. In terms of code and documentation quality, it was one of the most well polished smart contract applications I’ve worked on. The dApp dev space is still very young and is finding its legs both in terms of coding practices and high level direction. In this case it was very obvious that the team behind the project is mature, has extensive experience with smart contract development, and is working on solving real problems. All of this made the work feel especially meaningful and motivated me to put in extra effort to measure up to the high standards set by the client.

• How do you collaborate with the other auditors?

  Usually, we get together on Slack just before the audit delivery to compare our findings, cross verify them and compile them into one report. In case of more complex projects such as the Gnosis DutchX, we also do a pre-debrief after digesting the project specification before delving into the code itself, to make sure everybody is on the same page and also to discuss high level design issues if there are any. In the process of auditing, we usually don’t discuss the work, this way everybody’s individual effort is apparent and unbiased in the final reports which serves as a motivation to really put in the work. We don’t do any formal rating of individual reports, but the informal friendly competition keeps everybody honest.

Do you directly collaborate with the author?

• Adam: Anytime we encounter a deep issue which might warrant extensive rewrite of the codebase, we pause the audit and let the client know, to give them an opportunity to correct the issue before continuing. In cases where the specification of the application isn’t complete or we have trouble parsing some parts of it, we work with the client on filling in the gaps to prevent any misunderstanding. We also keep in touch after the audit delivery to be able to clarify our findings if needed and verify fixes to the issues we’ve found. In most cases we also publish a revised version of the audit on our GitHub that reflects how the team reacted to our findings and whether the original issues were corrected.

• 

Do you even need a bug bounty after the audit?

• Adam: In my opinion, a bug bounty is a must for two reasons. One is that it builds trust for the project in the community and the other is that no auditor can guarantee that the code is issue free. Every auditor has a different experience and approach and for some issues it takes the person with the right combination of those to catch them, so the dev should try to get as many eyes on the code as possible.

• I might be undermining my work by saying this, but from my perspective, a well financed and publicized bug bounty is always superior to individual commissioned audits in terms of catching all of the issues. The main downside of bug bounties is that their total cost is unbounded and hard to predict, so it’s good to catch as much of the issues as possible in audits with a pre-agreed price and use the bug bounties as the final test.

Chris, how was your experience with Solidified?

• Chris: It was a great experience! First of all, and of course most importantly: we are super happy about the audit result and Solidified’s final report. We would be extremely surprised if the public bug bounty that is currently running will reveal any bugs at all — and indeed, none have been reported so far.

  Secondly, everyone at Solidified was super responsive at all times, which is quite unusual in my experience. In fact, the entire process was very smooth. We kicked off with a video call explaining the audit process, leading to a swift agreement of terms. The three auditors that were assigned to and separately audited the DutchX also audited the mechanism design on top of the smart contracts. The audit itself was done in a very short time period, which we started after a first day of audit with a brief call on open questions.

  After our developers reviewed Solidified’s input, the changes were audited once again, resulting in a final report.

• 

  In the last step, we also used Solidified’s bug bounty program, which was easy to set up and is a great initiative within their audit community. We were told that the code was reviewed around 50 times without any bugs found — an amazing statistic (and approval of the audit outcome).

Would you recommend us?

• Chris: Without a doubt. There is no better recommendation than to confidently say that we are looking to hire them again for our next audit. As we say in German: after one audit is before the next audit.

• 

  case study

• 

  partnership