LedgerScore Completes Successful Rock’n’Block Audit

We are proud to announce a successful Smart Contract Audit


The audit reviewed contract source code from Etherscan. Contract were reviewed in the context of the flattened file, which included a single solidity file. The review performed did not assess any scripts, tests, or other non-Solidity files.


This audit was performed as a comprehensive review of the codebase and takes into consideration both the Solidity code, as well as the target platform: Ethereum main network. The Solidity was reviewed not just for common vulnerabilities and antipatterns, but also for its parity with the intent of the deployer, for its efficiency, and for the practices used during development

Risk Assessment

Findings were categorized using a risk rating model based on the OWASP method. Each vulnerability takes into consideration the impact and likelihood of exploitation, as well as the relative ease with which the vulnerability is resolved; findings that permeate throughout the codebase will require much more review and work to solve and are rated higher as a result


1. NO critical-severity vulnerabilities were found.

2. NO high-severity vulnerabilities were found.

3. NO medium-severity vulnerabilities were found.

4. Low Severity

Disparity of expectation in release functions: Users use releaseOnce() and releaseAll() to release their frozen tokens once the freeze period has elapsed. In the event a user does not hold any frozen tokens eligible for release, the releaseOnce() function reverts state changes. This is not the case for releaseAll(), which will simply do nothing. While this does not pose a significant danger for users, we recommend the inconsistency be addressed. Overuse of public function visibility: The reviewed token contract is assembled using a script which generates a file of constants with which the token contract will set its initial values. Because each constant is marked public, Solidity implicitly creates a publicly visible getter function with the same name. While using constants is generally efficient, excessive use of public fields: 1. Makes a contract more expensive to deploy (longer bytecode) 2. Makes a contract more expensive to use, as each additional function selector created by these implicit getters means more options to traverse at runtime. Consider removing the word public from each constant unless absolutely necessary. They will be set to the default, internal, meaning they will still be accessible internally to the contract

Manual testing

All “Successful”

About Rock’n’Block

Rock’n’Block provides custom development and implementation of software-based blockchain technologies for businesses and startups.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store

Credit 2.0 for Cryptocurrency | Independent Financial Reporting for DeFi and Traditional Lending