Skip to main content

Rewards

Description​

Symbiotic can be considered an exchange hub between basically 3 parties: stakers, operators, and networks.

  • The stakers provide capital for the operators to use in favor of the networks
  • The operators provide maintenance of the networks’ liveness in a valid manner
  • The networks receive a security for their products depending on the economic side provided by the stakers and on the functioning side provided by the operators

Based on these exchange statements, it can be seen that the stakers and the operators provide services to the networks. Therefore, the networks are responsible for giving them something in exchange, and these are rewards.

rewards

Technical overview​

Symbiotic core contracts don’t contain the rewards logic enshrined. However, they provide enough data for external contracts to be able to create a rewards distribution, so anyone can create their own implementation of it.

info

The connection of the vault to the rewards contracts and the collection of the supported rewards implementations happens off-chain using on-chain data and GitHub pull requests (we’ll provide details later).

From our view, the rewards can be divided into staker and operator rewards.

  • The staker rewards can be provided depending purely on the provided stake’s value (the representation of value can differ from the standard $ view depending on alignment / token distribution / other factors)
  • The operator rewards can be provided depending on the economic factors similar to the above ones and on the operators’ performance metrics (e.g., number of tasks completed / liveness / validators’ distribution)

tech-rewards

Staker rewards​

Since the rewards contracts are not a part of the core contracts, we allow users to provide their own implementations. However, in the case of staker rewards, we assume that the contracts should support IStakerRewards interface for networks and stakers to get better UX for distribution and claims.

Default Staker Rewards​

We provide a default implementation of the IStakerRewards interface, which is represented by a simple pro-rata rewards distribution concerning the collateral amounts provided by stakers at the capture time point and providing an ability to the Vault curator to receive fees:

info

An unlimited number of networks can use one DefaultStakerRewards contract in favor of one specific vault’s stakers.

Code can be found here (DefaultStakerRewards)

A factory address for deployment can be found here (DefaultStakerRewardsFactory)

Operator Rewards​

Since the rewards contracts are not a part of the core contracts, we allow users to provide their own implementations. Here are three example implementations:

  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.

Default Operator Rewards​

We provide a default implementation of the operator rewards, which is represented by a simple Merkle tree rewards distribution, where each leaf represents a recipient (an operator’s treasury address) and the total amount of tokens earned for the whole period:

info

An unlimited number of networks can use one DefaultOperatorRewards contract in favor of an unlimited number of operators.

Code can be found here (DefaultOperatorRewards)

  • Network:

    1. Calculates a Merkle root for the rewards distribution (we’ve implemented a CLI for that purpose)
    2. Distributes the rewards via distributeRewards()

  • Operator:

    1. Claims the rewards via claimRewards() by the usage of a Merkle proof (it can be got with the help of CLI)

A factory address for deployment can be found here (DefaultOperatorRewardsFactory)