Authorizer

The Authorizer contract is a crucial component of the Mimic protocol, responsible for managing permissions and access control within the ecosystem. It provides a comprehensive permissions layer to regulate specific actions and operations performed by different accounts or entities.

The contract code of the Authorizer can be found here.

Functionality

The Authorizer contract provides the following key functions:

Authorize

This function serves the purpose of granting access to a specific account (who) to perform a particular action (what) on a designated entity (where). This function requires the sender to have the necessary permissions to authorize actions within the Authorizer contract.

/**
 * @dev Authorizes `who` to call `what` on `where` restricted by `params`
 * @param who Address to be authorized
 * @param where Target address to be granted for
 * @param what Function selector to be granted
 * @param params Optional params to restrict a permission attempt
 */
function authorize(address who, address where, bytes4 what, Param[] memory params) external;

The params argument provides flexibility by allowing the sender to specify various conditions under which permission to perform the corresponding action (where) should be granted or denied. Typically, these conditions pertain to the specific parameters of the action. For instance, the sender may wish to authorize an account to grant permissions for a specific action while restricting access to other actions. This fine-grained control can be achieved by configuring the params argument.

By utilizing the authorize function with the params argument, users can tailor permissions based on specific requirements and granular access control. This feature enables more nuanced authorization scenarios, allowing for the customization of permissions on a per-action basis.

Unauthorize

This function is employed to withdraw access granted to a particular account (who) for performing a specific action (what) on a designated entity (where). To successfully execute this function, the sender must possess the necessary permissions to revoke authorizations within the Authorizer contract.

/**
 * @dev Unauthorizes `who` to call `what` on `where`. Sender must be authorized.
 * @param who Address to be authorized
 * @param where Target address to be revoked for
 * @param what Function selector to be revoked
 */
function unauthorize(address who, address where, bytes4 what) external;

Change permissions

This function allows the sender to execute a batch of permission changes in a single transaction. The sender must have permission to grant and revoke access on the Authorizer.

/**
 * @dev Executes a list of permission changes
 * @param changes List of permission changes to be executed
 */
function changePermissions(PermissionChange[] memory changes) external;

Security Considerations

It is crucial to emphasize that the Authorizer contract serves as the central repository for managing permissions across all the user's deployed components. This is where the permissions for various elements (Smart Vault, Price Oracle, and Tasks) are defined and maintained.

When configuring the layout of permissions, it is highly recommended to seek guidance and support from the Mimic team. Their expertise can ensure that the permissions framework is properly established to align with your specific needs and requirements.

It is important to note that Mimic does not enforce any specific layout for permissions. Instead, it provides users with full control and flexibility to configure permissions according to their preferences. This level of customization empowers users to design a permissions framework that best suits their governance model and security objectives.

However, this flexibility also brings a significant responsibility. Users must exercise diligence and care in setting up the permissions layout to ensure proper connections and secure access control. Properly configuring the permissions module is crucial for maintaining the integrity, security, and smooth operation of the Mimic protocol.

Therefore, it is highly recommended to consult with the Mimic team during the setup process. Their assistance can help ensure that the permissions layout is established correctly, minimizing potential risks and maximizing the effectiveness of the permissions system.

Remember, the permissions module offers great flexibility, but it also requires a diligent and responsible approach to ensure its proper configuration and connection to the rest of the protocol's components. The Mimic team is ready to provide guidance and support to ensure a successful and secure implementation.

Last updated