Copyright © 2023 Enterprise Ethereum Alliance.
This section describes the status of this document at the time of its publication. Newer documents may supersede this document.
This specification is licensed by the Enterprise Ethereum Alliance, Inc. (EEA) under the terms of the Apache License, Version 2.0 [License]. Unless otherwise explicitly authorised in writing by the EEA, you can only use this document in accordance with those terms.
Unless required by applicable law or agreed to in writing, this document is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
Please send any comments to the EEA at https://entethalliance.org/contact/, or as issues via the EthTrust-public GitHub repository.
The Working Group expects at the time of publication to publish the next release version of this checklist alongside the next version of the Specification, in 2025.
This section is non-normative.
This companion document is a checklist for [EthTrust-sl-v2], the EEA EthTrust Security Levels Specification. It lists the requirements for granting EEA EthTrust Certification to a smart contract written in Solidity as a convenience for security reviewers, developers, or others, who are familiar with the EEA EthTrust Security Levels Specification, and want an aide memoire.
In case of any discrepancy between this checklist, and the relevant version of the EEA EthTrust Security Levels Specification, readers should assume that this document is in error, and the definitive version is the text in the specification.
EEA EthTrust Certification is a claim by a security reviewer that the Tested Code is not vulnerable to a number of known attacks or failures to operate as expected, based on the reviewer's assessment against those specific requirements.
EEA EthTrust Certification
does not and cannot ensure that the Tested Code
is completely secure from any attack.
Definitions of terms are formatted Like this.
Most of the terms are defined in the main specification document. Some definitions are repeated in this document.
References to defined terms are rendered as links
Like This. References to other documents are links to the relevant entry
in the § B. References section, within square brackets, such as: [CWE]. Links to requirements begin with a Security Level: [S], [M]
or [Q], and recommended good practices begin with [GP]. They then include
the requirement or good practice name. They are rendered as links in bold type, for example: Example of a link to [M] Document Special Code Use. Variables, introduced to be described further on in a statement or requirement, are formatted as
var.1.1.2 Typographic Conventions
The key words MAY, MUST, MUST NOT, RECOMMENDED, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
The EthTrust Security Levels Specification defines a number of requirements. As described in more detail by § 1.1.3 How to Read a Requirement of that document, each requirement has a Security Level ([S], [M] or [Q]), and a statement of the requirement that Tested Code MUST meet.
In order to achieve EEA EthTrust Certification at a specific Security Level, the Tested Code MUST meet all the requirements for that Security Level, including all the requirements for lower Security Levels. Some requirements can either be met directly, or by meeting one or more Overriding requirements that mean the requirement is considered met.
Section § 4.4 Recommended Good Practices, contains further recommendations. Although they are formatted similarly to requirements, they begin with a "level" marker [GP]. There is no requirement to test for these; however careful implementation and testing is RECOMMENDED.
Note that good implementation of the Recommended Good Practices can enhance security, but in some cases incomplete or low-quality implementation could reduce security.
To provide as strong a level of assurance as possible, Tested Code SHOULD meet as many requirements as possible at all Security Levels.
This document does not create an affirmative duty of compliance on any party, though requirements to comply with it could be created by contract negotiations or other processes with prospective customers or investors.
To grant Tested Code EEA EthTrust Certification, an auditor provides a Valid Conformance Claim, that the Tested Code meets the requirements of the Security Level for which it is certified.
There is no required format for a Valid conformance claim for Version 1 of this specification, beyond being legible and containing the required information as specified in this section.
A Valid Conformance Claim MUST include:
A Valid Conformance Claim for Security Level [Q] MUST contain a [SHA3-256] hash of the documentation provided to meet [Q] Document Contract Logic and [Q] Document System Architecture.
A Valid Conformance Claim SHOULD include
A Valid Conformance Claim MAY include:
Requirement | Status |
---|---|
[S] Encode Hashes with
chainid 🔗 Tested code MUST create hashes for transactions that incorporate chainid values
following the recommendation described in [EIP-155] |
|
[S] No
CREATE2 🔗 Tested code MUST NOT contain a CREATE2 instruction.
unless it meets the Set of Overriding Requirements |
|
[S] No |
|
[S] No Exact Balance Check 🔗 |
|
[S] No Conflicting Names 🔗 |
|
[S] No Hashing Consecutive Variable Length Arguments 🔗 |
|
[S] No
selfdestruct() 🔗 Tested code MUST NOT contain the selfdestruct() instruction
or its now-deprecated alias suicide()
unless it meets the Set of Overriding Requirements |
|
[S] No
assembly {} 🔗 Tested Code MUST NOT contain the assembly {} instruction
unless it meets the Set of Overriding Requirements
|
|
[S] No Unicode Direction Control Characters 🔗 |
|
[S] Check External Calls Return 🔗 |
|
[S] Use Check-Effects-Interaction 🔗
Tested code that makes external calls MUST use the Checks-Effects-Interactions pattern to protect against Re-entrancy Attacks unless it meets the Set of Overriding Requirements or it meets the Set of Overriding Requirements |
|
[S] No or it meets the Set of Overriding Requirements: |
|
[S] No Overflow/Underflow 🔗
Tested code MUST NOT use a Solidity compiler version older than 0.8.0 unless it meets the Set of Overriding Requirements |
|
[S] Compiler Bug SOL-2023-3 🔗 |
|
[S] Compiler Bug SOL-2022-6 🔗 |
|
[S] Compiler Bug SOL-2022-5 with |
|
[S] Compiler Bug SOL-2022-3 🔗
Tested code that
MUST NOT use a Solidity compiler version between 0.6.9 and 0.8.13 (inclusive). |
|
[S] Compiler Bug SOL-2022-2 🔗
Tested code with a nested array that
MUST NOT use a Solidity compiler version between 0.6.9 and 0.8.13 (inclusive). |
|
[S] Compiler Bug SOL-2022-1 🔗
Tested code that
and passes such literals to |
|
[S] Compiler Bug SOL-2021-4 🔗 |
|
[S] Compiler Bug SOL-2021-2 🔗 |
|
[S] Compiler Bug SOL-2021-1 🔗
Tested code that has 2 or more occurrences of an instruction keccak(mem,length) where
MUST NOT use the Optimizer with a Solidity compiler version older than 0.8.3. |
|
[S] Compiler Bug SOL-2020-11-push 🔗 |
|
[S] Compiler Bug SOL-2020-10 🔗 |
|
[S] Compiler Bug SOL-2020-9 🔗 |
|
[S] Compiler Bug SOL-2020-8 🔗 |
|
[S] Compiler Bug SOL-2020-6 🔗 |
|
[S] Compiler Bug SOL-2020-7 🔗 |
|
[S] Compiler Bug SOL-2020-5 🔗 |
|
[S] Compiler Bug SOL-2020-4 🔗
Tested code that makes assignments to tuples that
MUST NOT use a Solidity compiler version older than 0.6.4. |
|
[S] Compiler Bug SOL-2020-3 🔗 |
|
[S] Compiler Bug SOL-2020-1 🔗 |
|
[S] Use a Modern Compiler 🔗
Tested code MUST NOT use a Solidity compiler version older than 0.6.0, unless it meets all the following requirements from the EEA EthTrust Security Levels Specification Version 1, as if they were Overriding Requirements:
|
|
[S] No Ancient Compilers 🔗 |
|
[M] Pass Security Level [S] 🔗 |
|
[M] Explicitly Disambiguate Evaluation Order 🔗 |
|
[M] No Failing |
|
[M] Verify Exact Balance Checks 🔗 |
|
[M] No Unnecessary Unicode Controls 🔗 |
|
[M] No Homoglyph-style Attack 🔗 |
|
[M] Protect External Calls 🔗
For Tested code that makes external calls:
unless it meets the Set of Overriding Requirements
This is an Overriding Requirement for [S] Use Check-Effects-Interaction. |
|
[M] Avoid Read-only Re-entrancy Attacks 🔗 |
|
[M] Handle External Call Returns 🔗 |
|
[M] Document Special Code Use 🔗
Tested Code MUST document the need for each instance of:
block.number or block.timestamp , orand MUST describe how the Tested Code protects against misuse or errors in these cases, and the documentation MUST be available to anyone who can call the Tested Code. This is part of several Sets of Overriding Requirements, one for each of |
|
[M] Ensure Proper Rounding of Computations Affecting Value 🔗
Tested code MUST identify and protect against exploiting rounding errors:
|
|
[M] Protect Self-destruction 🔗
Tested code that contains the selfdestruct() or suicide()
instructions MUST
unless it meets the Overriding Requirement[Q] Enforce Least Privilege This is an Overriding Requirement for
[S] No |
|
[M] Avoid Common
assembly {} Attack Vectors 🔗 Tested Code MUST NOT use the assembly {} instruction to change a variable
unless the code cannot:
This is part of a Set of Overriding Requirements for
[S] No |
|
[M] Protect
CREATE2 Calls 🔗
For Tested Code that uses the CREATE2 instruction,
any contract to be deployed using CREATE2
unless it meets the Set of Overriding Requirements
This is part of a Set of Overriding Requirements for
[S] No |
|
[M] No Overflow/Underflow 🔗
Tested code MUST NOT contain calculations that can overflow or underflow unless
This is an Overriding Requirement for [S] No Overflow/Underflow. |
|
[M] Document Name Conflicts 🔗 |
|
[M] Sources of Randomness 🔗 |
|
[M] Don't Misuse Block Data 🔗 |
|
[M] Proper Signature Verification 🔗 |
|
[M] No Improper Usage of Signatures for Replay Attack Protection 🔗
Tested Code using signatures to prevent replay attacks MUST ensure that signatures cannot be reused:
unless it meets the Overriding Requirement [Q] Intended Replay. Additionally, Tested Code MUST verify that multiple signatures cannot be created for the same message, as is the case with Malleable Signatures. |
|
[M] Solidity Compiler Bug 2023-1 🔗 |
|
[M] Compiler Bug SOL-2022-7 🔗 |
|
[M] Compiler Bug SOL-2022-5 in |
|
[M] Compiler Bug SOL-2022-4 🔗 |
|
[M] Compiler Bug SOL-2021-3 🔗 |
|
[M] Compiler Bug Check Constructor Payment 🔗
Tested code that allows payment to a constructor function that is
MUST NOT use a Solidity compiler version between 0.4.5 and 0.6.7 (inclusive).
|
|
[M] Use a Modern Compiler 🔗
Tested code MUST NOT use a Solidity compiler version older than 0.6.0, unless it meets all the following requirements from the EEA EthTrust Security Levels Specification Version 1, as if they were Overriding Requirements: |
|
[Q] Pass Security Level [M] 🔗 |
|
[Q] Code Linting 🔗
Tested code
|
|
[Q] Manage Gas Use Increases 🔗 |
|
[Q] Protect Gas Usage 🔗 |
|
[Q] Protect against Oracle Failure 🔗 |
|
[Q] Protect against Front-Running 🔗 |
|
[Q] Protect against MEV Attacks 🔗 |
|
[Q] Protect against Governance Takeovers 🔗 |
|
[Q] Process All Inputs 🔗 |
|
[Q] State Changes Trigger Events 🔗 |
|
[Q] No Private Data 🔗 |
|
[Q] Intended Replay 🔗 |
|
[Q] Document Contract Logic 🔗 |
|
[Q] Document System Architecture 🔗 |
|
[Q] Annotate Code with NatSpec 🔗 |
|
[Q] Implement as Documented 🔗 |
|
[Q] Enforce Least Privilege 🔗 |
|
[Q] Use Revocable and Transferable Access Control Permissions 🔗 |
|
[Q] No Single Admin EOA for Privileged Actions 🔗 |
|
[Q] Verify External Calls 🔗
Tested Code that contains external calls
This is part of a Set of Overriding Requirements for [S] Use Check-Effects-Interaction, and for [M] Protect External Calls. |
|
[Q] Verify
tx.origin Usage 🔗 For Tested Code that uses tx.origin , each instance
This is an Overriding Requirement for
[S] No |
|
Recommended Practice | Status |
---|---|
[GP] Check For and Address New Security Bugs 🔗
|
|
[GP] Meet As Many Requirements As Possible 🔗
|
|
[GP] Use Latest Compiler 🔗
|
|
[GP] Write clear, legible Solidity code 🔗
|
|
[GP] Follow Accepted ERC Standards 🔗
|
|
[GP] Define a Software License 🔗 |
|
[GP] Disclose New Vulnerabilities Responsibly 🔗 |
|
[GP] Use Fuzzing 🔗 |
|
[GP] Use Formal Verification 🔗 |
|
[GP] Select an appropriate threshold for multisig wallets 🔗 |
|
[GP] Use TimeLock delays for sensitive operations 🔗
|
|
The following terms are defined in this document:
The following terms used in this checklist are defined in the EEA EthTrust Security Levels Specification.