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 ) 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).
Staking
The vault allocates stakes by setting limits for networks and operators.
Let the Vault be , the Delegator module of the vault is and the Slasher module is .
Given the current balance of the vault and the limits, we can capture the stake for the subsequent network epoch:
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.
Staking Lifecycle:
- The network registers by calling
NetworkRegistry.registerNetwork()
. - Operators register by calling
OperatorRegistry.registerOperator()
. - The operators must opt into the vault and the network.
- Stakers deposit funds into the vault.
- The network sets a maximum stake amount for the vault by calling
D.setMaxNetworkLimit(identifier, amount)
. - The
NETWORK_LIMIT_SET_ROLE
holder defines the stake limit for the network. - 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 the operator set within the middleware or network contract.
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
For each operator, the network can obtain its stake which will be valid during . 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-slashing or veto process of the Slasher module.
The network can slash the operator within the vault only if
- The operator is opted into the vault
- The operator is opted into the network
To initiate a slashing process, a network should call:
slash(subnetwork, operator, amount, captureTimestamp, hints)
for the Slasher module.requestSlash(subnetwork, operator, amount, captureTimestamp, hints)
for the VetoSlasher module.
The module will check the provided guarantees at the , denoted as . It also calculates cumulative slashings from the to the current moment, denoted as . It is guaranteed that for every correct , . The module will allow slashing no more than 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:
- 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.
- The network performs off-chain calculations to determine rewards and generates a Merkle tree, allowing operators to claim their rewards.
- 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.