In the Protocol, there are different types of modules(aka previously integrations):
Plugin
Hooks
Function Handler
Protocol does put a restriction on a contract being combination of above module. For example, a module can be Plugin and Function handler simultaneously. For practical use case see this.
Current check(...) function does not provide any information on whether a given module is listed as a Plugin/Hooks/Function handler. So, in the implementation of the registry with this spec allows a contract to be exclusively only one of the type of modules.
If multiple types are permitted in registry with current check(...) function, Protocol Manager implementation would not know whether an address should be allowed as a Plugin/Hooks/Function handler.
So, specs should define a way to extract information on the types of module a contract can be used as.
Current registry interface defines
check(...)
function as follows:https://github.com/safe-global/safe-core-protocol-specs/blob/aad7187bde16880244fb593e126dda776369abf8/registry/README.md?plain=1#L15
In the Protocol, there are different types of
modules
(aka previouslyintegrations
):Protocol does put a restriction on a contract being combination of above module. For example, a module can be Plugin and Function handler simultaneously. For practical use case see this.
Current
check(...)
function does not provide any information on whether a given module is listed as a Plugin/Hooks/Function handler. So, in the implementation of the registry with this spec allows a contract to be exclusively only one of the type of modules.If multiple types are permitted in registry with current
check(...)
function, Protocol Manager implementation would not know whether an address should be allowed as a Plugin/Hooks/Function handler.So, specs should define a way to extract information on the types of module a contract can be used as.