# A possible approach to CSM integrations

## Preface
To create a Node Operator in CSM, at least one deposit data and corresponding bond is required. When the operator is created, `managerAddress` and `rewardAddress` are set to `message.sender` by default to avoid loss of funds due to misconfiguration. These two facts make it hard to properly operate in a "bond provider + validator runner" model or DVT-based validator. For DVT, a multisig is required for the creation of the Node Operator. Even though both `managerAddress` and `rewardAddress` can be changed after Node Operator creation, the initial bond and deposit data still need to be managed by a single address during the Node Operator creation.

Recently added ability to set custom `managerAddress` and `rewardAddress` upon Node Operator creation opens a wide variety of custom CSM integrations.

## SimpleDVT-like approach


DVT operators create a Cluster Multisig beforehand and use it to create a Node Operator in CSM. Control over the Node Operator's keys can be kept at Cluster Multisig or delegated to the cluster leader (EOA or MultiSig). The `rewardAddress` (recipient of the rewards) should still be a Cluster Multisig to ensure the safety of the bond and rewards.

## Custom integrations
An alternative approach might be an integration middleware. CSM allows the assignment of a custom `managerAddress` and `rewardAddress` upon Node Operator creation. This allows middleware to prepare and verify required addresses before the call to `addNodeOperator`.

It is also crucial to note that bond funds can be collected customarily before the Node Operator creation. This allows for a smoother UX in this aspect.

### DVT


For DVT a middleware can create a splitter contract to be assigned as a `rewardAddress` and assign `managerAddress` to a Cluster leader (EOA or MultiSig). A middleware can store all necessary information about the cluster participants and the required rewards split algorithm.

A bond can also be collected on the middleware contract beforehand in a custom way. Say cluster participants supply parts of the bond in a trustless way to allow for further Node Operator creation or upload of additional keys.

Since bond top-up is a permissionless operation (anyone can top-up bond for the existing Node Operator), it is up to the middleware developers to decide on the suitable flow of the bond upload for the new keys uploaded after the Node Operator creation.

### A separate validator runner and bond provider


Custom middleware can also allow for the split of the validator runner and bond provider. In this case, all rewards can be transferred to the bond provider by setting him as a `rewardAddress`. At the same time, a `managerAddress` can be assigned to a validator runner (EOA or MultiSig) to allow for the keys management.

The bond provider can be sure that the validator runner will not be able to get access to the bond itself and other parts of the rewards since all of them will be allocated to the bond provider as a `rewardAddress` owner. It is up to the bond provider to decide on the actual reward split.

Since Node Operator creation requires at least one deposit data upload alongside the bond, a middleware can collect the bond from the provider and deposit data from the validator runner before creating a Node Operator.

For future uploads of the keys, the bond provider can top up the bond using a permissionless method. Once topped up, the validator runner can upload new deposit data.

> **Note:**
>
> Integration developers should take into account the fact that `rewardAddress` can reset `managerAddress`. In case of bond manager and validator runner separtion integration should ensure that bond manager can not 'rug' validator runner by taking over the `managerAddress` and triggering exits of validators after EIP-7002 implementation in the future versions of CSM.
>
> This can be done by using a reward splitter contract that will not be able to reset `managerAddress`.