Smart Contracts Security Verification Standard




Author: Paweł Kuryłowicz


In recent months, me and Damian Rusinek have worked together to standardize the security of smart contracts for developers, architects, security reviewers and vendors. In short — everyone working with smart contracts.


We set clear objectives to achieve:

  • Help to develop high quality code of the smart contracts,
  • Help to mitigate known vulnerabilities by design,
  • Provide a checklist for developers, architects and security reviewers,
  • Provide a clear and reliable assessment of how secure a smart contract is in relation to the percentage of SCSVS coverage.

It wasn’t as easy as we thought to think of something that would meet all four goals, but after a few creative evenings over beer — Damian came up with a great idea.


How did we implement it?


We created a 13-part checklist in a form inspired by well-known and widely used OWASP ASVS. Everyone in the #appsec knows or SHOULD KNOW this standard, that’s exactly why we think that this form will be the most handy and useful for everyone.


Here are key areas that we covered:


V1: Architecture, Design and Threat Modelling

Architecture, design and threat modelling in the context of creating secure smart contracts. Consider all possible threats before the implementation of the smart contract.


High-level requirements:

  • All related smart contracts are identified and used properly,
  • Specific smart contracts security assumptions are considered during the design phase.

Category “V1” lists requirements related to the architecture, design and threat modelling of the smart contracts.


V2: Access Control

Access control is the process of granting or denying specific requests to obtain and use information and related information processing services.


High-level requirements:

  • Users and other contracts are associated with a well-defined set of roles and privileges,
  • Access is granted only to privileged users and contracts.

Category “V2” lists requirements related to the access control mechanisms of the smart contracts.


V3: Blockchain Data

Smart contracts in public blockchains have no built-in mechanism to store secret data securely. It is important to protect sensitive data from reading by an untrusted actor.


High-level requirements:

  • Data stored in smart contract is identified and protected,
  • Secret data is not kept in blockchain as plaintext,
  • Smart contract is not vulnerable due to data misrepresentation.

Category “V3” lists requirements related to the blockchain data of the smart contracts.


V4: Communications

Communications includes the topic of the relations between smart contracts and their libraries.


High-level requirements:

  • The external calls from and to other contracts have considered abuse case and are authorized,
  • Used libraries are safe and state-of-the-art security libraries are used.

Category “V4” lists requirements related to the function calls between the verified contracts and other contracts out of the scope of the application.


V5: Arithmetic

Arithmetic category covers mathematical operations in the smart contracts.


High-level requirements:

  • All mathematical operations and extreme variable values are handled in a safe and predictable manner.

Category “V5” lists requirements related to the arithmetic operations of the smart contracts.


V6: Malicious input handling

Malicious input handling is about how values obtained as parameters by smart contracts should be validated.


High-level requirements:

  • The function parameters being passed are handled in a safe and predictable manner.

Category “V6” lists requirements related to the malicious input to the functions of smart contracts.


V7: Gas Usage & Limitations

The efficiency of gas consumption should be taken into account not only in terms of optimization, but also in terms of safety to avoid possible exhaustion. Smart contracts by nature have different limitations that, if they are not taken into account, can cause different vulnerabilities.


High-level requirements:

  • The use of gas is optimized and unnecessary losses are prevented,
  • The implementation is in line with the smart contracts’ limitations.

Category “V7” lists requirements related to gas and smart contract limitations.


V8: Business Logic

To build secure smart contracts, we need to consider the security of their business logic. Some of the smart contracts are influenced by vulnerabilities by their design. The components used should not be considered safe without verification. Business assumptions should meet with the principle of minimal trust, which is essential in building smart contracts.


High-level requirements:

  • The business logic flow is sequential and in order,
  • Business limits are specified and enforced,
  • Cryptocurrency and token business logic flows have considered abuse cases and malicious actors.

Category “V8” lists requirements related to the business logic of the smart contracts.


V9: Denial of Service

Denial of service category focuses on the availability of smart contracts and possible ways to minimize the risk of DoS.


High-level requirements:

  • The contract logic prevents influencing the availability of the contract.

Category “V9” lists requirements related to the possible denial of service of the smart contracts.


V10: Token

The token implementation should be in accordance with established standards.


High-level requirements:

  • The implemented token follows the security standards.

Category “V10” lists requirements related to the token of the smart contracts.


V11: Code Clarity

Keeping code clear and simple has many advantages but the reason why we have created a whole category it is that we believe security vulnerabilities will be much easier to spot and remediate.


High-level requirements:

  • The code is clear and easy to read,
  • There are no unwanted or unused parts of the code,
  • Variable names are in line with good practices,
  • The functions being used are secure.

Category “V11” lists requirements related to the code clarity of the smart contracts.


V12: Test Coverage

We know from experience that when and what is tested is as important as how and that is what Test Coverage focus on.


High-level requirements:

  • The specification has been formally tested,
  • The implementation has been tested statically and dynamically,
  • The implementation has been tested using symbolic execution.

Category “V12” lists requirements related to the testing process of the smart contracts.


V13: Known Attacks

The Known attacks category has a different form from the other categories. It covers all known attacks and link them to the requirements from other categories.

Category “V13” aims to ensure that a verified contract is protected from the known attacks.


I hope I got you a bit closer to the standard we’ve created. We really would like it to become a tool solving many problems related to the security of smart contracts in the future, but to this we need feedback from You. That’s why I invite you to contact:


Full Smart Contracts Security Verification Standard can be found at:

If you believe in this project, please SHARE so that more people can hear about SCSVS.



Other articles

Stay tuned!

  • Articles and free security guides
  • Reports
  • Presentations and news from conferences around the world
Providing personal data is voluntary. We will send the newsletter until the consent is withdrawn (You can withdraw your consent at any time). Your data will be processed for a period specified in the Privacy Policy available at the following URL.
The Data Controller is SecuRing SJ with the registered office at ul. Kalwaryjska 65/6, 30-504 Kraków. I have the right to withdraw my consent at any time (by sending an e-mail to the address or by phone: +48 (12) 425 25 75). I have the right to access, rectify, erase or limit the processing of my personal data, the right to object, the right to file a complaint with the supervisory authority and right to transfer data. The legal basis for the processing of personal data is Article 6 (1) (a) of the General Data Protection Regulation (GDPR).
The Data Controller uses various IT solutions that allow for more efficient communication and cooperates with entities supporting it in its business and IT processes (i.e. these companies are data recipients/processors). Data are not transferred outside the European Economic Area. These companies have signed appropriate contracts for entrustment of personal data processing.
Thank you for subscribing.
Something went wrong.
Please contact us by phone.