Symbiotic Parameters

This page outlines the parameters required to initialize a Symbiotic Byzantine Vault. These parameters enable the configuration of key Symbiotic modules: the BurnerRouter, the Vault, the Delegator, and the Slasher.

These parameters are specific to the Byzantine vaults that delegates their stake to operators and networks on Symbiotic.

SymParams

This data structure is the main container used to initialize a Sym Byz Vault. It aggregates the configuration for all Symbiotic modules: burner, vault, delegator, and slasher.

Parameter	Type	Description
burnerParams	BurnerParams	Configures where slashed funds are routed
vaultParams	VaultParams	Governs vault metadata, ownership, and epoch behavior
delegatorParams	DelegatorParams	Handles delegation logic across networks and operators
slasherParams	SlasherParams	Configures the slashing and veto rules

BurnerParams

This data structure defines the settings of the BurnerRouter contract tied to the vault. It configures where the slashed funds will be sent after a Symbiotic operator get slashed.

Parameter	Type
owner	address
delay	number
globalReceiver	address
networkReceivers	NetworkReceiver[]
operatorNetworkReceivers	OperatorNetworkReceiver[]

You can notice there are three different receivers in the router. Each of them have a different level of priority (1 being the highest) depending on the network and the slashed operator:

1. operatorNetworkReceivers

2. networkReceivers

3. globalReceivers

More details can be found here.

Breaking down the parameters

owner

Admin address of the BurnerRouter.

• Can change the routes by modifying or setting new receivers

• Can change the BurnerRouter's delay

• Must be a trusted address or set to address(0) to make the routes immutable

• This address cannot be changed once set, so choose it wisely.

---

delay

Delay (in seconds) before new settings on the BurnerRouter take effect. It allows the stakers to withdraw their position if they disagree with the owner's new configuration choice.

• When a new delay is set, it takes effect after delay seconds.

• When a new route is set, it takes effect after delay seconds.

---

globalReceiver

Default receiver address of the slashed funds.

• Funds are routed there only if no networkReceiver or operatorNetworkReceiver are configured for the slashing event.

• It is mainly the address of the token's default Burner contract.

---

networkReceivers

Optional array parameter to define a specific route if a specific network is slashed.

• Each network can have its own slashing policy and may choose not to burn the slashed funds, but instead use or redistribute them.

• Takes precedence over globalReceiver.

• Can be set as an empty array of NetworkReceiver[]

The NetworkReceiver data structure is made up of 2 addresses:

Parameter	Type
network	address
receiver	address

• network: the address of the network where the slashing is triggered

• receiver: the address where slashed funds will be routed if the network applies a slashing

---

operatorNetworkReceivers

Optional array parameter to define a specific route if a specific operator is slashed within a specific network.

• Each network can have its own slashing policy and may choose not to burn the slashed funds, but instead redistribute them to honest operators, for instance.

• Takes precedence over networkReceivers.

• Can be set as an empty array of OperatorNetworkReceiver[]

The OperatortNetworkReceiver data structure is made up of 3 addresses:

Parameter	Type
network	address
operator	address
receiver	address

• network: the address of the network where the slashing is triggered

• operator: the address of the operator that have been slashed

• receiver: the address where slashed funds will be routed if the network applies a slashing to operator

VaultParams

This data structure defines the settings of the Symbiotic Vault contract tied to the Byzantine Vault. It specifies ownership, implementation version, and epoch configuration for the Symbiotic vault.

Parameter	Type
version	number
epochDuration	number

Breaking down the parameters

version

Implementation version of the underlying Symbiotic vault that will be deployed.

• Only the versionManagers can migrate the Symbiotic Vault to newer versions

---

epochDuration

Symbiotic vault's epoch duration (in seconds)

• Defines the vault’s operational cycle. Learn more about epochDuration here.

DelegatorParams

This data structure defines the settings of the Symbiotic Delegator contract tied to the Sym Byz Vault. It handles stake delegation logic across networks and operators.

Parameter	Type
delegatorType	number
hook	address
hookSetRoleHolder	address
networkLimitSetRoleHolders	address[]
operatorNetworkLimitOrSharesSetRoleHolders	address[]
operator	address
network	address

Before moving forward, it's important to understand the different delegator types available on Symbiotic in order to create the restaking strategy that best meets your needs.

The specific features of each Delegator type are explained in details in the Symbiotic Delegator section. To sum it up, it exists 4 types of delegators:

Network Restake Delegator (Type 0)

• Allocations to networks are set using absolute numbers.

• Allocations to operators are expressed as shares of the network's total allocation.

• Restaking is allowed across networks, but not across operators within a single network.

• Operator and network allocations can be changed at any time by the respective role holders (networkLimitSetRoleHolders and operatorNetworkLimitOrSharesSetRoleHolders).

Full Restake Delegator (Type 1)

• Allocations to both networks and operators are absolute numbers.

• Restaking is allowed both across networks and across operators within each network.

• Operator and network allocations can be modified at any time by the designated role holders (networkLimitSetRoleHolders and operatorNetworkLimitOrSharesSetRoleHolders).

Operator Specific Delegator (Type 2)

• Stake is allocated to a single, fixed operator across one or more networks.

• Restaking across networks is possible only if the operator has opted in to each network.

• The operator is immutable once the vault is created.

• Network allocations can still be updated by the vault’s curator (networkLimitSetRoleHolders).

Operator Network Specific Delegator (Type 3)

• Stake is allocated to one specific operator on one specific network.

• This is the most restrictive delegation mode: both operator and network are fixed and immutable.

• No allocation changes are allowed after vault creation.

Breaking down the parameters

delegatorType

The type of Symbiotic Delegator to deploy:

• 0 for NETWORK_RESTAKE_DELEGATOR

• 1 for FULL_RESTAKE_DELEGATOR

• 2 for OPERATOR_SPECIFIC_DELEGATOR

• 3 for OPERATOR_NETWORK_SPECIFIC_DELEGATOR

---

hook

Optional hook contract to adjust delegations after a slashing event.

• If set, called on each slash.

• Examples of hooks can be found here.

• ⚠️ If not zero, the hook has to be appended to networkLimitSetRoleHolders and operatorNetworkLimitOrSharesSetRoleHolders so that the contract has the right to adjust the delegation strategy.

---

hookSetRoleHolder

Address allowed to set / change the hook contract.

• When the hook is changed, the new hook address has to be appended to networkLimitSetRoleHolders and operatorNetworkLimitOrSharesSetRoleHolders so that the new contract has the right to adjust the delegation strategy.

---

networkLimitSetRoleHolders

Array of authorized addresses to manage network delegation limits.

• Used in NETWORK_RESTAKE, FULL_RESTAKE, and OPERATOR_SPECIFIC delegators.

• Can be left empty for OPERATOR_NETWORK_SPECIFIC delegator (where vaults can only delegate to one unique network).

• networkLimit can be set only once networks have opted-in for the Vault (set a maxNetworkLimit higher than 0)

---

operatorNetworkLimitOrSharesSetRoleHolders

Array of authorized addresses to manage operator-network delegation.

• Used in NETWORK_RESTAKE (shares) and FULL_RESTAKE (limit) delegators.

• Can be left empty for OPERATOR_SPECIFIC and OPERATOR_NETWORK_SPECIFIC (where vaults can only delegate to one unique operator).

• For the operator-network stake to be accounted by the networks, operators must have opted-in for the networks and the vault.

---

operator

Address of the operator to delegate to.

• Only used if the chosen delegator is OPERATOR_SPECIFIC or OPERATOR_NETWORK_SPECIFIC (where the address of the operator must be set during the vault creation).

• Can be set to address(0) for the other type of delegators.

• Cannot be changed after vault deployment.

• This operator address has to be registered in the Symbiotic Operator Registry.

---

network

Address of the delegated network.

• Only used in OPERATOR_NETWORK_SPECIFIC (where the address of the network must be set during the vault creation).

• Can be set to address(0) for the other type of delegators.

• Cannot be changed after vault deployment.

• The network address has to be registered in the Symbiotic Network Registry.

SlasherParams

This data structure defines the settings of the Symbiotic Slasher contract tied to the Sym Byz Vault. It configures the slashing and veto rules (if enabled).

Parameter	Type
slasherType	number
vetoDuration	number
resolverSetEpochsDelay	number

It exists so far two types of slasher on Symbiotic:

Instant Slasher (Type 0)

• Common Slasher that receives slashing requests and instantly executes them

Veto Slasher (Type 1)

• Allows to veto received slashing requests using resolvers

• Only networks can set resolvers that can veto the slashing requests

• ⚠️ It is possible for the networks not to set a resolver, thus enabling an instant slashing mechanic similar to Instant Slasher.

• If the Vault curator is not ready to provide a stake without the resolver, the curator may simply not allocate any stake to such networks.

All slashers have by default isBurnerHook set to true to trigger the onSlash() function of the BurnerRouter if slashing

Breaking down the parameters

slasherType

The type of Symbiotic Slasher to deploy:

• 0 for INSTANT_SLASHER

• 1 for VETO_SLASHER

---

vetoDuration

The slasher’s veto duration in seconds.

• Used only in VETO slasher.

• Defines a period after a slashing request creation for resolvers to veto the request

• Can be set to zero to remove veto functionality

---

resolverSetEpochsDelay

The resolvers’ delay in epochs.

• Used only in VETO slasher.

• This parameter defines a period that needs to pass after a network updates a resolver for the resolver to be enabled for the network in the Slasher contract

• Can be set equal to a minimum of 3 epochs for users to be able to withdraw funds before the update.