Loki Now on Binance DEX

Binance Dex Lists Loki

We’re extremely excited to announce that as of today (like, right now), Loki is listed on Binance DEX

That’s awesome! How’d you do it?

Glad you asked. To make it work, we’ve created B-Loki, a token on Binance Chain which is specifically engineered to provide a smooth and fast DEX experience where all trades are executed on Binance Chain. 

What’s the difference between Loki and B-Loki?

Good question. While we’re proud that Loki is fungible, private, and secure, B-Loki doesn’t maintain all of these properties. Rather, its main purpose is to allow trading on Binance DEX.

Cool. Can Loki be swapped for B-Loki?

Yes! Through the brand new Loki Bridge, which allows Loki to be exchanged for B-Loki (and vice versa) on Binance Chain. Functionally, the bridge lets you send Mainnet Loki coins and specify a specific Binance address where you will receive B-Loki. 

Okay. But is the bridge secure?

Loki Bridge has been built with security in mind, and uses a mixture of best practice techniques to match the security of many of the top exchanges in the cryptocurrency world.

Phew. So how does it work?

Like an exchange, when you deposit Loki into Loki Bridge, you’re relying on that exchange to credit your account in order to trade on it. However in this case, as the bridge is crediting your B-Loki or Loki Wallet, you only have to trust the bridge with your funds while a swap is in progress. As soon as the bridge has finished swapping your coins, you have full control of them in your nominated wallet.

And it’s trustworthy?

We’ve sought legal advice on the creation and listing of B-Loki in order to make Loki Bridge as trustworthy as possible. After assessing the available options, the Loki Foundation has contracted the operation of Loki Bridge to a third party provider, Lunar8. JP from Lunar8 is one of our earliest investors and is a trusted member of the Loki community who has advised and supported us since Loki’s inception (in fact, before Loki was even called Loki), and currently runs several Service Nodes.

The Loki Foundation maintains full rights to audit the bridge at any time, and works with the service provider to ensure that the correct amount of B-Loki and Loki is being held on the bridge at any given time. The service provider may never use the Loki held on the bridge for any other purpose than usage on the bridge (except for fees), and must adhere to strict security policies set by the Loki team.

Great. How long does it take to swap Loki to B-Loki? And B-Loki to Loki?

On average, swapping Loki to B-Loki should take about an hour. This is how long it takes for 12 chain confirmations on the Loki blockchain, plus a processing period to confirm everything on the backend. This time may reduce after checkpointing is enforced on the Loki mainnet and has proven itself to be reliable.

Swapping B-Loki to Loki should be much faster and take about half an hour. Since Binance Chain has a low blocktime, it reaches finality very quickly. However, there will be some lag due to processing time on the backend of the bridge. 

It’s worth noting that not all processing happens automatically: the bridge operator can choose to investigate swaps as they happen to ensure that incoming and outgoing balances match. This may add additional processing time beyond the normal period – as much as 24 to 72 hours.  

Is Loki Bridge decentralised? 

No, however once you’ve crossed the bridge and have B-Loki or Loki, you have full control over your funds again with your own private keys. The only centralised part of the process is the swapping mechanism.

Hang on. Is this some grand plan for Loki to switch to Binance Chain?

Not at all. We’ve built Loki Bridge to allow users to access Loki from additional places (including Binance Chain), however Loki will continue running on it’s own mainnet – it is critical to keep the Service Node network functioning. 

We hope Loki’s listing on Binance DEX is music to your ears. It’s another step forward for us in offering the best experience for our users, providing another place to acquire Loki, and adding to our growing list of integrations and features on offer. Check out Loki Bridge here.

If anyone has trouble using Loki Bridge, please head to our Telegram or Discord for support.

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: https://lokidocs.com/ServiceNodes/DeregistrationRules/

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: https://github.com/loki-project/loki-storage-server

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.  

Hefty Heimdall Mandatory Upgrade Period

Hey Everyone!

It’s hardfork time again! The Hefty Heimdall upgrade period has begun, and that means everyone has approximately 12 days to upgrade to the latest versions of the Loki software before the hardfork on July 24. 

Below is a guide on how to prepare for the hardfork for each type of user in the Loki ecosystem: 

Wallet users

You guys don’t need to do anything yet. Over the course of the next two weeks we will be pushing updates to the Loki Desktop, iOS and Android wallets to upgrade them to the latest versions of the Loki software. 

Once these updates are released we encourage everyone to upgrade their wallet to the latest version, otherwise you will no longer be able to send transactions on the correct chain. 

Service Node Operators 

If you are using the Loki Launcher you can update to the latest binaries by using these commands: https://lokidocs.com/ServiceNodes/SNFullGuide/#updating-your-binaries.

For those more experienced with system administration and who aren’t using the Loki Launcher, you can upgrade your lokid binaries manually. Please note that you will also need to update to the latest Loki Storage Server. We have compiled a guide here: https://lokidocs.com/ServiceNodes/SNFullGuideLegacy/.


Pools do not need to enable RandomXL support until the hardfork on July 24 or at block 321467, however they should make sure they are ready to switch when the fork happens, and can look at these two reference implementations for changes they may need to introduce to their software.

A cryptonote-node-JS reference implementation pool which supports the new RandomXL Loki hashing algorithm can be found here: https://github.com/jagerman/cryptonote-nodejs-pool/tree/randomx.

A reference implementation for node-cryptonight-hashing can be found here: https://github.com/jagerman/node-cryptonight-hashing/commits/master.

A list of the full Loki changes to RandomX can be found here: https://github.com/loki-project/loki-randomXL.


Miners can continue to mine Loki using CN-Turtle, however on the July 24 at block height 321467 they will need to switch to using RandomXL which is supported in a mining software called Xmrig on their “evo” branch: https://github.com/xmrig/xmrig/tree/evo. Xmrig have not yet published release binaries with RandomXL support, and if they haven’t published release binaries by the hardfork, we willl build and distribute mining binaries from a fork of their repository. 


Exchanges will need to update their lokid and wallet with the latest CLI binaries found here: https://github.com/loki-project/loki/releases/latest. We will reach out to exchanges individually with any additional instructions if required.

Happy Forking!

Loki Issues B-Loki Token on Binance Chain

The Loki team is thrilled to announce that we will be joining the Binance ecosystem by creating B-Loki token on the Binance Chain! The Binance Chain blockchain has been specifically engineered to provide a smooth and fast DEX experience for members of the Binance community through the decentralised exchange feature developed on top of Binance Chain. Receiving positive votes from all Binance DEX validators will allow users to trade Loki on the decentralised exchange and will provide an additional onramp for users wanting to get Mainnet Loki. Loki as it currently exists on the Loki Mainnet won’t change, and will always be our main focus.

We’ll also be supporting the creation of Loki-to-Binance ‘bridges’ which will allow for the deposit and withdrawal of Mainnet Loki in exchange for B-Loki on the Binance Chain. Users will be able to exchange their Loki for trading purposes and move it back to mainnet Loki when they want to stake or use other privacy features. We’ve reached out to some trusted long-term community members to run these bridges and are helping them develop a secure and reliable system for exchanging Mainnet Loki with B-Loki.

We’re also considering a plan to develop a system which would allow users to exchange their Loki between the chains without requiring a trusted intermediary like Binance.com or the Bridges. If this is implemented, Service Nodes would be able to maintain a working knowledge of the B-Loki token on the Binance Chain, and would be able to authorise the locking and unlocking of Loki, and the minting and burning of B-Loki on the Binance Chain in a decentralised way.

We’re super excited about our upcoming product launches later this year. The Loki Messenger alpha will be release on the mainnet in July, and we believe that this will mark the beginning of the next phase for the Loki Project. 

In our new efforts to start climbing the adoption curve for Loki’s products, we want to ensure that we are doing what we can to provide the best experience for the new users we expect to gain from this next phase. We hope that supporting the trading of Loki on the Binance Chain/Dex will add to the growing list of integrations and features that we can offer.

Loki’s Hashing Algorithm Change

Recently there has been a lot of talk in the Loki community about merged mining, hashing algorithms and FPGAs. We have been listening to your conversations on Github, the Loki Discord, the Loki Telegram groups, and across our social media channels taking note of your suggestions and proposed changes. 

Here are a few key assessments made by the community that we agree with: 

  • Although the pool distribution is very equal, with no pool with greater than 25% hashrate, we suspect there are some very large miners merge mining TurtleCoin and Loki. These large miners present a risk for 51% attack pre checkpointing: 
    • Loki Address L8ntSS: ~145 MH/s total (~36MH/ on cnpool, ~36MH/s on cryptopool.space, suspected additional ~65 MH’s from conversations with other pools)
    • Loki Address L7StFQ: (~47MH/s on mine2gether)
  • We suspect that because of the current difficulty, CN-Turtle has become ineffective at protecting the network against profitable FPGA mining. This is reducing the number of GPU miners and further driving centralisation towards a group of large FPGA miners.
  • The Loki community and the Loki team have expressed concerns about the alignment of incentives in merge mining. Both groups have pointed out that miners of TurtleCoin have been forced to mine Loki in order to continue to be profitable. This can create negative economic incentives where miners discard Loki in favor of increasing their TurtleCoin holdings and visa versa. 

We have been discussing a number of these issues internally and we have decided it’s time for a change to the Loki hashing algorithm and current mining setup. 

Today we are announcing the integration of the RandomX hashing algorithm into Loki. You can see our pull request to the Loki codebase here: https://github.com/loki-project/loki/pull/675

We have made some small modifications to our RandomX parameters and from now on we will refer to the Loki hashing algorithm as RandomXL to avoid confusion. We are grateful to the developers who worked on RandomX, including tevador and hyc. A full list of contributors can be found here: https://github.com/tevador/RandomX.

Although this change is happening quite close to our revised testnet binaries release date (June 28), we have been looking into these changes for a while. Our friends at Arweave funded a security audit of RandomX (https://github.com/trailofbits/publications/blob/master/reviews/arweave-randomx.pdf) which further increased our confidence in RandomX being the right choice. Over the next two weeks of testnet we will be monitoring how RandomXL performs, and if there are no issues it will be enabled on our Hard Fork date on July 24. 

Going forward, this means that Loki will disable merge mining with any other chain. We want to thank our friends at TurtleCoin for their positive community interactions with the Loki team and the Loki community. Over the next 6 months we will continue to discuss mining rewards, hashing algorithms and merge mining, so please join in our conversations and let us know what you think.

Loki Launcher

The Loki Launcher has just been released, and we STRONGLY RECOMMEND that all Service Nodes update.

The Loki Launcher has a number of components which will improve the user experience for Service Node operators and reduce the chance of being deregistered. These include managing the Loki Storage Server, lokid, and in the future, Lokinet – which will startup and restart these applications if they crash.

User Experience Improvements

Easy access to the lokid console from Loki Launcher

Lokid is now handled by the Loki Launcher. Running the command ‘loki-launcher client’ will allow you to run commands compatible with the Loki daemon, such as ‘prepare_registration’, ‘print_sn_key’, e.t.c.

Unified config file for Loki Storage Server, lokid and Lokinet.

You can now use one unified config file to manage all aspects of the Loki Service Node software!

The Loki Launcher uses the newly unified config file to manage the Loki Storage Server, lokid and Lokinet properties! It also includes validation on startup to alert you to any errors in the config file.

Easier Updates

It’s now much easier to update your Service Node!

We’ve added commands to the Loki Launcher to make downloading the latest Loki binaries as simple as running, ‘loki-launcher download-binaries’.

Service Node Bench Utility

Running the SNbench utility will test your node and advise you on whether your setup meets the requirements for each release.

How to add Loki Launcher to your Service Node:

To update your Service Node to use the Loki Launcher, please run through the following guide:


How to set up a new Service Node with the Loki Launcher:

To set up a new Service Node using the Loki Launcher, please run through the following guide:


Hefty Heimdall 4.0.0

Loki Messenger alpha and Checkpointing!

Today we are announcing the release of our next Loki hardfork, Hefty Heimdall. This hardfork will include a number of updates for both Loki Messenger and Loki Core, including:

  • Service Node Checkpointing
  • Loki Storage Server (Stores Loki Messenger messages on Service Nodes)
  • Internode testing (Blockchain and message storage)
  • Loki Messenger alpha release

The testnet binaries will be released on June 26, so you can start testing these changes in just a few weeks.

There will be a mandatory upgrade period starting July 10.

The Hefty Heimdall hardfork will happen on July 24, with Checkpointing being enabled but not enforced.

We will start enforcing Checkpointing on September 12, completely preventing double spends after 12 blocks of confirmation.

As you may have already heard, we’re thrilled to announce the launch of the Loki Messenger alpha on the mainnet. This is a huge step forward for us and for the community, with Loki Messenger being the first Loki Service to make it out of the labs. We can’t wait to get it into your hands so that with your feedback, we can start to rapidly iterate on the design and feel of it in anticipation of the full launch later this year. We should make it very clear that the Loki Messenger alpha will not have the privacy properties that will be present in the final version. This alpha will primarily be for testing and feedback purposes.

The Basics

The Hefty Heimdall release will include an alpha version of Loki Messenger, which operates entirely on the Service Node network. Loki Messenger will be the first ever system which enables users to achieve both online and offline messaging in a fully decentralised, redundant and scalable way. The encryption used in Loki Messenger, which is also used in Signal, means your messages are only readable by you and the person you send them to. You can read more about the excellent security properties of this kind of end-to-end encryption in this article: http://www.alexkyte.me/2016/10/how-textsecure-protocol-signal-whatsapp.html

The Loki Messenger doesn’t connect to a central server like other messengers. Instead, groups of cooperative Service Nodes – called “Swarms” – store your messages while achieving a high rate of redundancy, meaning that if a Service Node goes offline, your message isn’t lost. Because Loki Messenger doesn’t use any central server, it’s extremely hard for malicious actors to shut the network down since the storage network is distributed across the world over hundreds of nodes.

However, we’ll stress again that the Loki Messenger alpha will not have many of the privacy qualities that the final version will have. Lokinet still has a while to go before it can be deployed on the Service Node network. The Loki Messenger alpha will allow you to communicate securely with your friends and family over a decentralised network while still having a comparable user experience to the chat apps you already know. And when used in conjunction with other network anonymisation tools, the Loki Messenger alpha will also have some reasonable privacy properties.

How it Works

Offline Messages (Asynchronous Mode)

The process below assumes your messenger client has never connected to the Loki Service Node network before, and you want to send a message to a user who is offline.


  1. Your messenger client gets a partial list of Service Nodes and IP Addresses from a set of hardcoded Loki seed nodes. This is done via a clearnet connection, meaning whoever runs the seed nodes can see that your IP address is requesting a list of currently operating nodes.
  2. Your messenger client contacts a single node randomly from the list, and asks them for the Service Nodes in the Swarm that correspond to your recipient’s public key. This means that a single Service Node knows that your IP address is likely messaging a recipient with X public key.  
  3. Your messenger client contacts three of the nodes inside your recipient’s Swarm and gives them the encrypted message for your recipient. These three nodes will know that your IP address sent a message to X public key.


  1. To find your Swarm, your messenger client contacts a random Service Node and asks for the Swarm that corresponds to your public key. Without Lokinet or a VPN, that random node can assume your IP address is linked to your public key.
  2. Your client then maintains a connection to three random Service Nodes in your Swarm and polls them regularly to find out if there are new messages destined for you. This means that three Service Nodes in your Swarm know that your IP address is requesting messages for a particular public key.

Online Messages (Synchronous Mode)

Sending and Receiving

  1. Sending an online message requires knowledge of two parties being online simultaneously, and the addresses they can be contacted at. To do this, Loki Messenger periodically sends your IP address inside encrypted offline messages to your contacts.
  2. When a client comes online they can use this contact information to attempt to establish a direct P2P link with another client. Messages can then flow between the two clients without needing to use the Storage Server. However, this means when you use Loki Messenger, all of your friends can see your IP address.

As you can see from the above descriptions, the Loki Messenger alpha provides reliability, censorship resistance and encryption, however it does not provide protection against metadata collection. It’s important to understand this when participating in the Loki Messenger alpha, since – depending on your threat model – you could be leaking metadata that could be used to draw inferences about your use.

The Hefty Heimdall hardfork is a particularly large one – we hope you’re all as excited as we are!  Please help us improve Loki Messenger for everyone by downloading and testing the alpha – your reports make all the difference. Keep an eye out for further updates as we approach the hardfork date.

The Loki Foundation achieves registered charity status in Australia

I’m pleased to announce that in recent months the Loki Foundation (LAG Foundation Ltd) was successful in attaining registered charity status with the Australian Charities and Not-for-profits Commission (ACNC). This is an exciting milestone for our project team and all in our community as it marks Loki as Australia’s first privacy software not-for-profit organisation.

Our not-for-profit status with the ACNC carries significant responsibility. It calls for Loki to adhere to a high standard of transparency and governance on the project, ensuring that we continue to support our growing community of developers to research and build new technologies to enhance digital privacy in Australia and beyond.

In addition to that, it allows us to stand alongside other charitable and not-for-profit efforts in Australia, including Digital Rights Watch, which advocates for digital rights and the control of personal data to be returned to individuals. With the Assistance and Access Act 2018 in place, and other local and international digital rights issues at play, we must do what we can to educate the public about these issues and the technology that we are building to enhance digital security for Australians and users of the wider internet.

With the ACNC’s governance as a benchmark, we look forward to championing greater security and privacy online in Australia with stronger accountability and support from the Loki community.

Simon Harman

Foundation Director and Project Lead

Service Node Autostaking Announcement

We are very quickly approaching the date where the first Service Node will be deregistered because of a natural expiry. On October the 20th, 30 days since the first Service Node being registered, the first group of Service Nodes will undergo deregistration.

There is a couple of things we wanted to go through for Service Node operators so they understand what the process is of re-registering, and issue a few warnings about Autostaking. If you are presently intending on using autostaking, you should read this announcement very carefully.

Updating software

The downtime between two registration periods is one of the best times to update your Service Node to the latest version of the Service Node software, as it can be done without the risk of accidentally deregistering your node.
The latest version of the Service Node software can be found here https://github.com/loki-project/loki/releases/latest and we have also complied a written guide and a video guide on how to update your Service Node software.

Solo Operators

If you are a solo operator and used autostake, then you must ensure that whatever computer you issued the stake command from is online during your re-registration period. You must also ensure that there is still a process running called loki-wallet-cli as this wallet will scan the blockchain and recognise when your node has been de-registered, and as soon as your funds become unlocked it will restake your Loki. 
If Autostaking fails for any reason then solo operators can run the prepare_registration command on their Service Node again and run the outputted command in their wallet. This will stake your Loki again.

Closed Pools

A closed pool is a pool in which each contributor is specified by their staking address and the amount they are contributing. If you are staking Loki without running a node, ask your operator whether you are in an closed or open pool, they should be able to give appropriate guidance.
If you are Autostaking in a closed pool as a participant we highly recommend that you contact your pool operator and switch away from autostaking back to manual staking. Disabling autostake is as simple as ending the wallet process (called loki-wallet-cli) on your machine, this can be done by using:

On Linux: pkill loki-wallet-cli or
ps aux | grep loki-wallet-cli and using the process id quoted and running kill <process ID>

On Windows: you can use task manager to find the loki-wallet-cli process and terminate it

On Mac: you can use the activity monitor to find and terminate loki-wallet-cli

The main reason we recommend disabling autostake is because in a closed pool if any participant decides they will not stake during the next registration period, you may lock up your Loki without being able to fill the vacancy left by the deserting party.

If you are staking without using autostake, contact your pool operator and ask them whether there has been any changes to their node, they will give you their Service Node pubkey and they can also tell you how much Loki is required during the next registration period (Remember the amount of Loki required to stake is decreasing overtime).

You can use this information and re-run the stake command, as stated above we recommend you do not use autostake unless you have high confidence that all your collaborators will also restake their contributions.

stake <Service Node Pubkey> <address> <contribution amount>

For operators of closed pools we recommend that you contact all participants in your pool and recommend they disable autostake before re-registration begins, unless you can ensure a scenario where you have high confidence in all staking participants. Operators who are also using autostake to re-register their Service Node should consider their pool participants and whether they will be staking in the next period, if not they may need to adjust their pool using the prepare_registration command.

Open Pools

Open pools are pools for which there is no specified contribution addresses. Anyone can contribute to an open pool without notifying the pool operator. 
For open pools in version 1.0.4 we have disabled the autostake feature. This is due to the high risk for operators or contributors to inadvertently lock funds due to a lack of communication. Additionally using autostake in open pools in the current implementation fails to reduce the amount of the stake as per the decreasing staking requirement.

Therefore we recommend that anyone who operates or is a participant in an an open pool terminate any wallet which is autostaking. Open pools are still available in version 1.0.4, however they only allow the client to use the stake command without the auto flag.  

As with all other Loki, Loki that was staked in open pools will be unlocked and the user is free to use this Loki in the same open pool (if it exists) by using the stake command as shown below:

stake <Service Node Pubkey> <address> <contribution amount>

Operators of open pools can also continue running open pools without autostake by running the prepare_registration command and submitting output through their wallet, users can be notified of the specifics of the new open pool when it is available.

User experience
We are looking at making changes to the user experience of staking in the future which will make the process less clunky and also reduce the risk of the user locking their funds without acting intentionally dishonestly.

Service Nodes Testnet Announcement

Hey Everyone,

The development pace in the Loki office has been consistent and quicker than expected, and I’m happy to announce that we will be launching Service Nodes well ahead of schedule. A huge thank you to our two main Service Node developers, jcktm and Doy-lee, who have been putting in long hours to get this out. This will mark the first time Proof of Service has been implemented on a CryptoNote coin and we’re really excited to have everyone onboard to test it out.

How will the rollout/update process work?

Beginning on 09/08/2018 (August 9th) the testnet will be restarted with Service Nodes enabled. The testnet will operate for two weeks in this state. During this period, we will make final changes to the Service Node software, fix bugs as they are reported to us, and add features which will be useful for the final release. Bugs found by community members in Service Node software will be rewarded with bounties at the discretion of the Loki team and depending on severity.

On 23/08/2018 (August 23rd) we anticipate the release of the final version of the Service node software, including any bug fixes/changes we found in the Service Node testnet period. This release marks a mandatory upgrade period between 23/08/2018 and 20/09/2018. In this period we will contact exchanges, pools, and miners. All clients will need to update their software.

Testnet will continue operation with the new changes, however on 20/09/2018 (September 20th) mainnet and stagenet will hard fork and Service Nodes will be released in a production environment.
Service Nodes already set up on testnet will NOT rollover to mainnet, so when the mainnet forks everyone will have the same opportunity to begin operating a service node using real Loki.

What do Service Nodes do in this update?

As part of the rollout process we need to slowly introduce Service Node functionality. In this upcoming fork, Service Nodes will only have the ability to register and receive rewards. There is no complex testing functionality yet enabled. In this fork Service Nodes will not route data other than propagating blockchain data to their peers. However to be rewarded, Service Nodes that are online automatically transmit pings to the network. If a ping is not submitted each hour a node is assumed to be offline and will be deregistered.

More complex functionality is being heavily developed as we speak and will be introduced to Service Nodes over the coming months. However, it is essential that we deploy the base functionality of Service Nodes before we can begin integrating more complex testing and begin routing packets on top of service nodes.

Remaining features that will be introduced over the coming months:

  • Blink (Instant Transactions)
  • Lokinet (Packet Routing & SNApps)
  • Loki Messenger (Message Storage)
  • Enforced Remote Nodes (Light Client Improvements)

How can I register a Service Node on testnet?

You will need the alpha software from here, and instructions on how to use it are here, this also includes a guide on how pooled staking works. This guide assumes you know how the CLI and daemon work. If you don’t, a complete guide on staking is in the works, so sit tight!

To test Service Nodes, you will need:

  • 100 testnet Loki
  • A VPS, or highly available home server
  • The Loki CLI wallet, and the Loki Daemon

On testnet, the staking requirement will be 100 Loki, so everyone can get in and test. We will distribute funds from the testnet foundation wallet, so just ping one of the admins in the Loki telegram or discord and we will send you some testnet Loki to stake. You can also mine testnet loki by running start_mining <address> in lokid.

We’ve also shortened the staking duration to just 2 days in the testnet, so you should be able to test restaking over the next couple of weeks to familiarise yourself with the process.

This would also be a good time for anyone seeking to pool their staking requirement to test out how that functionality works. So jump on testnet and start testing.

How can I provide feedback or submit bugs?

For general feedback and discussion about the software, you can go to the brand new #service-node-testing discord channel.

If you spot bugs in the code or add features to it, you should submit an issue or pull request to GitHub. The devs will review the bugand include any necessary fixes in the final release.

What are the requirements for setting up a Service Node on Mainnet?

We have been testing various VPS providers across the course of the last few months and we will be making some recommendations based on positive experiences. In the beginning Service Node operators will have much more choice about where they set up their nodes due to the significantly lower stresses they face. When Loki Messenger and Lokinet are finished, the bandwidth requirements will become more onerous and low performance nodes will have to upgrade hardware and network connections or risk being kicked off the network by automated bandwidth testing systems. When a date for Lokinet is set, we will warn Service Node operators at least 30 days in advance so that they can upgrade their servers.

Where can I go for more information on Service Nodes?

We are currently setting up a webpage to act as a central point for operators to stay updated with all of the latest information. This portal will be updated as we produce documentation on Service Nodes. We want to make setting up a Service Node as clear as possible, and provide in-depth explanations on how the process works, so operators don’t end up making expensive mistakes.
We are updating the channels in discord to include a dedicated Service Nodes category, so we can have more in-depth discussions about the software and provide support to those having difficulty.

Very exciting times! Let’s get testing, LOKIGANG!