Prime Rating
Search…
Technical Rating Report
High-level description of writing a technical report

Summary of the Rating Process

Very simply, the review looks for the following declarations from the developer's site. With these declarations, it is reasonable to trust the smart contracts:
  • Here are my smart contracts on the blockchain
  • Here is the documentation that explains what my smart contracts do
  • Here are the tests I ran to verify my smart contract
  • Here are the audit(s) performed on my code by third party experts
  • Here are the admin access controls and how they’re used
  • This is where the protocol gets its data, and these are some proactive steps we’ve taken to avoid problems.

Sections of the Review Process

The process breaks the scores into the following sections:
  • Code and Team -- Deployed Code Verification
  • Documentation -- Software Documentation for the Deployed
  • Code Test -- Overall testing measures for the Deployed
  • Code Security -- Review of the Software Security
  • Audits and Bug Bounty Access Controls -- Review of the public information about admin access controls
  • Oracles -- Explanation of the data sources used by the protocol and identification of potential vulnerabilities

Scoring

A review’s Final Score is indicated as a percentage. This percentage is calculated as total Achieved Points divided by the total Possible Points. For each question the answer can be either yes (Y), no (N), or a percentage (%). Each of these questions has a “Scoring Weight”, as some are more important than others. For example, “Question 1” is more important than “Question 15”, and therefore has a higher weight.
The individual question’s Achieved Points is the Scoring Weight times the answer (yes, no, %). The review’s Total Achieved Points is the sum of every question’s points.
Please see this example of a scoring matrix for reference:

Private Software Repos

Development teams, especially those in DeFi, often prefer a private repository to reduce the ability for an easy fork/copy of their development. We clearly understand the business incentive for this, but we cannot give scores for what we cannot see. Hence, the developers will be penalized for not having a publicly accessible repository.
This is due to the importance of public repositories in quantifying a steady development process as well as being able to see the testing records, and be able to verify the code in general. Although we fully encourage developers to have a private repository alongside a public one, the public repository must be an industry standard for protocols wishing to establish themselves as leaders in the DeFi space.
Audits are also of special importance. With a public repository, anyone can check the differences between the audited and deployed code because all the information is publicly available.
However, if there is no public repository, the audit is of lesser value because the code cannot be cross referenced. Assuming the audit takes place on private code, then 25% is deducted from the audit question score. This is because differences between deployed and audited code are too important to provide points for.

Last modified 1mo ago