Masternode owners are helping secure HashNET network by enforcing the following:
- Validating that all transactions have correct signatures for outputs being spent
- Transactions must be in correct data format
- Prevent double spending
- Outputs being spent are valid


If any event gossiped through HashNET contains transaction that violates some of the rules, then it will be rejected. In addition to securing the network, masternodes also provide some special functions:
- Participating in governance and voting
- Enable budgeting and treasury system of Tolar

Masternode is comprised of:
- A masternode operator (owner)
- Collateral held in Tolars that serves as guarantee to ensure masternode doesn’t act maliciously
- Server used as a part of decentralized infrastructure of HashNET


Since masternodes are critical for processing transactions and helping secure the network, there is need to ensure that masternodes won’t act maliciously. That’s why operators need to put in collateral in TOL which is then locked while masternode is active.

In case of constant malicious behaviour of masternode (trying to vote-in invalid transactions, DoS attacks on rest of the network, constant invalid data), collateral will be frozen, and masternode kicked off the network.

Required collateral for Tolar masternode is 500,000 TOL.

Masternode Server

Server in this case is computer or computing-cluster connected to a network which provides masternode services mentioned above.

Minimum requirements for server are:
• quad core 64bit processor
• 16 GB RAM
• 128 GB of available disk space
• 50 Mbps symetrical internet connection
• Fixed and unique IP (only one masternode can run at one IP address)

While these are minimum requirements, it’s recommended to have masternode on a better configuration, especially in higher network load scenarios. In case that your masternode starts lagging behind because of insufficient processing power or bandwidth, it will not receive masternode rewards for those rounds.

Masternode rewards

Since masternode operators are spending their resources to help secure the network, they will be incentivized to keep the masternodes running by getting masternode rewards.

Rewards will be comprised of:
• transaction fees of all transactions that masternode helped validate correctly and on time
• masternode incentives from Tolar monetary reserve fund

Since rewards depend on the transaction fees, it’s clear that rewards will fluctuate depending on the network usage. The more people use the network and make more transactions, masternode owners will receive more rewards. To insure best possible start of the network, for the first 3 years, if masternode rewards from transactions fee fall below 10% then part of rewards will be taken from Tolar reserve fund to insure a minimum of 10% ROI.

Example scenarios:

Scenario 1: Network constantly running at 0.1% capacity on average Around half of TOL supply in masternodes (around 1000 masternodes)
Generates: (200 transactions/sec * 0.01 TOL (fee) * 31,536,000 sec (1 year)) / 1000 masternodes =
63,072 TOL / masternode 63,072 TOL / 500,000 TOL = 12,6 % In this case, masternode owners makes 12,6% ROI yearly
Scenario 2: Network just starting, running below 0.005% capacity on average Only small part of TOL supply in masternodes (around 200 masternodes)

Generates: (10 transactions/sec * 0.01 TOL (fee) * 31,536,000 sec (1 year)) / 200 masternodes =
15,768 TOL / masternode In this case, part of rewards be taken from Tolar reserve fund (up to 1% of supply per year reserved for masternode rewards);

7,000,000 TOL / 200 masternodes =
35,000 TOL / masternode Total: 50,768 TOL / masternode 50,768 TOL / 500,000 TOL = 10,15 % Scenario 3: Network getting a lot of usage and traction (running at 0.2 % capacity on average)

Any node can submit a tender from one
of the following categories:

Social impact
Decentralisation and governance

After tenders are submitted, masternode owners then vote on each proposal, and accept or refuse it. This makes the masternode owner help the network in decision making process, as well as the technical validation.