Symbiotic Strategy

This section explores how the curators of a Sym Byz vault can efficiently and strategically manage their operator and network delegations.

Prerequisites

Read this page to understand the Delegation and Delegators concepts in the Symbiotic Protocol.

Overview

Byzantine has abstracted the complexity of the Symbiotic protocol's multiple contracts and features. Curators of the Sym Byz vault can easily manage and delegate stakes to networks and operators through a streamlined, single point of access. (cf. High Level Contract Structure)
The relevant curator roles mentioned in this section are: networkLimitSetRoleHolders and operatorNetworkLimitOrSharesSetRoleHolders. (cf. here)
At the creation of the Sym Byz vault, the vault creator must opt for a Delegator among the four types of Delegators implemented by Symbiotic: NetworkRestakeDelegator, FullRestakeDelegator, OperatorSpecificDelegator and OperatorNetworkSpecificDelegator. The level of risk varies from one delegator type to another.

If the term "Symbiotic vault" is not specified, "Sym Byz vault" and "vault" are synonymous in this section. A new Symbiotic vault is automatically created alongside a Sym Byz vault.

High Level Contract Structure

Curators interacts directly with the Sym Syz vault to manage their delegation strategy.

Links to the abovementionned contracts:

SymERC20ByzVault
SymbioticManager
BaseDelegator
SymNativeByzVault: available soon

Delegators in Symbiotic

To effectively manage a vault's delegations and develop a strategy that aligns with a particular risk profile, it is crucial to understand how the four types of Delegators work in the Symbiotic protocol.

The table below the respective features of the four Delegators to help curators assess the risk profile that suits their needs:

Features / Delegator Type*

NRD

FRD

OSD

ONSD

Vault configuration¹

MNMO

SNMO

MNMO

SNMO

MNSO

SNSO

Restaking across multiple networks ²

✅

❌

Restaking across multiple operators within the same network ³

❌

✅

❌

Stake isolation for networks ⁴

SNMO ✅ MNMO ❌

❌

✅

Stake isolation for operators⁵

❌

✅

Relative risk level⁶

(4 being the highest)

Explanatory note:

* Delegator Types:

NRD: Network Restake Delegator
FRD: Full Restake Delegator
OSD: Operator Specific Delegator
ONSD: Operator Network Specific Delegator

The types of Delegator allow various configurations of the vault regarding the number of networks and operators.
- MNMO: Multiple Networks, Multiple Operators
- MNSO: Multiple Networks, Single Operator
- SNMO: Single Network, Multiple Operators
- SNSO: Single Network, Single Operator
Restaking across multiple networks allows the stake of the vault to be restaked in every network that has been opted-in to the vault. (cf. Delegator diagram 1, 2 & 3)
Restaking across multiple operators within the same network allows the stake of the vault to be restaked across multiple operators within the same network. (cf. Network 3 in Delegator diagram 2)
Stake isolation for networks ensures that the stake is dedicated uniquely to a single network. This prevents cross-slashing events, ensuring that a slashing event in one network does not impact the stake levels in others.
Stake isolation for operators ensures that the stake is dedicated uniquely to a single operator. This protects against stake manipulation by malicious curators, as each operator's stake is independent and cannot affect others.
The risk level score is determined by comparing the four types of Delegators with each other.

For more details on how the Delegator type can affect the slashing result, go to here.

Diagram for understanding restaking in each Delegator type

Strategy Management

The delegation process varies depending on the type of Delegator selected. Regardless of the type of Delegator, the curator only needs to interact with the following two functions to implement a delegation strategy or modify it:

    /**
     * @notice Set operator shares or limit for a subnetwork for a set of operators
     */
    function manageOperatorsDelegation(
        bytes32[] memory subnetworks,
        address[] memory operators,
        uint256[] memory sharesOrLimits
    ) external;

Only the Network Limit Set Role Holders have the permission to call the above function.

    /**
     * @notice Set the stake limits of a set of subnetworks (how much stake the vault curator is ready to give to the subnetworks)
     */
    function manageNetworksDelegation(bytes32[] memory subnetworks, uint256[] memory limits) external;

Only the Operator Network Limit Set Role Holders have the permission to proceed with the above function.

Step-by-Step Strategy Implementation

Based on the chosen Delegator, curators can consult the appropriate step-by-step guide to learn how to establish and modify a delegation strategy.

🍀 Recommendations:

For a more efficient and straightforward strategy implementation process, it is recommended that curators get in touch with networks and operators in advance to ensure both's willing to work with the Sym Byz vault.

A network must set its maximum limit to the vault before the curator calls manageNetworksDelegation to set the network's stake limit. Otherwise, the Set network limits step mentioned below will fail. By setting a non-zero limit for a Sym Byz vault, the network shows its willingness to work with this particular vault.

There can be multiple networks and multiple operators in this delegator type.

1. Register all entities

Before any vault interaction can occur, operators and networks must first register in the Symbiotic registries.

Operators must register using registerOperator() in the OperatorRegistry contract.
Networks must register using registerNetwork() in the NetworkRegistry contract, and link their middleware using setMiddleware(address) in the NetworkMiddlewareService contract.

Registration is a one-time setup per entity. Once registered, operators and networks do not need to register again when interacting with other vaults.

2. Opt-ins

Once entities are registered, both operators and networks must explicitly opt into the Sym Byz vault before any stake can be delegated.

Operators must opt-in using: optIn(byzSymVaultAddress) via the VaultOptInService contract. This signals they are willing to receive stake from the SymByzVault.
Networks must set the maximum stake they are willing to receive by calling: setMaxNetworkLimit(subnetwork, maxLimit) directly on the delegator contract of the SymByzVault.

Without this opt-in, delegation will fail. This handshake confirms the willingness of each party to interact with the vault.

3. Delegation strategy

Once all entities have completed their registration and opt-ins, the curator of the Sym Byz vault can configure the delegation strategy.

In the NRD (Network Restake Delegator) configuration, delegation is handled in two steps:

First, define how much stake each network can receive.

Once the networks opted-in to vault have set their maximum limits (maxLimit) for the vault, the curator can call manageNetworksDelegation to set each network's limit to the vault (networkLimit). This defines the maximum amount of stake a curator can allocate to each network.

The network limit set by the curator should not exceed the maximum limit set by the network.

$networkLimit ≤ maxLimit$

Then, define how that stake is distributed across operators (one per network in NRD).

With the handshake between the networks and the SymByzVault now complete, the curator can set a stake limit for each operator within every opted-in network. This defines the maximum amount of stake a curator can allocate to each operator within the network.

The curator must specify a number of shares they wish to allocate to the operator for a particular network. As mentioned earlier, the NRD type does not allow restaking across multiple operators within the same network (cf. Diagram 1). The weight of the stake allocated to an operator depends on the total number of shares within the network. Each operator's stake is distinct, ensuring it's not reused (restaked) in the same network.

The example below illustrates the calculation of stake weight:

The total stake allocated to all operators within a single network will never exceed the total stake of the vault.

The total stake of the SymByzVault is 2000 ETH. Curator has allocated 200 shares to Operator 1 and 1000 shares to Operator 2 (total shares of 1000).

Calculation of the weight of each operator: $weightOp = sharesOp / totalShares$

Stake weight of Operator 1 ≈ 16.66%
Stake weight of Operator 2 ≈ 83.33%

Calculation of the stake allocated to each operator: $stakeOp = totalStake * weightOp$

Stake allocated to Operator 1 ≈ 333.2 ETH
Stake allocated to Operator 2 ≈ 1666.6 ETH

There can be multiple networks and multiple operators in this delegator type.

1. Register all entities

Before any vault interaction can occur, operators and networks must first register in the Symbiotic registries.

Operators must register using registerOperator() in the OperatorRegistry contract.
Networks must register using registerNetwork() in the NetworkRegistry contract, and link their middleware using setMiddleware(address) in the NetworkMiddlewareService contract.

Registration is a one-time setup per entity. Once registered, operators and networks do not need to register again when interacting with other vaults.

2. Opt-ins

Once entities are registered, both operators and networks must explicitly opt into the Sym Byz vault before any stake can be delegated.

Operators must opt-in using: optIn(byzSymVaultAddress) via the VaultOptInService contract. This signals they are willing to receive stake from the SymByzVault.
Networks must set the maximum stake they are willing to receive by calling: setMaxNetworkLimit(subnetwork, maxLimit) directly on the delegator contract of the SymByzVault.

Without this opt-in, delegation will fail. This handshake confirms the willingness of each party to interact with the vault.

3. Delegation strategy

Once all entities have completed their registration and opt-ins, the curator of the SymByzVault can configure the delegation strategy.

In the FRD (Full Restake Delegator) configuration, delegation is handled in two steps:

1. Set network limits

Once the networks opted-in to the vault have set their maximum limits (maxLimit) for the vault, the curator can call manageNetworksDelegation to set each network's limit to the vault (networkLimit). This defines the maximum amount of stake a curator can allocate to each network.

The network limit set by the curator should not exceed the maximum limit set by the network.

$networkLimit ≤ maxLimit$

2. Set operator limits for networks

The total stake allocated to all operators within a single network can exceed the total stake of the vault.

With the handshake between the networks and the SymByzVault now complete, the curator can set a stake limit for each operator within every opted-in network. This defines the maximum amount of stake a curator can allocate to each operator within the network.

Unlike the NRD, the curator specifies a limit of stake for each operator within a particular network. This thereby allows restaking not only across networks but also within the same network. In other words, every operator within a single network can be allocated the total amount of stake that a SymByzVault has. (cf. Diagram 2)

There can be multiple networks but one single operator in this delegator type.

1. Register all entities

Before any vault interaction can occur, operators and networks must first register in the Symbiotic registries.

Operators must register using registerOperator() in the OperatorRegistry contract.
Networks must register using registerNetwork() in the NetworkRegistry contract, and link their middleware using setMiddleware(address) in the NetworkMiddlewareService contract.

Registration is a one-time setup per entity. Once registered, operators and networks do not need to register again when interacting with other vaults.

2. Opt-ins

Once entities are registered, both operators and networks must explicitly opt into the Sym Byz vault before any stake can be delegated.

Operators must opt-in using: optIn(byzSymVaultAddress) via the VaultOptInService contract. This signals they are willing to receive stake from the SymByzVault.
Networks must set the maximum stake they are willing to receive by calling: setMaxNetworkLimit(subnetwork, maxLimit) directly on the delegator contract of the SymByzVault.

Without this opt-in, delegation will fail. This handshake confirms the willingness of each party to interact with the vault.

3. Delegation strategy

Once all entities have completed their registration and opt-ins, the curator of the SymByzVault can configure the delegation strategy.

In this delegator type, the creator should have already delegated 100% of the stake to a specific operator at the creation of the SymByzVault. This way, the curator has only one step to complete the delegation process.

Set network limits

The network limit set by the curator should not exceed the maximum limit set by the network.

$networkLimit ≤ maxLimit$

There can only be one single network and one single operator in this delegator type.

1. Register all entities

Before any vault interaction can occur, operators and networks must first register in the Symbiotic registries.

Operators must register using registerOperator() in the OperatorRegistry contract.
Networks must register using registerNetwork() in the NetworkRegistry contract, and link their middleware using setMiddleware(address) in the NetworkMiddlewareService contract.

Registration is a one-time setup per entity. Once registered, operators and networks do not need to register again when interacting with other vaults.

2. Opt-ins

Once entities are registered, both operators and networks must explicitly opt into the Sym Byz vault before any stake can be delegated.

Operators must opt-in using: optIn(byzSymVaultAddress) via the VaultOptInService contract. This signals they are willing to receive stake from the SymByzVault.
Networks must set the maximum stake they are willing to receive by calling: setMaxNetworkLimit(subnetwork, maxLimit) directly on the delegator contract of the SymByzVault.

Without this opt-in, delegation will fail. This handshake confirms the willingness of each party to interact with the vault.

3. Delegation strategy

Once all entities have completed their registration and opt-ins, the curator of the SymByzVault can configure the delegation strategy.

But in this delegator type, the curator has nothing to do as the strategy has been implemented at the creation of the Sym Byz vault. The vault creator should have delegate 100% of the vault stake to a specific network and to a specific operator.

Strategy Modifications

The curators can change the vault strategy by calling the same functions for implementation.

Useful Information For Strategy Management

Multiple parties are involved in dealing with the Symbiotic strategy implementation, such as networks, operators and curators. It is helpful for curators to know about the actions taken by the operators and the networks before making any decision. The following functions allow the curators to check the details related to participants of the vault.

Purposes

Contracts to interact with

Functions to call

Check if a Network or an Operator has registered within the Symbiotic ecosystem

IOperatorRegistry

isEntity()

Check if an Operator has opted-in to a Symbiotic vault (and at a specific moment)

IOptInService

isOptedIn() isOptedInAt()

Check if an Operator has opted-in to a Network

IOptInService

isOptedIn() isOptedInAt()

All types of Delegator

Check the maximum limit set by a Network

IBaseDelegator

maxNetworkLimit()

For NRD

Check the sum of Operators' shares for a specific Network (and at a specific moment)

INetworkRestakeDelegator

totalOperatorNetworkShares() totalOperatorNetworkSharesAt()

Check an Operator's shares for a Network

INetworkRestakeDelegator

operatorNetworkShares()

Check the Network limit set by the curator itself

INetworkRestakeDelegator

networkLimit()

For FRD

Check an Operator's limit for a Network (and at a specific moment)

IFullRestakeDelegator

operatorNetworkLimit() operatorNetworkLimitAt()

Check the Network limit set by the curator itself (and at a specific moment)

IFullRestakeDelegator

networkLimit() networkLimitAt()

For OSD

Check the Operator managing the vault's funds

IOperatorSpecificDelegator

operator()

Check the Network limit set by the curator itself (and at a specific moment)

IOperatorSpecificDelegator

networkLimit() networkLimitAt()

For ONSD

Check the Operator managing the vault's funds

IOperatorNetworkSpecificDelegator

operator()

Check the Network the vault delegates the funds to

IOperatorNetworkSpecificDelegator

network()

Check the maximum limit set by a Network at a specific moment

IOperatorNetworkSpecificDelegator

maxNetworkLimitAt()

To call the functions above mentioned, it is necessary to know the addresses of the deployed contracts. Find them here.

PreviousEigenLayer Strategy NextCross Protocol Vault

Last updated 13 days ago