solidity-argus 0.1.0

package/skills/checklists/cyfrin-best-practices-runtime/SKILL.md

@@ -0,0 +1,424 @@
+---
+name: cyfrin-best-practices-runtime
+description: Cyfrin best-practice checklist focused on runtime heuristics, cross-chain concerns, and timelock controls
+---
+<!-- Source: Cyfrin/audit-checklist -->
+<!-- Auto-generated from https://github.com/Cyfrin/audit-checklist -->
+
+# Cyfrin Audit Checklist — Best Practices (Runtime & Cross-chain)
+
+### Basics > Version Issues > Solidity Version Issues
+
+- [ ] **[SOL-Basics-VI-SVI-1]** Does the contract encode storage structs or arrays with types under 32 bytes directly using experimental ABIEncoderV2? (version 0.5.0~0.5.6)
+  - Storage structs and arrays with types shorter than 32 bytes can cause data corruption if encoded directly from storage using the experimental ABIEncoderV2.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-2]** Are there any instances where empty strings are directly passed to function calls? (version ~0.4.11)
+  - If an empty string is used in a function call, the following function arguments will not be correctly passed to the function.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-3]** Does the optimizer replace specific constants with alternative computations? (version ~0.4.10)
+  - In some situations, the optimizer replaces certain numbers in the code with routines that compute different numbers.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2017/05/03/solidity-optimizer-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-4]** Does the contract use `abi.encodePacked`, especially in hash generation? (version >= 0.8.17)
+  - If you use `keccak256(abi.encodePacked(a, b))` and both `a` and `b` are dynamic types, it is easy to craft collisions in the hash value by moving parts of `a` into `b` and vice-versa. More specifically, `abi.encodePacked(\'a\', \'bc\') == abi.encodePacked(\'ab\', \'c\').
+  - **Remediation:** Use `abi.encode` instead of `abi.encodePacked`.
+  - **References:**
+    - https://solodit.xyz/issues/m-1-abiencodepacked-allows-hash-collision-sherlock-nftport-nftport-git
+    - https://docs.soliditylang.org/en/v0.8.17/abi-spec.html?highlight=collisions#non-standard-packed-mode
+
+- [ ] **[SOL-Basics-VI-SVI-5]** BUILD: Is the contract optimized using sequences containing FullInliner with non-expression-split code? (version 0.6.7~0.8.20)
+  - Optimizer sequences containing FullInliner do not preserve the evaluation order of arguments of inlined function calls in code that is not in expression-split form.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2023/07/19/full-inliner-non-expression-split-argument-evaluation-order-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-6]** Are there any functions that conditionally terminate inside an inline assembly? (version 0.8.13~0.8.16)
+  - Calling functions that conditionally terminate the external EVM call using the assembly statements ``return(...)`` or ``stop()`` may result in incorrect removals of prior storage writes.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2022/09/08/storage-write-removal-before-conditional-termination/
+
+- [ ] **[SOL-Basics-VI-SVI-7]** Are tuples containing a statically-sized calldata array at the end being ABI-encoded? (version 0.5.8~0.8.15)
+  - ABI-encoding a tuple with a statically-sized calldata array in the last component would corrupt 32 leading bytes of its first dynamically encoded component.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2022/08/08/calldata-tuple-reencoding-head-overflow-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-8]** Does the contract have functions that copy `bytes` arrays from memory or calldata directly to storage? (version 0.0.1~0.8.14)
+  - Copying ``bytes`` arrays from memory or calldata to storage may result in dirty storage values.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2022/06/15/dirty-bytes-array-to-storage-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-9]** Is there a function with multiple inline assembly blocks? (version 0.8.13~0.8.14)
+  - The Yul optimizer may incorrectly remove memory writes from inline assembly blocks, that do not access solidity variables.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2022/06/15/inline-assembly-memory-side-effects-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-10]** Is a nested array being ABI-encoded or passed directly to an external function? (version 0.5.8~0.8.13)
+  - ABI-reencoding of nested dynamic calldata arrays did not always perform proper size checks against the size of calldata and could read beyond `calldatasize()`.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2022/05/17/calldata-reencode-size-check-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-11]** Is `abi.encodeCall` used together with fixed-length bytes literals? (version 0.8.11~0.8.12)
+  - Literals used for a fixed length bytes parameter in ``abi.encodeCall`` were encoded incorrectly.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2022/03/16/encodecall-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-12]** Is there any user defined types based on types shorter than 32 bytes? (version =0.8.8)
+  - User defined value types with underlying type shorter than 32 bytes used incorrect storage layout and wasted storage
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2021/09/29/user-defined-value-types-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-13]** Is there an immutable variable of signed integer type shorter than 256 bits? (version 0.6.5~0.8.8)
+  - Immutable variables of signed integer type shorter than 256 bits can lead to values with invalid higher order bits if inline assembly is used.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2021/09/29/signed-immutables-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-14]** Is there any use of `abi.encode` on memory with multi-dimensional array or structs? (version 0.4.16~0.8.3)
+  - If used on memory byte arrays, result of the function ``abi.decode`` can depend on the contents of memory outside of the actual byte array that is decoded.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2021/04/21/decoding-from-memory-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-15]** Is there an inline assembly block with `keccak256` inside? (version ~0.8.2)
+  - The bytecode optimizer incorrectly re-used previously evaluated Keccak-256 hashes. You are unlikely to be affected if you do not compute Keccak-256 hashes in inline assembly.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2021/03/23/keccak-optimizer-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-16]** Is there a copy of an empty `bytes` or `string` from `memory` or `calldata` to `storage`? (version ~0.7.3)
+  - Copying an empty byte array (or string) from memory or calldata to storage can result in data corruption if the target array's length is increased subsequently without storing new data.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2020/10/19/empty-byte-array-copy-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-17]** Is there a dynamically-sized storage-array with types of size at most 16 bytes? (version ~0.7.2)
+  - When assigning a dynamically-sized array with types of size at most 16 bytes in storage causing the assigned array to shrink, some parts of deleted slots were not zeroed out.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2020/10/07/solidity-dynamic-array-cleanup-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-18]** Does the library use contract types in events? (version 0.5.0~0.5.7)
+  - Contract types used in events in libraries cause an incorrect event signature hash
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-19]** Does the contract use internal library functions with calldata parameters via `using for`? (version =0.6.9)
+  - Function calls to internal library functions with calldata parameters called via ``using for`` can result in invalid data being read.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-20]** Are string literals with double backslashes passed directly to external or encoding functions with ABIEncoderV2 enabled? (version 0.5.14~0.6.7)
+  - String literals containing double backslash characters passed directly to external or encoding function calls can lead to a different string being used when ABIEncoderV2 is enabled.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-21]** Does the contract access slices of dynamic arrays, especially multi-dimensional ones? (version 0.6.0~0.6.7)
+  - Accessing array slices of arrays with dynamically encoded base types (e.g. multi-dimensional arrays) can result in invalid data being read.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-22]** Is there a contract with creation code, no constructor, but a base with a constructor that accepts non-zero values? (version 0.4.5~0.6.7)
+  - The creation code of a contract that does not define a constructor but has a base that does define a constructor did not revert for calls with non-zero value.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-23]** Does the contract create extremely large memory arrays? (version 0.2.0~0.6.4)
+  - The creation of very large memory arrays can result in overlapping memory regions and thus memory corruption.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2020/04/06/memory-creation-overflow-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-24]** Does the contract's inline assembly with Yul optimizer use assignments inside for loops combined with continue or break? (version =0.6.0)
+  - The Yul optimizer can remove essential assignments to variables declared inside for loops when Yul's continue or break statement is used. You are unlikely to be affected if you do not use inline assembly with for loops and continue and break statements.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-25]** Does the contract allow private methods to be overridden by inheriting contracts? (version 0.3.0~0.5.16)
+  - Private methods can be overridden by inheriting contracts.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-26]** Is there any Yul's continue or break statement inside the loop?? (version 0.5.8~0.5.15)
+  - The Yul optimizer can remove essential assignments to variables declared inside for loops when Yul's continue or break statement is used. You are unlikely to be affected if you do not use inline assembly with for loops and continue and break statements.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-27]** Are both experimental ABIEncoderV2 and Yul optimizer activated? (version =0.5.14)
+  - If both the experimental ABIEncoderV2 and the experimental Yul optimizer are activated, one component of the Yul optimizer may reuse data in memory that has been changed in the meantime.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-28]** Does the contract read from calldata structs with dynamic yet statically-sized members? (version 0.5.6~0.5.10)
+  - Reading from calldata structs that contain dynamically encoded, but statically-sized members can result in incorrect values.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-29]** Does the contract assign arrays of signed integers to differently typed storage arrays? (version 0.4.7~0.5.9)
+  - Assigning an array of signed integers to a storage array of different type can lead to data corruption in that array.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2019/06/25/solidity-storage-array-bugs/
+
+- [ ] **[SOL-Basics-VI-SVI-30]** Does the contract directly encode storage arrays with structs or static arrays in external calls or abi.encode*? (version 0.4.16~0.5.9)
+  - Storage arrays containing structs or other statically-sized arrays are not read properly when directly encoded in external function calls or in abi.encode*.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2019/06/25/solidity-storage-array-bugs/
+
+- [ ] **[SOL-Basics-VI-SVI-31]** Does the contract's constructor accept structs or arrays with dynamic arrays? (version 0.4.16~0.5.8)
+  - A contract's constructor that takes structs or arrays that contain dynamically-sized arrays reverts or decodes to invalid data.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-32]** Are uninitialized internal function pointers created in the constructor being called? (version 0.5.0~0.5.7)
+  - Calling uninitialized internal function pointers created in the constructor does not always revert and can cause unexpected behavior.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-33]** Are uninitialized internal function pointers created in the constructor being called? (version 0.4.5~0.4.25)
+  - Calling uninitialized internal function pointers created in the constructor does not always revert and can cause unexpected behavior.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-34]** Does the library use contract types in events? (version 0.3.0~0.4.25)
+  - Contract types used in events in libraries cause an incorrect event signature hash
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-35]** Does the contract encode storage structs or arrays with types under 32 bytes directly using experimental ABIEncoderV2? (version 0.4.19~0.4.25)
+  - Storage structs and arrays with types shorter than 32 bytes can cause data corruption if encoded directly from storage using the experimental ABIEncoderV2.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-36]** Does the contract's optimizer handle byte opcodes with a second argument of 31 or an equivalent constant expression? (version 0.5.5~0.5.6)
+  - The optimizer incorrectly handles byte opcodes whose second argument is 31 or a constant expression that evaluates to 31. This can result in unexpected values.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-37]** Are there double bitwise shifts with large constants that might sum up to overflow 256 bits? (version =0.5.5)
+  - Double bitwise shifts by large constants whose sum overflows 256 bits can result in unexpected values.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2019/03/26/solidity-optimizer-and-abiencoderv2-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-38]** Is the ** operator used with an exponent type shorter than 256 bits? (version ~0.4.24)
+  - Using the ** operator with an exponent of type shorter than 256 bits can result in unexpected values.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/
+
+- [ ] **[SOL-Basics-VI-SVI-39]** Are structs used in the logged events? (version 0.4.17~0.4.24)
+  - Using structs in events logged wrong data.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/
+
+- [ ] **[SOL-Basics-VI-SVI-40]** Are functions returning multi-dimensional fixed-size arrays called? (version 0.1.4~0.4.21)
+  - Calling functions that return multi-dimensional fixed-size arrays can result in memory corruption.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2018/09/13/solidity-bugfix-release/
+
+- [ ] **[SOL-Basics-VI-SVI-41]** Does the contract use both new-style and old-style constructors simultaneously? (version =0.4.22)
+  - If a contract has both a new-style constructor (using the constructor keyword) and an old-style constructor (a function with the same name as the contract) at the same time, one of them will be ignored.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-42]** Is there a function name crafted to potentially override the fallback function execution? (version ~0.4.17)
+  - It is possible to craft the name of a function such that it is executed instead of the fallback function in very specific circumstances.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-43]** Is the low-level .delegatecall() used without checking the actual execution outcome? (version 0.3.0~0.4.14)
+  - The low-level .delegatecall() does not return the execution outcome, but converts the value returned by the functioned called to a boolean instead.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-44]** Is the ecrecover() function used without validating its input? (version ~0.4.13)
+  - The ecrecover() builtin can return garbage for malformed input.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-45]** Is the `.selector` member accessed on complex expressions? (version 0.6.2~0.8.20)
+  - Accessing the ``.selector`` member on complex expressions leaves the expression unevaluated in the legacy code generation.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2023/07/19/missing-side-effects-on-selector-access-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-46]** Is there any inconsistency (`memory` vs `calldata`) in the param type during inheritance? (version 0.6.9~0.8.13)
+  - It was possible to change the data location of the parameters or return variables from ``calldata`` to ``memory`` and vice-versa while overriding internal and public functions. This caused invalid code to be generated when calling such a function internally through virtual function calls.
+  - **Remediation:** Use the latest Solidity version.
+  - **References:**
+    - https://blog.soliditylang.org/2022/05/17/data-location-inheritance-bug/
+
+- [ ] **[SOL-Basics-VI-SVI-47]** Are there any functions with the same name and parameter type inside the same contract? (version =0.7.1)
+  - The compiler does not flag an error when two or more free functions with the same name and parameter types are defined in a source unit or when an imported free function alias shadows another free function with a different name but identical parameter types.
+  - **Remediation:** Use the latest Solidity version.
+
+- [ ] **[SOL-Basics-VI-SVI-48]** Does the contract use tuple assignments with multi-stack-slot components, like nested tuples or dynamic calldata references? (version 0.1.6~0.6.5)
+  - Tuple assignments with components that occupy several stack slots, i.e. nested tuples, pointers to external functions or references to dynamically sized calldata arrays, can result in invalid values.
+  - **Remediation:** Use the latest Solidity version.
+
+### Hash / Merkle Tree
+
+- [ ] **[SOL-HMT-1]** Is the Merkle tree vulnerable to front-running attacks?
+  - When using a merkle tree, the new proof is calculated at a certain time and there exists a period of time between when the proof is generated and the proof is published.
+  - **Remediation:** Ensure that front-running the merkle proof setting does not affect the protocol.
+
+- [ ] **[SOL-HMT-2]** Does the claim method validate `msg.sender`?
+  - Validation of `msg.sender` is critical in the use of Merkle tree.
+  - **Remediation:** Ensure that the `msg.sender` is actually the same address included in the leave.
+
+- [ ] **[SOL-HMT-3]** What is the result when passing a zero hash to the Merkle tree functions?
+  - Passing the zero hash can lead to unintended behaviors or vulnerabilities if not properly handled.
+  - **Remediation:** Implement checks to handle zero hash values appropriately and prevent potential misuse.
+
+- [ ] **[SOL-HMT-4]** What occurs if the same proof is duplicated within the Merkle tree?
+  - Duplicate proofs within a Merkle tree can lead to double-spending or other vulnerabilities.
+  - **Remediation:** Ensure the Merkle tree construction and verification process detects and prevents the use of duplicate proofs.
+
+- [ ] **[SOL-HMT-5]** Are the leaves of the Merkle tree hashed with the claimable address included?
+  - Not including claimable addresses when hashing leaves can let an attacker to claim.
+  - **Remediation:** Ensure that the Merkle tree construction includes the hashing of claimable addresses within the leaves.
+
+### Heuristics
+
+- [ ] **[SOL-Heuristics-1]** Is there any logic implemented multiple times?
+  - Inconsistent implementations of the same logic can introduce errors or vulnerabilities.
+  - **Remediation:** Standardize the logic and make it as a separate function.
+
+- [ ] **[SOL-Heuristics-2]** Does the contract use any nested structures?
+  - If a variable of nested structure is deleted, only the top-level fields are reset by default values (zero) and the nested level fields are not reset.
+  - **Remediation:** Always ensure that inner fields are deleted before the outer fields of the structure.
+
+- [ ] **[SOL-Heuristics-3]** Is there any unexpected behavior when `src==dst` (or `caller==receiver`)?
+  - Overlooking the possibility of a sender and a recipient (source and destination) being the same in smart contracts can lead to unintended problems.
+  - **Remediation:** Ensure the protocol behaves as expected when `src==dst`.
+
+- [ ] **[SOL-Heuristics-4]** Is the NonReentrant modifier placed before every other modifier?
+  - The order of modifiers can influence the behavior of a function. Generally,  NonReentrant must come first than other modifiers.
+  - **Remediation:** Reorder modifiers so that NonReentrant is placed before other modifiers.
+
+- [ ] **[SOL-Heuristics-6]** Did you check the relevant EIP recommendations and security concerns?
+  - Incomplete or incorrect implementation of EIP recommendations can lead to vulnerabilities.
+  - **Remediation:** Read the recommendations and security concerns and ensure all are implemented as per the official recommendations.
+
+- [ ] **[SOL-Heuristics-7]** Are there any off-by-one errors?
+  - Off-by-one errors are not rare. Is `<=` correct in this context or should `<` be used? Should a variable be set to the length of a list or the length - 1? Should an iteration start at 1 or 0?
+  - **Remediation:** Review all usages of comparison operators for correctness.
+
+- [ ] **[SOL-Heuristics-8]** Are logical operators used correctly?
+  - Logical operators like `==`, `!=`, `&&`, `||`, `!` can be overlooked especially when the test coverage is not good.
+  - **Remediation:** Review all usages of logical operators for correctness.
+
+- [ ] **[SOL-Heuristics-9]** What happens if the protocol's contracts are inputted as if they are normal actors?
+  - Supplying unexpected addresses can lead to unintended behaviors, especially if the address points to another contract inside the same protocol.
+  - **Remediation:** Implement checks to validate receiver addresses and ensure the protocol behaves as expected.
+
+- [ ] **[SOL-Heuristics-10]** Are there rounding errors that can be amplified?
+  - While minor rounding errors can be inevitable in certain operations, they can pose significant issues if they can be magnified. Amplification can occur when a function is invoked multiple times strategically or under specific conditions.
+  - **Remediation:** Conduct thorough tests to identify and understand potential rounding errors. Ensure that they cannot be amplified to a level that would be detrimental to the system or its users. In cases where significant rounding errors are detected, the implementation should be revised to minimize or eliminate them.
+  - **References:**
+    - https://github.com/OpenCoreCH/smart-contract-audits/blob/main/reports/c4/rigor.md#high-significant-rounding-errors-for-interest-calculation
+
+- [ ] **[SOL-Heuristics-11]** Is there any uninitialized state?
+  - Checking a variable against its default value might be used to detect initialization. If such defaults can also be valid state, it could lead to vulnerabilities.
+  - **Remediation:** Avoid solely relying on default values to determine initialization status.
+
+- [ ] **[SOL-Heuristics-12]** Can functions be invoked multiple times with identical parameters?
+  - Functions that should be unique per parameters set might be callable multiple times, leading to potential issues.
+  - **Remediation:** Ensure functions have measures to prevent repeated calls with identical or similar parameters, especially when these calls can produce adverse effects.
+
+- [ ] **[SOL-Heuristics-13]** Is the global state updated correctly?
+  - While working with a `memory` copy for optimization, developers might overlook updating the global state.
+  - **Remediation:** Always ensure the global state mirrors changes made in `memory`. Consider tools or extensions that can highlight discrepancies.
+
+- [ ] **[SOL-Heuristics-14]** Is ETH/WETH handling implemented correctly?
+  - Contracts might have special logic for ETH, like wrapping to WETH. Assuming exclusivity between handling ETH and WETH without checks can introduce errors.
+  - **Remediation:** Clearly differentiate the logic between ETH and WETH handling, ensuring no overlap or mutual exclusivity assumptions without validation.
+
+- [ ] **[SOL-Heuristics-15]** Does the protocol put any sensitive data on the blockchain?
+  - Data on the blockchain, including that marked 'private' in smart contracts, is visible to anyone who knows how to query the blockchain's state or analyze its transaction history. Private variables are not exempt from public inspection.
+  - **Remediation:** Sensitive data should either be kept off-chain or encrypted before being stored on-chain. It's important to manage encryption keys securely and ensure that on-chain data does not expose private information even when encrypted, if the encryption method is weak or the keys are mishandled.
+
+- [ ] **[SOL-Heuristics-16]** Are there any code asymmetries?
+  - In many projects, there should be some symmetries for different functions. For instance, a `withdraw` function should (usually) undo all the state changes of a `deposit` function and a `delete` function should undo all the state changes of the corresponding `add` function. Asymmetries in these function pairs (e.g., forgetting to unset a field or to subtract from a value) can often lead to undesired behavior. Sometimes one side of a 'pair' is missing, like missing removing from a whitelist while there is a function to add to a whitelist.
+  - **Remediation:** Review paired functions for symmetry and ensure they counteract each other's state changes appropriately.
+  - **References:**
+    - https://github.com/OpenCoreCH/smart-contract-auditing-heuristics#code-asymmetries
+
+- [ ] **[SOL-Heuristics-17]** Does calling a function multiple times with smaller amounts yield the same contract state as calling it once with the aggregate amount?
+  - Associative properties of certain financial operations suggest that performing the operation multiple times with smaller amounts should yield an equivalent outcome as performing it once with the aggregate amount. Variations might be indicative of potential issues such as rounding errors, unintended fee accumulations, or other inconsistencies.
+  - **Remediation:** Implement tests to validate consistency. Where discrepancies exist, ensure they are intentional, minimal, and well-documented. If discrepancies are unintended, reevaluate the implementation to ensure precision and correctness.
+
+### Multi-chain/Cross-chain
+
+- [ ] **[SOL-McCc-1]** Are there assumption of consistency in the `block.number` or `block.timestamp` across chains?
+  - Block time can vary across different chains, leading to potential timing discrepancies.
+  - **Remediation:** Avoid comparing timestamp or block numbers for different chains.
+  - **References:**
+    - https://solodit.cyfrin.io/issues/m-06-l1xrenzobridge-and-l2xrenzobridge-uses-the-blocktimestamp-as-dependency-which-can-cause-issues-code4rena-renzo-renzo-git
+
+- [ ] **[SOL-McCc-2]** Has the protocol been checked for the target chain differences?
+  - Understanding the differences between chains is vital for ensuring compatibility and preventing unexpected behaviors.
+  - **Remediation:** Regularly check for chain differences and update the protocol accordingly.
+  - **References:**
+    - https://www.evmdiff.com/diff?base=1&target=10
+    - https://github.com/0xJuancito/multichain-auditor#differences-from-ethereum
+
+- [ ] **[SOL-McCc-3]** Are the EVM opcodes and operations used by the protocol compatible across all targeted chains?
+  - Incompatibility can arise when the protocol uses EVM operations not supported on certain chains.
+  - **Remediation:** Review and ensure compatibility for chains like Arbitrum and Optimism.
+  - **References:**
+    - https://docs.arbitrum.io/solidity-support
+    - https://community.optimism.io/docs/developers/build/differences/#transaction-costs
+
+- [ ] **[SOL-McCc-4]** Does the expected behavior of `tx.origin` and `msg.sender` remain consistent across all deployment chains?
+  - Different chains might interpret these values differently, leading to unexpected behaviors.
+  - **Remediation:** Test and verify the behavior on all targeted chains.
+  - **References:**
+    - https://community.optimism.io/docs/developers/build/differences/#opcode-differences
+
+- [ ] **[SOL-McCc-6]** Is there consistency in ERC20 decimals across chains?
+  - Decimals in ERC20 tokens can differ across chains.
+  - **Remediation:** Ensure consistent ERC20 decimals or implement chain-specific adjustments.
+  - **References:**
+    - https://github.com/0xJuancito/multichain-auditor#erc20-decimals
+
+- [ ] **[SOL-McCc-7]** Have contract upgradability implications been evaluated on different chains?
+  - Contracts may have different upgradability properties depending on the chain, like USDT being upgradable on Polygon but not on Ethereum.
+  - **Remediation:** Verify and document upgradability characteristics for each chain.
+
+- [ ] **[SOL-McCc-8]** Have cross-chain messaging implementations been thoroughly reviewed for permissions and functionality?
+  - Cross-chain messaging requires robust security checks to ensure the correct permissions and intended functionality.
+  - **Remediation:** Double check the access control over cross-chain messaging components.
+
+- [ ] **[SOL-McCc-9]** Is there a whitelist of compatible chains?
+  - Allowing messages from an unsupported chain can lead to unpredictable results.
+  - **Remediation:** Implement a whitelist to prevent messages from unsupported chains.
+
+- [ ] **[SOL-McCc-10]** Have contracts been checked for compatibility when deployed to the zkSync Era?
+  - zkSync Era might have specific requirements or differences when compared to standard Ethereum deployments.
+  - **Remediation:** Review and ensure compatibility before deploying contracts to zkSync Era.
+  - **References:**
+    - https://era.zksync.io/docs/reference/architecture/differences-with-ethereum.html
+
+- [ ] **[SOL-McCc-11]** Is block production consistency ensured?
+  - Inconsistent block production can lead to unexpected application behaviors.
+  - **Remediation:** Develop with the assumption that block production may not always be consistent.
+
+- [ ] **[SOL-McCc-12]** Is `PUSH0` opcode supported for Solidity version `>=0.8.20`?
+  - `PUSH0` might not be supported on all chains, leading to potential incompatibility issues.
+  - **Remediation:** Ensure if `PUSH0` is supported in the target chain.
+  - **References:**
+    - https://github.com/0xJuancito/multichain-auditor#support-for-the-push0-opcode
+
+- [ ] **[SOL-McCc-13]** Are there any attributes attached to the bridged assets?
+  - When assets (e.g. tokens) are bridged across chains, the relevant attributes (e.g. approval) must be bridged or reset accordingly.
+  - **Remediation:** Ensure accounting all the relevant attributes when assets are bridged.
+  - **References:**
+    - https://solodit.cyfrin.io/issues/not-update-rewards-in-handleincomingupdate-function-of-sdlpoolprimary-leads-to-incorrect-reward-calculations-codehawks-stakelink-git
+
+### Timelock
+
+- [ ] **[SOL-Timelock-1]** Are timelocks implemented for important changes?
+  - Immediate changes in the protocol can affect the users.
+  - **Remediation:** Implement timelocks for important changes, allowing users adequate time to respond to proposed alterations.
+

package/skills/checklists/cyfrin-best-practices-upgrades/SKILL.md

@@ -0,0 +1,157 @@
+---
+name: cyfrin-best-practices-upgrades
+description: Cyfrin best-practice checklist focused on proxy, upgradeability, and versioning concerns
+---
+<!-- Source: Cyfrin/audit-checklist -->
+<!-- Auto-generated from https://github.com/Cyfrin/audit-checklist -->
+<!-- Total items: 112 -->
+
+# Cyfrin Audit Checklist — Best Practices (Upgrades & Versioning)
+
+Best practice checklist items from [Cyfrin's audit checklist](https://github.com/Cyfrin/audit-checklist).
+
+Covers: proxy/upgradable patterns, Solidity version issues, OpenZeppelin version issues, EIP adoption, multi-chain/cross-chain considerations, timelocks, Merkle tree validation, block reorganization, and general heuristics for code quality.
+
+## Checklist Items
+
+### Basics > Block Reorganization
+
+- [ ] **[SOL-Basics-BR-1]** Does the protocol implement a factory pattern using the CREATE opcode?
+  - Contracts created with the CREATE opcode will be eliminated if a block reorg happens.
+  - **Remediation:** Use CREATE2 instead of CREATE.
+  - **References:**
+    - https://solodit.xyz/issues/m-08-factorycreate-is-vulnerable-to-reorg-attacks-code4rena-abracadabra-money-abracadabra-money-git
+    - https://solodit.xyz/issues/m-02-reorg-attack-on-users-vault-deployment-and-deposit-may-lead-to-theft-of-funds-code4rena-amphora-protocol-amphora-protocol-git
+    - https://solodit.xyz/issues/m-4-loss-of-bond-amounts-on-re-org-attacks-sherlock-optimism-fault-proofs-git
+    - https://solodit.xyz/issues/m-01-questfactory-is-suspicious-of-the-reorg-attack-code4rena-rabbithole-rabbithole-quest-protocol-contest-git
+    - https://solodit.xyz/issues/m-14-re-org-attack-in-factory-code4rena-frankencoin-frankencoin-git
+
+### Basics > Proxy/Upgradable
+
+- [ ] **[SOL-Basics-PU-1]** Is there a constructor in the proxied contract?
+  - Proxied contract can't have a constructor and it's common to move constructor logic to an external initializer function, usually called initialize
+  - **Remediation:** Use initializer functions for initialization of proxied contracts.
+
+- [ ] **[SOL-Basics-PU-2]** Is the `initializer` modifier applied to the `initialization()` function?
+  - Without the `initializer` modifier, there is a risk that the initialization function can be called multiple times.
+  - **Remediation:** Always use the `initializer` modifier for initialization functions in proxied contracts and ensure they're called once during deployment.
+
+- [ ] **[SOL-Basics-PU-3]** Is the upgradable version used for initialization?
+  - Upgradable contracts must use the upgradable versions of parent initializer functions. (e.g. Pausable vs PausableUpgradable)
+  - **Remediation:** Use upgradable versions of parent initializer functions.
+
+- [ ] **[SOL-Basics-PU-4]** Is the `authorizeUpgrade()` function properly secured in a UUPS setup?
+  - Inadequate security on the `authorizeUpgrade()` function can allow unauthorized upgrades.
+  - **Remediation:** Ensure proper access controls and checks are in place for the `authorizeUpgrade()` function.
+
+- [ ] **[SOL-Basics-PU-5]** Is the contract initialized?
+  - An uninitialized contract can be taken over by an attacker. This applies to both a proxy and its implementation contract, which may impact the proxy.
+  - **Remediation:** To prevent the implementation contract from being used, invoke the `_disableInitializers` function in the constructor to automatically lock it when it is deployed.
+  - **References:**
+    - https://docs.openzeppelin.com/contracts/4.x/api/proxy#Initializable
+
+- [ ] **[SOL-Basics-PU-6]** Are `selfdestruct` and `delegatecall` used within the implementation contracts?
+  - Using `selfdestruct` and `delegatecall` in implementation contracts can introduce vulnerabilities and unexpected behavior in a proxy setup.
+  - **Remediation:** Avoid using `selfdestruct` and `delegatecall` in implementation contracts to ensure contract stability and security.
+
+- [ ] **[SOL-Basics-PU-7]** Are values in immutable variables preserved between upgrades?
+  - Immutable variables are stored in the bytecode, not in the proxy storage. So using immutable variable is not recommended in proxy setup. If used, make sure all immutables stay consistent across implementations during upgrades.
+  - **Remediation:** Avoid using immutable variables in upgradable contracts.
+
+- [ ] **[SOL-Basics-PU-8]** Has the contract inherited the correct branch of OpenZeppelin library?
+  - Sometimes developers overlook and use an incorrect branch of OZ library, e.g. use Ownable instead of OwnableUpgradeable.
+  - **Remediation:** Make sure inherit the correct branch of OZ library according to the contract's upgradeability design.
+  - **References:**
+    - https://solodit.xyz/issues/h-01-usage-of-an-incorrect-version-of-ownbale-library-can-potentially-malfunction-all-onlyowner-functions-code4rena-covalent-covalent-contest-git
+
+- [ ] **[SOL-Basics-PU-9]** Could an upgrade of the contract result in storage collision?
+  - Storage collisions can occur when storage layouts between contract versions conflict, leading to data corruption and unpredictable behavior.
+  - **Remediation:** Maintain a consistent storage layout between upgrades, and when using inheritance, set storage gaps to avoid potential collisions.
+
+- [ ] **[SOL-Basics-PU-10]** Are the order and types of storage variables consistent between upgrades?
+  - Changing the order or type of storage variables between upgrades can lead to storage collisions.
+  - **Remediation:** Maintain a consistent order and type for storage variables across contract versions to avoid storage collisions.
+
+### Basics > Version Issues > EIP Adoption Issues
+
+- [ ] **[SOL-Basics-VI-EAI-1]** EIP-4758: Does the contract use `selfdestruct()`?
+  - `selfdestruct` will not be available after EIP-4758. This EIP will rename the SELFDESTRUCT opcode and replace its functionality.
+  - **Remediation:** Do not use `selfdestruct` to ensure the contract works in the future.
+  - **References:**
+    - https://eips.ethereum.org/EIPS/eip-4758
+    - https://solodit.xyz/issues/m-09-selfdestruct-will-not-be-available-after-eip-4758-code4rena-escher-escher-contest-git
+    - https://solodit.xyz/issues/m-03-system-will-not-work-anymore-after-eip-4758-code4rena-axelar-network-axelar-network-git
+
+### Basics > Version Issues > OpenZeppelin Version Issues
+
+- [ ] **[SOL-Basics-VI-OVI-1]** Does the contract use `ERC2771Context`? (version >=4.0.0 <4.9.3)
+  - `ERC2771Context._msgData()` reverts if `msg.data.length < 20`. The correct behavior is not specified in ERC-2771, but based on the specified behavior of `_msgSender` we assume the full `msg.data` should be returned in this case.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-2]** Does the contract use OpenZeppelin's GovernorCompatibilityBravo? (version >=4.3.0 <4.8.3)
+  - GovernorCompatibilityBravo may trim proposal calldata. The proposal creation entrypoint (propose) in GovernorCompatibilityBravo allows the creation of proposals with a signatures array shorter than the calldatas array. This causes the additional elements of the latter to be ignored, and if the proposal succeeds the corresponding actions would eventually execute without any calldata. The ProposalCreated event correctly represents what will eventually execute, but the proposal parameters as queried through getActions appear to respect the original intended calldata.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-3]** Does the contract use OpenZeppelin's ECDSA.recover or ECDSA.tryRecover? (version <4.7.3)
+  - ECDSA signature malleability. The functions ECDSA.recover and ECDSA.tryRecover are vulnerable to a kind of signature malleability due to accepting EIP-2098 compact signatures in addition to the traditional 65 byte signature format. This is only an issue for the functions that take a single bytes argument, and not the functions that take r, v, s or r, vs as separate arguments. The potentially affected contracts are those that implement signature reuse or replay protection by marking the signature itself as used rather than the signed message or a nonce included in it. A user may take a signature that has already been submitted, submit it again in a different form, and bypass this protection.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-4]** Does the contract use OpenZeppelin's ERC777? (version <3.4.0-rc.0)
+  - Extending this contract with a custom _beforeTokenTransfer function could allow a reentrancy attack to happen. More specifically, when burning tokens, _beforeTokenTransfer is invoked before the send hook is externally called on the sender while token balances are adjusted afterwards. At the moment of the call to the sender, which can result in reentrancy, state managed by _beforeTokenTransfer may not correspond to the actual token balances or total supply.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-5]** Does the contract use OpenZeppelin's `MerkleProof`? (version >=4.7.0 <4.9.2)
+  - When the `verifyMultiProof`, `verifyMultiProofCalldata`, `processMultiProof`, or `processMultiProofCalldata` functions are in use, it is possible to construct merkle trees that allow forging a valid multiproof for an arbitrary set of leaves.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-6]** Does the contract use OpenZeppelin's Governor or GovernorCompatibilityBravo? (version >=4.3.0 <4.9.1)
+  - Governor proposal creation may be blocked by frontrunning. By frontrunning the creation of a proposal, an attacker can become the proposer and gain the ability to cancel it. The attacker can do this repeatedly to try to prevent a proposal from being proposed at all. This impacts the Governor contract in v4.9.0 only, and the GovernorCompatibilityBravo contract since v4.3.0.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-7]** Does the contract use OpenZeppelin's TransparentUpgradeableProxy? (version >=3.2.0 <4.8.3)
+  - Transparency is broken in case of selector clash with non-decodable calldata. The TransparentUpgradeableProxy uses the ifAdmin modifier to achieve transparency. If a non-admin address calls the proxy the call should be frowarded transparently. This works well in most cases, but the forwarding of some functions can fail if there is a selector conflict and decoding issue.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-8]** Does the contract use OpenZeppelin's ERC721Consecutive?(version >=4.8.0 <4.8.2)
+  - The ERC721Consecutive contract designed for minting NFTs in batches does not update balances when a batch has size 1 and consists of a single token. Subsequent transfers from the receiver of that token may overflow the balance as reported by balanceOf. The issue exclusively presents with batches of size 1.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-9]** Does the contract use OpenZeppelin's ERC165Checker or ERC165CheckerUpgradeable? (version >=2.3.0 <4.7.2)
+  - Denial of Service (DoS) in the `supportsERC165InterfaceUnchecked()` function in `ERC165Checker.sol` and `ERC165CheckerUpgradeable.sol`, which can consume excessive resources when processing a large amount of data via an EIP-165 supportsInterface query.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-10]** Does the contract use OpenZeppelin's LibArbitrumL2 or CrossChainEnabledArbitrumL2? (version >=4.6.0 <4.7.2)
+  - Incorrect resource transfer between spheres via contracts using the cross-chain utilities for Arbitrum L2: `CrossChainEnabledArbitrumL2` or `LibArbitrumL2`. Calls from EOAs would be classified as cross-chain calls. The vulnerability will classify direct interactions of externally owned accounts (EOAs) as cross-chain calls, even though they are not started on L1.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-11]** Does the contract use OpenZeppelin's GovernorVotesQuorumFraction? (version >=4.3.0 <4.7.2)
+  - Checkpointing quorum was missing and past proposals that failed due to lack of quorum could pass later. It is necessary to avoid quorum changes making old, failed because of quorum, proposals suddenly successful.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-12]** Does the contract use OpenZeppelin's SignatureChecker? (version >=4.1.0 <4.7.1)
+  - Since 0.8.0, abi.decode reverts if the bytes raw data overflow the target type. SignatureChecker.isValidSignatureNow is not expected to revert. However, an incorrect assumption about Solidity 0.8's abi.decode allows some cases to revert, given a target contract that doesn't implement EIP-1271 as expected. The contracts that may be affected are those that use SignatureChecker to check the validity of a signature and handle invalid signatures in a way other than reverting.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-13]** Does the contract use OpenZeppelin's ERC165Checker? (version >=4.0.0 <4.7.1)
+  - Since 0.8.0, abi.decode reverts if the bytes raw data overflow the target type. ERC165Checker.supportsInterface is designed to always successfully return a boolean, and under no circumstance revert. However, an incorrect assumption about Solidity 0.8's abi.decode allows some cases to revert, given a target contract that doesn't implement EIP-165 as expected, specifically if it returns a value other than 0 or 1. The contracts that may be affected are those that use ERC165Checker to check for support for an interface and then handle the lack of support in a way other than reverting.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-14]** Does the contract use OpenZeppelin's GovernorCompatibilityBravo? (version >=4.3.0 <4.4.2)
+  - GovernorCompatibilityBravo incorrect ABI encoding may lead to unexpected behavior
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-15]** Does the contract use OpenZeppelin's Initializable? (version >=3.2.0 <4.4.1)
+  - It is possible for `initializer()`-protected functions to be executed twice, if this happens in the same transaction. For this to happen, either one call has to be a subcall the other, or both call have to be subcalls of a common initializer()-protected function. This can particularly be dangerous is the initialization is not part of the proxy construction, and reentrancy is possible by executing an external call to an untrusted address.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-16]** Does the contract use OpenZeppelin's ERC1155? (version >=4.2.0 <4.3.3)
+  - Possible inconsistency in the value returned by totalSupply DURING a mint. If you mint a token, the receiver is a smart contract, and the receiver implements onERC1155Receive, then this receiver is called with the balance already updated, but with the totalsupply not yet updated.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-17]** Does the contract use OpenZeppelin's UUPSUpgradeable? (version >=4.1.0 <4.3.2)
+  - Upgradeable contracts using UUPSUpgradeable may be vulnerable to an attack affecting uninitialized implementation contracts.
+  - **Remediation:** Use the latest stable OpenZeppelin version
+
+- [ ] **[SOL-Basics-VI-OVI-18]** Does the contract use OpenZeppelin's TimelockController? (version >=4.0.0-beta.0 <4.3.1\\n<3.4.2)
+  - A vulnerability in TimelockController allowed an actor with the executor role to take immediate control of the timelock, by resetting the delay to 0 and escalating privileges, thus gaining unrestricted access to assets held in the contract. Instances with the executor role set to 'open' allow anyone to use the executor role, thus leaving the timelock at risk of being taken over by an attacker.
+  - **Remediation:** Use the latest stable OpenZeppelin version