Execution modules

Execution modules are smart contracts containing the logic of the execution i.e. when conditions are met for the job to be executed. When a job is created through the JobRegistry contract, it commits to a single execution module. Execution modules are very abstract giving most flexibility for future execution logic. However, every execution module must implement the IExecutionModule interface:

interface IExecutionModule {
    function onExecuteJob(uint256 _index, uint32 _executionWindow) external returns (uint256);
    function onCreateJob(uint256 _index, bytes calldata _inputs, uint32 _executionWindow) external;
    function onDeleteJob(uint256 _index) external;
    function jobIsExpired(uint256 _index, uint32 _executionWindow) external view returns (bool);
    function jobIsInExecutionMode(uint256 _index, uint32 _executionWindow) external view returns (bool);
    function getEncodedData(uint256 _index) external view returns (bytes memory);
}

The onExecuteJob callback function is called by the JobRegistry upon execution. It returns the UNIX time in seconds when the job can be executed from. The onCreateJob callback function is called upon creation of a job and is passed arbitrary input data in form of the argument _input. It can be used to initialise auxiliary data structures within the module. Similarly, the onDeleteJob callback function is called by the JobRegistry contract upon deletion of a job. The jobIsExpired function returns a bool whether a job is expired and can be canceled. jobIsInExecutionMode returns whether the job is in execution mode. Lastly, the getEncodedData function returns all data stored in the execution module contract for a job index as an encoded bytes array.

Warning: onExecuteJob might revert which will in turn revert the original call to execute in JobRegistry. The execution module solely decides if the right conditions are met for the job to be executed.

In contrast to applications, execution modules are created and tested by the EES before being supported by the JobRegistry contract. The reason for gatekeeping the addition of execution modules is to avoid fragmentation as every executor has to implement logic to support new execution modules. However, the modular structure allows for progressively adding new and flexible logic to the protocol.

Note: Existing execution modules are completely immutable. The data stored in these can only be created or deleted with job creation or deletion but cannot be modified. A job cannot change execution module during its lifetime.

Applications can choose to implement logic to restrict creation of jobs with specific execution modules. An example could be a subscription payment application which chooses to only support recurring jobs. It is recommended that the set of supported modules is extensible, thus having the ability to support new modules in the future.