Tasks

Mimic offers a diverse range of standard tasks that users can seamlessly integrate into their Smart Vaults to automate various DeFi operations. These standard tasks provide users with a solid foundation for automating their workflows within the Mimic ecosystem.

The list of pre-defined tasks offered by Mimic can be found here.

Functionality

Tasks usually have responsibility to perform a single action on a Smart Vault. These either require permission granted on the Authorizer to execute that function, or sometimes they may rely on a connector to execute specific functionality that may require interacting with an external DeFi protocol (e.g. swapping assets in 1inch).

Settings

Tasks are highly customizable, allowing users to tailor their automated operations based on various parameters and conditions. Users can customize a wide range of configuration to control when these can be executed and triggered:

• Market conditions such as gas price or transaction cost limits

• Frequencies or time-locks of when these should be triggered

• Amount thresholds to control task execution

• Token lists to limit the set of tokens allowed for a task

Examples

A few examples of the standard tasks provided by Mimic are:

• Assets transfer tasks

• Assets collection tasks

• Swap tasks

• Bridge tasks

• Staking tasks

• LP related tasks

• Claiming rewards tasks

Customization

While the standard tasks cover a wide array of use cases, Mimic understands that each user may have unique requirements and specific use cases that may not be covered by the standard tasks. To address this, Mimic allows users to extend and customize the standard tasks to suit their individual needs. Users have the freedom to tweak and modify the existing tasks to align with their specific DeFi operations.

Furthermore, Mimic empowers users to implement their own custom tasks that cater to their specific use cases. If users encounter scenarios where the standard tasks do not suffice, the Mimic team is readily available to offer assistance. Users can reach out to the Mimic team for guidance and support in modeling their custom tasks, ensuring a tailored and comprehensive solution for their DeFi automation needs.

Some examples of custom tasks can be found here.

Initializers

First similarly to the rest of the standard tasks, custom tasks should expose two internal initializers:

• __ContractName_init_unchained which will only execute the initialization logic of the current contract without calling the upper contracts initializers, and

• __ContractName_init which will execute both the current and the upper contracts initializers

Then, custom tasks should expose an external initializer following the naming convention initializeCustomTaskName instead of initialize which is reserved for the standard tasks. Also if the custom task is inheriting a standard task, it disable the parent’s initializer.

Config structs

Defining custom configuration structs makes the deployment side a bit difficult. Therefore, we decided to add any custom arguments as extra parameters in the initializer function instead of providing a custom struct.

For example, the CollectorRelayerFunder task is indeed a Collector. Hence the initializer will receive the parent config as the first parameter, while adding any other required configuration as an extra parameter:

function initializeCollectorRelayerFunder(CollectConfig memory config, address relayer)
  external
  virtual
  initializer
{ ... }

Hooks

Similarly to all the standard tasks, custom tasks should define their own before and after hooks following the naming convetion _beforeContractName and _afterContractName. Each of these hooks must call the parent before and after hooks respectively.

Task amount

As well as hooks, while implementing custom tasks, users might want to override where the amount of a task should be read from. An example is the BaseRelayerFundTask task where the task amount is not determined based on a balance connector but based on the deposited balance in the Relayer contract.

Tokens source

Finally, the tokens source allows the user to specify an external source for the tokens that should be considered instead of the balance connectors which is the one used by default.