Liquid Staking

Stakelink
DeFiHardhatOracle
50,000 USDC
View results
Submission Details
Severity: high
Invalid

scripts/prod/1.0.0-metis-staking/2-deploy-metis-staking.ts

Analyzing your code from a security and best practices perspective, here are some potential vulnerabilities and areas of improvement to consider:


1. Uninitialized Addresses (Potential Logic Errors or Misconfigurations)

  • sequencerRewardsCCIPSenderAddress:

    • It is an empty string ('') but used as a parameter in deployments.

    • If the address is incorrect or left blank by mistake, the deployed contracts may behave unexpectedly, or operations may fail.

    Mitigation:

    • Add validation to ensure that this address is not empty before using it.

if (!sequencerRewardsCCIPSenderAddress) {
throw new Error('sequencerRewardsCCIPSenderAddress is required!');
}

2. Hardcoded External Contract Addresses (Configuration Risk)

  • ccipRouterAddress and chainlinkOracle are hardcoded.

    • If these addresses change or become invalid, the system could fail.

    • Additionally, malicious actors might target these addresses if vulnerabilities exist in the external contracts.

    Mitigation:

    • Store addresses in a configuration file or environment variables to prevent hardcoding and ease updates.

    • Add validation to check that these addresses are non-zero Ethereum addresses.


3. ZeroAddress Usage Without Restrictions

  • ethers.ZeroAddress (address(0x0)) is used for depositController.

    • If there is no control over deposits, malicious actors may deposit tokens without restriction.

    Mitigation:

    • Ensure that the absence of a deposit controller is intended. If not, require a valid address and provide comments clarifying the logic.

if (SequencerVCSArgs.depositController === ethers.constants.AddressZero) {
console.warn('No deposit controller specified. Ensure this is intended.');
}

4. Unchecked Contract Deployment Errors

  • If deployUpgradeable or deploy fails (e.g., due to gas issues or incorrect parameters), the code proceeds without reverting, which could leave the system in an inconsistent state.

    Mitigation:

    • Add error handling after deployments to verify the success.

if (!stakingPool) {
throw new Error('StakingPool deployment failed!');
}

5. Fee Configuration Errors (Basis Points Misuse)

  • Fee percentages are set in basis points. However:

    • 300 basis points = 3%.

    • 600 basis points = 6%.

    • Ensure these values are intentional and add validation to prevent misconfiguration.


6. Lack of Input Validation in Deployments

  • Parameters passed to deployments (like token names, symbols, and addresses) are not validated. This could result in contracts being deployed with unintended parameters.

    Mitigation:

    • Add input validation for important parameters (e.g., token symbols, fees, min/max deposits).

if (PriorityPoolArgs.queueDepositMin.gt(PriorityPoolArgs.queueDepositMax)) {
throw new Error('queueDepositMin cannot exceed queueDepositMax.');
}

7. Potential Oracle Manipulation Risks

  • The oracle update parameters (like minDepositsSinceLastUpdate) must be carefully configured to prevent manipulation:

    • If the deposit threshold or time window is too low, a malicious actor could force frequent updates and drain gas.

    • Chainlink jobId is set to ethers.ZeroHash, which might indicate an issue with job identification or an uninitialized value.

    Mitigation:

    • Ensure that the jobId is correctly configured.

    • Add rate limiting or update governance logic to avoid excessive updates.


8. Gas Limit Issues (Deployments in a Single Transaction)

  • Deploying multiple contracts in one script may exceed the block’s gas limit, especially on some chains.
    Mitigation:

    • Consider breaking the deployment into smaller batches or adding retries with gas management.


9. Process Exit Handling

  • Using process.exit(0) and process.exit(1) to exit could result in unintentional termination in some environments.
    Mitigation:

    • Use graceful shutdown logic to ensure resources are properly released.


10. Logging Sensitive Information

  • Be cautious with logging contract addresses or deployment details in production environments. Malicious actors could monitor logs for deployed addresses and attack newly deployed contracts.

    Mitigation:

    • Use environment-specific logging (console.debug vs. console.log).


Summary of Key Recommendations:

  1. Validate addresses and parameters before using them.

  2. Ensure fee configurations and ZeroAddress usages are intentional.

  3. Implement graceful error handling during deployments.

  4. Store critical addresses in environment variables for easier management.

  5. Check for oracle and external contract dependencies to prevent misuse.

Addressing these vulnerabilities will help make the deployment process more robust and secure.

Updates

Lead Judging Commences

inallhonesty Lead Judge about 1 year ago
Submission Judgement Published
Invalidated
Reason: Lack of quality

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.