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.

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

The middleware contracts integrate with Symbiotic Core for stake capture, validator set management, slashing, and optional rewards accounting inside the middleware. Optional here means that rewards logic can live in the middleware, while the existence, funding, and source of rewards are always defined by the Network.

The network also has its own operator set, which provides services to the network. The network’s software produces work, emits messages to be attested, and participates in epochs. Here the network admin defines voting power rules and thresholds, message formats, participation and liveness requirements, dispute inputs, and Relay compatibility if it wants cross chain verification.

Epoch

A network epoch (let’s name it NETWORK_EPOCHNETWORK_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

A valid operator set means the validator set captured for the current network epoch is the reference set used for verification and slashing during that epoch. While it remains valid, on chain checks verify signatures against that set and its associated weights, and any slashing decisions are made with respect to those same weights.

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

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:

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, later to be used as a validator set (a.k.a. valset) for its validating.

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=vaultEpochd$. Through its middleware, the Network initiates slashing when provable misbehavior occurs according to Network‑defined rules. Slashing protects stakers from dishonest or idle operators and protects Networks from operators taking stake without performing required work. Symbiotic Core enforces objective bounds so only stake guaranteed at capture can be burned.

A slashing request must reference a capture timestamp that is no more than one vault epoch old, not exactly equal to the epoch boundary. Requests can arrive at any time within this sliding window. Requiring equality would cause legitimate slashes to fail around boundaries.

Note that the actual slashed amount may be less than the requested one.

1. This may be influenced by cross-slashing.

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

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

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≤G$. The module will allow slashing no more than $G−C$ to justify the given guarantees.

Operating Lifecycle

A network can use flexible mechanics to keep its operator set state up-to-date, e.g., it’s convenient to use a conveyor approach for updating the stakes while keeping slashing guarantees for every particular version of the operator set:

1. At the beginning of every epoch the network can capture the state from vaults and their stake amount (this doesn’t require any on-chain interactions).
2. After this, the network will have slashing guarantees for one vault epoch duration, so it can use this state at most for one vault epoch.
3. When the epoch finishes and a slashing incident has taken place, the network will have time equal to the vault epoch duration minus the network epoch to request-veto-execute slash and go back to step 1 in parallel.

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

Relay SDK Integration

All of this can be cumbersome to scope, implement, and maintain from scratch. That is why Symbiotic provides the Relay SDK, a set of contracts and off chain components that let networks capture stake through Symbiotic, track operator sets and voting power, aggregate signatures, and plug into slashing without rebuilding their own verification layer.

Using the Relay SDK, a network can verify the same work across multiple EVM chains, aggregate operator signatures off chain and verify them once on chain, and significantly reduce verification costs while keeping its existing governance, message formats, and slashing rules unchanged.