feat: add default admin, pauser and upgrader roles on initialization

[lirona]

Summary by CodeRabbit

• New Features

  • Enhanced role management by allowing separate assignment of admin, manager, pauser, and upgrader roles when creating or initializing Hyperfund and Hyperstaker contracts.
  • Updated event payloads to include all assigned role addresses for greater transparency.

• Tests

  • Updated test cases to reflect the new initialization parameters and event structures for role assignments.

[coderabbitai]

Walkthrough

This update expands the role-based initialization of the Hyperfund and Hyperstaker contracts, as well as their deployment via the HyperfundFactory. The initialize functions for both contracts now accept four separate addresses for admin, manager, pauser, and upgrader roles, instead of a single manager address. The factory contract's creation functions and emitted events are updated to handle these additional parameters. Corresponding changes are made in the test suite to reflect the new function signatures and event payloads, with repeated use of the manager address for all roles in test scenarios.

Changes

File(s)	Change Summary
src/Hyperfund.sol, src/Hyperstaker.sol	Expanded initialize function signatures to accept four role addresses (admin, manager, pauser, upgrader); updated role assignment logic accordingly.
src/HyperfundFactory.sol	Updated createHyperfund, createHyperstaker, and createProject functions to accept and forward four role addresses; modified event signatures and payloads to include new roles.
test/Hyperfund.t.sol, test/Hyperstaker.t.sol, test/Integration.t.sol	Updated proxy initialization data to include four role addresses (manager address repeated in tests) for contract deployment.
test/HyperfundFactory.t.sol	Updated test calls to factory functions and event expectations to match new signatures and event structures; repeated manager address for all roles in tests.

Sequence Diagram(s)

sequenceDiagram
    participant User
    participant HyperfundFactory
    participant HyperfundProxy
    participant Hyperfund

    User->>HyperfundFactory: createHyperfund(hypercertTypeId, admin, manager, pauser, upgrader)
    HyperfundFactory->>HyperfundProxy: Deploy proxy with initialize data
    HyperfundProxy->>Hyperfund: initialize(hypercertMinter, hypercertTypeId, admin, manager, pauser, upgrader)
    Hyperfund->>Hyperfund: Assign roles to admin, manager, pauser, upgrader
    HyperfundFactory-->>User: Emit HyperfundCreated event (with all role addresses)

Loading

sequenceDiagram
    participant User
    participant HyperfundFactory
    participant HyperstakerProxy
    participant Hyperstaker

    User->>HyperfundFactory: createHyperstaker(hypercertTypeId, admin, manager, pauser, upgrader)
    HyperfundFactory->>HyperstakerProxy: Deploy proxy with initialize data
    HyperstakerProxy->>Hyperstaker: initialize(hypercertMinter, hypercertTypeId, admin, manager, pauser, upgrader)
    Hyperstaker->>Hyperstaker: Assign roles to admin, manager, pauser, upgrader
    HyperfundFactory-->>User: Emit HyperstakerCreated event (with all role addresses)

Loading

Possibly related PRs

• createProject function in factory #49: Introduces the original createProject function in the factory, which is now expanded in this PR to accept multiple role addresses for initialization.

Poem

Four roles now dance in the Hyperfund’s light,
Admin, manager, pauser, upgrader unite.
Factories craft with a more careful touch,
Each rabbit’s address matters so much!
Tests hop along, repeating the call,
In a field of addresses, we now assign all.
🐇✨ The warren grows strong, roles clear and bright!

Tip

⚡💬 Agentic Chat (Pro Plan, General Availability)

• We're introducing multi-step agentic chat in review comments and issue comments, within and outside of PR's. This feature enhances review and issue discussions with the CodeRabbit agentic chat by enabling advanced interactions, including the ability to create pull requests directly from comments and add commits to existing pull requests.

---

📜 Recent review details

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 0856675 and 1004a07.

📒 Files selected for processing (7)

• src/Hyperfund.sol (1 hunks)
• src/HyperfundFactory.sol (2 hunks)
• src/Hyperstaker.sol (1 hunks)
• test/Hyperfund.t.sol (1 hunks)
• test/HyperfundFactory.t.sol (4 hunks)
• test/Hyperstaker.t.sol (1 hunks)
• test/Integration.t.sol (1 hunks)

🔇 Additional comments (33)

src/Hyperfund.sol (3)

59-64: Updated parameter documentation aligns with the expanded role-based initialization.

The comment block now clearly documents each of the four role parameters that the initialize function accepts, making it clear what responsibility each parameter address will have in the system.

---

65-72: Function signature expanded to support dedicated role addresses.

The initialize function has been modified to accept separate addresses for different roles, which is a security improvement that follows the principle of least privilege by allowing role separation.

---

77-80: Role assignment now uses dedicated parameters instead of a single manager address.

This improves the security model by:

1. Granting DEFAULT_ADMIN_ROLE to _admin instead of msg.sender
2. Assigning PAUSER_ROLE and UPGRADER_ROLE to dedicated addresses

This change allows for better separation of responsibilities and follows the principle of least privilege.

test/Hyperfund.t.sol (1)

43-45: Test updated to use the new initialize function signature.

The initialization data correctly encodes the expanded parameter list, using the manager address for all four roles in the test environment. This ensures the tests properly validate the updated contract behavior.

test/Integration.t.sol (1)

41-43: Integration test updated to use the new initialize function signature.

The initialization data in the integration test has been correctly updated to include all four role parameters, maintaining consistency with the contract changes. For testing simplicity, the same manager address is used for all roles.

test/Hyperstaker.t.sol (1)

45-53: Hyperstaker test initialization updated to match new function signature.

The test now correctly encodes all six parameters (hypercertMinter, hypercertTypeId, and the four role addresses) for the Hyperstaker initialization. Using the same address for all roles in tests is a common practice that maintains simplicity while still testing the core functionality.

src/Hyperstaker.sol (3)

66-69: Good addition of NatSpec documentation for new role parameters

The NatSpec documentation clearly explains the purpose of each new parameter, which helps with code readability and maintenance.

---

70-77: Enhanced role-based access control with multiple roles

The function signature has been updated to accept separate addresses for admin, manager, pauser, and upgrader roles, which follows the principle of least privilege and improves security by allowing fine-grained access control.

---

82-85: Proper role assignment implementation

The implementation correctly grants specific roles to the provided addresses:

• DEFAULT_ADMIN_ROLE to _admin (instead of msg.sender)
• MANAGER_ROLE to _manager
• PAUSER_ROLE to _pauser
• UPGRADER_ROLE to _upgrader

This ensures proper separation of duties and follows best security practices.

test/HyperfundFactory.t.sol (11)

104-104: Updated event expectation with new role parameters

The test correctly expects the HyperfundCreated event with the expanded set of role parameters.

---

106-106: Updated function call with role parameters

The createHyperfund function call now includes the necessary role parameters (admin, manager, pauser, and upgrader).

---

118-120: Properly updated event expectation and function call for createHyperstaker

The event expectation and function call for createHyperstaker have been correctly updated to include all role parameters.

---

128-131: Updated function calls in redeployment tests

Both the initial call and the expected-to-revert call correctly use the new function signature with all role parameters.

---

135-138: Updated function calls in Hyperstaker redeployment tests

The Hyperstaker redeployment tests have been properly updated with all role parameters.

---

143-143: Zero address test updated with all role parameters

The test for creating a Hyperfund with zero address has been updated to check all role parameters.

---

148-148: Zero address test for Hyperstaker updated

The test for creating a Hyperstaker with zero address has been properly updated.

---

173-173: Updated failed deployment test

The test for failed Hyperfund deployment has been updated with the new function signature.

---

198-198: Updated failed Hyperstaker deployment test

The test for failed Hyperstaker deployment has been updated with the new function signature.

---

204-210: Updated ownership verification tests

The tests for verifying that only the owner of a hypercert can create Hyperfund and Hyperstaker contracts have been updated with the new function signatures.

---

214-215: Updated createProject test

The test for createProject has been updated to use the new function signature with all role parameters.

src/HyperfundFactory.sol (13)

25-32: Enhanced event definition with role parameters

The HyperfundCreated event has been updated to include all role parameters (admin, manager, pauser, upgrader) and now indexes the hypercertId instead of the manager address, which improves event filtering capabilities.

---

35-42: Enhanced HyperstakerCreated event with role parameters

The HyperstakerCreated event has been similarly updated to include all role parameters and proper indexing.

---

59-62: Updated createHyperfund function signature

The function now accepts multiple role parameters, allowing for better separation of concerns and more granular access control.

---

68-70: Updated initialization data for Hyperfund proxy

The initialization data correctly includes all role parameters for the Hyperfund contract.

---

78-78: Updated event emission with role parameters

The HyperfundCreated event emission now includes all role parameters.

---

83-89: Updated createHyperstaker function signature

The createHyperstaker function has been updated to accept all role parameters, consistent with the createHyperfund function.

---

95-97: Updated initialization data for Hyperstaker proxy

The initialization data correctly includes all role parameters for the Hyperstaker contract.

---

104-104: Updated HyperstakerCreated event emission

The event emission now includes all role parameters.

---

108-108: Updated createProject function signature

The createProject function has been updated to accept all role parameters.

---

116-118: Updated initialization data in createProject

The initialization data for both Hyperfund and Hyperstaker proxies in createProject correctly includes all role parameters.

---

125-125: Updated event emission in createProject

The HyperfundCreated event emission in createProject includes all role parameters.

---

132-132: Updated HyperstakerCreated event emission in createProject

The HyperstakerCreated event emission in createProject includes all role parameters.

---

128-129:

Details

✅ Verification successful

Verify initialization data in createProject for Hyperstaker

It seems the same initialization data is used for both Hyperfund and Hyperstaker in the createProject function. If these contracts have different initialize function signatures or parameter requirements, this could cause issues.

---

🏁 Script executed:

#!/bin/bash
# Check if Hyperfund and Hyperstaker initialize functions have matching signatures

# Get Hyperfund initialize function
rg -A 5 "function initialize" src/Hyperfund.sol

# Get Hyperstaker initialize function
rg -A 5 "function initialize" src/Hyperstaker.sol

Length of output: 437

---

Initialization signatures match – reuse of initData is safe

Verified that both Hyperfund and Hyperstaker define initialize(address,uint256,address,address,address) with identical parameter order, so using the same initData in createProject for both proxies is correct.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

🪧 Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>, please review it.
  • Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit testing code for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.
  • @coderabbitai read src/utils.ts and generate unit testing code.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  • @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai generate docstrings to generate docstrings for this PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

CodeRabbit Configuration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• Please see the configuration documentation for more information.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.