Networks

Description

In Symbiotic, we define networks as any protocol that requires a decentralized infrastructure network to deliver a service in the crypto economy, e.g. enabling developers to launch decentralized applications by taking care of validating and ordering transactions, providing off-chain data to applications in the crypto economy, or providing users with guarantees about cross-network interactions, etc.

Decentralized infrastructure networks can utilize Symbiotic to flexibly source their security in the form of operators and economic backing. In some cases, protocols may consist of multiple sub-networks with different infrastructure roles. The Symbiotic protocol’s modular design allows developers of such protocols to define the rules of engagement that participants need to opt into for any of these sub-networks.

Technical Overview

In Symbiotic, networks are represented through a network address (either an EOA or a contract) and its middleware contract, which can incorporate custom logic and is required to include slashing logic. The core protocol’s fundamental functionalities encompass slashing operators and rewarding both stakers and operators.

Epoch

A network epoch (let’s name it $\text{NETWORK\_EPOCH}$) is a period while a certain operator set, obtained given the captured stake, operates for the good of the network. The epoch plus the vault’s veto and execute phases’ durations should not exceed the duration of the vault’s epoch to ensure that withdrawals do not impact the captured stake (however, the conditions can be softer in practice).

See Vault Accounting Details

See Vault Epoch Details

Staking

The vault allocates stakes by setting limits for networks and operators.

Let the Vault be $V$, the Delegator module of the vault is $D$ and the Slasher module is $S$.

See Stake Allocating Details

Given the current $\text{active}$ balance of the vault and the limits, we can capture the stake for the subsequent network epoch:

$networkOperatorStake = D.stake(network, operator)$

Sub-networks

Instead of creating multiple instances of a network, the Symbiotic protocol allows the creation of multiple sub-networks within the same network. This is similar to an operator having multiple keys instead of creating several instances of the operator. All limits, stakes, and slashing requests are handled by sub-networks, not the main network. This approach diversifies the network’s stake across different staking mechanics. For example, one sub-network can have high limits and a trusted resolver in the Slasher module, while another sub-network can have lower limits but no resolver in the Slasher module.

The final ID is just a concatenation of the network’s address and the provided identifier, so collision is not possible.

For simplicity, we sometimes omit the presence of sub-networks and just use the term network.

note

In case the network doesn’t need several subnetworks, it may always use an identifier equal to 0.

Limits

The limits are set in the vault, and the network cannot control this process (unless the vault is managed by the network). However, the implementation prevents the vault from removing the previously given slashing guarantees.

Moreover, the network can limit the maximum amount of stake it wants to use via the D.setMaxNetworkLimit() method.

See Limits Details

Staking Lifecycle:

1. The network registers by calling NetworkRegistry.registerNetwork()
2. Operators register by calling OperatorRegistry.registerOperator()
3. The operators must opt into the vault and the network
4. Stakers deposit funds into the vault
5. The network sets a maximum stake amount for the vault by calling D.setMaxNetworkLimit(identifier, amount)
6. The NETWORK_LIMIT_SET_ROLE holder defines the stake limit for the network
7. The OPERATOR_NETWORK_SHARES_SET_ROLE/OPERATOR_NETWORK_LIMIT_SET_ROLE holder defines the stake share/limit for the operators in the vault

The current stake amount cannot be decreased by withdrawals for at least one epoch, although this restriction does not apply to slashings by the neighbor networks (in case the vault uses restaking).

Operator Set

The network has the flexibility to configure the operator set within the middleware or network contract.

The following functions could be useful:

• D.stakeAt(subnetwork, operator, timestamp, hints) - returns an operator’s allocated stake at the given point of time, where:

  • subnetwork - an address of the network concatenated with the sub-network’s identifier

  • operator - an address of the operator

  • timestamp - a time point to fetch the allocated stake at

  • hints - encoded data helping a checkpointing system to reduce the number of storage reads to minimize gas usage

    note

    Only if the vault uses FullRestakeDelegator
    The sum of operators’ stakes may exceed the network’s total stake, depending on the network’s and operators’ limits.

• NetworkOptInService.isOptedInAt(operator, network, timestamp, hint) - checks an opt-in status of the operator to the network, where:

  • operator - an address of the operator

  • network - an address of the network

  • timestamp - a time point to fetch the opt-in status at

  • hint - encoded data helping a checkpointing system to reduce the number of storage reads to minimize gas usage

• VaultOptInService.isOptedInAt(operator, vault, timestamp, hint) - checks an opt-in status of the operator to the vault

Slashing

See Slashing Details

For each operator, the network can obtain its stake which will be valid during $d = vaultEpoch$. It can slash the whole stake of the operator. Note that the stake itself is given according to the limits and other conditions.

Note that the actual slashed amount may be less than the requested one. This is influenced by the cross-slashings (slashings by the neighbor networks).

The network can slash the operator within the vault only if

1. The operator is opted into the vault
2. The operator is opted into the network

To initiate a slashing process, a network should call:

1. slash(subnetwork, operator, amount, captureTimestamp, hints) for the Slasher module, where:

   • subnetwork - an address of the network concatenated with the sub-network’s identifier

   • operator - an address of the operator

   • amount - an amount of the collateral to slash

   • captureTimestamp - a time point whose stake data was used for a validator set creation

   • hints - encoded data helping a checkpointing system to reduce the number of storage reads to minimize gas usage

2. requestSlash(subnetwork, operator, amount, captureTimestamp, hints) for the VetoSlasher module.

The module will check the provided guarantees at the $captureTimestamp$, denoted as $G$. It also calculates cumulative slashings from the $captureTimestamp$ to the current moment, denoted as $C$. It is guaranteed that for every correct $captureTimestamp$, $C \leq G$. The module will allow slashing no more than $G - C$ to justify the given guarantees.

Rewards

In Symbiotic, rewards are categorized into:

• Operator rewards
• Staker rewards

Operator Rewards

The network distributes the operator rewards at its discretion. Here are three examples:

1. The network performs off-chain calculations to determine the reward distributions. After calculating the rewards, the network executes batch transfers to distribute the rewards in a consolidated manner.
2. The network performs off-chain calculations to determine rewards and generates a Merkle tree, allowing operators to claim their rewards.
3. The network performs on-chain reward calculations within its middleware to determine the distribution of rewards.

Source of Data for Network On-Chain Reward Calculations:

For each epoch, networks obtain their staking information through our system. Additionally, all operators register through the network, providing necessary details such as commission rates, fixed payments, and other relevant conditions. This registration process ensures that networks have the required data to perform accurate on-chain reward calculations in their middleware.

Staker Rewards

See Staker Rewards Details