| SCSVS-ARCH-1 |
S1.1.A1 |
SCSTG-TEST-0005 |
Verify modularity and upgradability. |
- Are the smart contracts using import statements to include other contracts and libraries? |
|
|
|
|
- Are functions within the contract logically separated and grouped into different contracts or libraries? |
| SCSVS-ARCH-1 |
S1.1.A2 |
SCSTG-TEST-0006 |
Ensure secure and controlled updates. |
- Is the contract using a proxy pattern (e.g., Transparent Proxy or UUPS Proxy) for upgradability? |
|
|
|
|
- Are the upgradeTo or similar functions protected with onlyOwner or onlyAdmin modifiers? |
|
|
|
|
- Are there migration functions to safely transfer state variables to the new contract version? |
| SCSVS-ARCH-1 |
S1.1.A3 |
SCSTG-TEST-0006 |
Check module boundaries and dependencies. |
- Are interfaces and abstract contracts used to define boundaries between modules? |
|
|
|
|
- Are external calls to other modules made through well-defined interfaces? |
| SCSVS-ARCH-1 |
S1.1.A4 |
SCSTG-TEST-0006 |
Ensure changes to storage variables are managed. |
- Is there a well-documented storage layout for the contract? |
|
|
|
|
- Are storage variables added in storage gaps to avoid conflicts? |
| SCSVS-ARCH-1 |
S1.1.A5 |
SCSTG-TEST-0006 |
Verify critical privilege transfers. |
- Is there a two-step process for transferring ownership using transferOwnership and claimOwnership? |
|
|
|
|
- Are there events emitted for each step of the transfer process? |
| SCSVS-ARCH-1 |
S1.1.A6 |
SCSTG-TEST-0006 |
Verify data location handling in function overrides. |
- Are memory and storage keywords correctly used for parameters and return variables in overridden functions? |
|
|
|
|
- Are there tests covering function overrides to ensure no invalid virtual function calls? |
| SCSVS-ARCH-1 |
S1.1.B1 |
No Test ID |
Verify separation of different functionalities. |
- Are the contracts modular with clearly defined responsibilities? |
|
|
|
|
- Is there a single responsibility per contract or module? |
| SCSVS-ARCH-1 |
S1.1.B2 |
No Test ID |
Ensure minimal dependencies between modules. |
- Are modules loosely coupled? |
|
|
|
|
- Is each module's responsibility clearly defined and limited? |
| SCSVS-ARCH-1 |
S1.1.B3 |
No Test ID |
Check for cross-module dependencies. |
- Are there dependencies that could introduce security vulnerabilities? |
|
|
|
|
- Is each module's responsibility clearly defined and limited? |
| SCSVS-ARCH-1 |
S1.1.B4 |
No Test ID |
Ensure consistent operation during privilege transfers. |
- Are edge cases considered during privilege transfers? |
|
|
|
|
- Is there a fallback mechanism in case of transfer failure? |
| SCSVS-ARCH-1 |
S1.1.B5 |
No Test ID |
Verify proxy contract initialization. |
- Are proxy contracts using the onlyInitializing modifier? |
|
|
|
|
- Is there a check to prevent re-initialization? |
| SCSVS-ARCH-1 |
S1.1.B6 |
No Test ID |
Verify storage layout consistency. |
- Are storage layouts compatible across different contract versions? |
|
|
|
|
- Is there documentation for storage layout changes? |
| SCSVS-ARCH-1 |
S1.1.B7 |
No Test ID |
Ensure immutable variable consistency. |
- Are immutable variables properly defined and documented? |
|
|
|
|
- Is there a verification process for consistency across upgrades? |
| SCSVS-ARCH-1 |
S1.1.B8 |
No Test ID |
Verify consistency in logic implementation. |
- Is logic implemented consistently across the contract? |
|
|
|
|
- Is there a review process for verifying consistency? |
| SCSVS-ARCH-1 |
S1.1.B9 |
No Test ID |
Ensure separate handling of ETH and WETH. |
- Are ETH and WETH treated as distinct entities? |
|
|
|
|
- Are there checks in place to handle ETH and WETH appropriately? |
| SCSVS-ARCH-1 |
S1.1.B10 |
No Test ID |
Verify proxy setup for contracts with constructors. |
- Are contracts designed without constructors for proxy setups? |
|
|
|
|
- Is initializer logic implemented and verified? |
| SCSVS-ARCH-2 |
S1.2.A1 |
No Test ID |
Verify implementation of upgrade mechanisms. |
- Is the contract using a well-known proxy pattern such as Transparent Proxy or UUPS Proxy? |
|
|
|
|
- Are there unit tests verifying the upgrade functionality? |
|
|
|
|
- Is the upgrade mechanism designed to be easily extensible for future upgrades? |
| SCSVS-ARCH-2 |
S1.2.A2 |
No Test ID |
Ensure safeguards against unauthorized upgrades. |
- Is the upgradeTo function protected by onlyOwner or onlyAdmin modifiers? |
|
|
|
|
- Are access controls and ownership mechanisms properly tested and reviewed? |
|
|
|
|
- Are multi-signature wallets or other advanced access control mechanisms used for upgrade authorization? |
| SCSVS-ARCH-2 |
S1.2.A3 |
No Test ID |
Review and document the upgrade mechanism. |
- Is the upgrade mechanism thoroughly documented in the project documentation? |
|
|
|
|
- Has the upgrade mechanism undergone a formal security audit? |
|
|
|
|
- Are there guidelines and best practices documented for performing upgrades? |
| SCSVS-ARCH-2 |
S1.2.A4 |
No Test ID |
Verify consistency of immutable variables. |
- Are immutable variables defined and documented across all contract versions? |
|
|
|
|
- Is there a validation process to ensure consistency of immutable variables during upgrades? |
|
|
|
|
- Are there automated tests checking the state of immutable variables before and after upgrades? |
| SCSVS-ARCH-2 |
S1.2.A5 |
No Test ID |
Verify use of selfdestruct and delegatecall in proxy setup. |
- Is there a review process for identifying and mitigating risks associated with selfdestruct and delegatecall? |
|
|
|
|
- Are there unit tests covering scenarios involving selfdestruct and delegatecall? |
|
|
|
|
- Is the use of selfdestruct and delegatecall documented and justified in the contract? |
| SCSVS-ARCH-2 |
S1.2.A6 |
No Test ID |
Protect UUPSUpgradeable contracts. |
- Are UUPSUpgradeable contracts tested for initialization-related vulnerabilities? |
|
|
|
|
- Is there a mechanism to ensure that implementation contracts are properly initialized before use? |
|
|
|
|
- Are there security reviews focused on initialization and upgrade vulnerabilities in UUPSUpgradeable contracts? |
| SCSVS-ARCH-2 |
S1.2.B1 |
No Test ID |
Verify handling of deprecated contract versions. |
- Are deprecated contract versions clearly marked with appropriate deprecation notices in the code and documentation? |
|
|
|
|
- Is there a mechanism to disable functionality in deprecated contracts while maintaining state integrity? |
|
|
|
|
- Are deprecated contracts archived and isolated from the main deployment pipeline to prevent accidental usage? |
| SCSVS-ARCH-2 |
S1.2.B2 |
No Test ID |
Ensure restriction or disabling of access to deprecated versions. |
- Are access controls updated to restrict interactions with deprecated contract versions? |
|
|
|
|
- Is there a revocation process in place to revoke permissions or keys associated with deprecated contracts? |
|
|
|
|
- Are deprecated contracts audited to ensure no critical functions remain accessible post-deprecation? |
| SCSVS-ARCH-2 |
S1.2.B3 |
No Test ID |
Check security of migration paths from deprecated versions. |
- Is there a documented and tested migration plan for transitioning from deprecated to new contract versions? |
|
|
|
|
- Are migration scripts and tools audited for security vulnerabilities that could compromise the migration process? |
|
|
|
|
- Is there a rollback mechanism in case the migration encounters issues, ensuring no loss of state or functionality? |
| SCSVS-ARCH-3 |
S1.3.C1 |
No Test ID |
Verify implementation of high-priority risk mitigations. |
- Are there specific mitigations in place for reentrancy attacks, such as the use of checks-effects-interactions pattern or reentrancy guards? |
|
|
|
|
- Are overflow and underflow checks implemented using SafeMath or Solidity's built-in overflow protection? |
|
|
|
|
- Are access controls and role-based permissions thoroughly tested to prevent unauthorized access? |
| SCSVS-ARCH-3 |
S1.3.C2 |
No Test ID |
Ensure documentation and testing of mitigation strategies. |
- Are all mitigation strategies documented with clear explanations of how they address specific vulnerabilities? |
|
|
|
|
- Are there unit and integration tests specifically designed to validate the effectiveness of each mitigation strategy? |
|
|
|
|
- Is there a process for continuously updating the documentation and tests as new threats and mitigations are identified? |
| SCSVS-ARCH-3 |
S1.3.C3 |
No Test ID |
Review and validate effectiveness of implemented mitigations. |
- Are periodic security audits conducted to review and validate the effectiveness of implemented mitigations? |
|
|
|
|
- Are there automated tools and scripts in place to continuously monitor the security posture of the smart contracts? |
|
|
|
|
- Is there a feedback loop for integrating audit findings and monitoring results into the mitigation strategy? |