Harvesting⚓︎

Harvesting: The process by which Symbol adds new blocks to the chain and distributes rewards to participating accounts. It plays a similar role to mining in PoW or staking in PoS.

Harvesting nodes are associated with a harvester account which signs the blocks they produce.

Each new block is harvested by a single, randomly selected node. The fees from the included transactions, along with a portion of inflation, are distributed to the node's delegators and to other accounts designated by the node operator, which may or may not include the harvester account itself.

Unlike mining in PoW, harvesting does not require specialized hardware. Participation is open to any account holding at least 10,000 XYM and connected to a node, either directly or through delegation. This balance contributes to the account's importance score, which determines how often it can harvest a block.

Harvesting Process⚓︎

Symbol does not use an explicit selection process to determine which node will harvest the next block. Instead, every node independently attempts to produce a new block.

To do this, each node calculates its own target value, based primarily on the node's importance. The higher the node's importance, the higher its target will be.

The node then assembles a candidate block by collecting transactions from the unconfirmed pool and assigning the harvesting rewards to the selected harvester and the configured beneficiary. Once the block is assembled, the node hashes it and generates a random number called the hit.

If the hit is lower than the target, the node considers the block valid and announces it to the rest of the network. Other nodes then verify the block, ensuring:

The transactions are valid.
The target and hit values were correctly calculated.
The hit is indeed lower than the target.

If any of these checks fail, the block is ignored. The announcing node will remain on an isolated fork until it adopts the valid blocks produced by the network.

If the block is valid, it is accepted by other nodes and becomes the next block in the chain. This process is repeated at the next block height.

Simultaneous Block Creation

No special care is taken to prevent multiple nodes from generating blocks at the same time. When this happens, the network may split temporarily as different nodes adopt different blocks for the same height.

These forks are resolved naturally using the usual fork resolution mechanisms: nodes compare the chain score of competing chains and adopt the one with the highest score, allowing the network to re-converge.

Target and Hit Calculation

The target is calculated independently by each node and reflects its likelihood of harvesting the next block. It depends on three factors:
- The node's importance score: more active or better-funded nodes will harvest more often.
- The network-wide difficulty, which adjusts dynamically based on recent block production times, to maintain a constant rate.
- The time elapsed since the last block: longer delays increase the chance of a new block being produced.
The hit is a random number derived from the new block's content and the node's VRF key, making it unpredictable.

Without the VRF key, an attacker could predict which node is next in line and attempt to censor it, for example, by launching a DoS attack.

For the block to be valid, the node's target must be greater than its hit. A higher importance or a longer delay increases the target, making the condition easier to satisfy.

Block Score: A numerical value assigned to each block that reflects how hard it was to harvest. Lower scores indicate higher difficulty and are therefore preferred in fork resolution.

\[ \textit{block score} = difficulty − \textit{time elapsed since last block} \]

Chain Score: Sum of the block scores of all blocks produced in a given period of time.

Harvesting Methods⚓︎

Node owners can participate in harvesting by enabling local or remote harvesting, depending on their preferred balance between simplicity and security. Accounts that do not operate a node but meet the balance requirements can still harvest by linking to a node through delegated harvesting, sharing in its rewards.

Local Harvesting⚓︎

Local Harvesting: A type of harvesting where the rewards are sent directly to the harvester account. The node signs produced blocks using the operator's main key, which must be stored on the machine.

Warning

The harvester account must hold a significant balance to maintain a high importance score. Storing its private key on a machine that is permanently online puts the entire balance at risk in case of unauthorized access.

While local harvesting offers a straightforward setup, these security risks make it unsuitable for public nodes. Most operators instead prefer remote harvesting.

Remote Harvesting⚓︎

Remote Harvesting: A type of harvesting that delegates block signing to a separate proxy account, while the node's importance score and rewards remain tied to the operator's main key.

The proxy account holds no funds and exists only to sign blocks on behalf of the main account. Because its private key is stored in the node's configuration files, it is designed to be expendable.

The main account still determines the node's importance and receives all block rewards. However, its key remains offline, safe from compromise. For simplicity, the main account is still called the harvester account, even though blocks are signed by the proxy.

This separation of duties offers strong protection for the harvester's funds and makes remote harvesting the preferred option for most operators.

Delegated Harvesting⚓︎

Delegated Harvesting: A form of harvesting that allows eligible accounts not operating a node to delegate harvesting duties to a third-party node. The account's importance score is used, and any harvested fees are shared between the account and the node's configured beneficiary.

Such an account is called a delegator, or delegated harvester, even though the actual block signing is done by the node's proxy account.

Delegator: An account that delegates harvesting to a third-party node while retaining its importance and receiving a share of the harvested rewards. Also called a delegated harvester.

Although the node performs the work, the delegator is still considered the harvester. This arrangement benefits both parties: the account earns rewards without running a node, and the node increases its block production (and collected fees) without relying solely on its own importance.

Delegated harvesting uses the same proxy-based setup as remote harvesting. The delegator signs a transfer transaction with an encrypted message that requests the node to harvest on its behalf.

Whether the node grants the request depends on its policy and any competing requests it may have received.

As with remote harvesting, block signing is performed by an account other than the delegator, so its private key never needs to leave secure storage.

Reward Distribution⚓︎

When a block is harvested, rewards are distributed among several participants. These rewards consist of:

The fees paid by the transactions included in the block.
An additional amount of inflation.

The total reward is divided among the following parties:

The network sink account:

A system account that receives a fixed 5% of the reward. This amount can be used to fund network-wide reward programs.
The node-designated beneficiary:

An optional account that receives a fixed percentage of the reward (after subtracting the network sink amount). The node owner choses both the account and the percentage (up to 25%).

Node owners may retain this portion for themselves or redistribute it through their own reward programs, for example, by sharing it with their delegators.
The selected harvester:

The account that was selected to harvest the block, based on its importance. It can be the node's remote harvesting account, or any of its delegators.

Example

For example, assuming 100 XYM of block rewards (fees + inflation) and a beneficiary percentage of 20%:

Recipient	Calculation	Amount
Network sink account	5% of 100 XYM	5 XYM
Beneficiary account	20% of remaining 95 XYM	19 XYM
Harvester account	Remaining 76 XYM	76 XYM
Total		100 XYM

Importance⚓︎

Importance: A measure of an account's contribution to the network, based on its balance, the transaction fees it has paid, and its participation in harvesting new blocks. This score determines harvesting eligibility and vote weight in consensus.

Importance serves a role similar to hashrate in PoW systems or stake in PoS systems: the higher the value, the greater the chance to harvest a block and earn rewards.

Importance Calculation

All accounts that have a balance of at least 10'000 XYM are called high value accounts and participate in the importance calculation.

The importance score \(I_A\) for a high value account \(A\) is based on its stake score, its transaction score, and its node score.

The stake score \(S_A\) is the percentage of currency it owns relative to the total currency owned by all high value accounts.
The transaction score \(T_A\) is the percentage of fees paid by the account relative to the total amount of fees paid by all high value accounts.
The node score \(N_A\) is the percentage of times it has been specified as a harvesting beneficiary relative to the total number of high value account beneficiaries in the same period.

The details about how these scores are combined to produce the importance score can be found in the Symbol whitepaper, section 14.1.