Node payment, rewards and risk

Here you can read about paid services nodes can perform as well as rewards, and risks of disputes.

How different node services earn fees and rewards

Node operators get paid fees for running four types of services:

• Baker services - signing and producing blocks. Baker fees depend on performance measured by peers
• ZK services - preprocessing data, executing ZK computations. See the fees paid for different ZK operations
• Oracle services - services related to BYOC, signing transfers. Deposit and withdrawal oracle nodes receive 0.1% of transferred value
• Price oracle nodes get a steady fee per signed price. The fee is 50K gas divided equally between the price signatories

A node operator earns fees when a user commits a transaction on the blockchain and pays a gas cost in BYOC. The gas spent covers the fee of the service performed by the nodes, this designs ensures that node operators get paid in BYOC tokens.

In addition to the fees paid for services, node operators and delegated stakers receive rewards in the form of MPC tokens from staking. Rewards are distributed according to the amount of tokens staked and node performance. See how rewards are calculated and distributed

How are baker fees calculated

Baker service fees depend on both the performance of the individual node and the level of activity on-chain, meaning the number and size of transactions committed in each epoch. It is important for the node operator to keep up to date to keep earning fees.

Fees for baker service are paid out by the Fee distribution contract. In the state of the contract you can see a collapsed map placed to the right of the field called epochs:

1. Click the map right of epochs
2. Unfold the successive maps and structs until you reach metrics

The map called metrics holds node operator addresses. Next to the address of each node in the network you find a list called signatureFrequencies. The signatureFrequencies tells you how many signatures on blocks the node has seen so far from each of the other nodes in the network in the current epoch. When every node has produced 100 blocks, the epoch is over and earned fees are distributed equally among the nodes receiving a vote from 2/3s of the nodes. A peer node will count how often your node's signature has appeared on a block it has seen. It creates a sorted list of the performers and casts a vote for each node in the top 2/3s.
Everyone that has received a vote from 2/3s of the committee gets paid an equal share of the fees of the epoch. If there are 100 nodes in the current committee then your node needs a vote from 66 other nodes each epoch to get paid.

How staking of MPC tokens work

Staked MPC tokens are used as collateral for a node performing a paid service. Collateral is the stake of a node, which will be used to pay compensation for misconduct committed with the node. For all services on PBC there is a basic safety principle: \(ValueOfStake \gt ValueOfService\). The safety principle can be showcased through the application of it in the oracle service and the ZK service, explained below:

Three oracle nodes performing oracle service together constitutes one small oracle. A small oracle can transfer less value than the total stake on the service (750K MPC). The theoretical maximum value of BYOC being bridged per epoch is equivalent to the ETH value of the total stake (collateral) of the three oracle nodes. In current practice the value that can be transferred is 50 ETH for withdrawal oracles and 25 ETH for deposit oracles.

Four ZK nodes performing ZK service together have an equal share in the total stake on the service, just like oracle nodes. A ZK node stakes 1/4 of the amount defined in the ZK contract to which they are allocated. The contract owner defines the total required stake to participate in the ZK job.

When tokens are allocated to a node service, the tokens are always locked to the system contract administrating the service for one epoch. See how the length of an epoch is determined here.

A node operator can resign from a service, and retrieve the tokens staked on the service. A delay of release ensures sufficient time for the service to complete and for the possibility of dispute claims. For this reason there are pending times for MPC tokens to change state from being associated , locked or staked. Changing state from staked to unstaked always takes 7 days plus the pending time for disassociation or unlocking.

How long does it take to retrieve stakes from a node service

MPC tokens need to be unstaked and free from vesting schedule to be transferable. You can always calculate how many MPC tokens you can transfer with the formula: \(MPC_{transferable} = MPC_{released} - MPC_{staked}\)

When a node operator wants to retrieve his stake from a node service, he disassociates and unstakes the tokens currently associated to the contract administrating the node service. The node operator should be aware of the total pending time for removing tokens from a node service. The total pending time is the sum of pending time of the two actions: disassociate and unstake. The table below explains the pending time for retrieving tokens from the contracts governing the different node services.

For in depth explanation of all states of MPC tokens in the accounts see MPC Token Model.

Retrieving stakes that are delegated

If a node is using delegated stakes, the delegator has to reach out to the node operator using the tokens to ask for release, if they wish to retrieve them. Same locking mechanisms and pending times apply to tokens that come from delegated stakes. Delegated MPC tokens, that are not associated to a contract or locked to a service, can be retrieved without any pending period.

Rules:

• If delegated to an account of a node operator, but not associated to a contract, token owner can retrieve with no issues
• If delegated to an account of a node operator, and associated to a contract but not being used for a job, token owner cannot retrieve before the node operator has disassociated the token from the job
• If delegated to the account of a node operator, associated to a contract and being used for a job, token owner cannot retrieve until the job completes, pending period is over, and the node operator has disassociated the tokens from the job
• Tokens retrieved from delegation are not immediately transferable. The token owner must unstake the tokens after retrieval. If the tokens have passed the release date the tokens will become transferable, when the 7-day pending period is over and the owner invokes Check pending unstakes
• Tokens must be retrieved to your account before you can unstake. This means you change the state of the tokens back from staked to unstaked. Unstaking causes a 7-day pending state for the tokens. Afterwards you need to invoke Check pending unstakes. This operation returns the tokens to your balance

Rewards for staked tokens

Every quarter rewards are given to delegated stakers and node operators based on the amount of tokens staked and node performance.

When you delegate tokens to a node operator you get rewards when a node operator associates your delegated tokens to a node service.

When each quarter ends the node operators decentrally calculate the amount of rewards to pay out and vote on-chain to pay out the rewards. See Voting for QuarterlyRewards

You can consult the calculation method for rewards, and the history of quarterly payouts here.

Dispute claims and malicious behavior

Malicious node behavior can result in slashing of staked tokens (slashed tokens get burned). The purpose of slashing is to prevent malicious activity.

It is possible to start a dispute against a node operator that has done a service for you. Dispute claims are audited by the large oracle. If the node operator is found responsible for the node's alleged malicious behavior tokens staked on the service may be slashed. Filing an illegitimate dispute claim against another node can also be considered malicious behavior and result in slashing.