> For the complete documentation index, see [llms.txt](https://csm-docs.cozy.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://csm-docs.cozy.finance/developer-guides/creating-a-safety-module/define-safety-module-configuration.md).

# Define Safety Module Configuration

Configuration for a Safety Module consists of `ReservePoolConfig[]`, `ControllerConfig[]`, and `DelaysConfig`. These configs are passed to `CozySafetyModuleManager.createSafetyModule` to deploy a new Safety Module.

```solidity
/// @notice Parameters for configuration updates.
struct ConfigUpdateCalldataParams {
  // The new reserve pool configs.
  ReservePoolConfig[] reservePoolConfigs;
  // The new controller configs.
  ControllerConfig[] controllerConfigUpdates;
  // The new delays config.
  Delays delaysConfig;
}

/// @notice Deploys a new SafetyModule with the provided parameters.
/// @param owner_ The owner of the SafetyModule.
/// @param pauser_ The pauser of the SafetyModule.
/// @param configs_ The configuration for the SafetyModule.
/// @param salt_ Used to compute the resulting address of the SafetyModule.
function createSafetyModule(
    address owner_,
    address pauser_,
    ConfigUpdateCalldataParams calldata configs_,
    bytes32 salt_
) external returns (ISafetyModule safetyModule_);
```

## Reserve Pool Config

```solidity
struct ReservePoolConfig {
  // The underlying asset of the reserve pool.
  IERC20 asset;
}
```

Note: The order of the reserve pool configs in the `ReservePoolConfig[]` array passed to `CozySafetyModuleManager.createSafetyModule` are used to determine the resulting reserve pool IDs in the deployed Safety Module.

### Reserve Pool Assets

Each reserve pool must have an underlying asset. Assets used by the Safety Module must follow the [Token Integration Guidelines](/developer-guides/token-integration-guidelines.md) to avoid any unexpected behavior. 

## Controller Config

```solidity
struct ControllerConfig {
  // The controller that is being configured.
  ISafetyModuleController controller;
  // Whether the controller is used by the SafetyModule.
  bool exists;
}
```

Safety Modules maintain a list of authorized controllers that can initiate a trigger event using `SafetyModule.trigger(bytes32 triggerEventId_)`. The `triggerEventId_`, generated by the controller, encodes information about the specific event. When triggered, the Safety Module updates the `TriggerEventRaiseState` for that `triggerEventId_` to `PENDING_RAISE`. The controller can then call `requestRaise(triggerEventId_)` to raise assets from the reserve pools, enabling them to be used as specified (see [Safety Module Raising](/developer-guides/safety-module-raises.md)).

### Controller

The controller to add to the Safety Module (see [Creating a Controller](/developer-guides/create-a-controller.md)).

### Exists

A boolean which specifies whether or not the trigger is used by the Safety Module. This is helpful for [configuration updates ](/developer-guides/manage-a-safety-module.md)to remove triggers from the list of triggers that are allowed to trigger the Safety Module.

## Delays Config

```solidity
struct Delays {
  // Duration between when SafetyModule updates are queued and when they can be executed.
  uint64 configUpdateDelay;
  // Defines how long the owner has to execute a configuration change, once it can be executed.
  uint64 configUpdateGracePeriod;
  // Delay for two-step withdraw process (for deposited reserve assets).
  uint64 withdrawDelay;
  // The default amount of time that a trigger event remains valid before expiring for this SafetyModule.
  uint256 triggerEventValidityDuration;
}
```

The Delays config is for Safety Module-level delays.

### Config Update Delay

The config update delay is the duration between when Safety Module updates are queued and when they can be applied / executed (see [Manage a Safety Module](/developer-guides/manage-a-safety-module.md)). This delay should be longer than the withdraw delay to allow Safety Module depositors to respond to queued config updates before they are applied.

### Config Update Grace Period

The config update grace period is the duration after the config update delay that the Safety Module owner is allowed to apply / execute the queued config changes  (see [Manage a Safety Module](/developer-guides/manage-a-safety-module.md)). If the owner does not apply the updates by the end of this period, they cannot be applied. 

### Withdraw Delay

The withdraw delay is for the two-step withdraw process (see [Safety Module Deposits](/developer-guides/safety-module-deposits.md)). This delay should be shorter than the config update delay to allow Safety Module depositors to respond to queued config updates before they are applied.

### Trigger Event Validity Duration

The trigger event validity duration outlines how long a trigger event from a controller is valid for. Once a trigger event expires, it can be reset by calling `safetyModule.resetTriggerEvent(ISafetyModuleController controller_, bytes32 triggerEventId_)`. Once a trigger event is reset, it can no longer be used to raise / tap funds from the safety module.