Q System Contracts Security Audit

With the recent source code assessment of Q’s system contracts (view on gitlab), the development of Q has reached another important milestone. It was a great success and awesome experience for the development team. Out of 26 findings the dev team has fixed 25, leaving only 1 finding with low severity. The full report has been published by ChainSecurity.

Findings and fixes

There is something you should know about software developers:

• All devs make mistakes.
• Good devs make few mistakes.
• Very good devs make few mistakes, but are aware that they do make mistakes.

The audit covered a total of 42 smart contracts, which covers all relevant Q system contracts, ranging from stakeholder tokenomics to governance features to the decentralized borrowing and lending contracts and related sub-contracts. ChainSecurity discovered a total of 26 issues, which are classified according to their taxonomy of severity.

Critical

No critical issue was discovered, which we are proud of.

High

Two of the issues were related to voting power. Under certain circumstances it was possible to reuse the same Q tokens to vote multiple times on the same Q token holder voting. The issues were difficult to spot (kudos to the auditors) but rather easy to fix.

The third issue (“missing owner”) was also easy to fix but revealed a structural weakness in our unit tests, which we also tackled in this context.

Medium

Most findings in this category got their severity classification from “high impact”, but “low likelihood”. The nature of those issues typically is:

• Probably not an issue in the early days and for quite a while;
• Some findings might never cause damage at all;
• When they become effective, a solution is needed very urgently, which increases risk of introducing new issues (Parity Multisig happened after “fixing” a much less severe issue).

So, while we could have launched like that probably without any issues, we are glad to say that all issues are resolved and no longer pose a threat.

Low

In this category we see issues either with low impact or medium impact but low likelihood. This includes topics like

• Inefficient code;
• Unlikely arithmetic overflows;
• Rounding issues (without substantial economic loss or other damage);
• Missing or outdated contract documentation;
• Things that currently work, but could break too easily if we change something.

Some of the fixes caused more effort than the higher severity issues. However, the gain in robustness and overall maintainability was worth every hour spent.

The one unresolved finding has been fixed at least partially. What remains are minor rounding errors that can be mitigated by small payments to the affected contracts (like 1 Q to cover the loss for centuries). The alternative would have been major breaks in the overall architecture, which appeared too risky in relation to the low impact. However, the intense discussions also revealed some potential for improvement, which is going to be analyzed for future upgrades.

The meta fixes

Fixing bugs is one thing. Applying abstractions to the development process to prevent future bugs is a different one. As learning from above findings we updated our development process in the following ways:

• Higher grade of automation in the deployment process to facilitate higher frequency of integration tests;
• Static code analysis via slither;
• Specific health monitoring scripts in the build pipeline (e.g. byte code size, missing NATSPEC code documentation, …);
• Fix of a gap in our unit tests that allowed the “missing owner” issue to go undetected;
• Exploration of further toolchain enhancements, e.g. Hardhat instead of Truffle (ongoing).

Conclusion

With the successful external code audit, the Q blockchain has reached a new level in terms of maturity and maintainability. Of course, development is ongoing, the backlog is packed with new features and we are eager to come up with new functionality. So, after the audit is before the audit. We are looking forward to it.