From the developer desk of Goldpepperr & Mittens.
With just a few days to go until the TipsyCoin launch, we’d like to share the results of our recent CertiK audit. In this post, we will help highlight and discuss the results in more ‘layman’s terms’ than the dense and jargon-packed official audit report. This is part of our continual commitment to security and transparency of TipsyCoin.
Part of that commitment is also to be an ‘audit first, deploy second’ project, meaning that we can ensure that none of the issues identified in the audit were ever in our ‘live’ code. For those interested, the full audit is available on our CertiK page, or as a downloadable PDF on our Github.
First, and foremost, our audit indicated no ‘critical issues’. For all other issues from Major to Minor, the TipsyCoin team worked closely with CertiK (over the course of more than a month, and 3 interim reports) to comprehensively address and either ‘resolve’ or ‘mitigate’ all issues found.
The total number of findings was 13. Excluding the ‘informational’ ones (5), there was 1 Minor (resolved), 3 Medium (all resolved), and 4 Major (2 resolved, 2 mitigated).
Some members of the community may be concerned that for the Major findings, only 2 issues were ‘resolved’, whilst 2 were ‘mitigated’, so let’s discuss what it means for an issue to be ‘resolved’ vs ‘mitigated’, and hopefully remove any doubt that ‘mitigated’ might mean ‘unsafe’.
For many smart contracts in use, there exist certain privileged functions that only the owner or creator of the contracts can execute. These are often required for management of the coin, and could include actions like adjusting fees and rewards, or integrating new functionality into the project. CertiK calls the existence of these privileged functions centralization risk. If a single account has the ability to execute powerful functions, there is the risk that the account, if compromised (technologically or morally), may use that power to harm the project.
These concerns by CertiK are well founded, as the Rekt leaderboard demonstrates a vast number of projects destroyed by compromised or ‘compromised’ keys – resulting in the loss of millions of dollars in user funds.
As CertiK points out in their audit, our code has some aspect of this centralization risk in the management functions of TipsyCoin, and the upgradability of our contracts. Importantly, CertiK considered our response addressing this risk reasonable, hence their ‘mitigated’ status on the audit report. But in order to allay concerns for the difference between ‘mitigated’ and ‘resolved’, we need to delve deeper.
Upgradability & Management
On upgradability, one of the main design features of TipsyCoin is that our contracts are upgradeable. This means their logic can be improved in the future, in order to facilitate additional functions or adjustments in our current smart contracts to get them integrating well into our rapidly expanding TipsyVerse ecosystem.
Since the blockchain is ‘immutable’, using upgradable contracts provides a way to facilitate smart contract ‘updates’ in a seamless manner without disrupting storage (such as user balances), or changing the original contract address, and this functionality is critical to guarantee compatibility with the rest of the TispyVerse into the future.
On TipsyCoin’s management functions, because all of our contracts are designed to not interact by default with other smart contracts (to prevent any bots), the ability to add new contracts to our ‘whitelist’ to is, again, critical to ensure that as we add new contracts into the ecosystem they can be whitelisted by our current ones.
A complete list of privileged functions included in TipsyCoin has been provided by CertiK below.
As these functions are critical for the management of TipsyCoin, we can’t simply remove them to ‘resolve’ the issue and eliminate the risk. Instead, to manage this risk, we’ve consulted with and followed the recommendations made by CertiK for both the short and long term mitigation of these risks. This involves 2 major steps : multisig authorization, and a 48-hour timelock.
Multisig authorization – a multisig requires multiple accounts to sign off on a proposed transaction before it executes, which prevents a single compromised key from damaging the project. Our team has implemented the use of Gnosis Safe [https://gnosis-safe.io/] to enforce multisig authorization for privileged functions. As an example, for contract upgrades, 3 out of 5 members of the multisig, which includes a mix of both founders and developers, will have to sign off on the proposed upgrade before the transaction can be executed.
48-hour timelock – Furthermore, before any privileged action is actually executed, it will go through a 48-hour delay timelock. This will allow the community to be aware of management or changes to our smart contracts before they are executed, and puts the pending transaction on chain for a minimum 48-hour period, ensuring transparency to our users for what will change when the pending transaction executes.
Our Gnosis Safe and Governance Timelock addresses are as follows.
Gnosis Safe #1 (2/3)
Gnosis Safe #1 (3/5)
TimeLock GOV #1 (Owner)
TimeLock GOV #2 (Proxy Admin)
We hope that with this article we’ve been able to convey the extensive effort put into addressing issues identified by CertiK, via either ‘resolution’ where possible and ‘mitigation’ where not.
It is also important to understand that privileged access (centralization) is a type of risk, not a bug, and these types of risks often cannot be completely eliminated, only mitigated. Since, for example, CertiK has no ability to guarantee that a contract upgrade 12 months from now will be bug free. Instead, through the use of multisig and timelocks, CertiK was satisfied that access to privileged functions never lies in the hands of a single user, and that a timelock provides 48 hours of notice and transparency to the community for changes that are pending.
This resolution also goes significantly further than other notable projects such as Decentraland, or even 1inch’s Limit Order feature, which had similar centralization concerns, but whose developers did not take steps towards the mitigation of risk – in contrast to TipsyCoin’s significant effort in this area.
As a final comment, the ‘mitigated’ status for issues is relatively new for CertiK, and so they’re not yet displayed or recognized on the project’s audit front page (hence the 2 of 4 resolved).
And, that’s it, we’re done! Thank you so much for taking the time to read through this write up, and we’re looking forward to welcoming you into TipsyVerse very soon!
TipsyCoin ($tipsy) will be lauched on 15th March 2022 (A.M. EST).
Follow our discord for first-hand information.