How to calculate masternode rewards

masternode rewards calculator

So you’ve heard that running a masternode or service node for a blockchain project can earn you cryptocurrency rewards — enticing, right? But have you factored in the costs? Is it worth the time and effort? This article will help you figure that out by showing you how to calculate your potential masternode rewards.

Masternode rewards formula

You can estimate your net masternode rewards using the following equation:

Masternode rewards formula: Net Rewards = (Gross Rewards - Costs)/Initial Cost

  • Gross Rewards are the total cryptocurrency rewards you receive for running a masternode or service node over a particular period of time.
  • Costs are the total costs you incur for running a masternode or service node over a particular period of time.
  • Initial Cost is the cost of your initial upfront contribution, which for masternodes or service nodes will be the amount of cryptocurrency you stake.
  • Net Rewards is the net change from your initial cost, expressed as a percentage.

How to work out your potential masternode rewards

While it’s easy to work out the rewards you’ve received in the past, predicting the rewards you could receive in the future is a bit more complicated.

Masternode and service node rewards vary in terms of amount and frequency. To accurately calculate future rewards, you’ll need to know the block time, the number of masternodes (or service nodes) on the network, and the emission curve.

Block time

A masternode (or service node) receives a reward every time a new block is generated. The time it takes for a block to be generated on a particular blockchain can be found within the project’s whitepaper or cryptoeconomic paper.

For example, Loki’s block generation time is 120 seconds, which means that every 120 seconds a block will be generated, and a masternode or service node will receive a reward.

Number of masternodes or service nodes on the network

For every block that’s generated, only one masternode or service node gets a reward. The order in which masternodes earn rewards varies from project to project. However, in order to estimate your future rewards, you just need to know how many masternodes are on the network.

Usually, this information can be found on a project’s ‘block explorer’. The number of service nodes on the Loki network can be found on either the Loki Block Explorer or the Loki Dashboard.


For the purposes of our example, let’s say that Loki has 738 active service nodes. 

Emission curve

The emission curve tells you how much cryptocurrency a masternode earns earn each time a block is produced, in relation to the current block height (the total number of blocks currently on the blockchain).

In most cases, this information can be found in the cryptocurrency project’s whitepaper or cryptoeconomic paper. For example, Loki’s Emission Curve equation, along with supporting information, can be found here. 

To calculate the amount of $LOKI you could earn each time a block is produced, use Loki’s Emission Curve equation:

Loki emission curve block reward formula: Reward = 28 + (100/2^(h/64800))


  • ‘Reward’ is the amount of $LOKI generated per block.
  • ‘h’ is the block height at which the reward will be created (for the purposes of this example, we’ll assume that Loki’s block height is 356147)Worked example of block reward formula: Reward = 28 + (100/2^(356147/64800)) * 0.5 = 15.10784843

You’d earn 15.1 $LOKI running a masternode or service node at a block height of 356147.

Note: The final figure is multiplied by 0.5 because Loki Service Nodes receive 50% of each block reward. The remaining 50% is split between miners (45%) and the Loki Foundation (5%).

Reward frequency

When you know the block time and the number of masternodes or service nodes on the network, you can use this formula to estimate how frequently you will receive rewards:

Reward frequency formula: Reward frequency = SNcount * BlockGenerationTime

Note: In most blockchains, rewards are automatically distributed by the network using a queue system. When you start running a masternode or service node, you’ll join the back of the rewards queue. When the masternode or service node at the front of the queue receives its reward, it moves to the back. Eventually, your masternode or service node will be first in queue and receive its reward.

Worked example of Loki reward frequency: Loki reward frequency = 738 * 2 minutes = 1476

In this example, with 738 active service nodes on the network, you’d receive a reward every 1,476 minutes (24.6 hours).

Gross masternode reward calculations

Assuming the rewards you earn remain constant, you can calculate the total rewards you’d receive in a given period — for example, one year.

At a block height of 356147, you’d earn 15.1 $LOKI every 24.6 hours. There are 8,760 hours in a year, so at this rate you’d earn a reward 356.09 times per year (8760 / 24.6 = 356.09).

If we multiply the number of times you’d receive a reward in a year by the amount of $LOKI you’d receive per reward, we can calculate that you could receive 5,377.07 $LOKI per year (356.09 x 15.1 = 5,377.07).

Imagining that the price of $LOKI is $US0.30, the gross rewards you could receive in a year would be US$1613.12 (5,377.07 x 0.30 = 1613.12)

Working out your costs

Initial Cost

Your Initial Cost is the staking requirement of your chosen masternode or service node. The staking requirement will be a certain amount of cryptocurrency, which may remain constant or change over time, depending on the crypto project in question.

In most cases, the staking requirement (or how to calculate it) will be outlined in a blockchain project’s whitepaper or crypto-economic paper. For example, the formula to work out the Loki Staking Requirement (LSR) can be found here:

LSR formula: LSR = 15000 + (25007/2^((h-101250)/129600)))


  • ‘LSR’ is the Loki Staking Requirement
  • ‘h’ is the block height (in this example, Loki’s block height is 356147)Worked example of LSR formula: LSR = 15000 + (25007/2^((356147-101250)/129600))) = 21397.3 Loki

The Loki Staking Requirement in this example would be 21,397.3 $LOKI.

If we imagine the price of Loki to be US$0.30, the Loki Staking Requirement in USD would be $6,419.19 (21,397.3 x 0.30 = 6419.19).

Ongoing costs


The most significant ongoing cost involved in running a masternode or service node is the cost of hosting the node itself. Typically, the cheapest and most effective way to run a masternode or service node is to use a Virtual Private Server (VPS). VPS providers let you rent out monthly access to a remote computer which can run the software needed for it to be a masternode or service node. There are thousands of options when it comes to VPS providers, and we recommend doing your own research to find a provider that works for you.

For the purposes of our example, let’s assume your VPS costs $15 USD per month (a fairly typical rate for a good-quality VPS service). Over a year, the total costs would be $180 USD (15 x 12 = 180).


You’ll need a reliable internet connection to manage your VPS. This will be crucial when you need to update your masternode or service node software, as out-of-date masternodes can be disqualified from receiving rewards, or even be decommissioned or deregistered from the network.

However, because internet access is widespread in most parts of the world, this cost will not be considered as part of the cost of running a masternode (and thus will be left out of our calculations).

Back to the masternode rewards formula

We now have the necessary information to calculate our masternode or service node rewards using the net reward formula:

  • The total rewards you could receive in a year, converted into USD, are $2,097.06
  • The total costs you might incur in a year are US$180
  • The hypothetical initial cost is US$7,039.71

Remembering our masternode rewards formula:

Masternode rewards formula: Net Rewards = (Gross Rewards - Costs)/Initial Cost

Using the above example amounts:

Worked example of Net Rewards formula: Net rewards = (2097.06 - 180)/7039.71

Net reward = 0.272321 (27.23%)

Over a period of one year, assuming all the above figures remain constant, your net reward for running a Loki service node would be 27.23%. This means that after a year, your initial contribution would have effectively increased by 27.23%. You also get back your initial crypto stake when you stop running your masternode.


The net reward equation is a great simple tool for estimating a masternode or service node’s reward output — but it’s just that, an estimation. There are several variables to consider, all of which can change over time. These include:

  • Masternode/service node count: The number of masternodes or service nodes on the network is constantly changing, and the higher the number, the longer you will have to wait to receive a payout.

  • Coin price: The price of the coin you’re staking is subject to market fluctuations. This means your holdings (and rewards) may be worth more at the end of your staking (lock-up) period, or less.

  • Block reward: Block rewards are dependent on the coin emission curve used by each particular blockchain project, and they can differ significantly. For example, Bitcoin’s block reward stays static for 4 years and then halves, while Loki’s block reward changes with each block, slowly reducing over time.

  • VPS prices: Choosing the cheapest VPS option doesn’t guarantee the lowest overall costs of running a masternode or service node. Cheaper options might not be as reliable as more expensive ones, and if your VPS goes offline for a while, you might miss out on rewards — or even be deregistered or decommissioned. 


Calculating a masternode or service node’s net reward is a great way to figure out which cryptocurrency project you might want to run a masternode for. This article outlines a quick and easy way to estimate your rewards, but you’ll want to do more in-depth research on the project you’re thinking of running a masternode for to get a more specific calculation of the rewards you could earn.

TLDR: Masternode (and service node) rewards

Running a masternode or service node can earn you cryptocurrency rewards, but before you spin up a service node, you should check that your costs won’t outstrip your rewards. Skim through each section above for a lowdown on the math behind the rewards.

Weekly Dev Update #71

Hey Y’all, 

Last week the Loki Messenger team continued their short term pivot to get File Attachments and Mentions finished for a quick release. These long requested features are very close to being rolled out. The Loki Core team continued their push to get Blink finished, while also working on LNS (Loki Name System) – expect updates on these soon. Finally, the Service Node checkpointing fork will be happening in about 24 hours from this post being published, so if you have not yet updated your Service Node to 5.1.2, please do so now. This will ensure your node does not desync when the fork occurs. 

Loki Core


If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What Went on Last Week with Lokinet: 

Work continued on the Lokinet control panel, which will become a GUI control interface in the next release. Progress was made on the changes to make Lokinet switch back to lokid’s standard ed25519 keys (added in loki-core 5.x). There’s also been prep work to make Lokinet talk directly to lokid, and continued work on the core VPN-layer functionality needed for future Android support.

PR Activity:

Loki Messenger for Desktop 

Loki Messenger for Mobile (iOS and Android)

Loki Messenger for iOS:

Loki Messenger for Android:



5.1.0 Trusty Tyr Mandatory Upgrade

loki network coin wallet

Hey Everybody, 

Today marks the start of the mandatory upgrade period for the new Loki Core Trusty Tyr 5.1.0 release. Trusty Tyr adds a number of notable features to Loki Core, including: 

  • Fully enabled and enforced Service Node checkpointing 
  • Updated RPC Calls to reflect transaction checkpoint status
  • RandomXL stability updates
  • Extended Uptime credits to 48 hours from 24 hours 
  • Number of bug fixes for issues which caused Service Nodes to calculate incorrect winners for certain blocks
  • Increased uptime proof relaying robustness 
  • Fully Linear Staking requirement curve
  • “Export_transfers” is now available via RPC (see Lokidocs RPC documentation for more information).
  • Better integration with Loki Storage Server to enforce network reliability

We have set the hardfork height for block 385,824, ‬which is approximately 13 days away and should fall on  ~22nd of October 2019 UTC. 

If you’re running a Service Node, mining pool, or you’re full node operator, you will need to update to the new version of Loki Core to ensure that you stay on the correct chain. 

Non Service Node Operators 

For mining pools and (Non Service Node) full nodes, Loki binaries can be downloaded directly here:

Service Node Operators

Service Node operators running Loki Launcher should refer to this guide for updating:

For those running Loki Service Nodes using the Debian releases, you can upgrade using this guide:

As part of their update procedures, Service Node operators should also update their Loki Storage Server to the newly released Version 1.0.7. This should happen automatically if you follow the guides above. 



Does Pulse Make the Rich Richer?

Loki cryptocurrency featured image

Loki Improvement Proposal: POS Scheme Pulse

Recently we released our fifth Loki Improvement Proposal in which we outlined a new Proof of Stake scheme, Pulse. If it’s to be implemented, Pulse would have Service Nodes produce blocks, order transactions, and secure the blockchain, rendering miners in the Loki ecosystem no longer necessary.

While we’re excited about the potential of Pulse, and the improvements it can bring to Loki’s suite of privacy tools, we’re aware it has raised some questions and concerns within the community. The main one being: “Won’t it Just Make the Rich Richer?”

Transitioning from Proof of Work to Proof of Stake

Let’s imagine Loki transitions from its current Proof of Work / Proof of Service hybrid consensus mechanism to Pulse (Proof of Stake). In this scenario, the Loki Network will be made up of two parties: Stakers and Non-Stakers. 

Stakers are those who are running a Service Node, either by themselves, or with others in a pool. They have enough $LOKI to do so.

Non-Stakers are those who aren’t running a Service Node, because they don’t have enough $LOKI to meet the staking threshold, or because they’re choosing to hold their $LOKI instead. 

Service Nodes

With Pulse, Service Nodes will create blocks in the Loki blockchain every two minutes, and receive a reward ($LOKI) for doing so. Ninety-five percent of that reward will go to the Service Node Staker (or Stakers, if it’s a pool), and the remaining five percent will go to the Loki Foundation.

In order to run a Service Node, we recommends you stake at least twenty-five percent of the full staking requirement. At the time of writing, that is roughly 5,200 $LOKI, which equates to about 1,400 USD. So Stakers – those that have enough (and choose) to stake the recommended amount of $LOKI – will increase their wealth through the accrual of rewards. 

Furthermore, each time a Service Node creates a block, the overall monetary supply of $LOKI increases. Just like in a traditional economy, assuming everything in the market stays constant, when the monetary supply increases, so does the inflation rate. And when the inflation rate goes up, the purchasing power of the currency goes down. This means everybody’s $LOKI buys a little less than it did before. This is an unfortunate (but not uncommon) side effect for those that hold (and don’t stake) currency. 

However, the inflation situation is the same with Proof of Work consensus mechanisms. When miners create blocks, they also receive rewards, which in turn increases the overall monetary supply and drives inflation up. 

One major difference between Proof of Work and Proof of Stake consensus mechanisms is the size of the barrier to entry. The initial investment (fixed cost) required to mine cryptocurrencies – specialised hardware, constant electricity, and a high-speed internet connection – is much higher than the cost of running a Service Node – which is essentially the cost of renting and maintaining a VPS. In essence, you need a lot more financial resources to be a miner, than to be a Staker. 

Of course, in reality everything in the market does not stay constant. The real-world market cap of $LOKI fluctuates, and if it increases, everyone’s purchasing power increases. Same goes the other way. Regardless, there still exists an inequality caused by the barriers to entry for mining or staking. However, a barrier to entry is necessary* in order to keep the Loki Network protected from malicious activities like Sybil Attacks. 

Low barrier of entry allows more people to benefit from POS

The lower barrier to entry for Service Node operators is why Pulse is an attractive prospect for Loki. It means more people have the opportunity to participate in the rewards-based ecosystem (especially when compared to Proof of Work). Ideally, it also means more Service Nodes are in operation on the Loki Network, making our privacy products better for all. So we think it’s a win-win.

We love that our community is engaged, and challenges us to be better, which is why we’ve endeavoured to answer this question. If you have more, please keep them coming on our various social media channels.

Testing Bounties

Loki cryptocurrency featured image

Service Node checkpointing is now being enforced on testnet v5.0.0. We really want to make sure everything is running smoothly, so are inviting you to do your best to break checkpointing on the testnet! 

As a reward for the hard-working testers out there who manage to find bugs in v5.0.0, we have put a bounty system together:

The total reward pool is 4000 $LOKI.

Bounty Guidelines:

  • Attacks should be performed on the Loki testnet, where the most recent checkpointing code has been activated. 
  • The goal of an attack should be to invalidate Service Node checkpointing. Functionally, this means you should be able to get an unmodified lokid node to sync or switch to any alternate chain that competes with a mainchain with more than 2 consecutive checkpoints.

Some attacks you might try to execute are:

  • Targeted attacks that prevent Service Nodes communicating during consensus. 
  • 51% attacks on the mining network. 
  • Joining a dishonest minority of Service Nodes – please remove these nodes from the network once you finish testing as others may be trying to use similar methods.
  • Constructing special transactions/blocks. 

The following attacks are out of the scope of this bounty program and will not be rewarded: 

  • Gaining more than 51% of the Service Nodes on the Service Node network (this would be prohibitively difficult on the mainnet). Note: The 20 Service Nodes operated by the Loki team on the Loki testnet represent the “Honest Majority”.
  • Blanket DDOS attacks are not considered in scope as they would be prohibitively difficult on the mainnet given the size of the Service Node network.

Bug Severity will be decided arbitrarily by the Loki team. High severity bugs will earn 50% of the total prize pool at the time your claim is approved. Medium severity bugs will earn 20%, and low severity bugs will earn 5%.

Happy Testing!

Weekly Dev Update #62

Hey Y’all, 

A small update this week as many of the Loki devs are attending conferences (I’m at Blockchain Week Berlin) or on holiday. Most of our work went into Loki Core and Lokinet releases, where we are successfully improving stability on both fronts. 

Loki Core


If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet:

We continued to focus on testing and fixing up various issues. Some major PRs have been added which have noticeably increased Lokinet connection and stability, however these changes have introduced a regression in network speed that we’re investigating. Next week we are focusing on solving the aforementioned issues, plus other general testing and fixes for an upcoming 0.5 release. The changelog for this past week is lighter than normal as Jeff was away for most of the week, but he’s back and at it now!


New/updated/pending PRs:

Loki Messenger for Mobile (iOS and Android)

What’s going on this week with Loki Messenger: 

We released the APK for Loki Messenger for Android which means Loki Messenger is now available on all major platforms! We will be working hard to iron out bugs and improve the user experience over the coming months.



Weekly Dev Update #61

Hey Y’all, 

This week we continued work on some key areas in Loki Messenger, including adding chat channel support for Android and iOS, and starting work on support for Loki Messenger across multiple devices. We also released an update to the Loki Storage Server which allows for the measuring of additional statistics, so we can continue to monitor the network and the success of the switch from testnet to mainnet for Loki Messenger. 

Loki Core

There’ll be a point release to Loki Core this week with a number of bug fixes that should increase Service Node stability. This is not a mandatory upgrade but is recommended for those running Service Nodes. 


If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet: 

Testing continues. We’ve identified a couple of issues related to existing sessions closing prematurely: we have a good idea where they are happening and are focusing on solving them.


New/updated/pending PRs:

Loki Messenger for Desktop 

Storage Server

Loki Messenger for Mobile (iOS and Android)

This week we released the APK for Loki Messenger for Android which means Loki Messenger is now available on all major platforms! We will be working hard to iron out bugs and improve the user experience of over the coming months.



Weekly Dev Update #59

Hey Y’all, 

This week we’ve mostly worked on bugs that were affecting Service Node operators as they transitioned from lokid 3.0.X to the 4.0.3 suite of Loki Service Node tools. We published a new release for the Loki Storage Server and Launcher, and we have also made good progress on transitioning Loki Messenger to the mainnet so it can take advantage of the ~550 Loki Storage Servers.

Loki Core


If you’re on our Discord you can catch Jeff, the lead developer of LLARP, live streaming as he codes at He typically streams on Tuesday mornings, 9am – 12pm Eastern (US) time.

What’s going on this week with Lokinet: 

All of the pull requests for the next version are either merged, or reviewed and to be merged in the next day or so. We are spinning up a distributed “toy” network to test the stability and functionality of the codebase in anticipation of a public release sometime in the next week or two (testing dependent). We also have internally-working debian packages for various recent Debian and Ubuntu versions to allow easy installation of Lokinet on those systems, and plan to release these with the public release.


New/updated Pull Requests:

Loki Messenger Desktop 

Storage Server

Loki Launcher

What’s going on this week with Loki Launcher:

With the launch of the Hefty Heimdall hardfork, the Loki Storage Server is now active. This week, after tracking down a number of bug reports submitted in Telegram and Discord about unexpected crashes, we found the suspect behaviour and put in a work around into the 1.0.0 release of the launcher. We also added a couple of fixes as a few new eyes were on the code, and improved its accuracy of status and startup.


  • Fix Storage Server pipe that would lock up Storage Server
  • Fix Storage Server stderr handler typo
  • SIGHUP guard fix
  • Double check running pid
  • Use SIGTERM instead of SIGINT to stop processes
  • Handle socket write errors better
  • Test socket for connectivity in status
  • Clear stale pid and socket files
  • Move uncaught exception log into var_path
  • Make sure Storage Server is running before startup is successful
  • Change version for git checkouts to be the last committed revision

Loki Blocks Onion Explorer 

The Loki Block Explorer has been expanded to show a number of new things including checkpoints and their votes, and decommissioned or inactive nodes. 

Loki Messenger on Mobile (iOS and Android)

We are very close to an Android release of Loki Messenger, and are now testing it internally in the office.



Weekly Dev Update #58

Loki Network Development Update 58

Hey Y’all, 

The Loki 4.0.0 hardfork is fast approaching! It’s happening in approximately 24 hours, so if you haven’t upgraded your Service Node, Miner or Mining Pool, now is your chance. If you don’t update in time, you will be left on an alternate chain and won’t be able to talk to the majority of the network.

A full guide on how to update can be found here:

Loki Core


If you’re on our Discord you might catch Jeff, the lead developer of LLARP, live streaming as he codes:  He typically streams on Tuesday mornings, 9am-12pm Eastern (US) time.

What’s going on this week with Lokinet:

Lokinet is entering a feature freeze for an upcoming release to the public, and is undergoing heavy internal testing to see how the network performs under various types of load.  We don’t have a fixed release date yet — it will depend on how testing goes this week, but look for one soon. The last several weeks of development have fixed a myriad of issues, big and small, and we think Lokinet will be ready for public testing soon.  Hence, we have internally frozen the codebase* to not add anything new (just important fixes!) between now and the 0.5.0 release.

* There is one exception; see below.


New Pull Requests:

Loki Messenger Desktop 

Storage Server

Loki Blocks Onion Explorer 

The Loki block explorer has been expanded to show a number of new things including checkpoints and their votes, and decommissioned or inactive nodes. 

Messenger Mobile (iOS and Android)



Hefty Heimdall Changes for Service Node Operators

There are a number of new and changing rules being implemented in the Loki Hefty Heimdall hardfork, and Service Node operators should make sure they’re aware of the new requirements.

The following changes will be implemented on July 24 at block height 321,467.

Changing Rules:

  • We have relaxed the Service Node deregistration rules in order to be more lenient on Service Nodes, particularly those that have previously demonstrated quality performance. 

New Rules

  • All Service Nodes must now run the Loki Storage Server to receive rewards.
  • All Service Nodes must now have an accessible Public IP address and must open ports for the Loki Storage Server.
  • There is now a penalty for Service Nodes that send their uptime proofs from different IP addresses.

More Detail:

Relaxed Deregistration: 

After reviewing feedback from Service Node operators on Discord and Github over the past 6 months, the Loki team proposed a number of relaxations (included in Hefty Heimdall) with regard to how Service Nodes are deregistered when they fail to meet the expected requirements. 

A few basic changes were made to implement the new system, including the introduction of a credit scheme and decommission/recommission transactions. The basic scheme is detailed below:

  • Each Service Node starts with 2 hours of credit.
  • Each Service Node earns 0.8 hours of credit per day of uninterrupted operation up to a maximum of 24 hours.
  • If a Service Node has been assessed to be no longer meeting the standards of the network (for example, not submitting uptime proofs) the quorum looks to see if they have any credit.
  • If the Service Node has 2 hours or more in credit, it will be decommissioned (instead of deregistered) for the amount of time it has in credit.
  • When a Service Node is decommissioned, its funds are not locked for 30 days but it is removed from the rewards pool and cannot participate in normal network functions.
  • If the Service Node starts sending uptime proofs again during the decommission period, the current quorum will detect this and submit a recommission transaction which will reset the Service Node’s credit balance to zero, and insert the decommissioned Service Node back to the bottom of the rewards list.
  • If, during the decommission period, the Service Node’s credit runs out before it can successfully submit an uptime proof, it will be deregistered.

TL;DR Service Nodes now have a longer grace period which grows the longer your Service Node is up and performing well. Service Nodes that have been running without interruption for 30 days will now have 24 hours where they can be offline before they are deregistered and your funds are locked for 30 days.

Read the full details of the relaxed deregistration rules here:

Loki Storage Server:

The Loki Storage Server is an application that exposes a public endpoint for Loki Messenger users to be able to store and retrieve messages on your Service Node. It is a necessary requirement for Loki Messenger.

Hefty Heimdall versions of lokid running in Service Node mode will look for a running Loki Storage Server on your machine. If lokid does not find a running Storage Server, it will refuse to start. Lokid will also periodically check to see if the Loki Storage Server is still running – if it isn’t, lokid will stop broadcasting uptime proofs.  

You can easily manage lokid and the Loki Storage Server with the Loki Launcher, which sets up the required utilities. If you are an experienced system administrator, you can manage these utilities yourself – though we recommend you test your setup on testnet.

TL;DR You need to run the Loki Storage Server alongside lokid. Loki Launcher will do this automatically, otherwise binaries can be found here:

Public IP address and Open Ports:

All Service Nodes must now have a public IP address and open ports for lokid P2P and the Loki Storage Server. The default port for mainnet lokid P2P is 22022, and for the Loki Storage Server the default port is 23023.

If you are currently running your Service Node without any open ports or behind NAT, you will need to look into creating port forwarding rules in your router, and/or opening these ports in your firewall. If you are running a custom setup, you can change your default ports for Loki Storage Server and lokid P2P communications.

TL;DR You need to open ports in your firewall or router and have a public IP address.

IP Address Change Penalty: 

We understand that many Service Node operators in the community are running backup servers which submit uptime proofs for their Service Node. Most operators have set up these backup servers by running another lokid with the –service-node flags on a seperate IP, but with the same Service Node key as their primary Service Node.

This setup creates a race between the two Service Nodes, which compete to send out the first uptime proof. Depending on the precise timing of when the separate lokids submit their uptime proofs, the relationship between the two Service Nodes can change. You may find one is master for a while, and then it switches. You may find the two Services Nodes swap on every announcement. 

This race condition will be a problem in Hefty Heimdall because of the inclusion of the Service Node IP address in each uptime proof. Every time the server sending the uptime proof “wins”, it changes the IP on which the network tries to reach the Service Node’s Storage Server, and of course, the backup won’t have the same messages stored as the primary server.

Without modifying the Storage Server code to create a syncing channel between a master and backup Service Node, this problem is difficult to solve. Instead, the Loki team has implemented a punishment for Service Nodes that submit uptime proofs from different IP addresses. Each time your IP address changes, you will be dropped to the bottom of the rewards list losing your previous position. 

From talking to Service Node operators, we found that one of the most common reasons they ran Service Node backups was because they didn’t have enough time to respond to outages on their Service Nodes. By addressing the core issue – which was the lack of forgiveness in the deregistration rules – we think there will be far fewer people wanting to run backup Service Nodes. 

Although this change does not explicitly prevent the running of backup Service Nodes, Service Node operators who choose to run backup servers should ensure that they only send uptime proofs from the backup Service Node when it’s clear that the master server is actually down, rather than just setting up two Service Nodes and having both submit proofs at competing times.

TL;DR Running two Loki Service Nodes with the same SN key on two machines with different IP addresses will likely lead to your Service Node being dropped to the bottom of the rewards list regularly.

We are really excited to see these changes go live on mainnet on July 24. The Loki team and Loki community are always looking for ways to improve the stability and usefulness of the Service Node network, while maintaining a simple user experience so the Service Node network can continue to grow.