Ethena Labs - clara's results

Enabling The Internet Bond

General Information

Platform: Code4rena

Start Date: 24/10/2023

Pot Size: $36,500 USDC

Total HM: 4

Participants: 147

Period: 6 days

Judge: 0xDjango

Id: 299

League: ETH

Ethena Labs

Findings Distribution

Researcher Performance

Rank: 76/147

Findings: 1

Award: $14.24

Analysis:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

14.2357 USDC - $14.24

Labels

analysis-advanced
grade-b
sufficient quality report
A-05

External Links

Approach taken in evaluating the codebase

I began by conducting an in-depth analysis of the provided Solidity contracts and their accompanying documentation. The primary objectives were to identify potential security vulnerabilities, assess design choices, and understand the overall architecture of the Ethena protocol. I paid particular attention to key features, role-based access control, potential attack vectors, and the mechanisms employed to achieve the protocol's goals.

Architecture Recommendations

  1. Enhance Modularity: The codebase could benefit from improved modularity by breaking down large contracts into smaller, more manageable components. This would enhance readability, maintainability, and facilitate easier auditing.

  2. Use Standard Libraries: Implement widely adopted libraries like SafeMath to prevent overflow/underflow vulnerabilities and enhance the overall security of the codebase.

  3. Implement Upgradeability: Consider incorporating upgradeability features into contracts to allow for future enhancements and bug fixes without disrupting the entire protocol.

  4. Comprehensive Documentation: Improve both inline code comments and external documentation to enhance readability and understanding, especially for potential auditors and developers.

  5. Test Coverage: Expand test coverage to include a diverse set of scenarios, edge cases, and potential attack vectors. Comprehensive testing is crucial for ensuring the robustness of the protocol.

  6. Consistent Naming Conventions: Maintain consistent naming conventions across the codebase to enhance clarity and maintainability.

  7. Reduce Gas Consumption: Optimize gas consumption by reviewing and refining complex operations, particularly in functions likely to be invoked frequently.

  8. Consistent Error Handling: Implement consistent and comprehensive error handling throughout the codebase to prevent unexpected behaviors and enhance security.

  9. Implement Timelocks: Consider introducing timelocks for critical operations to add an additional layer of security and prevent immediate exploitation of potential vulnerabilities.

  10. Integration Testing: Conduct thorough integration testing to ensure seamless interactions between different components and contracts.

Codebase Quality Analysis

EthenaMinting.sol

Summary: EthenaMinting.sol facilitates minting and redeeming of the USDe stablecoin in a single, atomic, trustless transaction. It uses OpenZeppelin libraries for security, role-based access control, and various functionalities.

Recommendations:

  1. Access Control Enhancement:

    • Implement stricter access control for critical functions like minting and redeeming. Consider using role-based access control with well-defined permissions.
  2. Gas Optimization:

    • Review and optimize gas consumption, especially in functions like mint and redeem, to enhance overall efficiency.
  3. Reentrancy Mitigation:

    • While ReentrancyGuard is used, conduct a thorough review to ensure all potential reentrancy risks are mitigated.
  4. Standard Library Usage:

    • Consider using SafeMath for arithmetic operations to prevent overflow/underflow vulnerabilities and enhance security.
  5. Documentation Improvement:

    • Enhance inline comments and external documentation to improve readability and understanding, especially for auditors and developers.
  6. Comprehensive Testing:

    • Expand test coverage to include diverse scenarios, edge cases, and potential attack vectors to ensure robustness.
  7. Consistent Naming Conventions:

    • Maintain consistent naming conventions across the codebase to improve clarity and maintainability.
  8. Error Handling:

    • Implement consistent and comprehensive error handling throughout the codebase to prevent unexpected behaviors.
  9. Timelocks Implementation:

    • Consider introducing timelocks for critical operations to add an extra layer of security.
  10. Integration Testing:

    • Conduct thorough integration testing to ensure seamless interactions between different components and contracts.

Security Flaw Mitigation:

  • The use of ReentrancyGuard mitigates reentrancy risks in the contract.
  • Implement checks for contract addresses in functions like addSupportedAsset and removeSupportedAsset to prevent potential issues.

SingleAdminAccessControl.sol

Summary: SingleAdminAccessControl.sol provides a simplified alternative to OpenZeppelin's AccessControlDefaultAdminRules, maintaining a single admin role with a two-step transfer process.

Recommendations:

  1. Standard Library Usage:

    • Consider utilizing the latest version of OpenZeppelin's AccessControl contract for additional security features.
  2. Documentation Clarity:

    • Enhance documentation to clearly explain the purpose and usage of the SingleAdminAccessControl contract.

Security Flaw Mitigation:

  • The two-step admin transfer process is a good security measure.
  • Security also depends on how the admin manages their private keys.

StakedUSDe.sol

Summary: StakedUSDe.sol is a staking contract for USDe tokens with role-based access control, vesting, and features like blacklisting and token rescue.

Recommendations:

  1. Role Renouncement:

    • Consider allowing role renouncement with careful consideration of potential implications.
  2. Dynamic Parameter Adjustment:

    • Implement a mechanism to adjust parameters like vesting period and minimum shares for future protocol upgrades.
  3. Security Flaw Mitigation:

    • Centralization risks should be carefully managed to prevent potential misuse.
    • Ensure comprehensive testing, including role-related functionalities.

StakedUSDeV2.sol

Summary: StakedUSDeV2.sol extends StakedUSDe with a cooldown mechanism, allowing users to stake USDe tokens and earn rewards.

Recommendations:

  1. Overflow/Underflow Checks:

    • Add explicit checks for overflow and underflow using SafeMath or similar libraries.
  2. Owner's Cooldown Duration Adjustment Limit:

    • Consider limiting the owner's ability to change the cooldown duration to prevent potential misuse.

Security Flaw Mitigation:

  • The contract structure seems well-organized, but caution is advised regarding the owner's ability to change cooldown duration.

USDe.sol

Summary: USDe.sol defines a stablecoin contract inheriting from OpenZeppelin contracts, featuring a single minter with the ability to change the minter address.

Recommendations:

  1. Centralization Risk Mitigation:

    • Carefully manage the centralized nature, especially regarding the owner's power to set the minter.
  2. Minter Validation:

    • Validate the new minter address in the setMinter function to prevent potential loss of control.
  3. Minting Limit Implementation:

    • Introduce a minting limit to prevent potential inflationary risks.

Security Flaw Mitigation:

  • Centralization risks should be carefully managed to prevent potential misuse.
  • Validate the new minter address in the setMinter function.

USDeSilo.sol

Summary: USDeSilo.sol is a contract for storing USDe tokens during a staking cooldown process, using OpenZeppelin for safe ERC20 token operations.

Recommendations:

  1. Amount Checking in Withdraw Function:
    • Check if the withdrawal amount is less than or equal to the contract's USDe balance to prevent failed transactions.

Security Flaw Mitigation:

  • The use of OpenZeppelin libraries enhances the security of ERC20 token operations.
  • Implementing checks for withdrawal amounts can prevent potential failed transactions.

Centralization Risks

  1. Owner Control: The centralized control by the owner and admin roles in various contracts poses a risk. Consider strategies to mitigate the impact of compromised keys.

  2. Single Minter: The reliance on a single minter address introduces centralization. Explore options for distributed or decentralized minting.

Mechanism Review

Ethena presents a comprehensive protocol with distinct smart contracts, each serving a crucial role. Let's delve into the key mechanisms:

  1. USDe.sol (Stablecoin):

    • Overview: This contract defines the stablecoin "USDe" with features like burning, permitting, and ownership transfer.
    • Security Considerations: Centralization risk due to a single owner controlling the minter address. Lack of minter validation and absence of a minting limit pose potential risks.
  2. EthenaMinting.sol (Minting and Redemption):

    • Overview: Facilitates minting and redemption of USDe using stETH or other collateral. Involves EIP712 signatures and controlled by GATEKEEPER_ROLE, MINTER_ROLE, and REDEEMER_ROLE.
    • Security Measures: Implements on-chain minting and redemption limits per block to mitigate compromised MINTER_ROLE. GATEKEEPER_ROLE acts as a safety layer. External organizations can be granted GATEKEEPER_ROLE cautiously.
  3. SingleAdminAccessControl.sol (Role-based Access Control):

    • Overview: A simplified contract providing a single admin role using OpenZeppelin's AccessControl. Admin transfer follows a two-step process.
    • Security Measures: Relies on well-audited OpenZeppelin contracts. Two-step admin transfer enhances security, contingent on the admin managing private keys securely.
  4. StakedUSDe.sol (Staking Contract):

    • Overview: Allows users to stake USDe, earn rewards, and includes roles for access control. Features vesting, blacklisting, and token rescue mechanisms.
    • Security Considerations: Centralization risk due to owner's ability to blacklist, rescue tokens, and redistribute. Addresses unable to renounce roles could pose potential issues.
  5. StakedUSDeV2.sol (Staking Contract with Cooldown):

    • Overview: An extension of StakedUSDe with a cooldown mechanism for withdrawal. Cooldown duration is adjustable by the contract owner.
    • Security Measures: Well-structured contract with potential reliance on the owner for cooldown duration changes. Lack of explicit checks for overflow/underflow in arithmetic operations.

In summary, Ethena demonstrates a robust architecture with multiple layers of security. Key roles are assigned carefully, and mechanisms are in place to mitigate risks associated with compromised keys. Continuous monitoring, cautious external access, and adherence to security best practices are pivotal for long-term success.

Systemic Risks

  1. Smart Contract Upgradability: The ability to upgrade contracts introduces systemic risks. Ensure upgrade mechanisms are secure and well-audited.

  2. External Organization Gatekeepers: The introduction of external organizations as gatekeepers should be approached with caution. Establish clear criteria and controls to prevent misuse.

  3. Cooldown Duration Adjustment: The ability to adjust the cooldown duration introduces systemic risks. Implement careful controls and possibly involve governance mechanisms for such adjustments.

  4. Soft and Full Restriction Roles: The restrictions on stakers based on geographical locations and legal requirements may have implications. Clearly communicate and enforce these restrictions transparently.

  5. Gnosis Safe Multisig: The reliance on a Gnosis Safe Multisig for ownership introduces systemic risks. Ensure the multisig setup follows best practices and has proper security measures.

  6. Role-based Access Control: The extensive use of roles introduces systemic risks. Ensure a thorough review of role assignments and permissions to prevent unintended consequences.

  7. Emergency Fund Management: The management of the emergency fund needs careful consideration. Define clear procedures for fund allocation and utilization.

  8. External Gatekeeper Removal: The ability to remove external organizations as gatekeepers may pose risks. Implement

Time spent:

8 hours

#0 - c4-pre-sort

2023-11-01T14:17:32Z

raymondfam marked the issue as sufficient quality report

#1 - c4-judge

2023-11-10T19:51:28Z

fatherGoose1 marked the issue as grade-b

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter