The process of creating new blocks is called harvesting.

In this process, the account that harvests a block is called the harvester and is rewarded with any transaction fees produced and any inflation tokens generated.

Each produced block stores in its header the public key of the harvester account and the block’s signature that it created.


Eligibility criteria

The importance score determines the probability that an account is chosen to harvest the next block among all the accounts which have harvesting enabled.

Symbol’s public network defines that an account needs to hold at least 10,000 harvesting mosaics to have an importance score greater than zero. Eligible accounts can use their importance score to create new blocks either by running a node or enabling delegated harvesting.

Regardless of the method chosen, any account willing to activate harvesting must first announce a valid VrfKeyLinkTransaction. This key is required by Symbol to randomize harvester selection.


Harvesting mosaic

The Symbol platform supports defining any mosaic for harvesting purposes to fit different business needs.

For example, consortium networks can distribute harvesting mosaics between the companies that are running the infrastructure, while other participants need to pay fees in the form of currency mosaic to consume services.

By contrast, public networks might use the same mosaic for paying transaction fees and running the network. Symbol’s public network uses symbol.xym as the harvesting mosaic, enabling any eligible participant to harvest new blocks.



Network operators can define a network fee sink account that will receive a percentage of the harvesting rewards (block fees and inflation). In the case of the public main network, this fee is set to 5% and is used to support the different Reward Programs.

Additionally, each node can set a beneficiary account to share a percentage (up to 25%) of the harvesting rewards. The node operators can use this feature to create incentive structures for their node supporters.

The sharing ratios for the beneficiary and network sink accounts are configurable per network.


Rewards division when the network’s sharing ratio for network sink is 20% and for beneficiary is 10%.


The calculation of the beneficiary percentage will occur after the network sink calculation. When the node operator does not define a beneficiary or a Network Fee Sink, all the rewards go to the block signer.


Harvesting types

There are different kinds of harvesting available, depending on whether or not the harvester account owns the node and the amount of desired security: Local, Remote and Delegated.


Local harvesting

This is the simplest to set up, and the most insecure method. It requires changing a node’s configuration, so it is only available to node owners. It is enabled by filling-in the appropriate harvesting properties in the node configuration file.

As it can be seen, the harvester account’s private key is stored in the harvesterSigningPrivateKey property, since it is needed to sign off created blocks. This is a security concern since this account contains funds and the configuration file might be accessed by uninvited actors if the node is compromised. Funded accounts’ private keys should always be stored offline.

Therefore, this method is strongly discouraged. Remote or delegated harvesting are recommended instead.


Remote harvesting

Node owners can use a remote account to act as proxy and sign off the newly created blocks, while harvesting fees are still collected by their main account. The remote account has no funds, so the fact that its private key is exposed in a configuration file on the node is not a concern. The importance score is still based on the main account.

In this setup the main account is still called the Harvester, for simplicity, whereas the remote account is called a Proxy.

Remote harvesting is enabled just like local harvesting but using the remote account’s private key in the harvesterSigningPrivateKey property and announcing an AccountKeyLinkTransaction that links the remote and main accounts.

This is the recommended method for node owners. See the Harvesting guides for step-by-step instructions on how to activate remote harvesting.


Delegated harvesting

Eligible accounts not owning a node can still benefit from harvesting by requesting a node to harvest for them. The account’s importance score is used and any collected fees are divided among the account and the node’s beneficiary (as explained in the Rewards section). It is a advantageous agreement to both the account and the node.

It is then said that the account delegates harvesting to the node, but the account is still considered the harvester.

Delegated harvesting is enabled similarly to remote harvesting but, since the account has no access to the node’s configuration, it announces a PersistentDelegationRequest transaction instead. Upon receiving the request, the node may or may not grant it, depending on its configuration and the rest of requests received.

As with remote harvesting a proxy remote account is used so the main account’s private key is never put at risk.

See the Harvesting guides for step-by-step instructions on how to activate delegated harvesting and check if the delegation request has been granted.


Persistent Delegation Request Transaction

This is actually a TransferTransaction sent to the node owner’s account with a special 132-byte message, formatted as a 264-characters hexadecimal string:


Hex digits




Header: FE2A8061577301E2



Ephemeral keypair public key.

Below is encoded with the ephemeral key:



AES GCM tag.



AES GCM initialization vector.








Continue: Inflation.

Last updated by Xavi Artigas on 2021-10-07.

Did you find what you were looking for? Give us your feedback.