Zeitgeist Completes All Code Audits
We recently completed two rounds of code audits on our software, and here can present a detailed summary on the most recent report by the Chaintroopers team.
There has been a lot of work going on behind the scenes here at Zeitgeist as we prepare for our application to go live. In order to have an efficient and high quality prediction markets experience, we needed to ensure there were no major bugs or issues with our software, and thus employed the use of some leading code auditors to assist.
While we engaged with another group of Substrate blockchain developers who have extensive experience with Polkadot projects, we also utilized the services of Chaintroopers, who pride themselves as one of the foremost blockchain security experts in the ecosystem. Chaintroopers were kind enough to make their elaborate report public, and so in light of that, and for the sake of transparency, we’d like to share with you some of the key findings that they made during their audit (noting that this specific report is one of two code audits completed on the Zeitgeist software).
Chaintroopers divided the issues they discovered into four categories:
- High Risk
- Medium Risk
- Low Risk
- Informational
The company uncovered a total of fourteen issues with the Zeitgeist code that were worth taking action on, of which four of them fell in the High Risk category, three would be categorized as Medium Risk, four were deemed “Low Risk”, and the final three issues were deemed as “Informational”.
High Risk Issues
The high risk issues were primarily Business Logic and Data Validation related, in which the Business Logic issues would have allowed malicious actors to exploit our protocol leading to Denial of Service attacks. The High Risk Data Validation issues were in connection with permissionless markets, which would have allowed malicious actors to abuse “market authorization” roles and forcefully reject markets of their choice, while another Data Validation issue found that the publicly available dispatch call for creating categorical markets was not marked as transactional (this would have caused user’s funds to remain reserved in the event of an error).
Medium Risk Issues
The Medium Risk vulnerabilities were also related to Data Validation and Business Logic, this time with one of them being Data Validation and two being Business Logic related. There was a subsidy pool that did not have a minimum amount required, which would have allowed attackers to abuse available pool funds. In terms of medium-risk Business Logic issues, an issue was found whereby the “reject market” function was ignoring the market state (thus potentially causing successful markets to be unnecessarily removed from the application). And the third Medium Risk issue was directly related to this “reject market” issue, whereby the related outcome market shares would not be handled by the reject functionality, meaning that in the event of a rejected market with associated outcome assets, the reserved funds would not be released.
Low Risk Issues
Three of the low risk issues were related to admin functions, while one was related to outcome market shares in categorical markets. The first admin function allowed a pallet to emit events when it wants to notify external entities about changes or conditions in the runtime to external entities, but it was recommended to rather emit events related to the specific administrative functionality. The second low risk issue saw market types provided at "admin_set_pool_as_stale" and at "set_pool_as_stale" functionalities, but this information could be stored in the pool entity in order to avoid taking later security decisions on user-provided parameters.
The third Low Risk issue identified no minimum amount being required in the publicly available dispatch functionality to buy a complete set of outcome shares of a market, allowing users to issue requests for zero amounts. The fourth Low Risk issue found that certain admin functions do not utilize the "deposit_event", with some corresponding events also missing.
Informational Issues
Informational issues are primarily related to Zeitgeist’s documentation, and can make it harder for developers to find and fix vulnerabilities. Chaintroopers found the following docs/informational issues that needed correcting:
The first informational issue identified was that a Substrate dispatchable function associated with items from the “impl” code blocks was not included in the documentation of the examined pallet. The second was that no upper limits were defined for “range.end” value of Market Periods, and the third informational issue found that the "admin_move_market_to_closed" does not handle cases where the "current_block" or the " T::MarketCommons::now()" is smaller than the "range.start" value.
Conclusion
All of the above fourteen issues were duly reported in comprehensive detail to the engineering team here at Zeitgeist, and we got to work immediately addressing them. Within two weeks of the report, we called on Chaintroopers to test each issue and ensure they had been adequately handled. We’re delighted to report that Chaintroopers thoroughly examined our corrections, and were pleased with how we carried them out.
The Chaintroopers team thus closed out the Audit a few weeks later, and compiled this extensive report which we’re happy to make available for viewing here.
We’re grateful for the work of Chaintroopers in the examination of our software, and appreciate their professional and communicative attitude throughout. We have consistently stated that our ambition is to build the best Prediction Markets software available, and such code audits are imperative in achieving this. We’re confident that we have a far better protocol thanks to the work of Chaintroopers and others involved in these audits, and we can’t wait to release our enhanced software to the world.