Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: bundler can have modules #450

Closed
wants to merge 1 commit into from
Closed

feat: bundler can have modules #450

wants to merge 1 commit into from

Conversation

adhusson
Copy link
Contributor

Modules are called using the bundler's new callModule(address module, bytes data) function. No onchain whitelist of module addresses is needed, and users should only approve modules they use.

When called, a bundler module receives the current initiator and the data argument. A module contract should inherit BaseMorphoBundlerModule and implement the internal function _morphoBundlerModuleCall. It is wrapped in an external function morphoBundlerModuleCall that checks the caller. So modules can trust that the initiator is correct.

Some alternatives:

  • Remove BaseMorphoBundlerModule. Keep only the IMorphoBundlerModule interface and document that all implementations should check the caller. But it's more error-prone vs. the inheritance of BaseMorphoBundlerModule which is not heavy.
  • Remove the caller check and the initiator argument, have modules call bundler.initiator() if they want to know the initiator. But it costs more gas.

Note: The signature of morphoBundlerModuleCall(address initiator, bytes calldata data) is 0xd26db89e and does not appear in 4byte.directory.

@adhusson adhusson closed this Sep 10, 2024
@adhusson adhusson deleted the feat/modules branch September 10, 2024 13:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant