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 a 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

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)$

Subnetworks

Instead of creating multiple instances of a network, the Symbiotic protocol allows the creation of multiple subnetworks 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 subnetworks, not the main network. This approach diversifies the network’s stake across different staking mechanics. For example, one subnetwork can have high limits and a trusted resolver in the Slasher module, while another subnetwork 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 subnetworks and just use the term network.

Network Middleware

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_LIMIT_SET_ROLE holder defines the stake limit for the operator-network pair.

The current stake amount cannot be withdrawn for at least one epoch, although this restriction does not apply to cross-slashing.

Operator Set

The network has the flexibility to configure an operator set within the middleware contract later to be used as a validator set (a.k.a. valset) for its validating.

Off-chain view of stake captures

The following functions could be useful:

• D.stakeAt(subnetwork, operator, timestamp, hints): Determines minimum stake eligibility. Note that the sum of operators’ stakes may exceed the network’s total stake, depending on the network’s and operators’ limits in the delegator module.
• OptInService.isOptedInAt(operator, subnetwork, timestamp, hint): Checks the opt-in status.

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.

1. This may be influenced by the cross-slashing.

External slashing risks

2. This may be influenced by slashings by the network itself, as the consequent valsets may depend on the stake used for the creation of the previous valsets.

Internal slashing across multiple stake captures

3. In the case of a task-like system, where each task is backed by the corresponding operator’s stake, this may be influenced by slashings by the network itself if the operators have a pooled stake.

Task-like system stake captures

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.
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