Symbiotic Parameters
Last updated
Last updated
This page outlines the parameters required to initialize a Symbiotic Byzantine Vault. These parameters enable the configuration of key Symbiotic modules: the , the , the , and the .
These parameters are specific to the Byzantine vaults that delegates their stake to operators and networks on Symbiotic.
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.
BurnerParams
Configures where slashed funds are routed
VaultParams
Governs vault metadata, ownership, and epoch behavior
DelegatorParams
Handles delegation logic across networks and operators
SlasherParams
Configures the slashing and veto rules
This data structure defines the settings of the contract tied to the vault. It configures where the slashed funds will be sent after a Symbiotic operator get slashed.
address
number
address
NetworkReceiver[]
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:
number
number
number
address
address
address[]
address[]
address
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.
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.
Allocations to both networks and operators are absolute numbers.
Restaking is allowed both across networks and across operators within each network.
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.
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.
number
number
number
It exists so far two types of slasher on Symbiotic:
Common Slasher that receives slashing requests and instantly executes them
Only networks can set resolvers that can veto the slashing requests
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.
More details can be found .
Can change the BurnerRouter's
Delay (in seconds) before new settings on the BurnerRouter take effect. It allows the stakers to withdraw their position if they disagree with the 's new configuration choice.
Funds are routed there only if no or are configured for the slashing event.
It is mainly the address of the token's .
Each network can have its own slashing policy and may choose not to burn the slashed funds, but instead .
Takes precedence over .
Each network can have its own slashing policy and may choose not to burn the slashed funds, but instead , for instance.
Takes precedence over .
This data structure defines the settings of the contract tied to the Byzantine Vault. It specifies ownership, implementation version, and epoch configuration for the Symbiotic vault.
Only the can migrate the Symbiotic Vault to newer versions
Defines the vault’s operational cycle. Learn more about epochDuration .
This data structure defines the settings of the contract tied to the Sym Byz Vault. It handles stake delegation logic across networks and operators.
The specific features of each Delegator type are explained in details in the . To sum it up, it exists 4 types of delegators:
Operator and network allocations can be changed at any time by the respective role holders ( and ).
Operator and network allocations can be modified at any time by the designated role holders ( and ).
Network allocations can still be updated by the vault’s curator ().
Examples of hooks can be found .
If not zero, the hook has to be appended to and so that the contract has the right to adjust the delegation strategy.
When the hook is changed, the new hook address has to be appended to and so that the new contract has the right to adjust the delegation strategy.
Used in , , and delegators.
Can be left empty for delegator (where vaults can only delegate to one unique network).
Used in (shares) and (limit) delegators.
Can be left empty for and (where vaults can only delegate to one unique operator).
Only used if the chosen delegator is or (where the address of the operator must be set during the vault creation).
This operator address has to be registered in the .
Only used in (where the address of the network must be set during the vault creation).
The network address has to be registered in the .
This data structure defines the settings of the contract tied to the Sym Byz Vault. It configures the slashing and veto rules (if enabled).
Allows to veto received slashing requests using
It is possible for the networks not to set a resolver, thus enabling an instant slashing mechanic similar to Instant Slasher.
All slashers have by default set to true
to trigger the onSlash()
function of the if slashing
Used only in slasher.
Defines a period after a slashing request creation for to veto the request
Used only in slasher.
This parameter defines a period that needs to pass after a network updates a for the resolver to be enabled for the network in the Slasher contract