# Programmable Clusters
### Overview
Programmable clusters enable developers to build custom validator and operator management modules, specializing in specific usecases. Open to all.
Cluster modules can be for specific staking apps (Lido, RPL, etc), public good(ERC20 modules) or even completley private (e.g. a Coinbase SSV module used internally by them).
Module developers can optmize and innovate around cluster modules to attract developers and operators. Modules can charge fees, creating a thriving module market.
Advantages:
* Ultimate developer and operator flexability
* Specific modules optimized for specific use cases
* Native fee abstraction support
* Simplified SSV contracts
* Module market and economics, breeds innovation
* Private operators abstracted as a module
* Optimize operator cost/revenue by utilizing infra as much as possible
### What Programmable Cluster Modules can control
1. Validators registration: Who, when, how, custom data, etc, changing cluster operators.
2. Operator registration: whitelisted/ public, collateral, slashing, etc.
3. User<>Operator Settelment: price, token, method(changeble, custom, programmatic)
### Examples Shortlist
* ERC20 module - pay in any erc20
* Lido specific module
* RPL specific module that distribuited rETH and RPL as rewards for squad staking
* Constant fee module - all operators paid the same, simplifies registration and makes it cheaper
* Private clusters - enable registering whitelisted users only
* Pegged ETH, stETH, rETH, etc fee - fee that is a % of rewards (using an oracle)
* Squad staking - set withdrawal address to the cluster module and distribuite inbound rewards to squad staking validators
* Collateralized operators - require operator collateral for registration to the module

## Details
The SSV contracts manage operator and validator registration.
When an operator registers, it's assigned a unique ID. Operators can opt-in to multiple cluster modules (each is a separate contract).
Users register a validator to a set of operators (cluster), following:
* All operators must support the selected cluster module
* If relevant, deposit to the module can be done
* SSV contract calls the module with registerValidator
* SSV contract adds validator to account to update network fee

Non complete cluster module interface, all cluster implementations must enforce.
~~~solidity
interface ICluster {
/// @notice Returns the module's name
function moduleName() external view returns(string);
/// @notice Registers a new validator
/// @notice CALLED ONLY BY THE SSV CONTRACT
/// @param publicKey The public key of the new validator
/// @param operatorIds Array of IDs of operators managing this validator
/// @param amount Amount of SSV tokens to be deposited
/// @param clusterModule The module to be used for all operators, 0x0000000000000000000000000000000000000000 for no module
/// @param info data to be used by the implementation, optional
function registerValidator(
bytes calldata publicKey,
uint64[] memory operatorIds,
uint256 amount,
address clusterModule,
bytes calldata info
) external;
/// @notice Removes an existing validator from the SSV Network
/// @param publicKey The public key of the validator to be removed
/// @param operatorIds Array of IDs of operators managing the validator
/// @param info data to be used by the implementation, optional
function removeValidator(bytes calldata publicKey, uint64[] memory operatorIds, bytes calldata info) external;
/// @notice Registers an operator to the cluster module
function registerOperator(uint64 operatorId) external;
...
}
~~~