How to Improve your Score

This page contains information about how to improve the scores of specific questions. Please use the “Report an Issue” button on the right side of your PQR to submit an issue, or contact our analysts on telegram.

Smart Contracts and Team

1) Are the smart contract addresses easy to find?
Make the addresses of the smart contracts utilized by your application available on either your website, Gitbook or GitHub (in the README for instance). Ensure the addresses are up to date, and that they can be verified using a block explorer.
Your documentation should ideally comprise a section called “Smart Contracts”, “Smart Contract Addresses”, or “Deployed Addresses” in order to make them easy to find.
2) How active is the primary smart contract?
Make sure to list your main executing smart contract addresses in a section of your documentation. This will make it easier for us to evaluate your contract’s user interactions, as well as make it easier for you to get 100% for this question.
3) Does the protocol have a public software repository?
Ensure your contracts are available for viewing on a public software repository (like GitHub). The link to it can be from your protocol’s website or GitBook documentation. Any alternative public repository service is acceptable as well, provided it is identified.
4) Is there a development history visible?
In order to maximize your score for this question, make sure to actively develop your public GitHub. This doesn’t mean that you cannot also have a private GitHub, but your users should at least be able to see a decent amount of development history in it.
A good way to rack up the commits is to also add your testing suite to your GitHub, and then continuously test for bugs which would go straight into your CI.
5) Is the team public (not anonymous)?
Create a section of documentation linking to employees, founders or contributors in an easily accessible place such as a website, LinkedIn etc.
To score fully, name the contributors to this protocol in your documentation and ensure that this corroborates information that can be found elsewhere on the internet (e.g. LinkedIn/ a personal website). Alternatively, software repository contributors can be public, though once again these must be cross-confirmed.

Documentation

6) Is there a whitepaper?
Ensure that your white paper is available for viewing from your website’s front page, GitBooks documentation, or at least the README.md of your GitHub repository.
Moreover, protocols should update their whitepapers frequently to meet the capabilities of their present application.
7) Is the protocol software architecture documented?
Write this document based on the deployed code and how it operates. For guidance, refer to the SecurEth System Description Document. This document should be written before deployment.
8) Does the software documentation fully cover the deployed contracts' source code?
This score can be improved by ensuring protocol documents fully and comprehensively cover everything deployed by the protocol.
A good way to do it is to list literally every function for every smart contract that you have deployed for your protocol. Not only that, but you also include a brief description of what the specific contract function does and how it does it. Natspec Crawler may assist in this effort.
9) Is it possible to trace the documented software to its implementation in the protocol's source code?
This score can be improved by adding traceability from documents to code such that it is clear where each outlined code function in the documentation is coded in the protocol’s GitHub repository. For reference, check the SecurEth guidelines on traceability.

Testing

10) Has the protocol tested their deployed code?
This score can be improved by adding tests to fully cover the code. Document what is covered by traceability or test results in the software repository. Ideally, you should have a test file per smart contract deployed on the blockchain.
In addition, providing scripts to run your tests is an essential part of testing transparency, and no testing suite should come without them.
11) What is the documented code coverage from the tests?
This score can be improved by performing code coverage tests that are as close to 100% coverage as possible. In the event that some lines of code or entire contracts are missed, you should clearly outline why this is the case in your coverage report.
Hence, you should also be aiming to perform code coverage tests upon every single deployment. This proves that the code is rigorously tested, and therefore has a degree of reliability attributed to it. Integrate the result of your code coverage result in your GitHub repository readme, like Tetu protocol has done here.
12) Does the protocol provide scripts and instructions to run their tests? (Y/N)
Add the scripts to the repository and ensure they work. Ask an outsider to create the environment and run the tests. Improve the scripts and documents based on their feedback.
13) Is there a detailed report of the protocol’s test results?
Add a code coverage test report with the results. This should not only be a code coverage output, but rather a combination of your coverage output and a deeper insight on your methodology used. An exemplary test report from Balancer Finance can be found here.
14) Has the protocol undergone formal verification?
Undergo a Formal Verification for your protocol’s algorithms, and use the services provided by the reputable formal verifiers in the space such as Certora and Runtime Verification. Although this can become expensive, it is an essential part of legitimizing your software’s integrity.
15) Were the smart contracts deployed to a testnet?
Make sure to utilize testnet networks in your developing and deployment process. It is an environment that lets you fully test the capability and functionality of your smart contracts: this ensures a certain degree of stability.
Don’t forget to link your testnet smart contract addresses in your documentation, as we need proof in order to score this question. If you used Ganache or an equivalent, please state and document this.

Security

16) Is the protocol sufficiently audited?
Your score for this question can improve by having your future deployments rigorously audited before deployment. In order to achieve full marks, you must have had your smart contracts audited twice before being deployed. Nevertheless, one audit performed before deployment still gives you a great score for this metric.
Another point you can seek to improve on is implementing the recommendations brought to you by the audit. We read every audit thoroughly, and not implementing important fixes will definitely affect your score negatively.
Finally, having one audit published either before or after a deployment is infinitely better than having none at all. Even if you have just one audit, you’re on the right track. Just make sure that it is traceable to your own code, and that the audited smart contracts have their addresses publicly available.
17) Is the bounty value acceptably high?
Bug Bounty programs increase the amount of eyes that are continuously checking your source code for bugs. Implementing monetary incentives will make your code more secure because it is more scrutinised. The other side of the coin is that posting a multi-million-dollar bounty will naturally make you feel more inclined to be certain that your code does not have any flaws in it.

Admin Controls

18) Is the admin control information easy to find?
You can improve this score by putting all of your admin controls information under one overarching section of your documentation. It needs to be as easy to find and as easy to identify as possible.
Acceptable identifiers of admin controls documentation include: “Governance”, “DAO” (if applicable), or “Admin Access/Powers”.
19) Are relevant contracts clearly labelled as upgradeable or immutable?
You can improve your score by clearly labelling the upgradeability capabilities of each of your deployed smart contracts. Doing this is important from a user perspective.
Full points will be awarded here if you state all of your contracts are immutable. Examples can be found here.
20) Is the type of contract ownership clearly indicated?
You can improve your score through clearly outlining the ownership functions (OnlyOwner, MultiSig, Defined Roles) attributed to your deployed smart contract. Ideally, this would all be clearly formatted within your admin controls section.
At the bare minimum, these functions should be established and explained in your protocol’s code or code comments.
21) Is the contract change capability described?
You can improve your score for this question by adding all the necessary information regarding the capabilities of your smart contracts’ upgradeability in your documentation. An example of this can be found here.
22) Is the admin controls information easy to understand?
Create a document that covers the items described above in plain language that investors can understand. An example is enclosed.
23) Is there sufficient Pause Control documentation?
To improve your score, you should either implement or expand upon the information available on your Pause Control function. Additionally, make sure to perform consistent “fire drill” tests on your emergency pause so that we can be assured that it has been battle-tested.
You should also create a document that covers the items described above in plain language that investors can understand. An example is enclosed.
24) Is there sufficient Timelock documentation?
Create a document that identifies the timelock, its length and which contracts it is applicable to. This should be included in the protocol documentation.
An example of good timelock documentation is Uniswap’s. Protocols may seek to use this as a starting point for their own Timelock documentation.
25) Is the timelock of an adequate length?
In your Timelock documentation, make sure to include the duration of it and an adequate description of why this specific timeframe was chosen.
If you do not use Timelocks make sure to clearly outline this in your docs and appropriately justify it.

Oracles

26) Is the protocol’s Oracle sufficiently documented?
Include a section within protocol documentation explaining the oracle it employs. Pancakeswap documentation identifies the oracles that it uses, and justifies why it chose them. Protocols might emulate this.
If your protocol does not need a data source, this should be explained and full marks will be awarded.
27) Is front running mitigated by this protocol?
Document the frontrunning countermeasures your protocol employs. If no frontrunning countermeasures are employed, state and justify this. For an example of documentation relating to frontrunning countermeasures, see mistX’s documentation.
28) Can flashloan attacks be applied to the protocol, and if so, are those flashloan attack risks mitigated?
Identify in your documentation what countermeasure the protocol employs to prevent a flashloan attack. An example of how this might be prevented can be found here and this should be documented in this way.