Smart Contract Security Verification Standard (SCSVS) v0.0.1

The SCSVS project was created to share insights from research into smart contract security by the Research Team at CredShields. We acknowledge CredShields for their work in defining the initial requirements and establishing the project.

• S1. Architecture, Design, and Threat Modeling
  • S1.1 Secure Design Patterns
    • S1.1.A Modularity and Upgradability
      • S1.1.A1 Verify that the contract is divided into modular components or contracts.
      • S1.1.A2 Ensure that upgrade mechanisms are designed to allow secure and controlled updates.
      • S1.1.A3 Check that module boundaries are clearly defined and that dependencies are managed.
      • S1.1.A4 Ensure that changes to storage variable order or types between contract versions are managed to avoid storage collisions and data corruption
      • S1.1.A5 Verify that critical privilege transfers are conducted in a two-step process to ensure secure and reliable privilege changes.
      • S1.1.A6 Verify that the data location of parameters and return variables is correctly handled when overriding internal and public functions to avoid generating invalid code during virtual function calls.
    • S1.1.B Separation of Concerns
      • S1.1.B1 Verify that different functionalities are separated into distinct contracts or modules.
      • S1.1.B2 Ensure that each module has a single responsibility and minimal dependencies on other modules.
      • S1.1.B3 Check for any cross-module dependencies that could lead to security risks.
      • S1.1.B4 Ensure that the protocol maintains consistent and reliable operation during the transfer of privileges, with considerations for various edge cases.
      • S1.1.B5 Verify that proxy contracts use the onlyInitializing modifier instead of initializer to ensure proper initialization.
      • S1.1.B6 Verify that storage layouts between contract versions are consistent to prevent data corruption and unpredictable behavior.
      • S1.1.B7 Ensure that immutable variables are consistent across implementations during proxy upgrades.
      • S1.1.B8 Verify that implementations of the same logic across different parts of the contract are consistent to avoid introducing errors or vulnerabilities.
      • S1.1.B9 Ensure that ETH and WETH are handled separately with appropriate checks to avoid errors due to incorrect assumptions about exclusivity.
      • S1.1.B10 Verify that contracts with constructors are not used in a proxy setup, and initializer logic is used instead.
  • S1.2 Proxy Patterns
    • S1.2.A Upgrade Mechanisms
      • S1.2.A1 Verify that an upgrade mechanism (e.g., proxy pattern) is implemented for the contract.
      • S1.2.A2 Ensure that the upgrade process includes safeguards against unauthorized upgrades.
      • S1.2.A3 Check that the upgrade mechanism is documented and reviewed for security.
      • S1.2.A4 Verify that immutable variables are consistent across implementations during proxy upgrades to prevent misuse.
      • S1.2.A5 Verify that selfdestruct and delegatecall in implementation contracts do not introduce vulnerabilities or unexpected behaviors in a proxy setup.
      • S1.2.A6 Verify that UUPSUpgradeable contracts are protected against vulnerabilities that may affect uninitialized implementation contracts, ensuring secure upgrade mechanisms.
    • S1.2.B Managing Deprecation
      • S1.2.B1 Verify that deprecated contract versions are correctly marked and handled.
      • S1.2.B2 Ensure that access to deprecated versions is restricted or disabled.
      • S1.2.B3 Check that migration paths from deprecated versions to new versions are secure.
    • S1.2.C Transparent vs. Opaque Proxies
      • S1.2.C1 Verify whether a transparent or opaque proxy pattern is used and its suitability for the contract.
      • S1.2.C2 Ensure that the proxy pattern is correctly implemented and does not introduce vulnerabilities.
      • S1.2.C3 Check that the proxy pattern’s choice is documented and justified.
      • S1.2.C4 Ensure that uninitialized contracts cannot be taken over by attackers and that initialization functions are secured with the correct modifiers.
      • S1.2.C5 Verify that TransparentUpgradeableProxy and similar proxy patterns handle selector clashes and non-decodable calldata correctly to maintain transparency.
  • S1.3 Threat Modeling
    • S1.3.A Identifying Threats
      • S1.3.A1 Verify that potential threats are identified and documented.
      • S1.3.A2 Ensure that the threat identification process includes input from security experts.
      • S1.3.A3 Check that threats are categorized based on their impact and likelihood.
      • S1.3.A4 Implement protections against front-running in governor proposal creation to prevent attackers from blocking proposals or gaining undue advantages.
    • S1.3.B Assessing Risks
      • S1.3.B1 Verify that risk assessments are performed for identified threats.
      • S1.3.B2 Ensure that risks are prioritized based on their potential impact and likelihood.
      • S1.3.B3 Check that risk assessment results are documented and reviewed.
    • S1.3.C Implementing Mitigations
      • S1.3.C1 Verify that mitigations are implemented for high-priority risks.
      • S1.3.C2 Ensure that mitigation strategies are documented and tested.
      • S1.3.C3 Check that the effectiveness of implemented mitigations is reviewed and validated.
• S2. Policies, Procedures, and Code Management
  • S2.1 Development Policies
    • S2.1.A Secure coding standards
      • S2.1.A1 Ensure that developers do not use outdated compiler versions and adhere to the latest compiler recommendations.
      • S2.1.A2 Verify that deprecated functions are not used in the code.
    • S2.1.B Code review processes
      • S2.1.B1 Verify that all smart contract code changes are reviewed by at least two independent developers with expertise in smart contract security before merging to the main branch.
      • S2.1.B2 Ensure that code reviews of smart contracts involve automated static analysis tools specifically designed for smart contracts, and that all flagged issues are addressed or documented prior to merging.
      • S2.1.B3 Check that the code review process for smart contracts includes a thorough analysis for vulnerabilities such as reentrancy attacks, integer overflows, and improper access control.
      • S2.1.B4 Verify that code reviews include adherence to smart contract development standards, such as the use of safe math libraries and secure design patterns.
      • S2.1.B5 Ensure that code reviews incorporate a checklist of common smart contract vulnerabilities, and that each item on the list is addressed before code is approved.
  • S2.2 Code Clarity
    • S2.2.A Readability and documentation
      • S2.2.A1 Ensure that all smart contract functions and critical code blocks are documented with clear comments that explain their purpose and logic.
      • S2.2.A2 Verify that the structure of the smart contract is logical and organized to facilitate understanding and modification by other developers.
      • S2.2.A3 Check that the smart contract documentation includes a high-level overview of its functionality, usage instructions, and any dependencies on other contracts or systems.
      • S2.2.A4 Ensure that smart contract code follows consistent naming conventions for variables, functions, and contract names to improve readability and maintainability.
    • S2.2.B Code linting and formatting tools
      • S2.2.B1 Ensure that a code linting tool specific to smart contracts is integrated into the development workflow to enforce coding standards and style guidelines.
      • S2.2.B2 Verify that all smart contract code passes linting checks without errors or warnings before being committed to the repository.
      • S2.2.B3 Check that code formatting tools are applied to maintain consistent indentation, spacing, and line breaks in smart contract code.
      • S2.2.B4 Ensure that the linting and formatting configurations are reviewed and updated regularly to reflect new best practices and emerging issues in smart contract development.
      • S2.2.B5 Verify that the linting and formatting tools are compatible with the development environment and do not introduce unintended changes to the smart contract code.
  • S2.3 Test Coverage
    • S2.3.A Unit tests, integration tests, automated testing
      • S2.3.A1 Verify that all critical functions in the smart contract have comprehensive unit tests that cover both typical and edge cases.
      • S2.3.A2 Ensure that integration tests are implemented to validate the interactions between the smart contract and other contracts or external systems.
      • S2.3.A3 Check that automated tests are set up to run on each code commit to detect regressions and maintain continuous quality of the smart contract.
      • S2.3.A4 Verify that test coverage tools are used to monitor and achieve a high percentage of coverage for the smart contract code.
      • S2.3.A5 Ensure that the testing framework supports mocking and simulating external dependencies to effectively isolate and test specific functionalities of the smart contract.
    • S2.3.B Security-specific tests
      • S2.3.B1 Verify that the test suite for the smart contract includes security-specific tests designed to identify vulnerabilities such as reentrancy, integer overflows, and improper access controls.
      • S2.3.B2 Ensure that the security tests validate proper implementation of access controls and permissions within the smart contract.
      • S2.3.B3 Check that fuzz testing is conducted to uncover unexpected behaviors and potential security issues under various input scenarios.
      • S2.3.B4 Verify that the smart contract's response to invalid inputs and edge cases is thoroughly tested to ensure robust security measures are in place.
• S3. Business Logic and Economic Security
  • S3.1 Economic Models
    • S3.1.A Incentive structures
      • S3.1.A1 Ensure that the withdrawal process implements a pull-based approach rather than a push-based one to track accounting and allow users to pull payments.
      • S3.1.A2 The rate of cbETH to ETH can decrease, impacting users who hold or interact with cbETH. Ensure mechanisms are in place to handle fluctuations in conversion rates.
      • S3.1.A3 Validators on the Ethereum 2.0 Beacon Chain can be penalized or slashed for misbehavior, which can affect the value of rETH. Ensure that these dynamics are considered in value assessments and interactions.
      • S3.1.A4 The conversion rate between ETH and rETH might change over time based on the rewards accrued from staking. Ensure that these fluctuations are properly managed and captured.
  • S3.2 Tokenomics
    • S3.2.A Economic security of tokens and their use cases
      • S3.2.A1 Ensure that Merkle trees do not contain duplicate proofs, as this can lead to vulnerabilities like double-spending.
      • S3.2.A2 Verify that DeFi protocols account for tokens with negative rebase mechanisms, ensuring that value changes and potential miscalculations are properly handled and mitigated.
      • S3.2.A3 Verify that reward claims are correctly implemented to ensure users receive their correct rewards.
      • S3.2.A4 Verify that tokens do not have vulnerabilities such as incorrect fee application or unexpected behavior due to token transfer issues.
      • S3.2.A5 Verify that all claimable addresses are included in the hashing process for Merkle tree leaves to prevent attackers from claiming funds they should not.
  • S3.3 Preventing Reentrancy and Logic Flaws
    • S3.3.A Transaction flow security
      • S3.3.A1 Check for edge cases in loop control structures to prevent unexpected behaviors due to break or continue statements.
      • S3.3.A2 Ensure that scenarios where sender and recipient are the same are considered to prevent unintended issues in smart contracts.
      • S3.3.A3 Ensure that the NonReentrant modifier is applied before other modifiers in functions to prevent reentrancy attacks.
      • S3.3.A4 Verify that the check-effect-interaction pattern is implemented to prevent reentrancy attacks.
      • S3.3.A5 Ensure that function calls with arbitrary user input and low-level calls are handled securely to avoid introducing risks.
    • S3.3.B Function integrity
      • S3.3.B1 Ensure that functions intended to be unique per parameter set are not callable multiple times to prevent potential issues.
      • S3.3.B2 Verify that state changes in functions, such as withdraw and deposit, are symmetrically handled to avoid undesired behavior due to inconsistencies.
• S4. Access Control and Authentication
  • S4.1 Role-Based Access Control (RBAC)
    • S4.1.A Multi-signature schemes
      • S4.1.A1 Ensure that the visibility modifier for all functions is appropriate, preventing unnecessary exposure of internal functions.
    • S4.1.B Identity verification
      • S4.1.B1 Validate that unexpected addresses do not result in unintended behaviors, particularly when these addresses refer to contracts within the same protocol.
      • S4.1.B2 Verify that functions like ecrecover handle all potential null addresses properly to avoid vulnerabilities arising from unexpected ecrecover outputs
    • S4.1.C Least Privilege Principle
      • S4.1.C1 Use msg.sender instead of tx.origin for authorization to avoid potential abuse from malicious contracts; include checks like require(tx.origin == msg.sender) to ensure the sender is an EOA.
      • S4.1.C2 Certain addresses might be blocked or restricted from receiving tokens (e.g., LUSD). Ensure that address restrictions are properly managed and verified.
      • S4.1.C3 Ensure that Guard’s hooks (e.g., checkTransaction(), checkAfterExecution()) are executed to enforce critical security checks.
      • S4.1.C4 Ensure that access controls are implemented correctly to determine who can use certain functions, and avoid unauthorized changes or withdrawals.
  • S4.2 Authorization Mechanisms
    • S4.2.A Secure access to critical functions
      • S4.2.A1 Verify that the contract uses msg.sender for authorization instead of tx.origin to avoid vulnerabilities related to contracts that forward calls from legitimate users.
      • S4.2.A2 Implement and verify appropriate access controls for functions that modify contract state or perform sensitive operations to prevent unauthorized access.
    • S4.2.B Timed Permissions
      • S4.2.B1 Ensure that msg.sender validation is properly implemented when using Merkle trees to maintain security and prevent unauthorized access.
      • S4.2.B2 Use whitelisting to restrict interactions to a specific set of addresses, providing additional security against malicious actors.
      • S4.2.B3 Ensure that functions modifying the contract state or accessing sensitive operations have proper access controls implemented.
  • S4.3 Decentralized Identity
    • S4.3.A Decentralized Identifiers (DIDs)
      • S4.3.A1 Verify that the smart contract for handling DIDs adheres to the latest standards and best practices for decentralized identity management.
      • S4.3.A2 Ensure that the DID management contract includes mechanisms to prevent unauthorized modifications and ensure the integrity of DID records.
      • S4.3.A3 Check that DID documents managed by the smart contract are securely stored and can be retrieved in a decentralized manner.
      • S4.3.A4 Verify that the smart contract supports reliable DID resolution and includes mechanisms for handling conflicts and updates.
      • S4.3.A5 Ensure that the smart contract maintains the privacy and confidentiality of DID-related information throughout its lifecycle.
    • S4.3.B Verifiable Credentials
      • S4.3.B1 Verify that the smart contract manages verifiable credentials in a way that ensures their authenticity and integrity through cryptographic proofs.
      • S4.3.B2 Ensure that the issuance process of verifiable credentials by the smart contract includes proper identity verification and validation procedures.
      • S4.3.B3 Check that the smart contract supports cryptographic proofs to verify the validity of credentials without disclosing sensitive information.
      • S4.3.B4 Verify that the smart contract includes a secure process for revoking verifiable credentials when necessary.
      • S4.3.B5 Ensure that the smart contract’s handling of verifiable credentials complies with relevant standards and best practices for secure credential management.
• S5. Secure Interactions and Communications
  • S5.1 Contract Interactions
    • S5.1.A Secure message passing
      • S5.1.A1 Ensure that calls to inherited functions from LzApp use recommended approaches (e.g., _lzSend) to avoid vulnerabilities associated with direct calls to lzEndpoint.send.
      • S5.1.A2 Ensure that when interacting with external contracts, the msg.sender remains consistent to avoid security issues related to unexpected changes in sender context.
      • S5.1.A3 Manage untrusted external contract calls to prevent unexpected results such as multiple withdrawals or out-of-order events
      • S5.1.A4 Missing verification of interacting pools can introduce risks. Ensure that all pools are properly verified before interaction to prevent potential security issues.
      • S5.1.A5 Verify that the low-level .delegatecall() is properly managed, acknowledging that it converts the return value to a Boolean without providing the execution outcome.
    • S5.1.B Minimal trusted surface
      • S5.1.B1 Verify that the smart contract minimizes its trusted surface by only interacting with other contracts and systems through well-defined and limited interfaces.
      • S5.1.B2 Ensure that the smart contract includes checks to validate the trustworthiness and authenticity of interacting parties before executing sensitive operations.
      • S5.1.B3 Check that the smart contract's interactions are designed to avoid dependencies on external data or contracts that could compromise security.
      • S5.1.B4 Verify that the contract handles failures or unexpected behaviors from external interactions gracefully to avoid cascading failures.
      • S5.1.B5 Ensure that interactions with other contracts are monitored and audited to detect and address any unusual or unauthorized activities.
  • S5.2 Oracle Integrations
    • S5.2.A Secure data feeds
      • S5.2.A1 Verify that the smart contract uses oracles that provide secure and tamper-proof data feeds, including checks for data integrity and authenticity.
      • S5.2.A2 Ensure that the smart contract validates the data received from oracles to prevent malicious or incorrect data from affecting contract operations.
      • S5.2.A3 Check that the smart contract includes fallback mechanisms in case of oracle failure or unreliable data.
      • S5.2.A4 Verify that the integration with oracles follows best practices for data security, including encryption and secure communication channels.
      • S5.2.A5 Ensure that the smart contract's oracle integration is designed to handle any potential discrepancies or conflicts in data from multiple sources.
    • S5.2.B Decentralized oracles
      • S5.2.B1 Verify that the smart contract uses decentralized oracles to enhance data reliability and prevent single points of failure or manipulation.
      • S5.2.B2 Ensure that the smart contract includes mechanisms to validate the consensus or majority opinion of decentralized oracles before taking actions based on their data.
      • S5.2.B3 Check that the smart contract accounts for potential latency or delays in data from decentralized oracles to maintain operational reliability.
      • S5.2.B4 Verify that the smart contract includes checks to prevent manipulation or collusion among decentralized oracles.
      • S5.2.B5 Ensure that the decentralized oracle integration adheres to standards for security and reliability in multi-oracle environments.
  • S5.3 Cross-Chain Interactions
    • S5.3.A Handling external calls securely
      • S5.3.A1 Ensure that parameters for Chainlink VRF (Verifiable Random Function) are thoroughly validated to prevent the fulfillRandomWord function from returning incorrect values instead of reverting.
      • S5.3.A2 Implement robust security checks for cross-chain messaging to ensure correct permissions and intended functionality.
      • S5.3.A3 Verify that contracts created using the CREATE opcode handle block reorganizations securely to prevent unexpected eliminations.
      • S5.3.A4 Ensure robust cross-chain messaging security checks to prevent replay attacks where signatures valid on one chain might be exploited on another.
    • S5.3.B Atomic swaps
      • S5.3.B1 Verify that the smart contract supports atomic swaps with robust mechanisms to ensure that swaps are completed successfully or not executed at all.
      • S5.3.B2 Ensure that the smart contract includes checks to validate the atomic swap conditions and prevent partial or fraudulent swaps.
      • S5.3.B3 Check that the smart contract handles potential failures or disputes in atomic swaps securely and fairly.
      • S5.3.B4 Verify that the atomic swap functionality is tested thoroughly to cover various scenarios and edge cases.
  • S5.4 Bridges
    • S5.4.A Cross-chain transaction security
      • S5.4.A1 Verify that the smart contract for cross-chain transactions includes robust mechanisms for verifying and validating transactions across different chains.
      • S5.4.A2 Ensure that the smart contract prevents double-spending and replay attacks in cross-chain transactions by implementing appropriate security checks.
      • S5.4.A3 Check that the cross-chain transaction contract handles communication and data integrity securely between different blockchain networks.
      • S5.4.A4 Verify that the smart contract includes fallback and recovery mechanisms for handling failures or inconsistencies in cross-chain transactions.
• S6. Cryptographic Practices
  • S6.1 Key Management
    • S6.1.A Secure handling and storage of private keys
      • S6.2.A1 Verify that the ecrecover() function handles malformed inputs correctly and does not return invalid data.
      • S6.2.A2 Ensure that signature verification mechanisms are robust against signature malleability and replay attacks, particularly by using nonces or hashed messages rather than relying solely on the signature itself.
      • S6.2.A3 Verify that SignatureChecker.isValidSignatureNow handles edge cases properly and does not revert unexpectedly, considering the ABI decoding issues introduced in Solidity 0.8.
      • S6.2.A4 Ensure that all signatures are checked thoroughly to prevent unauthorized transactions or actions due to weak or improperly managed signature validation.
      • S6.2.A5 Validate that signature protection mechanisms are up-to-date and resistant to signature malleability attacks by avoiding outdated libraries and practices.
    • S6.1.B Multi-signature wallets
      • S6.1.B1 Verify that multi-signature wallets require a predefined number of signatures before executing any transaction.
      • S6.1.B2 Ensure that the multi-signature wallet logic is resistant to replay attacks.
      • S6.1.B3 Verify that the process of adding or removing signatories from the multi-signature wallet is secure and controlled.
  • S6.2 Signature Verification
    • S6.2.A Cryptographic techniques for authentication
      • S6.2.A1 Ensure that cryptographic algorithms used for signature verification are secure and follow best practices.
    • S6.2.B Standard compliance (e.g., EIP-712)
      • S6.2.B1 Verify that ECDSA signature handling functions, such as ECDSA.recover and ECDSA.tryRecover, properly manage signature formats to prevent signature malleability, especially when handling both traditional 65-byte and EIP-2098 compact signatures
  • S6.3 Secure Random Number Generation
    • S6.3.A Best practices for randomness
      • S6.3.A1 Ensure that random number generation follows best practices and uses secure sources of entropy.
      • S6.3.A2 Verify that any random number generation is resistant to manipulation and prediction.
• S7. Arithmetic and Logic Security
  • S7.1 Preventing Overflow/Underflow
    • S7.1.A Use of safe math libraries
      • S7.1.A1 Verify that explicit type casting does not lead to overflow or underflow issues.
      • S7.1.A2 Verify that integer arithmetic operations do not exceed their bounds to prevent integer overflow or underflow vulnerabilities.
      • S7.1.A3 Ensure that operations involving time units and other expressions handle potential overflows correctly.
      • S7.1.A4 Verify that division by zero is correctly handled and causes a transaction revert to prevent unexpected behavior.
      • S7.1.A5 Ensure that variables are managed within their bounds to prevent reverts due to exceeding limits.
      • S7.1.A6 Ensure that arithmetic operations within the unchecked{} block are carefully managed to prevent unintentional overflow or underflow.
      • S7.1.A7 Confirm that inline assembly operations handle division by zero and overflow/underflow according to desired behavior and revert appropriately.
      • S7.1.A8 Implement checks to handle cases where operations might introduce unintended precision issues or rounding errors.
    • S7.1.B Fixed-point arithmetic
      • S7.1.B1 Verify that fixed-point arithmetic operations are performed safely to prevent overflow, underflow, and precision loss.
  • S7.2 Arithmetic Integrity
    • S7.2.A Secure calculations and logic
      • S7.2.A1 Ensure that price or rate calculations derived from asset balances are protected from manipulation, considering attack vectors like flash loans and donations
      • S7.2.A2 Ensure that the use of structs and arrays does not lead to data corruption or incorrect values due to storage encoding issues.
      • S7.2.A3 Avoid operations that could lead to unintended data type conversions or precision loss by ensuring arithmetic operations are performed correctly.
      • S7.2.A4 Enforce a minimum transaction amount to prevent attackers from clogging the network with zero amount or dust transactions.
      • S7.2.A5 Validate that financial operations respect associative properties, ensuring consistent outcomes whether operations are performed in aggregate or iteratively.
      • S7.2.A6 Implement proper rounding direction for calculations where accounting relies on user shares to avoid inaccuracies.
      • S7.2.A7 Validate that inequalities and comparisons are correctly implemented to handle edge values appropriately.
      • S7.2.A8 Ensure that abi.decode adheres to the type limits to avoid reverts due to overflow of target types.
      • S7.2.A9 Ensure that logical operators such as ==, !=, &&, ||, and ! are used correctly, especially when test coverage may be limited.
    • S7.2.B Precondition and postcondition checks
      • S7.2.B1 Ensure that multiplication is performed before division to maintain precision in calculations.
      • S7.2.B2 Ensure that multiplication is performed before division to maintain precision in calculations.
      • S7.2.B3 Ensure that the request confirmation number is high enough to mitigate risks associated with chain re-orgs.
      • S7.2.B4 Verify that off-by-one errors are avoided in loops and iterations, ensuring correct handling of list lengths and indexing.
      • S7.2.B5 Verify that unsigned integers are not used to represent negative values, as this can lead to erroneous behavior.
      • S7.2.B6 Verify that calculations with multiple terms handle all possible edge cases for min/max values to avoid errors.
• S8. Denial of Service (DoS)
  • S8.1 Gas Limits
    • S8.1.A Efficient loop and function design
      • S8.1.A1 Ensure that contracts are protected against insufficient gas griefing attacks by carefully managing gas consumption in critical functions.
      • S8.1.A2 Ensure that systems like the RocketDepositPool contract handle failures in functions like burn() gracefully.
      • S8.1.A3 Verify that gas usage in functions and loops is efficient to avoid out-of-gas errors.
      • S8.1.A4 Implement mechanisms to prevent denial of service attacks due to block gas limits, ensuring that transactions or operations do not exceed the gas limit constraints.
    • S8.1.B Fallback mechanisms
      • S8.1.B1 Ensure that try/catch blocks are provided with adequate gas to avoid failures and unexpected behavior in case of errors.
  • S8.2 Resilience Against Resource Exhaustion
    • S8.2.A Rate limiting
      • S8.2.A1 Avoid using blocking mechanisms that could lead to a Denial-of-Service (DoS) attack.
      • S8.2.A1 Protect against potential DoS in functions like supportsERC165InterfaceUnchecked() by handling excessive data queries efficiently.
      • S8.2.A2 Ensure that assertions do not lead to denial of service or unexpected contract reverts, especially in scenarios where conditions are not met.
      • S8.2.A3 Verify that return values from external function calls are checked to prevent issues related to unchecked return values, which could lead to unexpected behavior.
      • S8.2.A4 Ensure that contract functions are protected against denial of service due to unexpected reverts by handling all possible error conditions appropriately.
      • S8.2.A5 Ensure that functions such as supportsERC165InterfaceUnchecked() in ERC165Checker.sol handle large data queries efficiently to avoid excessive resource consumption.
• S9. Blockchain Data and State Management
  • S9.1 State Management
    • S9.1.A Efficient and secure state handling
      • S9.1.A1 Ensure that payable functions in contracts handle all ETH passed in msg.value and provide a mechanism for withdrawal to avoid ETH being locked in the contract.
      • S9.1.A2 Verify that deleting a variable of a nested structure correctly resets all nested level fields to default values to avoid unexpected behavior.
      • S9.1.A3 Verify that storage structs and arrays with types shorter than 32 bytes are handled correctly, avoiding data corruption when encoded directly from storage using the experimental ABIEncoderV2.
      • S9.1.A4 Verify that storage arrays containing structs or other statically-sized arrays are properly read and encoded in external function calls to prevent data corruption.
      • S9.1.A5 Ensure that copying bytes arrays from memory or calldata to storage handles empty arrays correctly, avoiding data corruption when the target array's length is increased subsequently without storing new data.
    • S9.1.B State channels
      • S9.1.B1 Verify that global state updates are correctly handled when working with memory copies to ensure accurate state management.
  • S9.2 Data Privacy
    • S9.2.A Ensuring sensitive data is secure
      • S9.2.A1 Ensure that private data marked in contracts is protected from unauthorized access through blockchain analysis.
    • S9.2.B Zero-knowledge proofs
      • S9.2.B1 Verify that zero-knowledge proofs are implemented to ensure privacy without revealing any underlying data.
      • S9.2.B2 Validate the correctness of proof generation and verification processes to prevent any potential leaks or exploits.
      • S9.2.B3 Ensure that zero-knowledge proofs are integrated seamlessly with the blockchain to maintain performance and security.
    • S9.2.C Private Transactions
      • S9.2.C1 Verify that private transaction mechanisms (e.g., zk-SNARKs, zk-STARKs) are correctly implemented to ensure confidentiality of transaction details.
      • S9.2.C2 Ensure that private transactions maintain the integrity and validity of the blockchain.
    • S9.2.D Confidential Contracts
      • S9.2.D1 Verify that confidential contracts use cryptographic techniques to hide contract state and execution details from unauthorized parties.
      • S9.2.D2 Ensure that only parties with appropriate permissions can access data within confidential contracts.
  • S9.3 Event Logging
    • S9.3.A Transparent and secure logging practices
      • S9.3.A1 Verify that events are emitted properly, especially for critical changes to ensure traceability and transparency.
      • S9.3.A2 Verify that the contract’s event logging correctly reflects critical changes to ensure transparency and traceability.
    • S9.3.B Log analysis
      • S9.3.B1 Implement tools and processes for analyzing event logs to detect anomalies or unauthorized changes.
      • S9.3.B2 Set up alerts for unusual patterns or discrepancies in logged events.
  • S9.4 Decentralized Storage
    • S9.4.A IPFS, Arweave
      • S9.4.A1 Ensure that data stored on decentralized platforms like IPFS or Arweave is encrypted and access-controlled.
      • S9.4.A2 Implement mechanisms for data redundancy and backup to ensure data availability.
• S10. Gas Usage, Efficiency, and Limitations
  • S10.1 Optimizing Gas Usage
    • S10.1.A Understanding gas costs and limits
      • S10.1.A1 Implement best practices for optimizing gas consumption to ensure cost-effective and efficient contract execution.
    • S10.1.B Gas estimation tools
      • S10.1.B1 Verify that transaction confirmation numbers are chosen appropriately to mitigate risks related to chain re-orgs and ensure reliable contract operation.
  • S10.2 Efficient Contract Design
    • S10.2.A Layer 2 solutions
      • S10.2.A1 Explore and integrate Layer 2 scaling solutions (e.g., rollups, state channels) to improve transaction throughput and reduce gas costs.
      • S10.2.A2 Verify the security and reliability of Layer 2 solutions before integration.
• S11. Component-Specific Security
  • S11.1 Tokens (ERC20, ERC721, ERC1155)
    • S11.1.A Secure implementation and management
      • S11.1.A1 Verify that the totalSupply value is consistent during token minting operations, ensuring that callbacks do not result in incorrect values.
      • S11.1.A2 Some tokens have multiple addresses associated with them, which can introduce vulnerabilities. Ensure all token addresses are managed and verified securely to avoid related risks.
      • S11.1.A3 Verify that tokens handle zero amount transfers properly to prevent issues in integrations and operations.
      • S11.1.A4 Verify that tokens handle zero amount transfers properly to prevent issues in integrations and operations.
      • S11.1.A5 Some tokens revert on the transfer of a zero amount, which can cause issues in certain integrations and operations. Ensure compatibility with such tokens to avoid integration problems.
      • S11.1.A6 Not all ERC20 tokens comply with the EIP20 standard; some may not return a boolean flag or revert on failure. Verify compliance with the ERC20 standard to avoid compatibility issues.
  • S11.2 NFT Security
    • S11.2.A Best practices for non-fungible tokens
      • S11.2.A1 Implement standards and best practices for NFT creation, management, and transfer to prevent common vulnerabilities.
      • S11.2.A2 Ensure proper metadata integrity and prevent unauthorized minting or transfers.
      • S11.2.A3 Safeguard against potential exploits related to royalty payments or token burns.
  • S11.3 Vaults
    • S11.3.A Secure asset storage and management
      • S11.3.A1 Address potential overhead issues associated with withdrawing stETH or wstETH, including queue times and withdrawal limits, to ensure smooth operations.
      • S11.3.A2 Handle conversions between stETH and wstETH carefully to avoid potential issues due to the rebasing nature of stETH.
  • S11.4 Liquid Staking
    • S11.4.A Secure staking mechanisms
      • S11.4.A1 Verify that mechanisms for detaching sfrxETH from frxETH are robust to prevent discrepancies and ensure accurate reward transfers, particularly when controlled by centralized entities.
      • S11.4.A2 Monitor potential future changes in the sfrxETH/ETH rate and ensure users are adequately forewarned to mitigate risks associated with rate fluctuations.
  • S11.5 Liquidity Pools (AMMs)
    • S11.5.A Security in automated market makers
      • S11.5.A1 [WIP/Will be removed]
  • S11.6 Uniswap V4 Hook
    • S11.6.A Secure integration and customization
      • S11.6.A1 Verify the correct usage of Uniswap’s TickMath and FullMath libraries to ensure proper handling of unchecked arithmetic operations, adhering to version-specific Solidity considerations