Rewards

Rewards are payments that Networks make to stakers and operators in exchange for security and work.

• Stakers provide collateral that backs operator behavior and is at risk of slashing.
• Operators run the infrastructure or strategies that the Network depends on: validators, relay/bridge nodes, risk engines, or DeFi execution logic.

Rewards compensate:

• stakers, for locking capital into a vault and accepting slashing risk, and
• operators, for running infrastructure and meeting performance and liveness requirements.

Rewards may come from protocol fees, scheduled token emissions, external client payments, or amounts routed from slashing (via Burner policy). Symbiotic does not dictate the economics; it only provides the plumbing so Networks can express their own reward logic and deliver it efficiently to stakers and operators.

Vaults themselves do not define rewards. They only hold collateral and enforce delegation and slashing. Rewards are defined and paid by Networks, and claimed through the Rewards V2 system.

Rewards V2 architecture

Rewards V2 is Symbiotic’s standard mechanism for computing and distributing rewards across chains. It introduces a small set of on-chain contracts and an off-chain distribution script that together produce a Merkle-committed “cumulative distribution” from which all participants can claim.

On-chain contracts

Rewards V2 deploys three singleton contracts per chain that has Symbiotic Core:

The main contract for distributions and claiming. It stores cumulative reward distributions as Merkle roots and exposes claim functions for stakers, operators, and curators. Networks (or their designated rewarder address) commit new distributions to this contract.

A registry that stores fee settings for operators and curators. Operators and curators configure their fees once (for example via the Symbiotic CLI). When a Network constructs a distribution, it reads this registry to apply fee splits correctly.

A registry mapping each vault to its curator (the fee receiver). This ensures curator fees are routed to the correct address without per-network bespoke logic.

These contracts are shared by all Networks on that chain.

Off-chain distribution model

Rewards V2 assumes an off-chain distribution script that reads Symbiotic state, computes who should be paid and how much, and then commits the result to the Rewards contract.

At a high level, that script is built from a set of modules:

• OperatorsVaultsProvider returns, for each subnetwork, the relevant operators, their vaults, and the distribution shares for each operator–vault pair (typically based on stake or Symbiotic Relay voting power).
• FeesProvider takes those operators and vaults and returns the associated curators and the fee configuration for operators and curators (read from FeeRegistry and CuratorRegistry).
• StakersProvider takes vault addresses and returns the stakers in each vault and their shares, based on vault balances at the chosen distribution timestamp.
• Storage stores and retrieves cumulative distributions in a data-availability layer. By default this is Symbiotic’s backend.
• Committer writes the new cumulative distribution to Storage and then commits its Merkle root and metadata on chain via the Rewards contract, potentially on multiple chains.

Symbiotic provides default implementations of all these modules, plus:

• a Go package (rewards_constructor) that takes the module outputs and constructs a new cumulative distribution, and
• a default Distribution Script that ties everything together.

Networks can adopt the defaults as-is, or replace individual modules when they need custom behavior.

Execution of the Distribution Script is up to the Network. It can run as a cron job, a validator-run daemon that reacts to epoch changes, or a manually triggered tool.

What Rewards V2 provides

From the perspective of each participant:

Networks

Networks use Rewards V2 to turn their economic logic into on-chain payouts without custom infrastructure.

• They define what rewards pay for (for example, stake value, relay voting power, tasks completed) and plug that logic into the OperatorsVaultsProvider or a custom module.
• They use the default Distribution Script and rewards_constructor to generate a new cumulative distribution for each period (for example, each network epoch or at another cadence).
• They use a single on-chain call to Rewards to commit a Merkle root representing the updated cumulative distribution, and can do this on multiple chains at once.

This reduces gas costs (one on-chain commitment per distribution instead of many small transfers), reduces integration work, and allows the same distribution logic to be reused across chains.

Stakers

Stakers receive rewards for providing collateral and taking slashing risk through vaults.

In Rewards V2:

• the staker portion of rewards is computed based on their vault shares at the distribution timestamp
• a single claim against the Rewards contract can aggregate multiple distributions and multiple vaults, reducing gas per claim
• stakers use the Symbiotic UI or CLI to view and claim rewards, rather than interacting with a different rewards contract per Network

The underlying Merkle structure is abstracted away; stakers only need to know that their claims are validated against the latest committed root.

Operators

Operators receive rewards for running infrastructure or strategies for the Network.

With Rewards V2:

• operator fee parameters are stored centrally in FeeRegistry, set once via CLI or direct contract interaction
• the distribution script reads these settings and allocates operator fees as part of the cumulative distribution
• operators claim their rewards from the same Rewards contract using the Symbiotic CLI, instead of managing per-network custom flows

This shortens the path from “Network decides to pay operators” to “operator can claim” and standardizes the way fees are expressed.

Curators

Curators receive a fee in return for designing and managing vault policies.

Rewards V2:

• uses CuratorRegistry to map each vault to a curator address
• uses FeeRegistry to encode curator fee settings
• includes curator shares in the cumulative distribution built by the Distribution Script

Curators configure their fee levels once, and then receive rewards whenever Networks use the vaults they manage and include curator fees in their distribution logic.

Key concepts and terminology

To read or write distribution code, a few terms matter:

• Distribution timestamp is the time at which on-chain data is read. All balances, voting powers, and fee settings used in a distribution are evaluated at this point.
• Cumulative distribution is the running total of all distributions for a Network. Each new distribution updates the cumulative state; claims compare what has already been claimed against this cumulative total.
• Distribution script is the off-chain program that runs all providers (operators/vaults, fees, stakers), constructs the new cumulative distribution with rewards_constructor, writes the data to Storage, and calls the Committer to commit the Merkle root to the Rewards contract.

Symbiotic provides the contracts, modules, tooling, backend, and UI so that Networks can focus on what to reward (their economics and incentives), while Rewards V2 standardizes how those rewards are delivered and claimed.