From 59ee6e6aa73456a61ec76afda2c15d820ffef597 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=AD=D1=80=D0=B8=D0=BA=20=D0=A1=D1=83=D0=BB=D1=82=D0=B0?=
 =?UTF-8?q?=D0=BD=D0=B0=D0=BB=D0=B8=D0=B5=D0=B2?= <ersul4ik@mail.ru>
Date: Tue, 20 Nov 2018 14:29:02 +0600
Subject: [PATCH 01/18] MC-23 Changed the get_last_version method return value

---
 swcregistrypython.egg-info/PKG-INFO             | 14 --------------
 swcregistrypython.egg-info/SOURCES.txt          | 12 ------------
 swcregistrypython.egg-info/dependency_links.txt |  1 -
 swcregistrypython.egg-info/requires.txt         |  1 -
 swcregistrypython.egg-info/top_level.txt        |  1 -
 5 files changed, 29 deletions(-)
 delete mode 100644 swcregistrypython.egg-info/PKG-INFO
 delete mode 100644 swcregistrypython.egg-info/SOURCES.txt
 delete mode 100644 swcregistrypython.egg-info/dependency_links.txt
 delete mode 100644 swcregistrypython.egg-info/requires.txt
 delete mode 100644 swcregistrypython.egg-info/top_level.txt

diff --git a/swcregistrypython.egg-info/PKG-INFO b/swcregistrypython.egg-info/PKG-INFO
deleted file mode 100644
index 7088d96..0000000
--- a/swcregistrypython.egg-info/PKG-INFO
+++ /dev/null
@@ -1,14 +0,0 @@
-Metadata-Version: 1.1
-Name: swcregistrypython
-Version: 0.0.0.9
-Summary: An package to get the required swc definition fields.
-Home-page: https://github.com/SmartContractSecurity/SWC-registry-python
-Author: SmartContractSecurity
-Author-email: ersul4ik@gmail.com
-License: UNKNOWN
-Description: # empty
-Platform: UNKNOWN
-Classifier: Programming Language :: Python
-Classifier: Programming Language :: Python :: 3
-Classifier: Programming Language :: Python :: 3.3
-Classifier: Programming Language :: Python :: 3.4
diff --git a/swcregistrypython.egg-info/SOURCES.txt b/swcregistrypython.egg-info/SOURCES.txt
deleted file mode 100644
index 56fe14c..0000000
--- a/swcregistrypython.egg-info/SOURCES.txt
+++ /dev/null
@@ -1,12 +0,0 @@
-MANIFEST.in
-README.rst
-setup.py
-swcregistrypython/__init__.py
-swcregistrypython/get_entry_info.py
-swcregistrypython/swc-definition.json
-swcregistrypython/test.py
-swcregistrypython.egg-info/PKG-INFO
-swcregistrypython.egg-info/SOURCES.txt
-swcregistrypython.egg-info/dependency_links.txt
-swcregistrypython.egg-info/requires.txt
-swcregistrypython.egg-info/top_level.txt
\ No newline at end of file
diff --git a/swcregistrypython.egg-info/dependency_links.txt b/swcregistrypython.egg-info/dependency_links.txt
deleted file mode 100644
index 8b13789..0000000
--- a/swcregistrypython.egg-info/dependency_links.txt
+++ /dev/null
@@ -1 +0,0 @@
-
diff --git a/swcregistrypython.egg-info/requires.txt b/swcregistrypython.egg-info/requires.txt
deleted file mode 100644
index 5610e90..0000000
--- a/swcregistrypython.egg-info/requires.txt
+++ /dev/null
@@ -1 +0,0 @@
-requests==2.20.1
diff --git a/swcregistrypython.egg-info/top_level.txt b/swcregistrypython.egg-info/top_level.txt
deleted file mode 100644
index 8e06944..0000000
--- a/swcregistrypython.egg-info/top_level.txt
+++ /dev/null
@@ -1 +0,0 @@
-swcregistrypython

From 47205cdce6d19b1c80e1a291bcd392e63997f6e5 Mon Sep 17 00:00:00 2001
From: Joran Honig <joran.honig@gmail.com>
Date: Tue, 20 Nov 2018 23:47:58 +0100
Subject: [PATCH 02/18] Move loading logic to separate singleton class Don't
 write on an update Refactor the functions of SWC, making some private and
 some not properties

Move test outside of packaged directory

Create setup.py test command
---
 setup.cfg                                     |  2 +
 setup.py                                      |  3 +
 swcregistrypython/get_entry_info.py           | 90 +++++++++++++------
 tests/__init__.py                             |  0
 .../test.py => tests/test_get_entry_info.py   | 30 ++++---
 5 files changed, 82 insertions(+), 43 deletions(-)
 create mode 100644 setup.cfg
 create mode 100644 tests/__init__.py
 rename swcregistrypython/test.py => tests/test_get_entry_info.py (53%)

diff --git a/setup.cfg b/setup.cfg
new file mode 100644
index 0000000..9af7e6f
--- /dev/null
+++ b/setup.cfg
@@ -0,0 +1,2 @@
+[aliases]
+test=pytest
\ No newline at end of file
diff --git a/setup.py b/setup.py
index 269c541..4b39b25 100644
--- a/setup.py
+++ b/setup.py
@@ -1,4 +1,5 @@
 import setuptools
+
 setuptools.setup(
     name="swcregistrypython",
     version="1.0",
@@ -18,4 +19,6 @@
         'Programming Language :: Python :: 3.3',
         'Programming Language :: Python :: 3.4'
     ],
+    setup_requires=["pytest-runner"],
+    tests_require=["pytest"]
 )
diff --git a/swcregistrypython/get_entry_info.py b/swcregistrypython/get_entry_info.py
index f01a740..f1bbea8 100644
--- a/swcregistrypython/get_entry_info.py
+++ b/swcregistrypython/get_entry_info.py
@@ -3,59 +3,91 @@
 import json
 
 
-class SWC:
-    def __init__(self, swc_id):
-        self.swc_id = swc_id
-        self.path_file_content = os.path.join(os.path.dirname(__file__),'swc-definition.json')
+class Singleton(type):
+    _instances = {}
 
-    @property
-    def get_content_by_file(self):
-        with open(self.path_file_content, 'r') as f:
-            response = json.load(f)
-        return response
+    def __call__(cls, *args, **kwargs):
+        if cls not in cls._instances:
+            cls._instances[cls] = super(Singleton, cls).__call__(*args, **kwargs)
+        return cls._instances[cls]
 
-    @property
-    def get_last_version(self):
+
+class SWCRegistry(object, metaclass=Singleton):
+    """
+    Registry class takes care of loading and downloading the swc registry
+    """
+    def __init__(self):
+        self._content = None
+
+    @staticmethod
+    def _get_latest_version():
         try:
-            url = ('https://raw.githubusercontent.com/SmartContractSecurity/SWC-registry/master/export/swc-definition.json')
+            url = ('https://raw.githubusercontent.com/SmartContractSecurity/SWC-registry/master/export/swc-definition'
+                   '.json')
             response = requests.get(url).json()
-            with open(self.path_file_content, 'w') as outputfile:
-                json.dump(response, outputfile)
+            return response
         except requests.exceptions.RequestException:
-            response = self.get_content_by_file
-        return "swc-definition.json - updated"
+            return None
+
+    def _load_from_file(self):
+        path_file_content = os.path.join(os.path.dirname(__file__), 'swc-definition.json')
+        with open(path_file_content, 'r') as f:
+            self._content = json.load(f)
+
+    def update(self):
+        self._content = SWCRegistry._get_latest_version()
 
     @property
     def content(self):
-        entries = self.get_content_by_file
+        if self._content is None:
+            self._load_from_file()
+        return self._content
+
+
+class SWC:
+    """
+    SWC class contains information on an SWC entry
+
+    Example usage:
+        swc = SWC('SWC-100')
+        print(swc.title)
+    """
+    def __init__(self, swc_id, get_last=False):
+        self.swc_id = swc_id
+        if get_last:
+            SWCRegistry().update()
+
+    @property
+    def _swc_content(self):
+        return SWCRegistry().content
+
+    @property
+    def _content(self):
+        entries = self._swc_content
         current_entry = entries.get(self.swc_id, {})
         content = current_entry.get('content', {})
         return content
 
-    @content.setter
-    def content(self, value):
-        self._content = value
-
     @property
-    def title(self):
-        content = self.content
+    def title(self) -> str:
+        content = self._content
         title = content.get('Title', {})
         return title
 
     @property
-    def relationships(self):
-        content = self.content
+    def relationships(self) -> str:
+        content = self._content
         relationships = content.get('Relationships', {})
         return relationships
 
     @property
-    def description(self):
-        content = self.content
+    def description(self) -> str:
+        content = self._content
         description = content.get('Description', {})
         return description
 
     @property
-    def remediation(self):
-        content = self.content
+    def remediation(self) -> str:
+        content = self._content
         remediation = content.get('Remediation', {})
         return remediation
diff --git a/tests/__init__.py b/tests/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/swcregistrypython/test.py b/tests/test_get_entry_info.py
similarity index 53%
rename from swcregistrypython/test.py
rename to tests/test_get_entry_info.py
index 1b8752b..5a6df31 100644
--- a/swcregistrypython/test.py
+++ b/tests/test_get_entry_info.py
@@ -1,40 +1,42 @@
 import unittest
 import json
+import os
 
 from unittest.mock import MagicMock
-from get_entry_info import SWC
+from swcregistrypython import SWC
+from swcregistrypython.get_entry_info import SWCRegistry
 
 
 class TestMethods(unittest.TestCase):
     def setUp(self):
-        with open('swc-definition.json') as f:
+        with open(os.path.dirname(__file__) + '/../swcregistrypython/swc-definition.json') as f:
             self.object = json.load(f)
         self.swc = SWC('SWC-100')
-     
+        SWCRegistry()._load_from_file()
+
     def test_get_title(self):
-        self.swc.content = MagicMock(return_value=self.object['SWC-100']['content'])
         self.assertEqual(self.swc.title, self.object['SWC-100']['content']['Title'])
 
     def test_get_relationships(self):
-        self.swc.content = MagicMock(return_value=self.object['SWC-100']['content'])
         self.assertEqual(self.swc.relationships, self.object['SWC-100']['content']['Relationships'])
 
     def test_get_description(self):
-        self.swc.content = MagicMock(return_value=self.object['SWC-100']['content'])
         self.assertEqual(self.swc.description, self.object['SWC-100']['content']['Description'])
     
     def test_get_remediation(self):
-        self.swc.content = MagicMock(return_value=self.object['SWC-100']['content'])
         self.assertEqual(self.swc.remediation, self.object['SWC-100']['content']['Remediation'])
 
     def test_get_last_version(self):
-        self.object['SWC-100']['content']['Title'] = "Test"
-        with open('swc-definition.json', 'w') as f:
-            json.dump(self.object, f)
-        self.assertEqual(self.swc.title, "Test")
-        
-        self.swc.get_last_version
-        self.assertNotEqual(self.swc.title, "Test")
+        # Act
+        after_content = SWCRegistry().content
+        after_content['SWC-100']['content']['Title'] = "Brick"
+        SWCRegistry._get_latest_version = MagicMock(return_value=after_content)
+
+        SWCRegistry().update()
+
+        # Assert
+        new_title = self.swc.title
+        self.assertEqual(new_title, "Brick")
 
 
 if __name__ == '__main__':

From 77362e9880bb1066e9aa9469b80bf334e5a291e6 Mon Sep 17 00:00:00 2001
From: Aleksandr Sobolev <thesobolev@gmail.com>
Date: Wed, 21 Nov 2018 17:51:32 +0600
Subject: [PATCH 03/18] #12 Use empty string as default for SWC getters. Add
 pytest to requirements_dev.txt

---
 .circleci/config.yml                                    | 2 +-
 .gitignore                                              | 3 ++-
 MANIFEST.in                                             | 2 +-
 requirements_dev.txt                                    | 1 +
 setup.py                                                | 4 ++--
 {swcregistrypython => swc_registry}/__init__.py         | 2 +-
 {swcregistrypython => swc_registry}/get_entry_info.py   | 8 ++++----
 {swcregistrypython => swc_registry}/swc-definition.json | 0
 tests/test_get_entry_info.py                            | 6 +++---
 9 files changed, 15 insertions(+), 13 deletions(-)
 create mode 100644 requirements_dev.txt
 rename {swcregistrypython => swc_registry}/__init__.py (59%)
 rename {swcregistrypython => swc_registry}/get_entry_info.py (91%)
 rename {swcregistrypython => swc_registry}/swc-definition.json (100%)

diff --git a/.circleci/config.yml b/.circleci/config.yml
index 88e2293..f8ed938 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -7,7 +7,7 @@ jobs:
         - checkout
         - run:
             name: Tests runner
-            working_directory: swcregistrypython/
+            working_directory: swc_registry/
             command: |
               pip install -r ../requirements.txt
               python test.py
diff --git a/.gitignore b/.gitignore
index 8e71b18..187d6c7 100644
--- a/.gitignore
+++ b/.gitignore
@@ -17,4 +17,5 @@ requests.egg-info/
 *.egg
 env/
 dist
-swcregistrypython.egg-info/
\ No newline at end of file
+*.egg-info/
+.eggs/
diff --git a/MANIFEST.in b/MANIFEST.in
index 37f1a57..8b6d08a 100644
--- a/MANIFEST.in
+++ b/MANIFEST.in
@@ -1 +1 @@
-include swcregistrypython/swc-definition.json
+include swc_registry/swc-definition.json
diff --git a/requirements_dev.txt b/requirements_dev.txt
new file mode 100644
index 0000000..273b14e
--- /dev/null
+++ b/requirements_dev.txt
@@ -0,0 +1 @@
+pytest==4.0.0
diff --git a/setup.py b/setup.py
index 4b39b25..df1fdc2 100644
--- a/setup.py
+++ b/setup.py
@@ -1,14 +1,14 @@
 import setuptools
 
 setuptools.setup(
-    name="swcregistrypython",
+    name="swc-registry",
     version="1.0",
     url="https://github.com/SmartContractSecurity/SWC-registry-python",
     author="SmartContractSecurity",
     author_email="ersul4ik@gmail.com",
     description="An package to get the required swc definition fields.",
     long_description=open('README.rst').read(),
-    packages=['swcregistrypython'],
+    packages=['swc_registry'],
     include_package_data = True,
     install_requires=[
         'requests==2.20.1',
diff --git a/swcregistrypython/__init__.py b/swc_registry/__init__.py
similarity index 59%
rename from swcregistrypython/__init__.py
rename to swc_registry/__init__.py
index 23f755b..c2795e7 100644
--- a/swcregistrypython/__init__.py
+++ b/swc_registry/__init__.py
@@ -1,4 +1,4 @@
-from swcregistrypython.get_entry_info import SWC
+from swc_registry.get_entry_info import SWC
 
 __version__ = '1.0'
 __author__ = 'SmartContractSecurity'
diff --git a/swcregistrypython/get_entry_info.py b/swc_registry/get_entry_info.py
similarity index 91%
rename from swcregistrypython/get_entry_info.py
rename to swc_registry/get_entry_info.py
index f1bbea8..b4641c5 100644
--- a/swcregistrypython/get_entry_info.py
+++ b/swc_registry/get_entry_info.py
@@ -71,23 +71,23 @@ def _content(self):
     @property
     def title(self) -> str:
         content = self._content
-        title = content.get('Title', {})
+        title = content.get('Title', '')
         return title
 
     @property
     def relationships(self) -> str:
         content = self._content
-        relationships = content.get('Relationships', {})
+        relationships = content.get('Relationships', '')
         return relationships
 
     @property
     def description(self) -> str:
         content = self._content
-        description = content.get('Description', {})
+        description = content.get('Description', '')
         return description
 
     @property
     def remediation(self) -> str:
         content = self._content
-        remediation = content.get('Remediation', {})
+        remediation = content.get('Remediation', '')
         return remediation
diff --git a/swcregistrypython/swc-definition.json b/swc_registry/swc-definition.json
similarity index 100%
rename from swcregistrypython/swc-definition.json
rename to swc_registry/swc-definition.json
diff --git a/tests/test_get_entry_info.py b/tests/test_get_entry_info.py
index 5a6df31..e748657 100644
--- a/tests/test_get_entry_info.py
+++ b/tests/test_get_entry_info.py
@@ -3,13 +3,13 @@
 import os
 
 from unittest.mock import MagicMock
-from swcregistrypython import SWC
-from swcregistrypython.get_entry_info import SWCRegistry
+from swc_registry import SWC
+from swc_registry.get_entry_info import SWCRegistry
 
 
 class TestMethods(unittest.TestCase):
     def setUp(self):
-        with open(os.path.dirname(__file__) + '/../swcregistrypython/swc-definition.json') as f:
+        with open(os.path.dirname(__file__) + '/../swc_registry/swc-definition.json') as f:
             self.object = json.load(f)
         self.swc = SWC('SWC-100')
         SWCRegistry()._load_from_file()

From 485e942d7e66457cdc6cf0d9034a64a2d925f6bb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=AD=D1=80=D0=B8=D0=BA=20=D0=A1=D1=83=D0=BB=D1=82=D0=B0?=
 =?UTF-8?q?=D0=BD=D0=B0=D0=BB=D0=B8=D0=B5=D0=B2?= <ersul4ik@mail.ru>
Date: Thu, 22 Nov 2018 13:13:55 +0600
Subject: [PATCH 04/18] Changed package version for correct

---
 setup.py                 | 2 +-
 swc_registry/__init__.py | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/setup.py b/setup.py
index df1fdc2..28c3702 100644
--- a/setup.py
+++ b/setup.py
@@ -2,7 +2,7 @@
 
 setuptools.setup(
     name="swc-registry",
-    version="1.0",
+    version="0.0.1",
     url="https://github.com/SmartContractSecurity/SWC-registry-python",
     author="SmartContractSecurity",
     author_email="ersul4ik@gmail.com",
diff --git a/swc_registry/__init__.py b/swc_registry/__init__.py
index c2795e7..456450a 100644
--- a/swc_registry/__init__.py
+++ b/swc_registry/__init__.py
@@ -1,5 +1,5 @@
 from swc_registry.get_entry_info import SWC
 
-__version__ = '1.0'
+__version__ = '0.0.1'
 __author__ = 'SmartContractSecurity'
 __all__ = []

From d9209eb248394d0bb985cd1859ac5d779bfa484b Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=AD=D1=80=D0=B8=D0=BA=20=D0=A1=D1=83=D0=BB=D1=82=D0=B0?=
 =?UTF-8?q?=D0=BD=D0=B0=D0=BB=D0=B8=D0=B5=D0=B2?= <ersul4ik@mail.ru>
Date: Thu, 22 Nov 2018 13:29:28 +0600
Subject: [PATCH 05/18] Changed package description

---
 setup.py                 | 4 ++--
 swc_registry/__init__.py | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/setup.py b/setup.py
index 28c3702..0df1ba0 100644
--- a/setup.py
+++ b/setup.py
@@ -2,11 +2,11 @@
 
 setuptools.setup(
     name="swc-registry",
-    version="0.0.1",
+    version="0.0.2",
     url="https://github.com/SmartContractSecurity/SWC-registry-python",
     author="SmartContractSecurity",
     author_email="ersul4ik@gmail.com",
-    description="An package to get the required swc definition fields.",
+    description="Python library for accessing SWC-registry content.",
     long_description=open('README.rst').read(),
     packages=['swc_registry'],
     include_package_data = True,
diff --git a/swc_registry/__init__.py b/swc_registry/__init__.py
index 456450a..9e08e51 100644
--- a/swc_registry/__init__.py
+++ b/swc_registry/__init__.py
@@ -1,5 +1,5 @@
 from swc_registry.get_entry_info import SWC
 
-__version__ = '0.0.1'
+__version__ = '0.0.2'
 __author__ = 'SmartContractSecurity'
 __all__ = []

From f13a532a7e7e03b37e2fb9906fbf351189970626 Mon Sep 17 00:00:00 2001
From: Erik Sultanaliev <ersul4ik@mail.ru>
Date: Tue, 27 Nov 2018 17:56:23 +0600
Subject: [PATCH 06/18] Added condition of checking object for existence. (#17)

* Added the condition for checking object exists
* Created SWCDoesNotExist class
* Changed default value of the current_entry variables
---
 swc_registry/get_entry_info.py | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/swc_registry/get_entry_info.py b/swc_registry/get_entry_info.py
index b4641c5..5afb6a7 100644
--- a/swc_registry/get_entry_info.py
+++ b/swc_registry/get_entry_info.py
@@ -3,6 +3,10 @@
 import json
 
 
+class SWCDoesNotExist(Exception):
+    pass
+
+
 class Singleton(type):
     _instances = {}
 
@@ -64,7 +68,9 @@ def _swc_content(self):
     @property
     def _content(self):
         entries = self._swc_content
-        current_entry = entries.get(self.swc_id, {})
+        current_entry = entries.get(self.swc_id)
+        if not current_entry:
+            raise SWCDoesNotExist('SWC does not exist')
         content = current_entry.get('content', {})
         return content
 

From 8cf15181a6e4411239630abd9cbdc636c84b2efd Mon Sep 17 00:00:00 2001
From: Dominik Muhs <dmuhs@protonmail.ch>
Date: Tue, 27 Nov 2018 17:45:13 +0100
Subject: [PATCH 07/18] Format registry json

---
 swc_registry/swc-definition.json | 264 ++++++++++++++++++++++++++++++-
 1 file changed, 263 insertions(+), 1 deletion(-)

diff --git a/swc_registry/swc-definition.json b/swc_registry/swc-definition.json
index b571f28..d3158e5 100644
--- a/swc_registry/swc-definition.json
+++ b/swc_registry/swc-definition.json
@@ -1 +1,263 @@
-{"SWC-100": {"markdown": "# Title \nFunction Default Visibility\n\n## Relationships \n[CWE-710: Improper Adherence to Coding Standards](https://cwe.mitre.org/data/definitions/710.html)\n\n## Description \n\nFunctions that do not have a function visibility type specified are `public` by default. This can lead to a vulnerability if a developer forgot to set the visibility and a malicious user is able to make unauthorized or unintended state changes.     \n\n## Remediation\n\nFunctions can be specified as being `external`, `public`, `internal` or `private`. It is recommended to make a conscious decision on which visibility type is appropriate for a function. This can dramatically reduce the attack surface of a contract system. \n\n## References \n- [Ethereum Smart Contract Best Practices - Explicitly mark visibility in functions and state variables](https://consensys.github.io/smart-contract-best-practices/recommendations/#explicitly-mark-visibility-in-functions-and-state-variables)\n- [SigmaPrime - Visibility](https://github.com/sigp/solidity-security-blog#visibility)\n\n", "content": {"Title": "Function Default Visibility", "Relationships": "[CWE-710: Improper Adherence to Coding Standards](https://cwe.mitre.org/data/definitions/710.html)", "Description": "Functions that do not have a function visibility type specified are `public` by default. This can lead to a vulnerability if a developer forgot to set the visibility and a malicious user is able to make unauthorized or unintended state changes.", "Remediation": "Functions can be specified as being `external`, `public`, `internal` or `private`. It is recommended to make a conscious decision on which visibility type is appropriate for a function. This can dramatically reduce the attack surface of a contract system."}}, "SWC-101": {"markdown": "# Title \nInteger Overflow and Underflow\n\n## Relationships\n[CWE-682: Incorrect Calculation](https://cwe.mitre.org/data/definitions/682.html) \n\n## Description \n\nAn overflow/underflow happens when an arithmetic operation reaches the maximum or minimum size of a type. For instance if a number is stored in the uint8 type, it means that the number is stored in a 8 bits unsigned number ranging from 0 to 2^8-1. In computer programming, an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of bits \u2013 either larger than the maximum or lower than the minimum representable value.\n\n## Remediation\n\nIt is recommended to use vetted safe math libraries for arithmetic operations consistently throughout the smart contract system.\n\n## References \n- [Ethereum Smart Contract Best Practices - Integer Overflow and Underflow](https://consensys.github.io/smart-contract-best-practices/known_attacks/#integer-overflow-and-underflow)\n", "content": {"Title": "Integer Overflow and Underflow", "Relationships": "[CWE-682: Incorrect Calculation](https://cwe.mitre.org/data/definitions/682.html)", "Description": "An overflow/underflow happens when an arithmetic operation reaches the maximum or minimum size of a type. For instance if a number is stored in the uint8 type, it means that the number is stored in a 8 bits unsigned number ranging from 0 to 2^8-1. In computer programming, an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of bits \u2013 either larger than the maximum or lower than the minimum representable value.", "Remediation": "It is recommended to use vetted safe math libraries for arithmetic operations consistently throughout the smart contract system."}}, "SWC-102": {"markdown": "# Title \nOutdated Compiler Version\n\n## Relationships\n[CWE-937: Using Components with Known Vulnerabilities](http://cwe.mitre.org/data/definitions/937.html)\n\n## Description \n\nUsing an outdated compiler version can be problematic especially if there are publicly disclosed bugs and issues that affect the current compiler version.\n\n## Remediation\n\nIt is recommended to use a recent version of the Solidity compiler.  \n\n## References \n- [Solidity Release Notes](https://github.com/ethereum/solidity/releases)\n- [Etherscan Solidity Bug Info](https://etherscan.io/solcbuginfo)\n", "content": {"Title": "Outdated Compiler Version", "Relationships": "[CWE-937: Using Components with Known Vulnerabilities](http://cwe.mitre.org/data/definitions/937.html)", "Description": "Using an outdated compiler version can be problematic especially if there are publicly disclosed bugs and issues that affect the current compiler version.", "Remediation": "It is recommended to use a recent version of the Solidity compiler."}}, "SWC-103": {"markdown": "# Title \nFloating Pragma \n\n## Relationships\n[CWE-664: Improper Control of a Resource Through its Lifetime](https://cwe.mitre.org/data/definitions/664.html)\n\n## Description \n\nContracts should be deployed with the same compiler version and flags that they have been tested with thoroughly. Locking the pragma helps to ensure that contracts do not accidentally get deployed using, for example, an outdated compiler version that might introduce bugs that affect the contract system negatively.\n\n## Remediation\n\nLock the pragma version and also consider known bugs (https://github.com/ethereum/solidity/releases) for the compiler version that is chosen. \n\nPragma statements can be allowed to float when a contract is intended for consumption by other developers, as in the case with contracts in a library or EthPM package. Otherwise, the developer would need to manually update the pragma in order to compile locally.\n\n## References \n- [Ethereum Smart Contract Best Practices - Lock pragmas to specific compiler version](https://consensys.github.io/smart-contract-best-practices/recommendations/#lock-pragmas-to-specific-compiler-version)\n\n\n", "content": {"Title": "Floating Pragma", "Relationships": "[CWE-664: Improper Control of a Resource Through its Lifetime](https://cwe.mitre.org/data/definitions/664.html)", "Description": "Contracts should be deployed with the same compiler version and flags that they have been tested with thoroughly. Locking the pragma helps to ensure that contracts do not accidentally get deployed using, for example, an outdated compiler version that might introduce bugs that affect the contract system negatively.", "Remediation": "Lock the pragma version and also consider known bugs (https://github.com/ethereum/solidity/releases) for the compiler version that is chosen. \n\n\nPragma statements can be allowed to float when a contract is intended for consumption by other developers, as in the case with contracts in a library or EthPM package. Otherwise, the developer would need to manually update the pragma in order to compile locally."}}, "SWC-104": {"markdown": "# Title \nUnchecked Call Return Value\n\n## Relationships\n[CWE-252: Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html)\n\n## Description \n\nThe return value of a message call is not checked. Execution will resume even if the called contract throws an exception. If the call fails accidentally or an attacker forces the call to fail, this may cause unexpected behaviour in the subsequent program logic.\n\n## Remediation\n\nIf you choose to use low-level call methods, make sure to handle the possibility that the call will fail by checking the return value.\n\n## References \n- [Ethereum Smart Contract Best Practices - Handle errors in external calls](https://consensys.github.io/smart-contract-best-practices/recommendations/#handle-errors-in-external-calls)\n", "content": {"Title": "Unchecked Call Return Value", "Relationships": "[CWE-252: Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html)", "Description": "The return value of a message call is not checked. Execution will resume even if the called contract throws an exception. If the call fails accidentally or an attacker forces the call to fail, this may cause unexpected behaviour in the subsequent program logic.", "Remediation": "If you choose to use low-level call methods, make sure to handle the possibility that the call will fail by checking the return value."}}, "SWC-105": {"markdown": "# Title \nUnprotected Ether Withdrawal\n\n## Relationships\n[CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html)\n\n## Description \n\nDue to missing or insufficient access controls, malicious parties can withdraw some or all Ether from the contract account.\n\nThis bug is sometimes caused by unintentionally exposing initialization functions. By wrongly naming a function intended to be a constructor, the constructor code ends up in the runtime byte code and can be called by anyone to re-initialize the contract.\n\n## Remediation\n\nImplement controls so withdrawals can only be triggered by authorized parties or according to the specs of the smart contract system.\n\n## References \n\n- [Rubixi smart contract](https://etherscan.io/address/0xe82719202e5965Cf5D9B6673B7503a3b92DE20be#code)\n", "content": {"Title": "Unprotected Ether Withdrawal", "Relationships": "[CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html)", "Description": "Due to missing or insufficient access controls, malicious parties can withdraw some or all Ether from the contract account.\n\n\nThis bug is sometimes caused by unintentionally exposing initialization functions. By wrongly naming a function intended to be a constructor, the constructor code ends up in the runtime byte code and can be called by anyone to re-initialize the contract.", "Remediation": "Implement controls so withdrawals can only be triggered by authorized parties or according to the specs of the smart contract system."}}, "SWC-106": {"markdown": "# Title \nUnprotected SELFDESTRUCT Instruction\n\n## Relationships\n[CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html)\n\n## Description \n\nDue to missing or insufficient access controls, malicious parties can self-destruct the contract.\n\n## Remediation\n\nConsider removing the self-destruct functionality unless it is absolutely required. If there is a valid use-case, it is recommended to implement a multisig scheme so that multiple parties must approve the self-destruct action.\n\n## References \n- [Parity \"I accidentally killed it\" bug](https://www.parity.io/a-postmortem-on-the-parity-multi-sig-library-self-destruct/)\n", "content": {"Title": "Unprotected SELFDESTRUCT Instruction", "Relationships": "[CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html)", "Description": "Due to missing or insufficient access controls, malicious parties can self-destruct the contract.", "Remediation": "Consider removing the self-destruct functionality unless it is absolutely required. If there is a valid use-case, it is recommended to implement a multisig scheme so that multiple parties must approve the self-destruct action."}}, "SWC-107": {"markdown": "# Title \nReentrancy\n\n## Relationships\n[CWE-841: Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html)\n\n## Description\n\nOne of the major dangers of calling external contracts is that they can take over the control flow. In the reentrancy attack (a.k.a. recursive call attack), a malicious contract calls back into the calling contract before the first invocation of the function is finished. This may cause the different invocations of the function to interact in undesirable ways.\n\n## Remediation\n\nThe best practices to avoid Reentrancy weaknesses are: \n\n- Use `transfer()` instead of `contract.call()` to transfer Ether to untrusted addresses. \n- When using low-level calls, make sure all internal state changes are performed before the call is executed.\n\n## References \n\n- [Ethereum Smart Contract Best Practices - Reentrancy](https://consensys.github.io/smart-contract-best-practices/known_attacks/#reentrancy)\n", "content": {"Title": "Reentrancy", "Relationships": "[CWE-841: Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html)", "Description": "One of the major dangers of calling external contracts is that they can take over the control flow. In the reentrancy attack (a.k.a. recursive call attack), a malicious contract calls back into the calling contract before the first invocation of the function is finished. This may cause the different invocations of the function to interact in undesirable ways.", "Remediation": "The best practices to avoid Reentrancy weaknesses are: \n\n\n- Use `transfer()` instead of `contract.call()` to transfer Ether to untrusted addresses. \n- When using low-level calls, make sure all internal state changes are performed before the call is executed."}}, "SWC-108": {"markdown": "# Title \nState Variable Default Visibility \n\n## Relationships\n[CWE-710: Improper Adherence to Coding Standards](https://cwe.mitre.org/data/definitions/710.html)\n\n## Description \n\nLabeling the visibility explicitly makes it easier to catch incorrect assumptions about who can access the variable.\n\n## Remediation\n\nVariables can be specified as being `public`, `internal` or `private`. Explicitly define visibility for all state variables.\n\n## References \n- [Ethereum Smart Contract Best Practices - Explicitly mark visibility in functions and state variables](https://consensys.github.io/smart-contract-best-practices/recommendations/#explicitly-mark-visibility-in-functions-and-state-variables)\n", "content": {"Title": "State Variable Default Visibility", "Relationships": "[CWE-710: Improper Adherence to Coding Standards](https://cwe.mitre.org/data/definitions/710.html)", "Description": "Labeling the visibility explicitly makes it easier to catch incorrect assumptions about who can access the variable.", "Remediation": "Variables can be specified as being `public`, `internal` or `private`. Explicitly define visibility for all state variables."}}, "SWC-109": {"markdown": "# Title \nUninitialized Storage Pointer\n\n## Relationships\n[CWE-824: Access of Uninitialized Pointer](https://cwe.mitre.org/data/definitions/824.html)\n\n## Description \nUninitialized local storage variables can point to other unexpected storage variables in the contract, leading to intentional or unintentional vulnerabilities.\n\n## Remediation\nIt is recommended to explicitly specify the data location `memory` or `storage` when dealing with complex types to ensure they behave as expected.\n\n## References \n- [SigmaPrime - Unintialised Storage Pointers](https://github.com/sigp/solidity-security-blog#unintialised-storage-pointers-1)", "content": {"Title": "Uninitialized Storage Pointer", "Relationships": "[CWE-824: Access of Uninitialized Pointer](https://cwe.mitre.org/data/definitions/824.html)", "Description": "Uninitialized local storage variables can point to other unexpected storage variables in the contract, leading to intentional or unintentional vulnerabilities.", "Remediation": "It is recommended to explicitly specify the data location `memory` or `storage` when dealing with complex types to ensure they behave as expected."}}, "SWC-110": {"markdown": "# Title \nAssert Violation\n\n## Relationships\n\n[CWE-670: Always-Incorrect Control Flow Implementation](https://cwe.mitre.org/data/definitions/670.html)\n\n## Description \n\nThe Solidity `assert()` function is meant to assert invariants. Properly functioning code should *never* reach a failing assert statement. A reachable assertion can mean one of two things:\n\n1. A bug exists in the contract that allows it to enter an invalid state;\n2. The `assert` statement is used incorrectly, e.g. to validate inputs.\n\n## Remediation\n\nConsider whether the condition checked in the `assert()` is actually an invariant. If not, replace the `assert()` statement with a `require()` statement.\n\nIf the exception is indeed caused by unexpected behaviour of the code, fix the underlying bug(s) that allow the assertion to be violated.\n\n## References\n\n- [The use of revert(), assert(), and require() in Solidity, and the new REVERT opcode in the EVM](https://media.consensys.net/when-to-use-revert-assert-and-require-in-solidity-61fb2c0e5a57)\n", "content": {"Title": "Assert Violation", "Relationships": "[CWE-670: Always-Incorrect Control Flow Implementation](https://cwe.mitre.org/data/definitions/670.html)", "Description": "The Solidity `assert()` function is meant to assert invariants. Properly functioning code should *never* reach a failing assert statement. A reachable assertion can mean one of two things:\n\n\n1. A bug exists in the contract that allows it to enter an invalid state;\n1. The `assert` statement is used incorrectly, e.g. to validate inputs.", "Remediation": "Consider whether the condition checked in the `assert()` is actually an invariant. If not, replace the `assert()` statement with a `require()` statement.\n\n\nIf the exception is indeed caused by unexpected behaviour of the code, fix the underlying bug(s) that allow the assertion to be violated."}}, "SWC-111": {"markdown": "# Title \nUse of Deprecated Solidity Functions\n\n## Relationships\n[CWE-477: Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html)\n\n## Description \n\nSeveral functions and operators in Solidity are deprecated. Using them leads to reduced code quality. With new major versions of the Solidity compiler, deprecated functions and operators may result in side effects and compile errors.\n\n## Remediation\n\nSolidity provides alternatives to the deprecated constructions. Most of them are aliases, thus replacing old constructions will not break current behavior. For example, `sha3` can be replaced with `keccak256`.\n\n| Deprecated              | Alternative             |\n|-------------------------|-------------------------|\n| `suicide(address)`      | `selfdestruct(address)` |\n| `block.blockhash(uint)` | `blockhash(uint)`       |\n| `sha3(...)`             | `keccak256(...)`        |\n| `callcode(...)`         | `delegatecall(...)`     |\n| `throw`                 | `revert()`              |\n| `msg.gas`               | `gasleft`               |\n| `constant`              | `view`                  |\n\n## References \n\n* [List of global variables and functions, as of Solidity 0.4.25](https://solidity.readthedocs.io/en/v0.4.25/miscellaneous.html#global-variables)\n* [Error handling: Assert, Require, Revert and Exceptions](https://solidity.readthedocs.io/en/v0.4.25/control-structures.html#error-handling-assert-require-revert-and-exceptions)\n* [View functions](https://solidity.readthedocs.io/en/v0.4.25/contracts.html#view-functions)\n* [Solidity compiler changelog](https://github.com/ethereum/solidity/releases)\n", "content": {"Title": "Use of Deprecated Solidity Functions", "Relationships": "[CWE-477: Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html)", "Description": "Several functions and operators in Solidity are deprecated. Using them leads to reduced code quality. With new major versions of the Solidity compiler, deprecated functions and operators may result in side effects and compile errors.", "Remediation": "Solidity provides alternatives to the deprecated constructions. Most of them are aliases, thus replacing old constructions will not break current behavior. For example, `sha3` can be replaced with `keccak256`.\n\n\n| Deprecated | Alternative | \n|: ---------:| ---------:| \n| `suicide(address)` | `selfdestruct(address)` | \n| `block.blockhash(uint)` | `blockhash(uint)` | \n| `sha3(...)` | `keccak256(...)` | \n| `callcode(...)` | `delegatecall(...)` | \n| `throw` | `revert()` | \n| `msg.gas` | `gasleft` | \n| `constant` | `view` |"}}, "SWC-112": {"markdown": "# Title \nDelegatecall to Untrusted Callee\n\n## Relationships\n[CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)\n\n## Description \n\nThere exists a special variant of a message call, named `delegatecall` which is identical to a message call apart from the fact that the code at the target address is executed in the context of the calling contract and `msg.sender` and `msg.value` do not change their values. This allows a smart contract to dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract.\n\nCalling into untrusted contracts is very dangerous, as the code at the target address can change any storage values of the caller and has full control over the caller's balance.\n\n## Remediation\n\nUse `delegatecall` with caution and make sure to never call into untrusted contracts. If the target address is derived from user input ensure to check it against a whitelist of trusted contracts.\n\n## References\n\n- [Solidity Documentation - Delegatecall / Callcode and Libraries](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)\n- [How to Secure Your Smart Contracts: 6 Solidity Vulnerabilities and how to avoid them (Part 1) - Delegate Call](https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d)\n- [Solidity Security: Comprehensive list of known attack vectors and common anti-patterns - Delegatecall](https://blog.sigmaprime.io/solidity-security.html#delegatecall)\n", "content": {"Title": "Delegatecall to Untrusted Callee", "Relationships": "[CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)", "Description": "There exists a special variant of a message call, named `delegatecall` which is identical to a message call apart from the fact that the code at the target address is executed in the context of the calling contract and `msg.sender` and `msg.value` do not change their values. This allows a smart contract to dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract.\n\n\nCalling into untrusted contracts is very dangerous, as the code at the target address can change any storage values of the caller and has full control over the caller's balance.", "Remediation": "Use `delegatecall` with caution and make sure to never call into untrusted contracts. If the target address is derived from user input ensure to check it against a whitelist of trusted contracts."}}, "SWC-113": {"markdown": "# Title \n\nDoS with Failed Call \n\n## Relationships\n\n[CWE-703: Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html)\n\n## Description \n\nExternal calls can fail accidentally or deliberately, which can cause a DoS condition in the contract. To minimize the damage caused by such failures, it is better to isolate each external call into its own transaction that can be initiated by the recipient of the call. This is especially relevant for payments, where it is better to let users withdraw funds rather than push funds to them automatically (this also reduces the chance of problems with the gas limit).\n\n## Remediation\n\nIt is recommended to follow call best practices:\n\n- Avoid combining multiple calls in a single transaction, especially when calls are executed as part of a loop\n- Always assume that external calls can fail\n- Implement the contract logic to handle failed calls\n\n## References\n\n- [ConsenSys Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/recommendations/#favor-pull-over-push-for-external-calls)\n", "content": {"Title": "DoS with Failed Call", "Relationships": "[CWE-703: Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html)", "Description": "External calls can fail accidentally or deliberately, which can cause a DoS condition in the contract. To minimize the damage caused by such failures, it is better to isolate each external call into its own transaction that can be initiated by the recipient of the call. This is especially relevant for payments, where it is better to let users withdraw funds rather than push funds to them automatically (this also reduces the chance of problems with the gas limit).", "Remediation": "It is recommended to follow call best practices:\n\n\n- Avoid combining multiple calls in a single transaction, especially when calls are executed as part of a loop\n- Always assume that external calls can fail\n- Implement the contract logic to handle failed calls"}}, "SWC-114": {"markdown": "# Title\nTransaction Order Dependence\n\n## Relationships\n[CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html)\n\n## Description\nThe Ethereum network processes transactions in blocks with new blocks getting confirmed around every 17 seconds. The miners look at transactions they have received and select which transactions to include in a block, based who has paid a high enough gas price to be included. Additionally, when transactions are sent to the Ethereum network they are forwarded to each node for processing. Thus, a person who is running an Ethereum node can tell which transactions are going to occur before they are finalized.A race condition vulnerability occurs when code depends on the order of the transactions submitted to it.\n\nThe simplest example of a race condition is when a smart contract give a reward for submitting information. Say a contract will give out 1 token to the first person who solves a math problem. Alice solves the problem and submits the answer to the network with a standard gas price. Eve runs an Ethereum node and can see the answer to the math problem in the transaction that Alice submitted to the network. So Eve submits the answer to the network with a much higher gas price and thus it gets processed and committed before Alice's transaction. Eve receives one token and Alice gets nothing, even though it was Alice who worked to solve the problem. A common way this occurs in practice is when a contract rewards people for calling out bad behavior in a protocol by giving a bad actor's deposit to the person who proved they were misbehaving.\n\nThe race condition that happens the most on the network today is the race condition in the ERC20 token standard. The ERC20 token standard includes a function called 'approve' which allows an address to approve another address to spend tokens on their behalf. Assume that Alice has approved Eve to spend n of her tokens, then Alice decides to change Eve's approval to m tokens. Alice submits a function call to approve with the value n for Eve. Eve runs a Ethereum node so knows that Alice is going to change her approval to m. Eve then submits a tranferFrom request sending n of Alice's tokens to herself, but gives it a much higher gas price than Alice's transaction. The transferFrom executes first so gives Eve n tokens and sets Eve's approval to zero. Then Alice's transaction executes and sets Eve's approval to m. Eve then sends those m tokens to herself as well. Thus Eve gets n + m tokens even thought she should have gotten at most max(n,m).\n\n## Remediation\nA possible way to remedy for race conditions in submission of information in exchange for a reward is called a commit reveal hash scheme. Instead of submitting the answer the party who has the answer submits hash(salt, address, answer) [salt being some number of their choosing] the contract stores this hash and the sender's address. To claim the reward the sender then submits a transaction with the salt, and answer. The contract hashes (salt, msg.sender, answer) and checks the hash produced against the stored hash, if the hash matches the contract releases the reward.\n\nThe best fix for the ERC20 race condition is to add a field to the inputs of approve which is the expected current value and to have approve revert if Eve's current allowance is not what Alice indicated she was expecting. However this means that your contract no longer conforms to the ERC20 standard. If it important to your project to have the contract conform to ERC20, you can add a safe approve function. From the user perspective it is possible to mediate the ERC20 race condition by setting approvals to zero before changing them.\n\n## References\n[General Article on Race Conditions](https://medium.com/coinmonks/solidity-transaction-ordering-attacks-1193a014884e)\n[ERC20 Race Condition](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#)\n", "content": {"Title": "Transaction Order Dependence", "Relationships": "[CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html)", "Description": "The Ethereum network processes transactions in blocks with new blocks getting confirmed around every 17 seconds. The miners look at transactions they have received and select which transactions to include in a block, based who has paid a high enough gas price to be included. Additionally, when transactions are sent to the Ethereum network they are forwarded to each node for processing. Thus, a person who is running an Ethereum node can tell which transactions are going to occur before they are finalized.A race condition vulnerability occurs when code depends on the order of the transactions submitted to it.\n\n\nThe simplest example of a race condition is when a smart contract give a reward for submitting information. Say a contract will give out 1 token to the first person who solves a math problem. Alice solves the problem and submits the answer to the network with a standard gas price. Eve runs an Ethereum node and can see the answer to the math problem in the transaction that Alice submitted to the network. So Eve submits the answer to the network with a much higher gas price and thus it gets processed and committed before Alice's transaction. Eve receives one token and Alice gets nothing, even though it was Alice who worked to solve the problem. A common way this occurs in practice is when a contract rewards people for calling out bad behavior in a protocol by giving a bad actor's deposit to the person who proved they were misbehaving.\n\n\nThe race condition that happens the most on the network today is the race condition in the ERC20 token standard. The ERC20 token standard includes a function called 'approve' which allows an address to approve another address to spend tokens on their behalf. Assume that Alice has approved Eve to spend n of her tokens, then Alice decides to change Eve's approval to m tokens. Alice submits a function call to approve with the value n for Eve. Eve runs a Ethereum node so knows that Alice is going to change her approval to m. Eve then submits a tranferFrom request sending n of Alice's tokens to herself, but gives it a much higher gas price than Alice's transaction. The transferFrom executes first so gives Eve n tokens and sets Eve's approval to zero. Then Alice's transaction executes and sets Eve's approval to m. Eve then sends those m tokens to herself as well. Thus Eve gets n + m tokens even thought she should have gotten at most max(n,m).", "Remediation": "A possible way to remedy for race conditions in submission of information in exchange for a reward is called a commit reveal hash scheme. Instead of submitting the answer the party who has the answer submits hash(salt, address, answer) [salt being some number of their choosing] the contract stores this hash and the sender's address. To claim the reward the sender then submits a transaction with the salt, and answer. The contract hashes (salt, msg.sender, answer) and checks the hash produced against the stored hash, if the hash matches the contract releases the reward.\n\n\nThe best fix for the ERC20 race condition is to add a field to the inputs of approve which is the expected current value and to have approve revert if Eve's current allowance is not what Alice indicated she was expecting. However this means that your contract no longer conforms to the ERC20 standard. If it important to your project to have the contract conform to ERC20, you can add a safe approve function. From the user perspective it is possible to mediate the ERC20 race condition by setting approvals to zero before changing them."}}, "SWC-115": {"markdown": "# Title \nAuthorization through tx.origin\n\n## Relationships\n[CWE-477: Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html)\n\n## Description \n`tx.origin` is a global variable in Solidity which returns the address of the account that sent the transaction. Using the variable for authorization could make a contract vulnerable if an authorized account calls into a malicious contract. A call could be made to the vulnerable contract that passes the authorization check since `tx.origin` returns the original sender of the transaction which in this case is the authorized account.\n\n## Remediation\n\n`tx.origin` should not be used for authorization. Use `msg.sender` instead.\n\n## References\n- [Solidity Documentation - tx.origin](https://solidity.readthedocs.io/en/develop/security-considerations.html#tx-origin)\n- [Ethereum Smart Contract Best Practices - Avoid using tx.origin](https://consensys.github.io/smart-contract-best-practices/recommendations/#avoid-using-txorigin)\n- [SigmaPrime - Visibility](https://github.com/sigp/solidity-security-blog#tx-origin)\n", "content": {"Title": "Authorization through tx.origin", "Relationships": "[CWE-477: Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html)", "Description": "`tx.origin` is a global variable in Solidity which returns the address of the account that sent the transaction. Using the variable for authorization could make a contract vulnerable if an authorized account calls into a malicious contract. A call could be made to the vulnerable contract that passes the authorization check since `tx.origin` returns the original sender of the transaction which in this case is the authorized account.", "Remediation": "`tx.origin` should not be used for authorization. Use `msg.sender` instead."}}, "SWC-116": {"markdown": "# Title \nTimestamp Dependence\n\n## Relationships\n[CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)\n\n## Description \n\nContracts often need access to the current timestamp to trigger time-dependent events. As Ethereum is decentralized, nodes can synchronize time only to some degree. Moreover, malicious miners can alter the timestamp of their blocks, especially if they can gain advantages by doing so. However, miners can't set timestamp smaller than the previous one (otherwise the block will be rejected), nor can they set the timestamp too far ahead in the future. Taking all of the above into consideration, developers can't rely on the preciseness of the provided timestamp.\n\n## Remediation\n\nDevelopers should write smart contracts with the notion that block timestamp and real timestamp may vary up to half a minute. Alternatively, they can use block number or external source of timestamp via oracles.\n\n## References\n\n* [Safety: Timestamp dependence](https://github.com/ethereum/wiki/wiki/Safety#timestamp-dependence)\n* [Ethereum Smart Contract Best Practices - Timestamp Dependence](https://consensys.github.io/smart-contract-best-practices/recommendations/#timestamp-dependence)\n* [How do Ethereum mining nodes maintain a time consistent with the network?](https://ethereum.stackexchange.com/questions/5924/how-do-ethereum-mining-nodes-maintain-a-time-consistent-with-the-network/5926#5926)\n* [Solidity: Timestamp dependency, is it possible to do safely?](https://ethereum.stackexchange.com/questions/15047/solidity-timestamp-dependency-is-it-possible-to-do-safely)\n", "content": {"Title": "Timestamp Dependence", "Relationships": "[CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)", "Description": "Contracts often need access to the current timestamp to trigger time-dependent events. As Ethereum is decentralized, nodes can synchronize time only to some degree. Moreover, malicious miners can alter the timestamp of their blocks, especially if they can gain advantages by doing so. However, miners can't set timestamp smaller than the previous one (otherwise the block will be rejected), nor can they set the timestamp too far ahead in the future. Taking all of the above into consideration, developers can't rely on the preciseness of the provided timestamp.", "Remediation": "Developers should write smart contracts with the notion that block timestamp and real timestamp may vary up to half a minute. Alternatively, they can use block number or external source of timestamp via oracles."}}, "SWC-117": {"markdown": "# Title\nSignature Malleability\n\n## Relationships\n[CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)\n\n## Description\n\nThe implementation of a cryptographic signature system in Ethereum contracts often assumes that the signature is unique, but signatures can be altered without the possession of the private key and still be valid. The EVM specification defines several so-called \u2018precompiled\u2019 contracts one of them being `ecrecover` which executes the elliptic curve public key recovery. A malicious user can slightly modify the three values _v_, _r_ and _s_ to create other valid signatures. A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages.  \n\n## Remediation\n\nA signature should never be included into a signed message hash to check if previously messages have been processed by the contract. \n\n## References\n[Bitcoin Transaction Malleability](https://eklitzke.org/bitcoin-transaction-malleability)\n[CTF - Challenge](https://ropsten.etherscan.io/address/0x0daabce0a1261b582e0d949ebca9dff4c22c88ef#code)\n", "content": {"Title": "Signature Malleability", "Relationships": "[CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)", "Description": "The implementation of a cryptographic signature system in Ethereum contracts often assumes that the signature is unique, but signatures can be altered without the possession of the private key and still be valid. The EVM specification defines several so-called \u2018precompiled\u2019 contracts one of them being `ecrecover` which executes the elliptic curve public key recovery. A malicious user can slightly modify the three values _v_, _r_ and _s_ to create other valid signatures. A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages.", "Remediation": "A signature should never be included into a signed message hash to check if previously messages have been processed by the contract."}}, "SWC-118": {"markdown": "# Title \nIncorrect Constructor Name \n\n## Relationships\n[CWE-665: Improper Initialization](http://cwe.mitre.org/data/definitions/665.html)\n\n## Description \nConstructors are special functions that are called only once during the contract creation. They often perform critical, privileged actions such as setting the owner of the contract. Before Solidity version 0.4.22, the only way of defining a constructor was to create a function with the same name as the contract class containing it. A function meant to become a constructor becomes a normal, callable function if its name doesn't exactly match the contract name.\nThis behavior sometimes leads to security issues, in particular when smart contract code is re-used with a different name but the name of the constructor function is not changed accordingly. \n\n## Remediation\n\nSolidity version 0.4.22 introduces a new `constructor` keyword that make a constructor definitions clearer. It is therefore recommended to upgrade the contract to a recent version of the Solidity compiler and change to the new constructor declaration. \n\n## References\n\n- [SigmaPrime - Constructors with Care](https://blog.sigmaprime.io/solidity-security.html#constructors)\n", "content": {"Title": "Incorrect Constructor Name", "Relationships": "[CWE-665: Improper Initialization](http://cwe.mitre.org/data/definitions/665.html)", "Description": "Constructors are special functions that are called only once during the contract creation. They often perform critical, privileged actions such as setting the owner of the contract. Before Solidity version 0.4.22, the only way of defining a constructor was to create a function with the same name as the contract class containing it. A function meant to become a constructor becomes a normal, callable function if its name doesn't exactly match the contract name.\nThis behavior sometimes leads to security issues, in particular when smart contract code is re-used with a different name but the name of the constructor function is not changed accordingly.", "Remediation": "Solidity version 0.4.22 introduces a new `constructor` keyword that make a constructor definitions clearer. It is therefore recommended to upgrade the contract to a recent version of the Solidity compiler and change to the new constructor declaration."}}, "SWC-119": {"markdown": "# Title \nShadowing State Variables\n\n## Relationships\n[CWE-710: Improper Adherence to Coding Standards](http://cwe.mitre.org/data/definitions/710.html)\n\n## Description \n\nSolidity allows for ambiguous naming of state variables when inheritance is used. Contract `A` with a variable `x` could inherit contract `B` that also has a state variable `x` defined. This would result in two separate versions of `x`, one of them being accessed from contract `A` and the other one from contract `B`. In more complex contract systems this condition could go unnoticed and subsequently lead to security issues. \n\nShadowing state variables can also occur within a single contract when there are multiple definitions on the contract and function level. \n\n## Remediation\n\nReview storage variable layouts for your contract systems carefully and remove any ambiguities. Always check for compiler warnings as they can flag the issue within a single contract.\n\n## References\n- [Issue on Solidity's Github - Shadowing of inherited state variables should be an error (override keyword)](https://github.com/ethereum/solidity/issues/2563)\n- [Issue on Solidity's Github - Warn about shadowing state variables](https://github.com/ethereum/solidity/issues/973)\n", "content": {"Title": "Shadowing State Variables", "Relationships": "[CWE-710: Improper Adherence to Coding Standards](http://cwe.mitre.org/data/definitions/710.html)", "Description": "Solidity allows for ambiguous naming of state variables when inheritance is used. Contract `A` with a variable `x` could inherit contract `B` that also has a state variable `x` defined. This would result in two separate versions of `x`, one of them being accessed from contract `A` and the other one from contract `B`. In more complex contract systems this condition could go unnoticed and subsequently lead to security issues. \n\n\nShadowing state variables can also occur within a single contract when there are multiple definitions on the contract and function level.", "Remediation": "Review storage variable layouts for your contract systems carefully and remove any ambiguities. Always check for compiler warnings as they can flag the issue within a single contract."}}, "SWC-120": {"markdown": "# Title \nWeak Sources of Randomness from Chain Attributes\n\n## Relationships\n[CWE-330: Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html)\n\n## Description \n\nAbility to generate random numbers is very helpful in all kinds of applications. One obvious example is gambling DApps, where pseudo-random number generator is used to pick the winner. However, creating a strong enough source of randomness in Ethereum is very challenging. For example, use of `block.timestamp` is insecure, as a miner can choose to provide any timestamp within a few seconds and still get his block accepted by others. Use of `blockhash`, `block.difficulty` and other fields is also insecure, as they're controlled by the miner. If the stakes are high, the miner can mine lots of blocks in a short time by renting hardware, pick the block that has required block hash for him to win, and drop all others.\n\n## Remediation\n\n* Using [commitment scheme](https://en.wikipedia.org/wiki/Commitment_scheme), e.g. [RANDAO](https://github.com/randao/randao).\n* Using external sources of randomness via oracles, e.g. [Oraclize](http://www.oraclize.it/). Note that this approach requires trusting in oracle, thus it may be reasonable to use multiple oracles.\n* Using Bitcoin block hashes, as they are more expensive to mine.\n\n## References\n\n* [How can I securely generate a random number in my smart contract?](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)\n* [When can BLOCKHASH be safely used for a random number? When would it be unsafe?](https://ethereum.stackexchange.com/questions/419/when-can-blockhash-be-safely-used-for-a-random-number-when-would-it-be-unsafe)\n* [The Run smart contract](https://etherscan.io/address/0xcac337492149bdb66b088bf5914bedfbf78ccc18)\n", "content": {"Title": "Weak Sources of Randomness from Chain Attributes", "Relationships": "[CWE-330: Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html)", "Description": "Ability to generate random numbers is very helpful in all kinds of applications. One obvious example is gambling DApps, where pseudo-random number generator is used to pick the winner. However, creating a strong enough source of randomness in Ethereum is very challenging. For example, use of `block.timestamp` is insecure, as a miner can choose to provide any timestamp within a few seconds and still get his block accepted by others. Use of `blockhash`, `block.difficulty` and other fields is also insecure, as they're controlled by the miner. If the stakes are high, the miner can mine lots of blocks in a short time by renting hardware, pick the block that has required block hash for him to win, and drop all others.", "Remediation": "- Using [commitment scheme](https://en.wikipedia.org/wiki/Commitment_scheme), e.g. [RANDAO](https://github.com/randao/randao).\n- Using external sources of randomness via oracles, e.g. [Oraclize](http://www.oraclize.it/). Note that this approach requires trusting in oracle, thus it may be reasonable to use multiple oracles.\n- Using Bitcoin block hashes, as they are more expensive to mine."}}, "SWC-121": {"markdown": "# Title \nMissing Protection against Signature Replay Attacks\n\n## Relationships\n[CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)\n\n## Description \n\nIt is sometimes necessary to perform signature verification in smart contracts to achieve better usability or to save gas cost. A secure implementation needs to protect against Signature Replay Attacks by for example keeping track of all processed message hashes and only allowing new message hashes to be processed. A malicious user could attack a contract without such a control and get message hash that was sent by another user processed multiple times. \n\n\n## Remediation\n\nIn order to protect against signature replay attacks consider the following recommendations:\n\n- Store every message hash that has been processed by the smart contract. When new messages are received check against the already existing ones and only proceed with the business logic if it's a new message hash. \n- Include the address of the contract that processes the message. This ensures that the message can only be used in a single contract. \n- Under no circumstances generate the message hash including the signature. The `ecrecover` function is susceptible to signature malleability (see also SWC-117).\n\n## References\n\n- [Medium - Replay Attack Vulnerability in Ethereum Smart Contracts Introduced by transferProxy()](https://medium.com/cypher-core/replay-attack-vulnerability-in-ethereum-smart-contracts-introduced-by-transferproxy-124bf3694e25)\n\n", "content": {"Title": "Missing Protection against Signature Replay Attacks", "Relationships": "[CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)", "Description": "It is sometimes necessary to perform signature verification in smart contracts to achieve better usability or to save gas cost. A secure implementation needs to protect against Signature Replay Attacks by for example keeping track of all processed message hashes and only allowing new message hashes to be processed. A malicious user could attack a contract without such a control and get message hash that was sent by another user processed multiple times.", "Remediation": "In order to protect against signature replay attacks consider the following recommendations:\n\n\n- Store every message hash that has been processed by the smart contract. When new messages are received check against the already existing ones and only proceed with the business logic if it's a new message hash. \n- Include the address of the contract that processes the message. This ensures that the message can only be used in a single contract. \n- Under no circumstances generate the message hash including the signature. The `ecrecover` function is susceptible to signature malleability (see also SWC-117)."}}, "SWC-122": {"markdown": "# Title \nLack of Proper Signature Verification \n\n## Relationships\n[CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)\n\n## Description \n\nMany smart contract systems allow users to sign off-chain messages instead of directly requesting users to do an on-chain transaction. These systems usually assume that the message will be signed by the same address that owns the assets. However, one can hold assets directly in the regular account (controlled by a private key) or in a smart contract that acts as a wallet (e.g. a multisig contract). The current design of many smart contracts prevent contract based accounts from interacting with them, since contracts do not possess private keys and therefore can not directly sign messages. In order to solve the problem implementations that assume the validity of a signed message based on other methods that do not have that barrier. An example of such a method is to use `msg.sender`  and assume if the message originated from the address then it is valid. This can lead to vulnerabilities especially in scenarios where proxies can be used to relay transactions.\n\n## Remediation\n\nIt is not recommended to use alternate verification schemes that do require proper signature verification through `ecrecover()`. \n\n## References\n\n", "content": {"Title": "Lack of Proper Signature Verification", "Relationships": "[CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)", "Description": "Many smart contract systems allow users to sign off-chain messages instead of directly requesting users to do an on-chain transaction. These systems usually assume that the message will be signed by the same address that owns the assets. However, one can hold assets directly in the regular account (controlled by a private key) or in a smart contract that acts as a wallet (e.g. a multisig contract). The current design of many smart contracts prevent contract based accounts from interacting with them, since contracts do not possess private keys and therefore can not directly sign messages. In order to solve the problem implementations that assume the validity of a signed message based on other methods that do not have that barrier. An example of such a method is to use `msg.sender`  and assume if the message originated from the address then it is valid. This can lead to vulnerabilities especially in scenarios where proxies can be used to relay transactions.", "Remediation": "It is not recommended to use alternate verification schemes that do require proper signature verification through `ecrecover()`."}}, "SWC-123": {"markdown": "# Title\nRequirement Violation\n\n## Relationships\n\n[CWE-573: Improper Following of Specification by Caller](https://cwe.mitre.org/data/definitions/573.html)\n\n## Description\n\nThe Solidity `require()` construct is meant to validate external inputs of a function. In most cases, such external inputs are provided by callers, but they may also be returned by callees. In the former case, we refer to them as precondition violations. Violations of a requirement can indicate one of two possible issues:\n\n1. A bug exists in the contract that provided the external input.\n2. The condition used to express the requirement is too strong.\n\n## Remediation\n\nIf the required logical condition is too strong, it should be weakened to allow all valid external inputs.\n\nOtherwise, the bug must be in the contract that provided the external input and one should consider fixing its code by making sure no invalid inputs are provided.\n\n## References\n\n- [The use of revert(), assert(), and require() in Solidity, and the new REVERT opcode in the EVM](https://media.consensys.net/when-to-use-revert-assert-and-require-in-solidity-61fb2c0e5a57)\n", "content": {"Title": "Requirement Violation", "Relationships": "[CWE-573: Improper Following of Specification by Caller](https://cwe.mitre.org/data/definitions/573.html)", "Description": "The Solidity `require()` construct is meant to validate external inputs of a function. In most cases, such external inputs are provided by callers, but they may also be returned by callees. In the former case, we refer to them as precondition violations. Violations of a requirement can indicate one of two possible issues:\n\n\n1. A bug exists in the contract that provided the external input.\n1. The condition used to express the requirement is too strong.", "Remediation": "If the required logical condition is too strong, it should be weakened to allow all valid external inputs.\n\n\nOtherwise, the bug must be in the contract that provided the external input and one should consider fixing its code by making sure no invalid inputs are provided."}}, "SWC-124": {"markdown": "# Title\r\nWrite to Arbitrary Storage Location\r\n\r\n## Relationships\r\n\r\n[CWE-123: Write-what-where Condition](https://cwe.mitre.org/data/definitions/123.html)\r\n\r\n## Description\r\n\r\nA smart contract's data (e.g., storing the owner of the contract) is persistently stored\r\nat some storage location (i.e., a key or address) on the EVM level. The contract is\r\nresponsible for ensuring that only authorized user or contract accounts may write to\r\nsensitive storage locations. If an attacker is able to write to arbitrary storage\r\nlocations of a contract, the authorization checks may easily be circumvented. This can\r\nallow an attacker to corrupt the storage; for instance, by overwriting a field that stores\r\nthe address of the contract owner.\r\n\r\n## Remediation\r\n\r\nAs a general advice, given that all data structures share the same storage (address)\r\nspace, one should make sure that writes to one data structure cannot inadvertently\r\noverwrite entries of another data structure.\r\n\r\n## References\r\n\r\n- [Entry to Underhanded Solidity Coding Contest 2017 (honorable mention)](https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte)\r\n", "content": {"Title": "Write to Arbitrary Storage Location", "Relationships": "[CWE-123: Write-what-where Condition](https://cwe.mitre.org/data/definitions/123.html)", "Description": "A smart contract's data (e.g., storing the owner of the contract) is persistently stored\nat some storage location (i.e., a key or address) on the EVM level. The contract is\nresponsible for ensuring that only authorized user or contract accounts may write to\nsensitive storage locations. If an attacker is able to write to arbitrary storage\nlocations of a contract, the authorization checks may easily be circumvented. This can\nallow an attacker to corrupt the storage; for instance, by overwriting a field that stores\nthe address of the contract owner.", "Remediation": "As a general advice, given that all data structures share the same storage (address)\nspace, one should make sure that writes to one data structure cannot inadvertently\noverwrite entries of another data structure."}}, "SWC-125": {"markdown": "# Title \nIncorrect Inheritance Order\n\n## Relationships\n[CWE-696: Incorrect Behavior Order](https://cwe.mitre.org/data/definitions/696.html)\n\n## Description \nSolidity supports multiple inheritance, meaning that one contract can inherit several contracts. Multiple inheritance introduces ambiguity called [Diamond Problem](https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem): if two or more base contracts define the same function, which one should be called in the child contract? Solidity deals with this ambiguity by using reverse [C3 Linearization](https://en.wikipedia.org/wiki/C3_linearization), which sets a priority between base contracts.\n\nThat way, base contracts have different priorities, so the order of inheritance matters. Neglecting inheritance order can lead to unexpected behavior.\n\n## Remediation\nWhen inheriting multiple contracts, especially if they have identical functions, a developer should carefully specify inheritance in the correct order. The rule of thumb is to inherit contracts from more /general/ to more /specific/.\n\n## References \n* [Smart Contract Best Practices - Multiple Inheritance Caution](https://consensys.github.io/smart-contract-best-practices/recommendations/#multiple-inheritance-caution)\n* [Solidity docs - Multiple Inheritance and Linearization](https://solidity.readthedocs.io/en/v0.4.25/contracts.html#multiple-inheritance-and-linearization)\n* [Solidity anti-patterns: Fun with inheritance DAG abuse](https://pdaian.com/blog/solidity-anti-patterns-fun-with-inheritance-dag-abuse)\n", "content": {"Title": "Incorrect Inheritance Order", "Relationships": "[CWE-696: Incorrect Behavior Order](https://cwe.mitre.org/data/definitions/696.html)", "Description": "Solidity supports multiple inheritance, meaning that one contract can inherit several contracts. Multiple inheritance introduces ambiguity called [Diamond Problem](https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem): if two or more base contracts define the same function, which one should be called in the child contract? Solidity deals with this ambiguity by using reverse [C3 Linearization](https://en.wikipedia.org/wiki/C3_linearization), which sets a priority between base contracts.\n\n\nThat way, base contracts have different priorities, so the order of inheritance matters. Neglecting inheritance order can lead to unexpected behavior.", "Remediation": "When inheriting multiple contracts, especially if they have identical functions, a developer should carefully specify inheritance in the correct order. The rule of thumb is to inherit contracts from more /general/ to more /specific/."}}, "SWC-127": {"markdown": "# Title \nArbitrary Jump with Function Type Variable\n\n## Relationships\n[CWE-695: Use of Low-Level Functionality](https://cwe.mitre.org/data/definitions/695.html)\n\n## Description \nSolidity supports function types. That is, a variable of function type can be assigned with a reference to a function with a matching signature. The function saved to such variable can be called lust like a regular function.\n\nThe problem arises when a user has the ability to arbitrarily change the function type variable and thus execute random code instructions. As Solidity doesn't support pointer arithmetics, it's impossible to change such variable to an arbitrary value. However, if the developer uses assembly instructions, such as `mstore` or assign operator, in the worst case scenario an attacker is able to point a function type variable to any code instruction, violating required validations and required state changes.\n\n## Remediation\nThe use of assembly should be minimal. A developer should not allow a user to assign arbitrary values to function type variables.\n\n## References \n* [Solidity CTF](https://medium.com/authio/solidity-ctf-part-2-safe-execution-ad6ded20e042)\n* [Solidity docs - Solidity Assembly](https://solidity.readthedocs.io/en/v0.4.25/assembly.html)\n* [Solidity docs - Function Types](https://solidity.readthedocs.io/en/v0.4.25/types.html#function-types)\n", "content": {"Title": "Arbitrary Jump with Function Type Variable", "Relationships": "[CWE-695: Use of Low-Level Functionality](https://cwe.mitre.org/data/definitions/695.html)", "Description": "Solidity supports function types. That is, a variable of function type can be assigned with a reference to a function with a matching signature. The function saved to such variable can be called lust like a regular function.\n\n\nThe problem arises when a user has the ability to arbitrarily change the function type variable and thus execute random code instructions. As Solidity doesn't support pointer arithmetics, it's impossible to change such variable to an arbitrary value. However, if the developer uses assembly instructions, such as `mstore` or assign operator, in the worst case scenario an attacker is able to point a function type variable to any code instruction, violating required validations and required state changes.", "Remediation": "The use of assembly should be minimal. A developer should not allow a user to assign arbitrary values to function type variables."}}, "SWC-128": {"markdown": "# Title\nDoS With Block Gas Limit\n\n## Relationships\n[CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)\n\n## Description\n\nWhen smart contracts are deployed or functions inside them are called, the execution of these actions always requires a certain amount of gas, based of how much computation is needed to complete them. The Ethereum network specifies a block gas limit and the sum of all transactions included in a block can not exceed the threshold. \n\nProgramming patterns that are harmless in centralized applications can lead to Denial of Service conditions in smart contracts when the cost of executing a function exceeds the block gas limit. Modifying an array of unknown size, that increases in size over time, can lead to such a Denial of Service condition.\n\n## Remediation\n\nCaution is advised when you expect to have large arrays that grow over time. Actions that require looping across the entire data structure should be avoided.  \n\nIf you absolutely must loop over an array of unknown size, then you should plan for it to potentially take multiple blocks, and therefore require multiple transactions.\n\n## References\n* [Ethereum Design Rationale](https://github.com/ethereum/wiki/wiki/Design-Rationale#gas-and-fees)\n* [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)\n* [Clear Large Array Without Blowing Gas Limit](https://ethereum.stackexchange.com/questions/3373/how-to-clear-large-arrays-without-blowing-the-gas-limit)\n* [GovernMental jackpot payout DoS Gas](https://www.reddit.com/r/ethereum/comments/4ghzhv/governmentals_1100_eth_jackpot_payout_is_stuck/)\n\n", "content": {"Title": "DoS With Block Gas Limit", "Relationships": "[CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)", "Description": "When smart contracts are deployed or functions inside them are called, the execution of these actions always requires a certain amount of gas, based of how much computation is needed to complete them. The Ethereum network specifies a block gas limit and the sum of all transactions included in a block can not exceed the threshold. \n\n\nProgramming patterns that are harmless in centralized applications can lead to Denial of Service conditions in smart contracts when the cost of executing a function exceeds the block gas limit. Modifying an array of unknown size, that increases in size over time, can lead to such a Denial of Service condition.", "Remediation": "Caution is advised when you expect to have large arrays that grow over time. Actions that require looping across the entire data structure should be avoided.  \n\n\nIf you absolutely must loop over an array of unknown size, then you should plan for it to potentially take multiple blocks, and therefore require multiple transactions."}}, "SWC-129": {"markdown": "# Title\nTypographical Error\n\n## Relationships\n[CWE-480: Use of Incorrect Operator](https://cwe.mitre.org/data/definitions/480.html)\n\n## Description\nA typographical error can occur for example when the intent of a defined operation is to sum a number to a variable (+=) but it has accidentally been defined in a wrong way (=+), introducing a typo which happens to be a valid operator. Instead of calculating the sum it initializes the variable again. \n\nThe unary + operator is deprecated in new solidity compiler versions.\n\n## Remediation\nThe weakness can be avoided by performing pre-condition checks on any math operation or using a vetted library for arithmetic calculations such as SafeMath developed by OpenZeppelin.\n\n## References\n* [HackerGold Bug Analysis](https://blog.zeppelin.solutions/hackergold-bug-analysis-68d893cad738)\n* [SafeMath by OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/math/SafeMath.sol)\n* [Disallow Unary plus](https://github.com/ethereum/solidity/issues/1760)\n", "content": {"Title": "Typographical Error", "Relationships": "[CWE-480: Use of Incorrect Operator](https://cwe.mitre.org/data/definitions/480.html)", "Description": "A typographical error can occur for example when the intent of a defined operation is to sum a number to a variable (+=) but it has accidentally been defined in a wrong way (=+), introducing a typo which happens to be a valid operator. Instead of calculating the sum it initializes the variable again. \n\n\nThe unary + operator is deprecated in new solidity compiler versions.", "Remediation": "The weakness can be avoided by performing pre-condition checks on any math operation or using a vetted library for arithmetic calculations such as SafeMath developed by OpenZeppelin."}}}
\ No newline at end of file
+{
+    "SWC-100": {
+        "markdown": "# Title \nFunction Default Visibility\n\n## Relationships \n[CWE-710: Improper Adherence to Coding Standards](https://cwe.mitre.org/data/definitions/710.html)\n\n## Description \n\nFunctions that do not have a function visibility type specified are `public` by default. This can lead to a vulnerability if a developer forgot to set the visibility and a malicious user is able to make unauthorized or unintended state changes.     \n\n## Remediation\n\nFunctions can be specified as being `external`, `public`, `internal` or `private`. It is recommended to make a conscious decision on which visibility type is appropriate for a function. This can dramatically reduce the attack surface of a contract system. \n\n## References \n- [Ethereum Smart Contract Best Practices - Explicitly mark visibility in functions and state variables](https://consensys.github.io/smart-contract-best-practices/recommendations/#explicitly-mark-visibility-in-functions-and-state-variables)\n- [SigmaPrime - Visibility](https://github.com/sigp/solidity-security-blog#visibility)\n\n",
+        "content": {
+            "Title": "Function Default Visibility",
+            "Relationships": "[CWE-710: Improper Adherence to Coding Standards](https://cwe.mitre.org/data/definitions/710.html)",
+            "Description": "Functions that do not have a function visibility type specified are `public` by default. This can lead to a vulnerability if a developer forgot to set the visibility and a malicious user is able to make unauthorized or unintended state changes.",
+            "Remediation": "Functions can be specified as being `external`, `public`, `internal` or `private`. It is recommended to make a conscious decision on which visibility type is appropriate for a function. This can dramatically reduce the attack surface of a contract system."
+        }
+    },
+    "SWC-101": {
+        "markdown": "# Title \nInteger Overflow and Underflow\n\n## Relationships\n[CWE-682: Incorrect Calculation](https://cwe.mitre.org/data/definitions/682.html) \n\n## Description \n\nAn overflow/underflow happens when an arithmetic operation reaches the maximum or minimum size of a type. For instance if a number is stored in the uint8 type, it means that the number is stored in a 8 bits unsigned number ranging from 0 to 2^8-1. In computer programming, an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of bits – either larger than the maximum or lower than the minimum representable value.\n\n## Remediation\n\nIt is recommended to use vetted safe math libraries for arithmetic operations consistently throughout the smart contract system.\n\n## References \n- [Ethereum Smart Contract Best Practices - Integer Overflow and Underflow](https://consensys.github.io/smart-contract-best-practices/known_attacks/#integer-overflow-and-underflow)\n",
+        "content": {
+            "Title": "Integer Overflow and Underflow",
+            "Relationships": "[CWE-682: Incorrect Calculation](https://cwe.mitre.org/data/definitions/682.html)",
+            "Description": "An overflow/underflow happens when an arithmetic operation reaches the maximum or minimum size of a type. For instance if a number is stored in the uint8 type, it means that the number is stored in a 8 bits unsigned number ranging from 0 to 2^8-1. In computer programming, an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of bits – either larger than the maximum or lower than the minimum representable value.",
+            "Remediation": "It is recommended to use vetted safe math libraries for arithmetic operations consistently throughout the smart contract system."
+        }
+    },
+    "SWC-102": {
+        "markdown": "# Title \nOutdated Compiler Version\n\n## Relationships\n[CWE-937: Using Components with Known Vulnerabilities](http://cwe.mitre.org/data/definitions/937.html)\n\n## Description \n\nUsing an outdated compiler version can be problematic especially if there are publicly disclosed bugs and issues that affect the current compiler version.\n\n## Remediation\n\nIt is recommended to use a recent version of the Solidity compiler.  \n\n## References \n- [Solidity Release Notes](https://github.com/ethereum/solidity/releases)\n- [Etherscan Solidity Bug Info](https://etherscan.io/solcbuginfo)\n",
+        "content": {
+            "Title": "Outdated Compiler Version",
+            "Relationships": "[CWE-937: Using Components with Known Vulnerabilities](http://cwe.mitre.org/data/definitions/937.html)",
+            "Description": "Using an outdated compiler version can be problematic especially if there are publicly disclosed bugs and issues that affect the current compiler version.",
+            "Remediation": "It is recommended to use a recent version of the Solidity compiler."
+        }
+    },
+    "SWC-103": {
+        "markdown": "# Title \nFloating Pragma \n\n## Relationships\n[CWE-664: Improper Control of a Resource Through its Lifetime](https://cwe.mitre.org/data/definitions/664.html)\n\n## Description \n\nContracts should be deployed with the same compiler version and flags that they have been tested with thoroughly. Locking the pragma helps to ensure that contracts do not accidentally get deployed using, for example, an outdated compiler version that might introduce bugs that affect the contract system negatively.\n\n## Remediation\n\nLock the pragma version and also consider known bugs (https://github.com/ethereum/solidity/releases) for the compiler version that is chosen. \n\nPragma statements can be allowed to float when a contract is intended for consumption by other developers, as in the case with contracts in a library or EthPM package. Otherwise, the developer would need to manually update the pragma in order to compile locally.\n\n## References \n- [Ethereum Smart Contract Best Practices - Lock pragmas to specific compiler version](https://consensys.github.io/smart-contract-best-practices/recommendations/#lock-pragmas-to-specific-compiler-version)\n\n\n",
+        "content": {
+            "Title": "Floating Pragma",
+            "Relationships": "[CWE-664: Improper Control of a Resource Through its Lifetime](https://cwe.mitre.org/data/definitions/664.html)",
+            "Description": "Contracts should be deployed with the same compiler version and flags that they have been tested with thoroughly. Locking the pragma helps to ensure that contracts do not accidentally get deployed using, for example, an outdated compiler version that might introduce bugs that affect the contract system negatively.",
+            "Remediation": "Lock the pragma version and also consider known bugs (https://github.com/ethereum/solidity/releases) for the compiler version that is chosen. \n\n\nPragma statements can be allowed to float when a contract is intended for consumption by other developers, as in the case with contracts in a library or EthPM package. Otherwise, the developer would need to manually update the pragma in order to compile locally."
+        }
+    },
+    "SWC-104": {
+        "markdown": "# Title \nUnchecked Call Return Value\n\n## Relationships\n[CWE-252: Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html)\n\n## Description \n\nThe return value of a message call is not checked. Execution will resume even if the called contract throws an exception. If the call fails accidentally or an attacker forces the call to fail, this may cause unexpected behaviour in the subsequent program logic.\n\n## Remediation\n\nIf you choose to use low-level call methods, make sure to handle the possibility that the call will fail by checking the return value.\n\n## References \n- [Ethereum Smart Contract Best Practices - Handle errors in external calls](https://consensys.github.io/smart-contract-best-practices/recommendations/#handle-errors-in-external-calls)\n",
+        "content": {
+            "Title": "Unchecked Call Return Value",
+            "Relationships": "[CWE-252: Unchecked Return Value](https://cwe.mitre.org/data/definitions/252.html)",
+            "Description": "The return value of a message call is not checked. Execution will resume even if the called contract throws an exception. If the call fails accidentally or an attacker forces the call to fail, this may cause unexpected behaviour in the subsequent program logic.",
+            "Remediation": "If you choose to use low-level call methods, make sure to handle the possibility that the call will fail by checking the return value."
+        }
+    },
+    "SWC-105": {
+        "markdown": "# Title \nUnprotected Ether Withdrawal\n\n## Relationships\n[CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html)\n\n## Description \n\nDue to missing or insufficient access controls, malicious parties can withdraw some or all Ether from the contract account.\n\nThis bug is sometimes caused by unintentionally exposing initialization functions. By wrongly naming a function intended to be a constructor, the constructor code ends up in the runtime byte code and can be called by anyone to re-initialize the contract.\n\n## Remediation\n\nImplement controls so withdrawals can only be triggered by authorized parties or according to the specs of the smart contract system.\n\n## References \n\n- [Rubixi smart contract](https://etherscan.io/address/0xe82719202e5965Cf5D9B6673B7503a3b92DE20be#code)\n",
+        "content": {
+            "Title": "Unprotected Ether Withdrawal",
+            "Relationships": "[CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html)",
+            "Description": "Due to missing or insufficient access controls, malicious parties can withdraw some or all Ether from the contract account.\n\n\nThis bug is sometimes caused by unintentionally exposing initialization functions. By wrongly naming a function intended to be a constructor, the constructor code ends up in the runtime byte code and can be called by anyone to re-initialize the contract.",
+            "Remediation": "Implement controls so withdrawals can only be triggered by authorized parties or according to the specs of the smart contract system."
+        }
+    },
+    "SWC-106": {
+        "markdown": "# Title \nUnprotected SELFDESTRUCT Instruction\n\n## Relationships\n[CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html)\n\n## Description \n\nDue to missing or insufficient access controls, malicious parties can self-destruct the contract.\n\n## Remediation\n\nConsider removing the self-destruct functionality unless it is absolutely required. If there is a valid use-case, it is recommended to implement a multisig scheme so that multiple parties must approve the self-destruct action.\n\n## References \n- [Parity \"I accidentally killed it\" bug](https://www.parity.io/a-postmortem-on-the-parity-multi-sig-library-self-destruct/)\n",
+        "content": {
+            "Title": "Unprotected SELFDESTRUCT Instruction",
+            "Relationships": "[CWE-284: Improper Access Control](https://cwe.mitre.org/data/definitions/284.html)",
+            "Description": "Due to missing or insufficient access controls, malicious parties can self-destruct the contract.",
+            "Remediation": "Consider removing the self-destruct functionality unless it is absolutely required. If there is a valid use-case, it is recommended to implement a multisig scheme so that multiple parties must approve the self-destruct action."
+        }
+    },
+    "SWC-107": {
+        "markdown": "# Title \nReentrancy\n\n## Relationships\n[CWE-841: Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html)\n\n## Description\n\nOne of the major dangers of calling external contracts is that they can take over the control flow. In the reentrancy attack (a.k.a. recursive call attack), a malicious contract calls back into the calling contract before the first invocation of the function is finished. This may cause the different invocations of the function to interact in undesirable ways.\n\n## Remediation\n\nThe best practices to avoid Reentrancy weaknesses are: \n\n- Use `transfer()` instead of `contract.call()` to transfer Ether to untrusted addresses. \n- When using low-level calls, make sure all internal state changes are performed before the call is executed.\n\n## References \n\n- [Ethereum Smart Contract Best Practices - Reentrancy](https://consensys.github.io/smart-contract-best-practices/known_attacks/#reentrancy)\n",
+        "content": {
+            "Title": "Reentrancy",
+            "Relationships": "[CWE-841: Improper Enforcement of Behavioral Workflow](https://cwe.mitre.org/data/definitions/841.html)",
+            "Description": "One of the major dangers of calling external contracts is that they can take over the control flow. In the reentrancy attack (a.k.a. recursive call attack), a malicious contract calls back into the calling contract before the first invocation of the function is finished. This may cause the different invocations of the function to interact in undesirable ways.",
+            "Remediation": "The best practices to avoid Reentrancy weaknesses are: \n\n\n- Use `transfer()` instead of `contract.call()` to transfer Ether to untrusted addresses. \n- When using low-level calls, make sure all internal state changes are performed before the call is executed."
+        }
+    },
+    "SWC-108": {
+        "markdown": "# Title \nState Variable Default Visibility \n\n## Relationships\n[CWE-710: Improper Adherence to Coding Standards](https://cwe.mitre.org/data/definitions/710.html)\n\n## Description \n\nLabeling the visibility explicitly makes it easier to catch incorrect assumptions about who can access the variable.\n\n## Remediation\n\nVariables can be specified as being `public`, `internal` or `private`. Explicitly define visibility for all state variables.\n\n## References \n- [Ethereum Smart Contract Best Practices - Explicitly mark visibility in functions and state variables](https://consensys.github.io/smart-contract-best-practices/recommendations/#explicitly-mark-visibility-in-functions-and-state-variables)\n",
+        "content": {
+            "Title": "State Variable Default Visibility",
+            "Relationships": "[CWE-710: Improper Adherence to Coding Standards](https://cwe.mitre.org/data/definitions/710.html)",
+            "Description": "Labeling the visibility explicitly makes it easier to catch incorrect assumptions about who can access the variable.",
+            "Remediation": "Variables can be specified as being `public`, `internal` or `private`. Explicitly define visibility for all state variables."
+        }
+    },
+    "SWC-109": {
+        "markdown": "# Title \nUninitialized Storage Pointer\n\n## Relationships\n[CWE-824: Access of Uninitialized Pointer](https://cwe.mitre.org/data/definitions/824.html)\n\n## Description \nUninitialized local storage variables can point to other unexpected storage variables in the contract, leading to intentional or unintentional vulnerabilities.\n\n## Remediation\nIt is recommended to explicitly specify the data location `memory` or `storage` when dealing with complex types to ensure they behave as expected.\n\n## References \n- [SigmaPrime - Unintialised Storage Pointers](https://github.com/sigp/solidity-security-blog#unintialised-storage-pointers-1)",
+        "content": {
+            "Title": "Uninitialized Storage Pointer",
+            "Relationships": "[CWE-824: Access of Uninitialized Pointer](https://cwe.mitre.org/data/definitions/824.html)",
+            "Description": "Uninitialized local storage variables can point to other unexpected storage variables in the contract, leading to intentional or unintentional vulnerabilities.",
+            "Remediation": "It is recommended to explicitly specify the data location `memory` or `storage` when dealing with complex types to ensure they behave as expected."
+        }
+    },
+    "SWC-110": {
+        "markdown": "# Title \nAssert Violation\n\n## Relationships\n\n[CWE-670: Always-Incorrect Control Flow Implementation](https://cwe.mitre.org/data/definitions/670.html)\n\n## Description \n\nThe Solidity `assert()` function is meant to assert invariants. Properly functioning code should *never* reach a failing assert statement. A reachable assertion can mean one of two things:\n\n1. A bug exists in the contract that allows it to enter an invalid state;\n2. The `assert` statement is used incorrectly, e.g. to validate inputs.\n\n## Remediation\n\nConsider whether the condition checked in the `assert()` is actually an invariant. If not, replace the `assert()` statement with a `require()` statement.\n\nIf the exception is indeed caused by unexpected behaviour of the code, fix the underlying bug(s) that allow the assertion to be violated.\n\n## References\n\n- [The use of revert(), assert(), and require() in Solidity, and the new REVERT opcode in the EVM](https://media.consensys.net/when-to-use-revert-assert-and-require-in-solidity-61fb2c0e5a57)\n",
+        "content": {
+            "Title": "Assert Violation",
+            "Relationships": "[CWE-670: Always-Incorrect Control Flow Implementation](https://cwe.mitre.org/data/definitions/670.html)",
+            "Description": "The Solidity `assert()` function is meant to assert invariants. Properly functioning code should *never* reach a failing assert statement. A reachable assertion can mean one of two things:\n\n\n1. A bug exists in the contract that allows it to enter an invalid state;\n1. The `assert` statement is used incorrectly, e.g. to validate inputs.",
+            "Remediation": "Consider whether the condition checked in the `assert()` is actually an invariant. If not, replace the `assert()` statement with a `require()` statement.\n\n\nIf the exception is indeed caused by unexpected behaviour of the code, fix the underlying bug(s) that allow the assertion to be violated."
+        }
+    },
+    "SWC-111": {
+        "markdown": "# Title \nUse of Deprecated Solidity Functions\n\n## Relationships\n[CWE-477: Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html)\n\n## Description \n\nSeveral functions and operators in Solidity are deprecated. Using them leads to reduced code quality. With new major versions of the Solidity compiler, deprecated functions and operators may result in side effects and compile errors.\n\n## Remediation\n\nSolidity provides alternatives to the deprecated constructions. Most of them are aliases, thus replacing old constructions will not break current behavior. For example, `sha3` can be replaced with `keccak256`.\n\n| Deprecated              | Alternative             |\n|-------------------------|-------------------------|\n| `suicide(address)`      | `selfdestruct(address)` |\n| `block.blockhash(uint)` | `blockhash(uint)`       |\n| `sha3(...)`             | `keccak256(...)`        |\n| `callcode(...)`         | `delegatecall(...)`     |\n| `throw`                 | `revert()`              |\n| `msg.gas`               | `gasleft`               |\n| `constant`              | `view`                  |\n\n## References \n\n* [List of global variables and functions, as of Solidity 0.4.25](https://solidity.readthedocs.io/en/v0.4.25/miscellaneous.html#global-variables)\n* [Error handling: Assert, Require, Revert and Exceptions](https://solidity.readthedocs.io/en/v0.4.25/control-structures.html#error-handling-assert-require-revert-and-exceptions)\n* [View functions](https://solidity.readthedocs.io/en/v0.4.25/contracts.html#view-functions)\n* [Solidity compiler changelog](https://github.com/ethereum/solidity/releases)\n",
+        "content": {
+            "Title": "Use of Deprecated Solidity Functions",
+            "Relationships": "[CWE-477: Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html)",
+            "Description": "Several functions and operators in Solidity are deprecated. Using them leads to reduced code quality. With new major versions of the Solidity compiler, deprecated functions and operators may result in side effects and compile errors.",
+            "Remediation": "Solidity provides alternatives to the deprecated constructions. Most of them are aliases, thus replacing old constructions will not break current behavior. For example, `sha3` can be replaced with `keccak256`.\n\n\n| Deprecated | Alternative | \n|: ---------:| ---------:| \n| `suicide(address)` | `selfdestruct(address)` | \n| `block.blockhash(uint)` | `blockhash(uint)` | \n| `sha3(...)` | `keccak256(...)` | \n| `callcode(...)` | `delegatecall(...)` | \n| `throw` | `revert()` | \n| `msg.gas` | `gasleft` | \n| `constant` | `view` |"
+        }
+    },
+    "SWC-112": {
+        "markdown": "# Title \nDelegatecall to Untrusted Callee\n\n## Relationships\n[CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)\n\n## Description \n\nThere exists a special variant of a message call, named `delegatecall` which is identical to a message call apart from the fact that the code at the target address is executed in the context of the calling contract and `msg.sender` and `msg.value` do not change their values. This allows a smart contract to dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract.\n\nCalling into untrusted contracts is very dangerous, as the code at the target address can change any storage values of the caller and has full control over the caller's balance.\n\n## Remediation\n\nUse `delegatecall` with caution and make sure to never call into untrusted contracts. If the target address is derived from user input ensure to check it against a whitelist of trusted contracts.\n\n## References\n\n- [Solidity Documentation - Delegatecall / Callcode and Libraries](https://solidity.readthedocs.io/en/latest/introduction-to-smart-contracts.html#delegatecall-callcode-and-libraries)\n- [How to Secure Your Smart Contracts: 6 Solidity Vulnerabilities and how to avoid them (Part 1) - Delegate Call](https://medium.com/loom-network/how-to-secure-your-smart-contracts-6-solidity-vulnerabilities-and-how-to-avoid-them-part-1-c33048d4d17d)\n- [Solidity Security: Comprehensive list of known attack vectors and common anti-patterns - Delegatecall](https://blog.sigmaprime.io/solidity-security.html#delegatecall)\n",
+        "content": {
+            "Title": "Delegatecall to Untrusted Callee",
+            "Relationships": "[CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)",
+            "Description": "There exists a special variant of a message call, named `delegatecall` which is identical to a message call apart from the fact that the code at the target address is executed in the context of the calling contract and `msg.sender` and `msg.value` do not change their values. This allows a smart contract to dynamically load code from a different address at runtime. Storage, current address and balance still refer to the calling contract.\n\n\nCalling into untrusted contracts is very dangerous, as the code at the target address can change any storage values of the caller and has full control over the caller's balance.",
+            "Remediation": "Use `delegatecall` with caution and make sure to never call into untrusted contracts. If the target address is derived from user input ensure to check it against a whitelist of trusted contracts."
+        }
+    },
+    "SWC-113": {
+        "markdown": "# Title \n\nDoS with Failed Call \n\n## Relationships\n\n[CWE-703: Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html)\n\n## Description \n\nExternal calls can fail accidentally or deliberately, which can cause a DoS condition in the contract. To minimize the damage caused by such failures, it is better to isolate each external call into its own transaction that can be initiated by the recipient of the call. This is especially relevant for payments, where it is better to let users withdraw funds rather than push funds to them automatically (this also reduces the chance of problems with the gas limit).\n\n## Remediation\n\nIt is recommended to follow call best practices:\n\n- Avoid combining multiple calls in a single transaction, especially when calls are executed as part of a loop\n- Always assume that external calls can fail\n- Implement the contract logic to handle failed calls\n\n## References\n\n- [ConsenSys Smart Contract Best Practices](https://consensys.github.io/smart-contract-best-practices/recommendations/#favor-pull-over-push-for-external-calls)\n",
+        "content": {
+            "Title": "DoS with Failed Call",
+            "Relationships": "[CWE-703: Improper Check or Handling of Exceptional Conditions](https://cwe.mitre.org/data/definitions/703.html)",
+            "Description": "External calls can fail accidentally or deliberately, which can cause a DoS condition in the contract. To minimize the damage caused by such failures, it is better to isolate each external call into its own transaction that can be initiated by the recipient of the call. This is especially relevant for payments, where it is better to let users withdraw funds rather than push funds to them automatically (this also reduces the chance of problems with the gas limit).",
+            "Remediation": "It is recommended to follow call best practices:\n\n\n- Avoid combining multiple calls in a single transaction, especially when calls are executed as part of a loop\n- Always assume that external calls can fail\n- Implement the contract logic to handle failed calls"
+        }
+    },
+    "SWC-114": {
+        "markdown": "# Title\nTransaction Order Dependence\n\n## Relationships\n[CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html)\n\n## Description\nThe Ethereum network processes transactions in blocks with new blocks getting confirmed around every 17 seconds. The miners look at transactions they have received and select which transactions to include in a block, based who has paid a high enough gas price to be included. Additionally, when transactions are sent to the Ethereum network they are forwarded to each node for processing. Thus, a person who is running an Ethereum node can tell which transactions are going to occur before they are finalized.A race condition vulnerability occurs when code depends on the order of the transactions submitted to it.\n\nThe simplest example of a race condition is when a smart contract give a reward for submitting information. Say a contract will give out 1 token to the first person who solves a math problem. Alice solves the problem and submits the answer to the network with a standard gas price. Eve runs an Ethereum node and can see the answer to the math problem in the transaction that Alice submitted to the network. So Eve submits the answer to the network with a much higher gas price and thus it gets processed and committed before Alice's transaction. Eve receives one token and Alice gets nothing, even though it was Alice who worked to solve the problem. A common way this occurs in practice is when a contract rewards people for calling out bad behavior in a protocol by giving a bad actor's deposit to the person who proved they were misbehaving.\n\nThe race condition that happens the most on the network today is the race condition in the ERC20 token standard. The ERC20 token standard includes a function called 'approve' which allows an address to approve another address to spend tokens on their behalf. Assume that Alice has approved Eve to spend n of her tokens, then Alice decides to change Eve's approval to m tokens. Alice submits a function call to approve with the value n for Eve. Eve runs a Ethereum node so knows that Alice is going to change her approval to m. Eve then submits a tranferFrom request sending n of Alice's tokens to herself, but gives it a much higher gas price than Alice's transaction. The transferFrom executes first so gives Eve n tokens and sets Eve's approval to zero. Then Alice's transaction executes and sets Eve's approval to m. Eve then sends those m tokens to herself as well. Thus Eve gets n + m tokens even thought she should have gotten at most max(n,m).\n\n## Remediation\nA possible way to remedy for race conditions in submission of information in exchange for a reward is called a commit reveal hash scheme. Instead of submitting the answer the party who has the answer submits hash(salt, address, answer) [salt being some number of their choosing] the contract stores this hash and the sender's address. To claim the reward the sender then submits a transaction with the salt, and answer. The contract hashes (salt, msg.sender, answer) and checks the hash produced against the stored hash, if the hash matches the contract releases the reward.\n\nThe best fix for the ERC20 race condition is to add a field to the inputs of approve which is the expected current value and to have approve revert if Eve's current allowance is not what Alice indicated she was expecting. However this means that your contract no longer conforms to the ERC20 standard. If it important to your project to have the contract conform to ERC20, you can add a safe approve function. From the user perspective it is possible to mediate the ERC20 race condition by setting approvals to zero before changing them.\n\n## References\n[General Article on Race Conditions](https://medium.com/coinmonks/solidity-transaction-ordering-attacks-1193a014884e)\n[ERC20 Race Condition](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#)\n",
+        "content": {
+            "Title": "Transaction Order Dependence",
+            "Relationships": "[CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')](https://cwe.mitre.org/data/definitions/362.html)",
+            "Description": "The Ethereum network processes transactions in blocks with new blocks getting confirmed around every 17 seconds. The miners look at transactions they have received and select which transactions to include in a block, based who has paid a high enough gas price to be included. Additionally, when transactions are sent to the Ethereum network they are forwarded to each node for processing. Thus, a person who is running an Ethereum node can tell which transactions are going to occur before they are finalized.A race condition vulnerability occurs when code depends on the order of the transactions submitted to it.\n\n\nThe simplest example of a race condition is when a smart contract give a reward for submitting information. Say a contract will give out 1 token to the first person who solves a math problem. Alice solves the problem and submits the answer to the network with a standard gas price. Eve runs an Ethereum node and can see the answer to the math problem in the transaction that Alice submitted to the network. So Eve submits the answer to the network with a much higher gas price and thus it gets processed and committed before Alice's transaction. Eve receives one token and Alice gets nothing, even though it was Alice who worked to solve the problem. A common way this occurs in practice is when a contract rewards people for calling out bad behavior in a protocol by giving a bad actor's deposit to the person who proved they were misbehaving.\n\n\nThe race condition that happens the most on the network today is the race condition in the ERC20 token standard. The ERC20 token standard includes a function called 'approve' which allows an address to approve another address to spend tokens on their behalf. Assume that Alice has approved Eve to spend n of her tokens, then Alice decides to change Eve's approval to m tokens. Alice submits a function call to approve with the value n for Eve. Eve runs a Ethereum node so knows that Alice is going to change her approval to m. Eve then submits a tranferFrom request sending n of Alice's tokens to herself, but gives it a much higher gas price than Alice's transaction. The transferFrom executes first so gives Eve n tokens and sets Eve's approval to zero. Then Alice's transaction executes and sets Eve's approval to m. Eve then sends those m tokens to herself as well. Thus Eve gets n + m tokens even thought she should have gotten at most max(n,m).",
+            "Remediation": "A possible way to remedy for race conditions in submission of information in exchange for a reward is called a commit reveal hash scheme. Instead of submitting the answer the party who has the answer submits hash(salt, address, answer) [salt being some number of their choosing] the contract stores this hash and the sender's address. To claim the reward the sender then submits a transaction with the salt, and answer. The contract hashes (salt, msg.sender, answer) and checks the hash produced against the stored hash, if the hash matches the contract releases the reward.\n\n\nThe best fix for the ERC20 race condition is to add a field to the inputs of approve which is the expected current value and to have approve revert if Eve's current allowance is not what Alice indicated she was expecting. However this means that your contract no longer conforms to the ERC20 standard. If it important to your project to have the contract conform to ERC20, you can add a safe approve function. From the user perspective it is possible to mediate the ERC20 race condition by setting approvals to zero before changing them."
+        }
+    },
+    "SWC-115": {
+        "markdown": "# Title \nAuthorization through tx.origin\n\n## Relationships\n[CWE-477: Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html)\n\n## Description \n`tx.origin` is a global variable in Solidity which returns the address of the account that sent the transaction. Using the variable for authorization could make a contract vulnerable if an authorized account calls into a malicious contract. A call could be made to the vulnerable contract that passes the authorization check since `tx.origin` returns the original sender of the transaction which in this case is the authorized account.\n\n## Remediation\n\n`tx.origin` should not be used for authorization. Use `msg.sender` instead.\n\n## References\n- [Solidity Documentation - tx.origin](https://solidity.readthedocs.io/en/develop/security-considerations.html#tx-origin)\n- [Ethereum Smart Contract Best Practices - Avoid using tx.origin](https://consensys.github.io/smart-contract-best-practices/recommendations/#avoid-using-txorigin)\n- [SigmaPrime - Visibility](https://github.com/sigp/solidity-security-blog#tx-origin)\n",
+        "content": {
+            "Title": "Authorization through tx.origin",
+            "Relationships": "[CWE-477: Use of Obsolete Function](https://cwe.mitre.org/data/definitions/477.html)",
+            "Description": "`tx.origin` is a global variable in Solidity which returns the address of the account that sent the transaction. Using the variable for authorization could make a contract vulnerable if an authorized account calls into a malicious contract. A call could be made to the vulnerable contract that passes the authorization check since `tx.origin` returns the original sender of the transaction which in this case is the authorized account.",
+            "Remediation": "`tx.origin` should not be used for authorization. Use `msg.sender` instead."
+        }
+    },
+    "SWC-116": {
+        "markdown": "# Title \nTimestamp Dependence\n\n## Relationships\n[CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)\n\n## Description \n\nContracts often need access to the current timestamp to trigger time-dependent events. As Ethereum is decentralized, nodes can synchronize time only to some degree. Moreover, malicious miners can alter the timestamp of their blocks, especially if they can gain advantages by doing so. However, miners can't set timestamp smaller than the previous one (otherwise the block will be rejected), nor can they set the timestamp too far ahead in the future. Taking all of the above into consideration, developers can't rely on the preciseness of the provided timestamp.\n\n## Remediation\n\nDevelopers should write smart contracts with the notion that block timestamp and real timestamp may vary up to half a minute. Alternatively, they can use block number or external source of timestamp via oracles.\n\n## References\n\n* [Safety: Timestamp dependence](https://github.com/ethereum/wiki/wiki/Safety#timestamp-dependence)\n* [Ethereum Smart Contract Best Practices - Timestamp Dependence](https://consensys.github.io/smart-contract-best-practices/recommendations/#timestamp-dependence)\n* [How do Ethereum mining nodes maintain a time consistent with the network?](https://ethereum.stackexchange.com/questions/5924/how-do-ethereum-mining-nodes-maintain-a-time-consistent-with-the-network/5926#5926)\n* [Solidity: Timestamp dependency, is it possible to do safely?](https://ethereum.stackexchange.com/questions/15047/solidity-timestamp-dependency-is-it-possible-to-do-safely)\n",
+        "content": {
+            "Title": "Timestamp Dependence",
+            "Relationships": "[CWE-829: Inclusion of Functionality from Untrusted Control Sphere](https://cwe.mitre.org/data/definitions/829.html)",
+            "Description": "Contracts often need access to the current timestamp to trigger time-dependent events. As Ethereum is decentralized, nodes can synchronize time only to some degree. Moreover, malicious miners can alter the timestamp of their blocks, especially if they can gain advantages by doing so. However, miners can't set timestamp smaller than the previous one (otherwise the block will be rejected), nor can they set the timestamp too far ahead in the future. Taking all of the above into consideration, developers can't rely on the preciseness of the provided timestamp.",
+            "Remediation": "Developers should write smart contracts with the notion that block timestamp and real timestamp may vary up to half a minute. Alternatively, they can use block number or external source of timestamp via oracles."
+        }
+    },
+    "SWC-117": {
+        "markdown": "# Title\nSignature Malleability\n\n## Relationships\n[CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)\n\n## Description\n\nThe implementation of a cryptographic signature system in Ethereum contracts often assumes that the signature is unique, but signatures can be altered without the possession of the private key and still be valid. The EVM specification defines several so-called ‘precompiled’ contracts one of them being `ecrecover` which executes the elliptic curve public key recovery. A malicious user can slightly modify the three values _v_, _r_ and _s_ to create other valid signatures. A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages.  \n\n## Remediation\n\nA signature should never be included into a signed message hash to check if previously messages have been processed by the contract. \n\n## References\n[Bitcoin Transaction Malleability](https://eklitzke.org/bitcoin-transaction-malleability)\n[CTF - Challenge](https://ropsten.etherscan.io/address/0x0daabce0a1261b582e0d949ebca9dff4c22c88ef#code)\n",
+        "content": {
+            "Title": "Signature Malleability",
+            "Relationships": "[CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)",
+            "Description": "The implementation of a cryptographic signature system in Ethereum contracts often assumes that the signature is unique, but signatures can be altered without the possession of the private key and still be valid. The EVM specification defines several so-called ‘precompiled’ contracts one of them being `ecrecover` which executes the elliptic curve public key recovery. A malicious user can slightly modify the three values _v_, _r_ and _s_ to create other valid signatures. A system that performs signature verification on contract level might be susceptible to attacks if the signature is part of the signed message hash. Valid signatures could be created by a malicious user to replay previously signed messages.",
+            "Remediation": "A signature should never be included into a signed message hash to check if previously messages have been processed by the contract."
+        }
+    },
+    "SWC-118": {
+        "markdown": "# Title \nIncorrect Constructor Name \n\n## Relationships\n[CWE-665: Improper Initialization](http://cwe.mitre.org/data/definitions/665.html)\n\n## Description \nConstructors are special functions that are called only once during the contract creation. They often perform critical, privileged actions such as setting the owner of the contract. Before Solidity version 0.4.22, the only way of defining a constructor was to create a function with the same name as the contract class containing it. A function meant to become a constructor becomes a normal, callable function if its name doesn't exactly match the contract name.\nThis behavior sometimes leads to security issues, in particular when smart contract code is re-used with a different name but the name of the constructor function is not changed accordingly. \n\n## Remediation\n\nSolidity version 0.4.22 introduces a new `constructor` keyword that make a constructor definitions clearer. It is therefore recommended to upgrade the contract to a recent version of the Solidity compiler and change to the new constructor declaration. \n\n## References\n\n- [SigmaPrime - Constructors with Care](https://blog.sigmaprime.io/solidity-security.html#constructors)\n",
+        "content": {
+            "Title": "Incorrect Constructor Name",
+            "Relationships": "[CWE-665: Improper Initialization](http://cwe.mitre.org/data/definitions/665.html)",
+            "Description": "Constructors are special functions that are called only once during the contract creation. They often perform critical, privileged actions such as setting the owner of the contract. Before Solidity version 0.4.22, the only way of defining a constructor was to create a function with the same name as the contract class containing it. A function meant to become a constructor becomes a normal, callable function if its name doesn't exactly match the contract name.\nThis behavior sometimes leads to security issues, in particular when smart contract code is re-used with a different name but the name of the constructor function is not changed accordingly.",
+            "Remediation": "Solidity version 0.4.22 introduces a new `constructor` keyword that make a constructor definitions clearer. It is therefore recommended to upgrade the contract to a recent version of the Solidity compiler and change to the new constructor declaration."
+        }
+    },
+    "SWC-119": {
+        "markdown": "# Title \nShadowing State Variables\n\n## Relationships\n[CWE-710: Improper Adherence to Coding Standards](http://cwe.mitre.org/data/definitions/710.html)\n\n## Description \n\nSolidity allows for ambiguous naming of state variables when inheritance is used. Contract `A` with a variable `x` could inherit contract `B` that also has a state variable `x` defined. This would result in two separate versions of `x`, one of them being accessed from contract `A` and the other one from contract `B`. In more complex contract systems this condition could go unnoticed and subsequently lead to security issues. \n\nShadowing state variables can also occur within a single contract when there are multiple definitions on the contract and function level. \n\n## Remediation\n\nReview storage variable layouts for your contract systems carefully and remove any ambiguities. Always check for compiler warnings as they can flag the issue within a single contract.\n\n## References\n- [Issue on Solidity's Github - Shadowing of inherited state variables should be an error (override keyword)](https://github.com/ethereum/solidity/issues/2563)\n- [Issue on Solidity's Github - Warn about shadowing state variables](https://github.com/ethereum/solidity/issues/973)\n",
+        "content": {
+            "Title": "Shadowing State Variables",
+            "Relationships": "[CWE-710: Improper Adherence to Coding Standards](http://cwe.mitre.org/data/definitions/710.html)",
+            "Description": "Solidity allows for ambiguous naming of state variables when inheritance is used. Contract `A` with a variable `x` could inherit contract `B` that also has a state variable `x` defined. This would result in two separate versions of `x`, one of them being accessed from contract `A` and the other one from contract `B`. In more complex contract systems this condition could go unnoticed and subsequently lead to security issues. \n\n\nShadowing state variables can also occur within a single contract when there are multiple definitions on the contract and function level.",
+            "Remediation": "Review storage variable layouts for your contract systems carefully and remove any ambiguities. Always check for compiler warnings as they can flag the issue within a single contract."
+        }
+    },
+    "SWC-120": {
+        "markdown": "# Title \nWeak Sources of Randomness from Chain Attributes\n\n## Relationships\n[CWE-330: Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html)\n\n## Description \n\nAbility to generate random numbers is very helpful in all kinds of applications. One obvious example is gambling DApps, where pseudo-random number generator is used to pick the winner. However, creating a strong enough source of randomness in Ethereum is very challenging. For example, use of `block.timestamp` is insecure, as a miner can choose to provide any timestamp within a few seconds and still get his block accepted by others. Use of `blockhash`, `block.difficulty` and other fields is also insecure, as they're controlled by the miner. If the stakes are high, the miner can mine lots of blocks in a short time by renting hardware, pick the block that has required block hash for him to win, and drop all others.\n\n## Remediation\n\n* Using [commitment scheme](https://en.wikipedia.org/wiki/Commitment_scheme), e.g. [RANDAO](https://github.com/randao/randao).\n* Using external sources of randomness via oracles, e.g. [Oraclize](http://www.oraclize.it/). Note that this approach requires trusting in oracle, thus it may be reasonable to use multiple oracles.\n* Using Bitcoin block hashes, as they are more expensive to mine.\n\n## References\n\n* [How can I securely generate a random number in my smart contract?](https://ethereum.stackexchange.com/questions/191/how-can-i-securely-generate-a-random-number-in-my-smart-contract)\n* [When can BLOCKHASH be safely used for a random number? When would it be unsafe?](https://ethereum.stackexchange.com/questions/419/when-can-blockhash-be-safely-used-for-a-random-number-when-would-it-be-unsafe)\n* [The Run smart contract](https://etherscan.io/address/0xcac337492149bdb66b088bf5914bedfbf78ccc18)\n",
+        "content": {
+            "Title": "Weak Sources of Randomness from Chain Attributes",
+            "Relationships": "[CWE-330: Use of Insufficiently Random Values](https://cwe.mitre.org/data/definitions/330.html)",
+            "Description": "Ability to generate random numbers is very helpful in all kinds of applications. One obvious example is gambling DApps, where pseudo-random number generator is used to pick the winner. However, creating a strong enough source of randomness in Ethereum is very challenging. For example, use of `block.timestamp` is insecure, as a miner can choose to provide any timestamp within a few seconds and still get his block accepted by others. Use of `blockhash`, `block.difficulty` and other fields is also insecure, as they're controlled by the miner. If the stakes are high, the miner can mine lots of blocks in a short time by renting hardware, pick the block that has required block hash for him to win, and drop all others.",
+            "Remediation": "- Using [commitment scheme](https://en.wikipedia.org/wiki/Commitment_scheme), e.g. [RANDAO](https://github.com/randao/randao).\n- Using external sources of randomness via oracles, e.g. [Oraclize](http://www.oraclize.it/). Note that this approach requires trusting in oracle, thus it may be reasonable to use multiple oracles.\n- Using Bitcoin block hashes, as they are more expensive to mine."
+        }
+    },
+    "SWC-121": {
+        "markdown": "# Title \nMissing Protection against Signature Replay Attacks\n\n## Relationships\n[CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)\n\n## Description \n\nIt is sometimes necessary to perform signature verification in smart contracts to achieve better usability or to save gas cost. A secure implementation needs to protect against Signature Replay Attacks by for example keeping track of all processed message hashes and only allowing new message hashes to be processed. A malicious user could attack a contract without such a control and get message hash that was sent by another user processed multiple times. \n\n\n## Remediation\n\nIn order to protect against signature replay attacks consider the following recommendations:\n\n- Store every message hash that has been processed by the smart contract. When new messages are received check against the already existing ones and only proceed with the business logic if it's a new message hash. \n- Include the address of the contract that processes the message. This ensures that the message can only be used in a single contract. \n- Under no circumstances generate the message hash including the signature. The `ecrecover` function is susceptible to signature malleability (see also SWC-117).\n\n## References\n\n- [Medium - Replay Attack Vulnerability in Ethereum Smart Contracts Introduced by transferProxy()](https://medium.com/cypher-core/replay-attack-vulnerability-in-ethereum-smart-contracts-introduced-by-transferproxy-124bf3694e25)\n\n",
+        "content": {
+            "Title": "Missing Protection against Signature Replay Attacks",
+            "Relationships": "[CWE-347: Improper Verification of Cryptographic Signature](https://cwe.mitre.org/data/definitions/347.html)",
+            "Description": "It is sometimes necessary to perform signature verification in smart contracts to achieve better usability or to save gas cost. A secure implementation needs to protect against Signature Replay Attacks by for example keeping track of all processed message hashes and only allowing new message hashes to be processed. A malicious user could attack a contract without such a control and get message hash that was sent by another user processed multiple times.",
+            "Remediation": "In order to protect against signature replay attacks consider the following recommendations:\n\n\n- Store every message hash that has been processed by the smart contract. When new messages are received check against the already existing ones and only proceed with the business logic if it's a new message hash. \n- Include the address of the contract that processes the message. This ensures that the message can only be used in a single contract. \n- Under no circumstances generate the message hash including the signature. The `ecrecover` function is susceptible to signature malleability (see also SWC-117)."
+        }
+    },
+    "SWC-122": {
+        "markdown": "# Title \nLack of Proper Signature Verification \n\n## Relationships\n[CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)\n\n## Description \n\nMany smart contract systems allow users to sign off-chain messages instead of directly requesting users to do an on-chain transaction. These systems usually assume that the message will be signed by the same address that owns the assets. However, one can hold assets directly in the regular account (controlled by a private key) or in a smart contract that acts as a wallet (e.g. a multisig contract). The current design of many smart contracts prevent contract based accounts from interacting with them, since contracts do not possess private keys and therefore can not directly sign messages. In order to solve the problem implementations that assume the validity of a signed message based on other methods that do not have that barrier. An example of such a method is to use `msg.sender`  and assume if the message originated from the address then it is valid. This can lead to vulnerabilities especially in scenarios where proxies can be used to relay transactions.\n\n## Remediation\n\nIt is not recommended to use alternate verification schemes that do require proper signature verification through `ecrecover()`. \n\n## References\n\n",
+        "content": {
+            "Title": "Lack of Proper Signature Verification",
+            "Relationships": "[CWE-345: Insufficient Verification of Data Authenticity](https://cwe.mitre.org/data/definitions/345.html)",
+            "Description": "Many smart contract systems allow users to sign off-chain messages instead of directly requesting users to do an on-chain transaction. These systems usually assume that the message will be signed by the same address that owns the assets. However, one can hold assets directly in the regular account (controlled by a private key) or in a smart contract that acts as a wallet (e.g. a multisig contract). The current design of many smart contracts prevent contract based accounts from interacting with them, since contracts do not possess private keys and therefore can not directly sign messages. In order to solve the problem implementations that assume the validity of a signed message based on other methods that do not have that barrier. An example of such a method is to use `msg.sender`  and assume if the message originated from the address then it is valid. This can lead to vulnerabilities especially in scenarios where proxies can be used to relay transactions.",
+            "Remediation": "It is not recommended to use alternate verification schemes that do require proper signature verification through `ecrecover()`."
+        }
+    },
+    "SWC-123": {
+        "markdown": "# Title\nRequirement Violation\n\n## Relationships\n\n[CWE-573: Improper Following of Specification by Caller](https://cwe.mitre.org/data/definitions/573.html)\n\n## Description\n\nThe Solidity `require()` construct is meant to validate external inputs of a function. In most cases, such external inputs are provided by callers, but they may also be returned by callees. In the former case, we refer to them as precondition violations. Violations of a requirement can indicate one of two possible issues:\n\n1. A bug exists in the contract that provided the external input.\n2. The condition used to express the requirement is too strong.\n\n## Remediation\n\nIf the required logical condition is too strong, it should be weakened to allow all valid external inputs.\n\nOtherwise, the bug must be in the contract that provided the external input and one should consider fixing its code by making sure no invalid inputs are provided.\n\n## References\n\n- [The use of revert(), assert(), and require() in Solidity, and the new REVERT opcode in the EVM](https://media.consensys.net/when-to-use-revert-assert-and-require-in-solidity-61fb2c0e5a57)\n",
+        "content": {
+            "Title": "Requirement Violation",
+            "Relationships": "[CWE-573: Improper Following of Specification by Caller](https://cwe.mitre.org/data/definitions/573.html)",
+            "Description": "The Solidity `require()` construct is meant to validate external inputs of a function. In most cases, such external inputs are provided by callers, but they may also be returned by callees. In the former case, we refer to them as precondition violations. Violations of a requirement can indicate one of two possible issues:\n\n\n1. A bug exists in the contract that provided the external input.\n1. The condition used to express the requirement is too strong.",
+            "Remediation": "If the required logical condition is too strong, it should be weakened to allow all valid external inputs.\n\n\nOtherwise, the bug must be in the contract that provided the external input and one should consider fixing its code by making sure no invalid inputs are provided."
+        }
+    },
+    "SWC-124": {
+        "markdown": "# Title\r\nWrite to Arbitrary Storage Location\r\n\r\n## Relationships\r\n\r\n[CWE-123: Write-what-where Condition](https://cwe.mitre.org/data/definitions/123.html)\r\n\r\n## Description\r\n\r\nA smart contract's data (e.g., storing the owner of the contract) is persistently stored\r\nat some storage location (i.e., a key or address) on the EVM level. The contract is\r\nresponsible for ensuring that only authorized user or contract accounts may write to\r\nsensitive storage locations. If an attacker is able to write to arbitrary storage\r\nlocations of a contract, the authorization checks may easily be circumvented. This can\r\nallow an attacker to corrupt the storage; for instance, by overwriting a field that stores\r\nthe address of the contract owner.\r\n\r\n## Remediation\r\n\r\nAs a general advice, given that all data structures share the same storage (address)\r\nspace, one should make sure that writes to one data structure cannot inadvertently\r\noverwrite entries of another data structure.\r\n\r\n## References\r\n\r\n- [Entry to Underhanded Solidity Coding Contest 2017 (honorable mention)](https://github.com/Arachnid/uscc/tree/master/submissions-2017/doughoyte)\r\n",
+        "content": {
+            "Title": "Write to Arbitrary Storage Location",
+            "Relationships": "[CWE-123: Write-what-where Condition](https://cwe.mitre.org/data/definitions/123.html)",
+            "Description": "A smart contract's data (e.g., storing the owner of the contract) is persistently stored\nat some storage location (i.e., a key or address) on the EVM level. The contract is\nresponsible for ensuring that only authorized user or contract accounts may write to\nsensitive storage locations. If an attacker is able to write to arbitrary storage\nlocations of a contract, the authorization checks may easily be circumvented. This can\nallow an attacker to corrupt the storage; for instance, by overwriting a field that stores\nthe address of the contract owner.",
+            "Remediation": "As a general advice, given that all data structures share the same storage (address)\nspace, one should make sure that writes to one data structure cannot inadvertently\noverwrite entries of another data structure."
+        }
+    },
+    "SWC-125": {
+        "markdown": "# Title \nIncorrect Inheritance Order\n\n## Relationships\n[CWE-696: Incorrect Behavior Order](https://cwe.mitre.org/data/definitions/696.html)\n\n## Description \nSolidity supports multiple inheritance, meaning that one contract can inherit several contracts. Multiple inheritance introduces ambiguity called [Diamond Problem](https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem): if two or more base contracts define the same function, which one should be called in the child contract? Solidity deals with this ambiguity by using reverse [C3 Linearization](https://en.wikipedia.org/wiki/C3_linearization), which sets a priority between base contracts.\n\nThat way, base contracts have different priorities, so the order of inheritance matters. Neglecting inheritance order can lead to unexpected behavior.\n\n## Remediation\nWhen inheriting multiple contracts, especially if they have identical functions, a developer should carefully specify inheritance in the correct order. The rule of thumb is to inherit contracts from more /general/ to more /specific/.\n\n## References \n* [Smart Contract Best Practices - Multiple Inheritance Caution](https://consensys.github.io/smart-contract-best-practices/recommendations/#multiple-inheritance-caution)\n* [Solidity docs - Multiple Inheritance and Linearization](https://solidity.readthedocs.io/en/v0.4.25/contracts.html#multiple-inheritance-and-linearization)\n* [Solidity anti-patterns: Fun with inheritance DAG abuse](https://pdaian.com/blog/solidity-anti-patterns-fun-with-inheritance-dag-abuse)\n",
+        "content": {
+            "Title": "Incorrect Inheritance Order",
+            "Relationships": "[CWE-696: Incorrect Behavior Order](https://cwe.mitre.org/data/definitions/696.html)",
+            "Description": "Solidity supports multiple inheritance, meaning that one contract can inherit several contracts. Multiple inheritance introduces ambiguity called [Diamond Problem](https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem): if two or more base contracts define the same function, which one should be called in the child contract? Solidity deals with this ambiguity by using reverse [C3 Linearization](https://en.wikipedia.org/wiki/C3_linearization), which sets a priority between base contracts.\n\n\nThat way, base contracts have different priorities, so the order of inheritance matters. Neglecting inheritance order can lead to unexpected behavior.",
+            "Remediation": "When inheriting multiple contracts, especially if they have identical functions, a developer should carefully specify inheritance in the correct order. The rule of thumb is to inherit contracts from more /general/ to more /specific/."
+        }
+    },
+    "SWC-127": {
+        "markdown": "# Title \nArbitrary Jump with Function Type Variable\n\n## Relationships\n[CWE-695: Use of Low-Level Functionality](https://cwe.mitre.org/data/definitions/695.html)\n\n## Description \nSolidity supports function types. That is, a variable of function type can be assigned with a reference to a function with a matching signature. The function saved to such variable can be called lust like a regular function.\n\nThe problem arises when a user has the ability to arbitrarily change the function type variable and thus execute random code instructions. As Solidity doesn't support pointer arithmetics, it's impossible to change such variable to an arbitrary value. However, if the developer uses assembly instructions, such as `mstore` or assign operator, in the worst case scenario an attacker is able to point a function type variable to any code instruction, violating required validations and required state changes.\n\n## Remediation\nThe use of assembly should be minimal. A developer should not allow a user to assign arbitrary values to function type variables.\n\n## References \n* [Solidity CTF](https://medium.com/authio/solidity-ctf-part-2-safe-execution-ad6ded20e042)\n* [Solidity docs - Solidity Assembly](https://solidity.readthedocs.io/en/v0.4.25/assembly.html)\n* [Solidity docs - Function Types](https://solidity.readthedocs.io/en/v0.4.25/types.html#function-types)\n",
+        "content": {
+            "Title": "Arbitrary Jump with Function Type Variable",
+            "Relationships": "[CWE-695: Use of Low-Level Functionality](https://cwe.mitre.org/data/definitions/695.html)",
+            "Description": "Solidity supports function types. That is, a variable of function type can be assigned with a reference to a function with a matching signature. The function saved to such variable can be called lust like a regular function.\n\n\nThe problem arises when a user has the ability to arbitrarily change the function type variable and thus execute random code instructions. As Solidity doesn't support pointer arithmetics, it's impossible to change such variable to an arbitrary value. However, if the developer uses assembly instructions, such as `mstore` or assign operator, in the worst case scenario an attacker is able to point a function type variable to any code instruction, violating required validations and required state changes.",
+            "Remediation": "The use of assembly should be minimal. A developer should not allow a user to assign arbitrary values to function type variables."
+        }
+    },
+    "SWC-128": {
+        "markdown": "# Title\nDoS With Block Gas Limit\n\n## Relationships\n[CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)\n\n## Description\n\nWhen smart contracts are deployed or functions inside them are called, the execution of these actions always requires a certain amount of gas, based of how much computation is needed to complete them. The Ethereum network specifies a block gas limit and the sum of all transactions included in a block can not exceed the threshold. \n\nProgramming patterns that are harmless in centralized applications can lead to Denial of Service conditions in smart contracts when the cost of executing a function exceeds the block gas limit. Modifying an array of unknown size, that increases in size over time, can lead to such a Denial of Service condition.\n\n## Remediation\n\nCaution is advised when you expect to have large arrays that grow over time. Actions that require looping across the entire data structure should be avoided.  \n\nIf you absolutely must loop over an array of unknown size, then you should plan for it to potentially take multiple blocks, and therefore require multiple transactions.\n\n## References\n* [Ethereum Design Rationale](https://github.com/ethereum/wiki/wiki/Design-Rationale#gas-and-fees)\n* [Ethereum Yellow Paper](https://ethereum.github.io/yellowpaper/paper.pdf)\n* [Clear Large Array Without Blowing Gas Limit](https://ethereum.stackexchange.com/questions/3373/how-to-clear-large-arrays-without-blowing-the-gas-limit)\n* [GovernMental jackpot payout DoS Gas](https://www.reddit.com/r/ethereum/comments/4ghzhv/governmentals_1100_eth_jackpot_payout_is_stuck/)\n\n",
+        "content": {
+            "Title": "DoS With Block Gas Limit",
+            "Relationships": "[CWE-400: Uncontrolled Resource Consumption](https://cwe.mitre.org/data/definitions/400.html)",
+            "Description": "When smart contracts are deployed or functions inside them are called, the execution of these actions always requires a certain amount of gas, based of how much computation is needed to complete them. The Ethereum network specifies a block gas limit and the sum of all transactions included in a block can not exceed the threshold. \n\n\nProgramming patterns that are harmless in centralized applications can lead to Denial of Service conditions in smart contracts when the cost of executing a function exceeds the block gas limit. Modifying an array of unknown size, that increases in size over time, can lead to such a Denial of Service condition.",
+            "Remediation": "Caution is advised when you expect to have large arrays that grow over time. Actions that require looping across the entire data structure should be avoided.  \n\n\nIf you absolutely must loop over an array of unknown size, then you should plan for it to potentially take multiple blocks, and therefore require multiple transactions."
+        }
+    },
+    "SWC-129": {
+        "markdown": "# Title\nTypographical Error\n\n## Relationships\n[CWE-480: Use of Incorrect Operator](https://cwe.mitre.org/data/definitions/480.html)\n\n## Description\nA typographical error can occur for example when the intent of a defined operation is to sum a number to a variable (+=) but it has accidentally been defined in a wrong way (=+), introducing a typo which happens to be a valid operator. Instead of calculating the sum it initializes the variable again. \n\nThe unary + operator is deprecated in new solidity compiler versions.\n\n## Remediation\nThe weakness can be avoided by performing pre-condition checks on any math operation or using a vetted library for arithmetic calculations such as SafeMath developed by OpenZeppelin.\n\n## References\n* [HackerGold Bug Analysis](https://blog.zeppelin.solutions/hackergold-bug-analysis-68d893cad738)\n* [SafeMath by OpenZeppelin](https://github.com/OpenZeppelin/openzeppelin-solidity/blob/master/contracts/math/SafeMath.sol)\n* [Disallow Unary plus](https://github.com/ethereum/solidity/issues/1760)\n",
+        "content": {
+            "Title": "Typographical Error",
+            "Relationships": "[CWE-480: Use of Incorrect Operator](https://cwe.mitre.org/data/definitions/480.html)",
+            "Description": "A typographical error can occur for example when the intent of a defined operation is to sum a number to a variable (+=) but it has accidentally been defined in a wrong way (=+), introducing a typo which happens to be a valid operator. Instead of calculating the sum it initializes the variable again. \n\n\nThe unary + operator is deprecated in new solidity compiler versions.",
+            "Remediation": "The weakness can be avoided by performing pre-condition checks on any math operation or using a vetted library for arithmetic calculations such as SafeMath developed by OpenZeppelin."
+        }
+    }
+}

From 392e12ceadba70c4b7431a12eaaed20331a3f7c5 Mon Sep 17 00:00:00 2001
From: Dominik Muhs <dmuhs@protonmail.ch>
Date: Tue, 27 Nov 2018 17:45:50 +0100
Subject: [PATCH 08/18] Make lookup error more expressive

---
 swc_registry/get_entry_info.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/swc_registry/get_entry_info.py b/swc_registry/get_entry_info.py
index 5afb6a7..89af951 100644
--- a/swc_registry/get_entry_info.py
+++ b/swc_registry/get_entry_info.py
@@ -3,7 +3,7 @@
 import json
 
 
-class SWCDoesNotExist(Exception):
+class SWCException(Exception):
     pass
 
 
@@ -70,7 +70,7 @@ def _content(self):
         entries = self._swc_content
         current_entry = entries.get(self.swc_id)
         if not current_entry:
-            raise SWCDoesNotExist('SWC does not exist')
+            raise SWCException('SWC with ID {} does not exist'.format(self.swc_id))
         content = current_entry.get('content', {})
         return content
 

From 46eef044b9ccf555597df25a7eb14e90dab3cea4 Mon Sep 17 00:00:00 2001
From: Dominik Muhs <dmuhs@protonmail.ch>
Date: Tue, 27 Nov 2018 17:45:59 +0100
Subject: [PATCH 09/18] Add repr methods

---
 swc_registry/get_entry_info.py | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/swc_registry/get_entry_info.py b/swc_registry/get_entry_info.py
index 89af951..41ffabd 100644
--- a/swc_registry/get_entry_info.py
+++ b/swc_registry/get_entry_info.py
@@ -47,6 +47,9 @@ def content(self):
             self._load_from_file()
         return self._content
 
+    def __repr__(self):
+        return "<SWCRegistry with {} entries>".format(len(self.content.keys()))
+
 
 class SWC:
     """
@@ -97,3 +100,6 @@ def remediation(self) -> str:
         content = self._content
         remediation = content.get('Remediation', '')
         return remediation
+
+    def __repr__(self):
+        return "<SWC swc_id={0.swc_id} title={0.title}>".format(self)

From 53959abb2ace39d8b5c842170a22645b765a931e Mon Sep 17 00:00:00 2001
From: Dominik Muhs <dmuhs@protonmail.ch>
Date: Tue, 27 Nov 2018 17:47:57 +0100
Subject: [PATCH 10/18] Add formatting fixes using black

---
 setup.py                       | 20 +++++++++-----------
 swc_registry/__init__.py       |  4 ++--
 swc_registry/get_entry_info.py | 26 ++++++++++++++++----------
 tests/test_get_entry_info.py   | 28 ++++++++++++++++++----------
 4 files changed, 45 insertions(+), 33 deletions(-)

diff --git a/setup.py b/setup.py
index 0df1ba0..314d7f8 100644
--- a/setup.py
+++ b/setup.py
@@ -7,18 +7,16 @@
     author="SmartContractSecurity",
     author_email="ersul4ik@gmail.com",
     description="Python library for accessing SWC-registry content.",
-    long_description=open('README.rst').read(),
-    packages=['swc_registry'],
-    include_package_data = True,
-    install_requires=[
-        'requests==2.20.1',
-      ],
+    long_description=open("README.rst").read(),
+    packages=["swc_registry"],
+    include_package_data=True,
+    install_requires=["requests==2.20.1"],
     classifiers=[
-        'Programming Language :: Python',
-        'Programming Language :: Python :: 3',
-        'Programming Language :: Python :: 3.3',
-        'Programming Language :: Python :: 3.4'
+        "Programming Language :: Python",
+        "Programming Language :: Python :: 3",
+        "Programming Language :: Python :: 3.3",
+        "Programming Language :: Python :: 3.4",
     ],
     setup_requires=["pytest-runner"],
-    tests_require=["pytest"]
+    tests_require=["pytest"],
 )
diff --git a/swc_registry/__init__.py b/swc_registry/__init__.py
index 9e08e51..9d01030 100644
--- a/swc_registry/__init__.py
+++ b/swc_registry/__init__.py
@@ -1,5 +1,5 @@
 from swc_registry.get_entry_info import SWC
 
-__version__ = '0.0.2'
-__author__ = 'SmartContractSecurity'
+__version__ = "0.0.2"
+__author__ = "SmartContractSecurity"
 __all__ = []
diff --git a/swc_registry/get_entry_info.py b/swc_registry/get_entry_info.py
index 41ffabd..6db95ac 100644
--- a/swc_registry/get_entry_info.py
+++ b/swc_registry/get_entry_info.py
@@ -20,22 +20,27 @@ class SWCRegistry(object, metaclass=Singleton):
     """
     Registry class takes care of loading and downloading the swc registry
     """
+
     def __init__(self):
         self._content = None
 
     @staticmethod
     def _get_latest_version():
         try:
-            url = ('https://raw.githubusercontent.com/SmartContractSecurity/SWC-registry/master/export/swc-definition'
-                   '.json')
+            url = (
+                "https://raw.githubusercontent.com/SmartContractSecurity/SWC-registry/master/export/swc-definition"
+                ".json"
+            )
             response = requests.get(url).json()
             return response
         except requests.exceptions.RequestException:
             return None
 
     def _load_from_file(self):
-        path_file_content = os.path.join(os.path.dirname(__file__), 'swc-definition.json')
-        with open(path_file_content, 'r') as f:
+        path_file_content = os.path.join(
+            os.path.dirname(__file__), "swc-definition.json"
+        )
+        with open(path_file_content, "r") as f:
             self._content = json.load(f)
 
     def update(self):
@@ -59,6 +64,7 @@ class SWC:
         swc = SWC('SWC-100')
         print(swc.title)
     """
+
     def __init__(self, swc_id, get_last=False):
         self.swc_id = swc_id
         if get_last:
@@ -73,32 +79,32 @@ def _content(self):
         entries = self._swc_content
         current_entry = entries.get(self.swc_id)
         if not current_entry:
-            raise SWCException('SWC with ID {} does not exist'.format(self.swc_id))
-        content = current_entry.get('content', {})
+            raise SWCException("SWC with ID {} does not exist".format(self.swc_id))
+        content = current_entry.get("content", {})
         return content
 
     @property
     def title(self) -> str:
         content = self._content
-        title = content.get('Title', '')
+        title = content.get("Title", "")
         return title
 
     @property
     def relationships(self) -> str:
         content = self._content
-        relationships = content.get('Relationships', '')
+        relationships = content.get("Relationships", "")
         return relationships
 
     @property
     def description(self) -> str:
         content = self._content
-        description = content.get('Description', '')
+        description = content.get("Description", "")
         return description
 
     @property
     def remediation(self) -> str:
         content = self._content
-        remediation = content.get('Remediation', '')
+        remediation = content.get("Remediation", "")
         return remediation
 
     def __repr__(self):
diff --git a/tests/test_get_entry_info.py b/tests/test_get_entry_info.py
index e748657..5e2c280 100644
--- a/tests/test_get_entry_info.py
+++ b/tests/test_get_entry_info.py
@@ -9,27 +9,35 @@
 
 class TestMethods(unittest.TestCase):
     def setUp(self):
-        with open(os.path.dirname(__file__) + '/../swc_registry/swc-definition.json') as f:
+        with open(
+            os.path.dirname(__file__) + "/../swc_registry/swc-definition.json"
+        ) as f:
             self.object = json.load(f)
-        self.swc = SWC('SWC-100')
+        self.swc = SWC("SWC-100")
         SWCRegistry()._load_from_file()
 
     def test_get_title(self):
-        self.assertEqual(self.swc.title, self.object['SWC-100']['content']['Title'])
+        self.assertEqual(self.swc.title, self.object["SWC-100"]["content"]["Title"])
 
     def test_get_relationships(self):
-        self.assertEqual(self.swc.relationships, self.object['SWC-100']['content']['Relationships'])
+        self.assertEqual(
+            self.swc.relationships, self.object["SWC-100"]["content"]["Relationships"]
+        )
 
     def test_get_description(self):
-        self.assertEqual(self.swc.description, self.object['SWC-100']['content']['Description'])
-    
+        self.assertEqual(
+            self.swc.description, self.object["SWC-100"]["content"]["Description"]
+        )
+
     def test_get_remediation(self):
-        self.assertEqual(self.swc.remediation, self.object['SWC-100']['content']['Remediation'])
+        self.assertEqual(
+            self.swc.remediation, self.object["SWC-100"]["content"]["Remediation"]
+        )
 
     def test_get_last_version(self):
         # Act
         after_content = SWCRegistry().content
-        after_content['SWC-100']['content']['Title'] = "Brick"
+        after_content["SWC-100"]["content"]["Title"] = "Brick"
         SWCRegistry._get_latest_version = MagicMock(return_value=after_content)
 
         SWCRegistry().update()
@@ -39,5 +47,5 @@ def test_get_last_version(self):
         self.assertEqual(new_title, "Brick")
 
 
-if __name__ == '__main__':
-    unittest.main()
\ No newline at end of file
+if __name__ == "__main__":
+    unittest.main()

From b112036f23d7d7f3c5808633c75c3cd2d9d78934 Mon Sep 17 00:00:00 2001
From: Aleksandr Sobolev <s0b0lev@users.noreply.github.com>
Date: Tue, 27 Nov 2018 23:33:59 +0600
Subject: [PATCH 11/18] Update and rename README.rst to README.md

---
 README.md  | 22 ++++++++++++++++++++++
 README.rst |  1 -
 2 files changed, 22 insertions(+), 1 deletion(-)
 create mode 100644 README.md
 delete mode 100644 README.rst

diff --git a/README.md b/README.md
new file mode 100644
index 0000000..9b99f80
--- /dev/null
+++ b/README.md
@@ -0,0 +1,22 @@
+# SWC-registry-python
+
+[![CircleCI](https://circleci.com/gh/SmartContractSecurity/SWC-registry-python.svg?style=svg)](https://circleci.com/gh/SmartContractSecurity/SWC-registry-python)
+
+## Description
+Python library for accessing SWC-registry content.
+
+## Installation
+
+```console
+$ pip install -U swc-registry
+```
+
+## Usage
+```python
+from swc_registry import SWC
+
+swc = SWC('SWC-100')
+swc.title
+```
+
+## Contribution
diff --git a/README.rst b/README.rst
deleted file mode 100644
index bc63beb..0000000
--- a/README.rst
+++ /dev/null
@@ -1 +0,0 @@
-# empty
\ No newline at end of file

From 1dfb48748ea441de860f121d8fbc9c0756bcd665 Mon Sep 17 00:00:00 2001
From: Erik <erik@Eriks-MacBook-Pro.local>
Date: Wed, 28 Nov 2018 10:01:11 +0600
Subject: [PATCH 12/18] Added some changes to tests for check on Circle CI

---
 .circleci/config.yml         | 2 +-
 tests/test_get_entry_info.py | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/.circleci/config.yml b/.circleci/config.yml
index f8ed938..406e303 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -10,4 +10,4 @@ jobs:
             working_directory: swc_registry/
             command: |
               pip install -r ../requirements.txt
-              python test.py
+              python ../tests/test_get_entry_info.py
diff --git a/tests/test_get_entry_info.py b/tests/test_get_entry_info.py
index 5e2c280..6a883c3 100644
--- a/tests/test_get_entry_info.py
+++ b/tests/test_get_entry_info.py
@@ -3,14 +3,14 @@
 import os
 
 from unittest.mock import MagicMock
-from swc_registry import SWC
-from swc_registry.get_entry_info import SWCRegistry
+from get_entry_info import SWC
+from get_entry_info import SWCRegistry
 
 
 class TestMethods(unittest.TestCase):
     def setUp(self):
         with open(
-            os.path.dirname(__file__) + "/../swc_registry/swc-definition.json"
+            os.path.dirname(__file__) + "./swc-definition.json"
         ) as f:
             self.object = json.load(f)
         self.swc = SWC("SWC-100")

From 8b2c6b028993e9a0a0c08aee711cd75f41a6b415 Mon Sep 17 00:00:00 2001
From: Erik <erik@Eriks-MacBook-Pro.local>
Date: Wed, 28 Nov 2018 10:06:22 +0600
Subject: [PATCH 13/18] Change path to module

---
 tests/test_get_entry_info.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/test_get_entry_info.py b/tests/test_get_entry_info.py
index 6a883c3..b118966 100644
--- a/tests/test_get_entry_info.py
+++ b/tests/test_get_entry_info.py
@@ -3,8 +3,8 @@
 import os
 
 from unittest.mock import MagicMock
-from get_entry_info import SWC
-from get_entry_info import SWCRegistry
+from swc_registry.get_entry_info import SWC
+from swc_registry.get_entry_info import SWCRegistry
 
 
 class TestMethods(unittest.TestCase):

From 5c91d0b777c8723eb2cb7b538c2e99f36d7076bd Mon Sep 17 00:00:00 2001
From: Erik <erik@Eriks-MacBook-Pro.local>
Date: Wed, 28 Nov 2018 10:25:37 +0600
Subject: [PATCH 14/18] Changed config.yml for resolve problems with tests
 running

---
 .circleci/config.yml         | 2 +-
 setup.py                     | 2 +-
 swc_registry/__init__.py     | 2 +-
 tests/test_get_entry_info.py | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/.circleci/config.yml b/.circleci/config.yml
index 406e303..363c6d6 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -10,4 +10,4 @@ jobs:
             working_directory: swc_registry/
             command: |
               pip install -r ../requirements.txt
-              python ../tests/test_get_entry_info.py
+              pytest
diff --git a/setup.py b/setup.py
index 314d7f8..4b9322e 100644
--- a/setup.py
+++ b/setup.py
@@ -2,7 +2,7 @@
 
 setuptools.setup(
     name="swc-registry",
-    version="0.0.2",
+    version="0.0.3",
     url="https://github.com/SmartContractSecurity/SWC-registry-python",
     author="SmartContractSecurity",
     author_email="ersul4ik@gmail.com",
diff --git a/swc_registry/__init__.py b/swc_registry/__init__.py
index 9d01030..350f246 100644
--- a/swc_registry/__init__.py
+++ b/swc_registry/__init__.py
@@ -1,5 +1,5 @@
 from swc_registry.get_entry_info import SWC
 
-__version__ = "0.0.2"
+__version__ = "0.0.3"
 __author__ = "SmartContractSecurity"
 __all__ = []
diff --git a/tests/test_get_entry_info.py b/tests/test_get_entry_info.py
index b118966..1470110 100644
--- a/tests/test_get_entry_info.py
+++ b/tests/test_get_entry_info.py
@@ -10,7 +10,7 @@
 class TestMethods(unittest.TestCase):
     def setUp(self):
         with open(
-            os.path.dirname(__file__) + "./swc-definition.json"
+            os.path.dirname(__file__) + "/../swc_registry/swc-definition.json"
         ) as f:
             self.object = json.load(f)
         self.swc = SWC("SWC-100")

From f4a4d61fe60a8b32680eeeeb24588a51e57ccce6 Mon Sep 17 00:00:00 2001
From: Erik <erik@Eriks-MacBook-Pro.local>
Date: Wed, 28 Nov 2018 10:26:49 +0600
Subject: [PATCH 15/18] Added pytest packages for run tests

---
 setup.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/setup.py b/setup.py
index 4b9322e..0fc1a7e 100644
--- a/setup.py
+++ b/setup.py
@@ -10,7 +10,7 @@
     long_description=open("README.rst").read(),
     packages=["swc_registry"],
     include_package_data=True,
-    install_requires=["requests==2.20.1"],
+    install_requires=["requests==2.20.1", "pytest"],
     classifiers=[
         "Programming Language :: Python",
         "Programming Language :: Python :: 3",

From 09bcd142189dc897a70f51f0182e9e01ba675cde Mon Sep 17 00:00:00 2001
From: Erik <erik@Eriks-MacBook-Pro.local>
Date: Wed, 28 Nov 2018 10:28:38 +0600
Subject: [PATCH 16/18] Attach requirements.txt

---
 requirements.txt | 1 +
 setup.py         | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/requirements.txt b/requirements.txt
index 5610e90..d5a12a2 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -1 +1,2 @@
 requests==2.20.1
+pytest==4.0.1
\ No newline at end of file
diff --git a/setup.py b/setup.py
index 0fc1a7e..4b9322e 100644
--- a/setup.py
+++ b/setup.py
@@ -10,7 +10,7 @@
     long_description=open("README.rst").read(),
     packages=["swc_registry"],
     include_package_data=True,
-    install_requires=["requests==2.20.1", "pytest"],
+    install_requires=["requests==2.20.1"],
     classifiers=[
         "Programming Language :: Python",
         "Programming Language :: Python :: 3",

From 86a339140146451c4923476053e5857ca353df14 Mon Sep 17 00:00:00 2001
From: Erik <erik@Eriks-MacBook-Pro.local>
Date: Wed, 28 Nov 2018 10:30:07 +0600
Subject: [PATCH 17/18] Changed config.yml to run test in test directory

---
 .circleci/config.yml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/.circleci/config.yml b/.circleci/config.yml
index 363c6d6..5ec29c3 100644
--- a/.circleci/config.yml
+++ b/.circleci/config.yml
@@ -10,4 +10,4 @@ jobs:
             working_directory: swc_registry/
             command: |
               pip install -r ../requirements.txt
-              pytest
+              pytest ../tests/

From cb8ee0985c4496db4496841cd73f3e2fa0a0dce1 Mon Sep 17 00:00:00 2001
From: ersul4ik <ersul4ik@mail.ru>
Date: Wed, 28 Nov 2018 11:12:00 +0600
Subject: [PATCH 18/18] Updated the code in setup.py #15

---
 setup.py | 37 ++++++++++++++++++++++++++++++++++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/setup.py b/setup.py
index 4b9322e..1102510 100644
--- a/setup.py
+++ b/setup.py
@@ -1,13 +1,41 @@
 import setuptools
 
-setuptools.setup(
+#!/usr/bin/env python
+# -*- coding: utf-8 -*-
+"""
+:copyright: (c) 2017 by Lev Lazinskiy
+:license: MIT, see LICENSE for more details.
+"""
+import os
+import sys
+
+from setuptools import setup
+from setuptools.command.install import install
+
+# circleci.py version
+VERSION = "1.1.1"
+
+class VerifyVersionCommand(install):
+    """Custom command to verify that the git tag matches our version"""
+    description = 'verify that the git tag matches our version'
+
+    def run(self):
+        tag = os.getenv('CIRCLE_TAG')
+
+        if tag != VERSION:
+            info = "Git tag: {0} does not match the version of this app: {1}".format(
+                tag, VERSION
+            )
+            sys.exit(info)
+
+setup(
     name="swc-registry",
-    version="0.0.3",
+    version=VERSION,
     url="https://github.com/SmartContractSecurity/SWC-registry-python",
     author="SmartContractSecurity",
     author_email="ersul4ik@gmail.com",
     description="Python library for accessing SWC-registry content.",
-    long_description=open("README.rst").read(),
+    long_description=open("README.md").read(),
     packages=["swc_registry"],
     include_package_data=True,
     install_requires=["requests==2.20.1"],
@@ -19,4 +47,7 @@
     ],
     setup_requires=["pytest-runner"],
     tests_require=["pytest"],
+    cmdclass={
+        'verify': VerifyVersionCommand,
+    }
 )