Merge pull request #6 from Credshields/dev

Dev

0.1/en/0x10-S1-Architecture_Design_and_Threat_Modeling.md

@@ -4,7 +4,9 @@
 
 ### Control Objective
 Ensure that smart contracts are designed with modularity, upgradability, and separation of concerns to enable secure operations, upgrades, and maintenance. Contracts should be designed to minimize security risks related to complex upgrades, privilege transfers, and mismanagement of dependencies.
+
 ### Security Verification Requirements
+
 ### S1.1.A Modularity and Upgradability
 
 | Ref          | Requirement                                                                 | L1 | L2 | L3 | SWE |

0.1/en/0x11-S2-Policies_Procedures_and_Code_Management.md

@@ -3,8 +3,6 @@
 ## Control Objective
 Ensure that development policies and procedures are in place to promote secure coding practices, thorough code reviews, and comprehensive testing. The aim is to prevent vulnerabilities and enhance the maintainability and clarity of smart contract code.
 
----
-
 ## S2.1 Development Policies
 
 ### Control Objective
@@ -27,8 +25,6 @@ Establish and enforce secure coding standards and review processes to minimize v
 | 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
 
 ### Control Objective
@@ -53,7 +49,6 @@ Promote code clarity and maintainability through thorough documentation, logical
 | 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
 

0.1/en/0x12-S3-Business_Logic_and_Economic_Security.md

@@ -3,7 +3,6 @@
 ## Control Objective
 Ensure that the smart contract's business logic and economic security are resilient against threats related to incentive structures, tokenomics, and logic vulnerabilities. Contracts should prevent abuse, misbehavior, or unexpected behaviors by implementing secure economic models, token handling, and transaction integrity.
 
----
 
 ## S3.1 Economic Models
 
@@ -19,7 +18,6 @@ Ensure that economic models, including incentive structures and tokenomics, are
 | 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
 
@@ -36,7 +34,6 @@ Ensure that tokens used within the smart contract ecosystem are securely impleme
 | 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
 

0.1/en/0x13-S4-Access-Control_and_Authentication.md

@@ -3,8 +3,6 @@
 ## Control Objective
 Establish robust access control and authentication mechanisms to ensure that only authorized entities can perform sensitive operations within the smart contract. This includes implementing role-based access control (RBAC), secure authorization mechanisms, and decentralized identity management.
 
----
-
 ## S4.1 Role-Based Access Control (RBAC)
 
 ### Control Objective
@@ -32,7 +30,6 @@ Implement role-based access control to manage permissions and ensure that only a
 | 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
 
@@ -54,7 +51,6 @@ Implement secure authorization mechanisms to safeguard critical functions and se
 | 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
 

0.1/en/0x14-S5-Secure-Interactions_and_Communications.md

@@ -3,7 +3,6 @@
 ## Control Objective
 Establish secure interaction protocols for smart contracts to ensure safe communication between contracts, external oracles, and cross-chain integrations. This includes managing contract interactions, securing oracle integrations, handling cross-chain interactions, and ensuring the security of bridges.
 
----
 
 ## S5.1 Contract Interactions
 
@@ -30,7 +29,6 @@ Ensure that all interactions between contracts are secure, minimizing risks asso
 | 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
 
@@ -57,7 +55,6 @@ Ensure that oracle integrations provide secure, reliable, and tamper-proof data
 | 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
 
@@ -82,8 +79,6 @@ Ensure secure handling of external calls and atomic swaps during cross-chain int
 | 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
 
 ### Control Objective

0.1/en/0x15-S6-Cryptographic-Practices.md

@@ -3,8 +3,6 @@
 ## Control Objective
 Establish secure cryptographic practices for managing keys, verifying signatures, and generating random numbers to protect the integrity and authenticity of transactions and data within smart contracts.
 
----
-
 ## S6.1 Key Management
 
 ### Control Objective
@@ -28,7 +26,6 @@ Ensure secure handling and storage of private keys and implement robust signatur
 | 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
 
@@ -47,8 +44,6 @@ Implement cryptographic techniques that ensure the secure verification of signat
 | ------------ | --------------------------------------------------------------------------- | -- | -- | -- | --- |
 | 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
 
 ### Control Objective

0.1/en/0x16-S7-Arithmetic_and_Logic-Security.md

@@ -3,7 +3,6 @@
 ## Control Objective
 Establish secure arithmetic and logic practices to prevent vulnerabilities such as overflow/underflow and ensure the integrity of calculations within smart contracts.
 
----
 
 ## S7.1 Preventing Overflow/Underflow
 
@@ -29,7 +28,6 @@ Implement safe arithmetic practices to prevent overflow and underflow vulnerabil
 | ------------ | --------------------------------------------------------------------------- | -- | -- | -- | --- |
 | S7.1.B1      | Verify that fixed-point arithmetic operations are performed safely to prevent overflow, underflow, and precision loss. |    | ✓  | ✓  |     |
 
----
 
 ## S7.2 Arithmetic Integrity
 

0.1/en/0x17-S8-Denial-of-Service-DoS.md

@@ -3,7 +3,6 @@
 ## Control Objective
 Establish practices and mechanisms to prevent Denial of Service (DoS) attacks that can disrupt contract functionality and availability.
 
----
 
 ## S8.1 Gas Limits
 
@@ -25,7 +24,6 @@ Ensure that contract design and function implementations are efficient in gas us
 | ------------ | --------------------------------------------------------------------------- | -- | -- | -- | --- |
 | 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
 

0.1/en/0x18-S9-Blockchain-Data_and-State-Management.md

@@ -3,8 +3,6 @@
 ## Control Objective
 Establish practices for effective management of blockchain data and state to ensure security, efficiency, and integrity of contract interactions.
 
----
-
 ## S9.1 State Management
 
 ### Control Objective
@@ -26,7 +24,6 @@ Ensure efficient and secure handling of state within smart contracts to prevent
 | ------------ | --------------------------------------------------------------------------- | -- | -- | -- | --- |
 | 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
 
@@ -61,8 +58,6 @@ Ensure that sensitive data within contracts is secured and that privacy measures
 | 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
 
 ### Control Objective
@@ -82,7 +77,6 @@ Implement transparent and secure logging practices to ensure traceability and de
 | 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
 

0.1/en/0x19-S10-Gas-Usage-Efficiency_and-limitations.md

@@ -3,8 +3,6 @@
 ## Control Objective
 Establish practices for optimizing gas usage and efficiency in smart contracts to minimize costs and enhance performance.
 
----
-
 ## S10.1 Optimizing Gas Usage
 
 ### Control Objective
@@ -22,7 +20,6 @@ Ensure gas consumption is minimized to promote cost-effective execution of smart
 | ------------ | --------------------------------------------------------------------------- | -- | -- | -- | --- |
 | 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
 

0.1/en/0x20-S11-Component-Specific-Security.md

@@ -3,8 +3,6 @@
 ## Control Objective
 Establish security practices and standards for various blockchain components to mitigate specific vulnerabilities associated with tokens, NFTs, vaults, and liquidity pools.
 
----
-
 ## S11.1 Tokens (ERC20, ERC721, ERC1155)
 
 ### Control Objective
@@ -21,7 +19,6 @@ Ensure secure implementation and management of token standards to prevent vulner
 | 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
 
@@ -36,7 +33,6 @@ Implement best practices for non-fungible tokens to safeguard against vulnerabil
 | 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
 
@@ -50,7 +46,6 @@ Ensure secure asset storage and management within vault systems.
 | 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
 
@@ -64,7 +59,6 @@ Ensure secure staking mechanisms to protect users' assets.
 | 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)
 
@@ -77,7 +71,7 @@ Establish security measures in automated market makers.
 | ------------ | --------------------------------------------------------------------------- | -- | -- | -- | --- |
 | S11.5.A1     | [WIP/Will be removed]                                                     |    |    |    |     |
 
----
+
 
 ## S11.6 Uniswap V4 Hook