TipsyCoin’s CertiK Audit
From the developer desk of Goldpepperr & Mittens.
Preface
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.
Audit Overview
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’.
Vulnerability
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.
Examples below:
– bZx
– LCX
– Dego Finance
– Vulcan Forged
– 8ight Finance
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 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)
Address: 0x884C908ea193B0Bb39f6A03D8f61C938F862e153
Constituent Members:
0x75bA26e94BC5261cABeC4B50208DF9e21b21245a
0x95c486EdBaf1b71a3391dE71A1c724C415695E44
0x5C39F4261b2292a4b0C778A10c555eDeFDFf54dA
Gnosis Safe #1 (3/5)
Address: 0xb4620C524245c584C5C2Ba79FD20CeB926FBd418
Constituent Members:
0x75bA26e94BC5261cABeC4B50208DF9e21b21245a
0x95c486EdBaf1b71a3391dE71A1c724C415695E44
0x2acca9B9b3052C49f89b8ba16e7cEfF305017646
0xF052482E025a056146d903a8802d04e7328543F5
0x51E710c9186a343439a51a27ecf6756700df5075
TimeLock GOV #1 (Owner)
https://bscscan.com/address/0xe50B0004DC067E5D2Ff6EC0f7bf9E9d8Eb1E83a6
TimeLock GOV #2 (Proxy Admin)
https://bscscan.com/address/0x10f47282dfc8E21E69A7Ad6367e9673062359935
Wrapping up
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.
