Laying Down Layer One: Loki

Over the last three months, there has been significant focus on Loki’s layer two, with numerous papers and articles revealing the true scope of Loki’s Service Node functionality with Loki now becoming a fully fledged mixnet. There has also been much talk about how Loki as a currency, or layer one transactional medium, will function in this framework. Initially we envisioned Loki would act as an access token to prevent Sybil attacks, however there are some downfalls of that system which we addressed in an article here. Given we have focused so much on Loki’s second layer, it’s time to give Loki’s first layer some explanation, and demonstrate why Loki is not only an advancement in layer two design, but also what makes it a worthwhile cryptocurrency.

A Move Towards Scaling

Monero and most other Cryptonote coins have dynamically scaling block sizes, meaning there is no hard limit to how many transactions can theoretically take place on the blockchain. However in practice, nodes must transmit data between each other, and as each block is accepted into the network and the block size grows, low performance nodes can struggle to keep up with the higher bandwidth requirements and suffer computational stress trying to verify all transactions. This can centralise the operation of full nodes to miners, who make up one of the only parties that have an incentive to operate full nodes.

If we can create a way to incentivise the operation of full nodes, we can avoid the aforementioned issues. This is one of the goals of Loki Service Nodes; to create a network of full nodes that are incentivised to hold and serve a full copy of the blockchain. These nodes must meet standards of service that are tested by a distributed method of flagging called Swarm Flagging. Because nodes are competing for a limited block reward and can be removed from the staking reward pool, they are always incentivised to serve copies of the blockchain to users and relay transactions.

Theoretically, this means that Loki can scale to handle much larger blocks and thus, handle a higher transaction throughput. This is predicated on the fact that the full nodes operating on the Loki network offer higher bandwidth/storage and compute performance than nodes on the Bitcoin or Monero network.

Instant Transactions with Blink

In a typical blockchain system, the confirmation time for any given transaction is the time it takes for a transaction to be included in a block. However, because of competing miners, withheld blocks, and Finney attacks, recipients usually require a number of additional blocks to be created on top of the block which holds a transaction before it is considered to be complete.[1] Depending on a multitude of factors specific to each blockchain, this process can take 10-60 minutes, which is inconvenient for merchants and customers who must wait for confirmations before they release goods or commence services.

Because of Loki’s Service Node architecture, near instant transactions are possible. Blink enables the same transactions that would occur on the Loki mainchain to be confirmed in seconds rather than minutes, assuring both the sender and the receiver of the validity of the transaction, and protecting the receiver against a double spend.

Blink works in a similar fashion to DASH’s InstantSend.[2] However unlike DASH’s InstantSend, Loki maintains all of its privacy properties throughout the process. Any third party looking at a Blink transaction will have no idea of the amount, nor the address of the sender and receiver. This opens up a range of new use cases for Loki, where face-to-face payments become increasingly practical and online payments become quicker and easier for users.

Stable and Formally Defined Funding Model

Funding models for cryptocurrencies are generally tricky, weak and informal, and donation only models can lead to the creation of special interest groups like blockstream, Bitcoin Unlimited and Bitcoin ABC. These groups typically act as for profit companies who drive an agenda that might not align with the community as a whole. The downside to most formally defined models is they act as a sort of tax, either through emissions or some kind of fee. This can be seen to take choice away from users as they are unable to allocate their funds to the projects they see as important.

Attempting to solve some of the aforementioned issues, Monero maintains a forum funding system, which is fully funded by a donations model. Projects vetted by the the Monero core team are featured on the Seeking Funding page, and users are free to donate Monero to projects they feel are worthy. The Monero core team also has an official donations wallet which often contributes large amounts of Monero to projects seeking funding. The advantage of the donations model is that users have full autonomy over how they spend their funds and what specific projects they support. However, there are also disadvantages to this model: funding is never guaranteed for high quality projects, and a large number of the projects receive about 1/5th of their donations from their ‘General Donations’ fund for Monero itself. The ability for a community like Monero to continue to self-fund and provide core contributions may decrease over time, and that’s something we want to avoid with Loki.

Loki’s long-term funding model is quite different from the donations model used by the cryptocurrencies mentioned above, and we think it will provide a significant advantage to consistent development, which will be in the interest of our users. Proposed in the whitepaper V3 is a revised governance block reward, which allocates 5% of each block reward to fund governance operations. Of this, 5% block reward 3.75% is controlled by the Loki Foundation, a registered Australian non-profit which is legally bound to spend the block reward as per its constitution.

“facilitating the development of an open source, highly secure, decentralised data

transmission network that allows individuals, business and government to freely

transact and communicate without the threat of malicious third party interference”

The other 1.25% is controlled by the Service Nodes through the Loki funding system. The Loki funding system is an entirely non-custodial system of proposal funding, meaning the Loki Foundation cannot control how its funds are allocated. Because Service Nodes are not bound by Australian law or a constitution, this greatly expands the range of proposals that can be funded. To distribute funds to proposals, Service Nodes vote on proposals that occur on-chain, and funding is allocated every two months via special funding blocks which pay a portion of their block reward to proposal addresses. Because Service Nodes represent players with a high stake in the Loki system, they are incentivised to vote on proposals which will increase the value of their stake.

Remote Node Availability

Due to the design of all CryptoNote coins, the blockchain cannot be easily queried by connection to a full node. Instead of simple queries being made for the balances of public keys, full nodes must transmit full blocks to users, and the user has to scan every transaction in the block and identify whether they can calculate the private spend key for the destination stealth address. This results in significant stress being placed on every remote node operator with no reward, and Monero and other Cryptonote coins therefore rely on the altruism of community members to fund these operations, which can be problematic.

It is common for mobile users in Monero to cycle through 3 or 4 remote nodes before connecting to one that is reliable. Additionally, as any user can become a remote node that serves blocks to the community, there is the possibility that “popular” remote nodes will provide an altered history of the blockchain. Though this altered history cannot be used to directly steal a user’s funds, in combination with other malicious attacks, a remote node could potentially convince a user to send funds twice to someone who has already received the transaction.

By rewarding Service Nodes, Loki creates a large, decentralised network of nodes with a full copy of the blockchain. These nodes are incentivised to serve copies of the blockchain to users and relay transaction. If a user chooses to connect to these nodes at random, ‘popular’ nodes are no longer an issue. This also balances the load of remote syncing across the whole network instead of onto a select few nodes.

Lokinet, SNApps and Highly Integrated Payments

Work is ongoing on Lokinet, which when fully launched will be a private, decentralised and Sybil resistant overlay network for the internet. You can read a detailed article about it here.

Anyone can host services on Lokinet, which will be called SNApps (Service Node Applications). With SNApps, any web developer will be able to host websites that are completely anonymous; the website owner won’t know the IP address of their visitors, and and the visitors won’t know the IP address of the website they connect to. All content hosted inside Lokinet will be accessible through the Loki browser.

The Loki browser will have an inbuilt wallet. Users will be able to fund this wallet with Loki, and the browser will automatically hook into SNApps that display Loki addresses for payments. This will make it very easy for a user to operate a store, or take or make payments for goods and services while maintaining anonymity between both networking and transactional layers. Lokinet will also have exit functionality, so any website operator who serves a website on the wider internet will be able to implement these hooks for users of the Loki browser to easily manage Loki payments.

In Summary

Loki’s value is derived not only from an inventive layer two, but also as a layer one transactional medium, or cryptocurrency. Although Loki is moving away from the use of $LOKI as simply an access token, there are still some significant advantages to $LOKI over other privacy based coins. Most of these advantages are a result of the widely distributed set of Sybil resistant nodes, called Service Nodes.  Due to Loki’s high scalability, Loki can handle a higher transaction throughput and offer higher bandwidth/storage and compute performance than nodes on the Bitcoin or Monero network. Leveraging Service Nodes, Loki can be sent near instantly and privately using Blink bringing instant new use-cases. Loki’s unique funding model provides strong governance and avoids the pitfalls and potential risks that donation-only models pose. Due to Loki’s incentivised Service Nodes, remote syncing loads are balanced across the whole network and the issues caused by ‘popular’ nodes are avoided. Layer one, coupled with an impressive layer two provides a whole suite of services to assist Loki users transact and communicate with absolute freedom.

[1]  “Irreversible Transactions – Bitcoin Wiki.” 15 Mar. 2018, Accessed 25 Apr. 2018.
[2] “Whitepaper · dashpay/dash Wiki · GitHub.” Accessed 27 Jul. 2018.

Weekly Dev Update #11

Testing, testing, testing! A Weekly Dev Update full of testing for y’all this week.
Service Nodes

LLARP / Lokinet
If you’re lucky and join our Discord, you might also catch Jeff or Ryan, the developers of LLARP, live streaming as they code: ,

  • Progress continues on Libllarp
    • Tuntap interfaces work
    • Multiplatform work (BSD, win32, gcc5)
    • CoDel improvements (requeue unprocessed items)
    • Update auto-gen config
    • Memory / IP helper utilities
    • Manual path rebuild
    • Make “Link Relay Commit” packet actually work
    • Make sessions hold paths between routers
    • Path refactor clean up
    • DHT queuing refactor
    • Additional unit tests
  • LokiBuilder updates
    • Submodule syncing
    • More public testnet RCs
    • Windows tun driver
    • Windows installer/uninstaller start
  • GitHub Pulse Stats for the last week: Excluding merges, 3 authors have pushed 55 commits to master and 55 commits to all branches. On master, 79 files have changed and there have been 2,101 additions and 764 deletions.
  • Most changes can be found at:
  • Current version: v0.0.3
  • Compile helper (include assets, initial seed routers and dependencies)

Architecture Team

  • Progress continues on exploration of Proof of Stake paper for Loki.
  • Will be re-releasing the economic paper as a archival document now that the proposal has been accepted by the community and it has been solidified in code.  


Weekly Dev Update #10

Hey everyone,

Big week of testnet changes this week

Service Nodes

0.3.3 Magic Mani tesnet beta, released

LLARP / Lokinet

If you’re lucky and join our Discord, you might catch Jeff or Ryan, the developers of LLARP, live streaming as they code: ,

  • Released LokiNET 0.0.3
    • Various incompatible protocol changes to propel the protocol forward, including SNTRUP, which strengthens the encryption against quantum-based attacks.
    • We urge all Lokinet toy node operators to upgrade ASAP as they’ll be unable to communicate as the network upgrades.
  • Progress continues on Libllarp
    • Use SNTRUP for introset public key
    • Moved netloop and logic into same thread
    • Hidden services should sorta work
    • More android/win32 fixes
    • Implement more tuntap code
    • Fix shadow/test net build
    • Fix RC nickname bug
    • Fix bug in prematurely closing socket under heavy load
    • Configuration/Defaults clean up
    • Hidden services now have a session
    • Move some of protocol handling into crypto thread
    • Intro timeout changed from 5s to 30s
  • LokiBuilder updates
    • llarpd => lokinet
    • Start Debian package support
  • GitHub Pulse Stats for the last week: Excluding merges, 2 authors have pushed 33 commits to master, and 33 commits to all branches. On master, 181 files have changed and there have been 8,181 additions and 1,583 deletions.
  • Most changes can be found at
  • Compile helper (include assets, initial seed routers and dependencies)

Architecture Team

  • Began writing a paper exploring block creation via Proof of Stake on Loki, findings will be presented as a proposal before the community and Loki Foundation.

Loki Locker

Loki Messenger


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!

Weekly Dev Update #9

Hey Y’all,

Some big things on the horizon for Loki, and a new dev update so we keep the community in the loop!

Service Nodes

LLARP / Lokinet

If you’re lucky and join our Discord, you might catch Jeff or Ryan, the developers of LLARP, live streaming as they code.

We want to give a special shout out to Despair, an open source contributor who has started porting Lokinet over to Windows (and improve BSD support).

  • Progress continues on Libllarp
    • Protocol updates, hidden service progress and DHT improvements
    • INI writer can now write to an existing INI file and preserve comments
    • Reorganise threading, logic and netio now run in the same thread
    • Fix epoll/kqueue tick logic, add timeouts for kqueue
    • Buffer bit function refactor, also allow aligned buffers to be filled with random data
    • Private IP range 172 accuracy improvements
      • Multiplatform work:
      • Per platform building instructions now in README
      • Android: Fixed headers
      • MacOS: Make pthread CMakeList more favorable to XCode
      • Windows: initial port (requires Windows NT 5.0+)
      • Shared Library and FFI fixes
    • Don’t put private addresses into RCs, allow nicknames and don’t store non-public RCs in nodedb
    • Nodedb now only loads .signed files
    • Deterministic logging and builds
  • DNS library
    • A couple refactor clean up passes
    • Newer hook interface to make .loki handling easier
    • Better packet parser, support SOA response parsing
    • Actually sends NXDOMAIN if not found
    • Handle multiple responses to already answered packets more gracefully
  • GitHub Pulse Stats for the last week: Excluding merges, 4 authors have pushed 50 commits to master and 47 commits to all branches. On master, 100 files have changed and there have been 5,120 additions and 1,116 deletions.
  • Most changes can be found at
  • Current version: v0.0.2
  • Compile helper (include assets and dependencies)

Loki Locker

Loki Locker will be Loki’s version of MyMonero. A web based wallet you can use to store your Loki. Work has kicked off as a fork of OpenMonero. This should be ready for release quite soon, giving the community another way to store their Loki.

  • Work has continued on the visual redesign of Open Monero you can see a teaser of the visual design here.
  • Worked on Integrated QR code scanning, and a new interface for transactions.

We also just got our third pull request merged back into Monero, and we’re aiming for our fourth to be IPV6 support to be PR’ed soon.