​
Context

​
Why use this method?

Opting-in through Symbiotic is ideal for validators that wish to be secured by ERC20 collateral residing from a Symbiotic vault.

Symbiotic is capital efficient in that vault collateral can be restaked towards other protocols. Further, Symbiotic offers a large degree of restaking configurability.

​
Prerequisites

Prior to opt-in through Symbiotic, it’s worth familiarizing yourself with their documentation on Networks, Vaults, and Operators. This method of validator opt-in requires competency in vault and operator curation.

​
Who is this for?

Mev-commit is flexible in the type of entities that use Symbiotic to restake, and secure validators with our protocol. Any combination of Operator and Vault entities can be used, whether each are from the same organization or not.

Most importantly, For L1 validators to be opted-in to mev-commit, some collateral stake must be slashable for each validator, in case that validator acts against its protocol commitments. In the context of Symbiotic, Vaults allocate slashable ERC20 collateral to Operators that are registered with the mev-commit network. This collateral may be slashable by other Symbiotic networks, hence it is restaked.

Operators for the mev-commit network are responsible for bulk registering groups of L1 validator pubkeys to an associated vault. Every registered validator is represented by restaked collateral from a single Vault and Operator. Each Vault’s total collateral can be split up to secure/represent many validators in groups.

​
Rewards

The primary reward that a validator earns in opting-in to mev-commit is increased yield, generated by providers being able to place higher bids in the mev-boost auction. See Why Participate for more details.

All vault/operator pairs must agree on how validator yield will be split or otherwise distributed.

We plan to introduce a points system that will be applied to all opted-in validators. In the context of using Symbiotic, each vault will earn points commensurate to the number of validators opted-in through that vault.

​
Setup

The following setup steps will reference various Symbiotic core contracts. Refer to their deployments page and core source code.

The Symbiotic CLI can assist in many of these steps. Refer to their docs.

1

Initial Network Setup

The Network in this context is mev-commit. Our network is represented by a network address, and a middleware contract. Both of which can be found on the testnet page. Mainnet support is coming soon.

Initially, the network address calls NetworkRegistry.registerNetwork to register with Symbiotic. Then NetworkMiddlewareService.setMiddleware to configure our middleware contract. This stage is completed by the mev-commit team (Primev).

2

Vault Configuration

A vault contract must be deployed and configured with slashable ERC20 collateral. Mev-commit will accept most forms of ERC20 collateral, unless they present significant risk of losing value. For non ETH denominated assets, overcollateralization may be required compared to their ETH denominated counterparts.

In general vault configuration is immutable, and thus important to get right. See Symbiotic’s vault configuration docs.

Mev-commit enforces vault configuration from the following dropdowns:

3

Operator Actions

Next, a Symbiotic operator can be setup as an EOA or a contract. The Operator must be registered with Symbiotic via OperatorRegistry.registerOperator().

The operator must then opt-in to the any vault which will secure validators via VaultOptInService.optIn(vaultAddress).

The operator then opts-in to the mev-commit network via NetworkOptInService.optIn(networkAddress). Do not confuse the mev-commit network address with the middleware contract address.

4

Coordinate with our Team

At this point you’ve setup a vault and operator pair that can be used to opt-in a group of validator pubkeys. Next you’ll need communicate the following details to our team:

  • The vault address and operator address setup in previous steps.
  • The type of ERC20 collateral that will be used to secure the validator pubkeys.
  • The decimal precision of the ERC20 collateral (not all ERC20s have 18 decimal precision).
  • The max amount of collateral your vault plans to allocate toward securing the mev-commit network. This value should be equal to or less than the total collateral in the vault.

Please provide these values to our team in the exact format described, and let us know if you have any questions.

From here our team will assign a slashAmount appropriate for the collateral type. slashAmount of collateral is required to define a single validator as being slashable, and therefore opted-in to mev-commit. The vault/operator pair is able to opt-in totalCollateral / slashAmount number of validators.

The network address (represented by Primev) will then set a max network limit for the vault’s delegator module, IBaseDelegator.setMaxNetworkLimit(uint96 identifier, uint256 amount). This is the maximum amount of collateral that will be accepted by the network from the vault.

The network address will also call:

  • MevCommitMiddleware.registerOperators to register the operator with the middleware contract.
  • MevCommitMiddleware.registerVaults to register the vault with the middleware contract, associated to a slashAmount.
5

Vault Actions

Finally the vault curator address must make some calls. setNetworkLimit(bytes32 subnetwork, uint256 amount) should be called on the delegator module of the vault. This sets the total amount of collateral the vault would like to restake to the mev-commit network.

For the mev-commit network, the subnetwork id is always 1, and the subnetwork argument can be computed using Symbiotic’s Subnetwork library, by concatenating the network address with the subnetwork ID. On Holesky for example, the subnetwork bytes value is 0x4535bd6ff24860b5fd2889857651a85fb3d3c6b1000000000000000000000001.

If using a NetworkRestakeDelegator, the vault curator must then call INetworkRestakeDelegator.setOperatorNetworkShares(bytes32 subnetwork, address operator, uint256 shares). This sets what portion of the mev-commit allocated stake the vault curator is allocating to a particular operator.

If using an OperatorSpecificDelegator, calling setOperatorNetworkShares is not required, as this type of delegator automatically allocates 100% of the “shares” to a single operator.

6

Setup Complete - Register Validators

Now that setup is complete, the operator can register validators to the vault, so long as enough slashable collateral is allocated to the operator from previous steps.

This is done through the holesky validator dashboard.

Validator deregistration is also done through this dashboard, and requires waiting a deregistration period.

​
How to Maintain Validators Stay Opted-In

It’s an operator’s responsibility to monitor vault collateral, and make sure all registered validators are also slashable. This means if vault collateral is reduced to a value that does not define all validators as slashable (considering slashAmount), the operator must deregister validators of its choice, or implicitly accept that some quasi-random validators will no longer be “opted-in”.

​
Context

​
Why use this method?

Opting-in through Symbiotic is ideal for validators that wish to be secured by ERC20 collateral residing from a Symbiotic vault.

Symbiotic is capital efficient in that vault collateral can be restaked towards other protocols. Further, Symbiotic offers a large degree of restaking configurability.

​
Prerequisites

Prior to opt-in through Symbiotic, it’s worth familiarizing yourself with their documentation on Networks, Vaults, and Operators. This method of validator opt-in requires competency in vault and operator curation.

​
Who is this for?

Mev-commit is flexible in the type of entities that use Symbiotic to restake, and secure validators with our protocol. Any combination of Operator and Vault entities can be used, whether each are from the same organization or not.

Most importantly, For L1 validators to be opted-in to mev-commit, some collateral stake must be slashable for each validator, in case that validator acts against its protocol commitments. In the context of Symbiotic, Vaults allocate slashable ERC20 collateral to Operators that are registered with the mev-commit network. This collateral may be slashable by other Symbiotic networks, hence it is restaked.

Operators for the mev-commit network are responsible for bulk registering groups of L1 validator pubkeys to an associated vault. Every registered validator is represented by restaked collateral from a single Vault and Operator. Each Vault’s total collateral can be split up to secure/represent many validators in groups.

​
Rewards

The primary reward that a validator earns in opting-in to mev-commit is increased yield, generated by providers being able to place higher bids in the mev-boost auction. See Why Participate for more details.

All vault/operator pairs must agree on how validator yield will be split or otherwise distributed.

We plan to introduce a points system that will be applied to all opted-in validators. In the context of using Symbiotic, each vault will earn points commensurate to the number of validators opted-in through that vault.

​
Setup

The following setup steps will reference various Symbiotic core contracts. Refer to their deployments page and core source code.

The Symbiotic CLI can assist in many of these steps. Refer to their docs.

1

Initial Network Setup

The Network in this context is mev-commit. Our network is represented by a network address, and a middleware contract. Both of which can be found on the testnet page. Mainnet support is coming soon.

Initially, the network address calls NetworkRegistry.registerNetwork to register with Symbiotic. Then NetworkMiddlewareService.setMiddleware to configure our middleware contract. This stage is completed by the mev-commit team (Primev).

2

Vault Configuration

A vault contract must be deployed and configured with slashable ERC20 collateral. Mev-commit will accept most forms of ERC20 collateral, unless they present significant risk of losing value. For non ETH denominated assets, overcollateralization may be required compared to their ETH denominated counterparts.

In general vault configuration is immutable, and thus important to get right. See Symbiotic’s vault configuration docs.

Mev-commit enforces vault configuration from the following dropdowns:

3

Operator Actions

Next, a Symbiotic operator can be setup as an EOA or a contract. The Operator must be registered with Symbiotic via OperatorRegistry.registerOperator().

The operator must then opt-in to the any vault which will secure validators via VaultOptInService.optIn(vaultAddress).

The operator then opts-in to the mev-commit network via NetworkOptInService.optIn(networkAddress). Do not confuse the mev-commit network address with the middleware contract address.

4

Coordinate with our Team

At this point you’ve setup a vault and operator pair that can be used to opt-in a group of validator pubkeys. Next you’ll need communicate the following details to our team:

  • The vault address and operator address setup in previous steps.
  • The type of ERC20 collateral that will be used to secure the validator pubkeys.
  • The decimal precision of the ERC20 collateral (not all ERC20s have 18 decimal precision).
  • The max amount of collateral your vault plans to allocate toward securing the mev-commit network. This value should be equal to or less than the total collateral in the vault.

Please provide these values to our team in the exact format described, and let us know if you have any questions.

From here our team will assign a slashAmount appropriate for the collateral type. slashAmount of collateral is required to define a single validator as being slashable, and therefore opted-in to mev-commit. The vault/operator pair is able to opt-in totalCollateral / slashAmount number of validators.

The network address (represented by Primev) will then set a max network limit for the vault’s delegator module, IBaseDelegator.setMaxNetworkLimit(uint96 identifier, uint256 amount). This is the maximum amount of collateral that will be accepted by the network from the vault.

The network address will also call:

  • MevCommitMiddleware.registerOperators to register the operator with the middleware contract.
  • MevCommitMiddleware.registerVaults to register the vault with the middleware contract, associated to a slashAmount.
5

Vault Actions

Finally the vault curator address must make some calls. setNetworkLimit(bytes32 subnetwork, uint256 amount) should be called on the delegator module of the vault. This sets the total amount of collateral the vault would like to restake to the mev-commit network.

For the mev-commit network, the subnetwork id is always 1, and the subnetwork argument can be computed using Symbiotic’s Subnetwork library, by concatenating the network address with the subnetwork ID. On Holesky for example, the subnetwork bytes value is 0x4535bd6ff24860b5fd2889857651a85fb3d3c6b1000000000000000000000001.

If using a NetworkRestakeDelegator, the vault curator must then call INetworkRestakeDelegator.setOperatorNetworkShares(bytes32 subnetwork, address operator, uint256 shares). This sets what portion of the mev-commit allocated stake the vault curator is allocating to a particular operator.

If using an OperatorSpecificDelegator, calling setOperatorNetworkShares is not required, as this type of delegator automatically allocates 100% of the “shares” to a single operator.

6

Setup Complete - Register Validators

Now that setup is complete, the operator can register validators to the vault, so long as enough slashable collateral is allocated to the operator from previous steps.

This is done through the holesky validator dashboard.

Validator deregistration is also done through this dashboard, and requires waiting a deregistration period.

​
How to Maintain Validators Stay Opted-In

It’s an operator’s responsibility to monitor vault collateral, and make sure all registered validators are also slashable. This means if vault collateral is reduced to a value that does not define all validators as slashable (considering slashAmount), the operator must deregister validators of its choice, or implicitly accept that some quasi-random validators will no longer be “opted-in”.