Katalyst – Proof of Loyalty v 0.1

License of White Paper



Present Problems & Needs

Blockchain technology rewards community participation via issuing its own tokens. For example Bitcoin rewards the miners 12.5 Bitcoins for implementing the proof-of-work (PoW) consensus algorithm – in the process, securing the Bitcoin transactions.

A proof-of-work (PoW) system (or protocol, or function) is an economic measure to deter denial of service attacks and other service abuses such as spam on a network by requiring some work from the service requester, usually meaning processing time by a computer. For doing that work, the service requester is rewarded with crypto tokens as a result.

In the case of Bitcoin, the “work” is to find a hash with leading zeros – traditionally referred to as mining. After doing that, the “worker” would be rewarded with 12.5 BTC.

Already in the last few years, there has been evolution of 1 other protocol. The proof-of-stake (PoS) protocol has been used in Waves, Peercoin, Dash, PIVX Coin or Bitshares. Very soon, it would be implemented for Ethereum as well.

Proof-of-stake (PoS) is a type of algorithm by which a cryptocurrency blockchain network aims to achieve distributed consensus. In PoS-based cryptocurrencies the creator of the next block is chosen via various combinations of random selection and wealth or age (i.e. the stake).

Proof-of-stake has its own criticism as well, including the criticism of centralization. That is the user with the most tokens can control the whole network. It is basically against the spirit of decentralization.

The other problem is the “nothing at stake” problem, where (in the case of a consensus failure) block-generators have nothing to lose by voting for multiple blockchain-histories, which prevents the consensus from ever resolving. Because there is little cost in working on several chains (unlike in proof-of-work systems), anyone can abuse this problem to attempt to double-spend (in case of blockchain reorganization) “for free”.

Putting the inherent flaws aside, there is still an issue that conventional proof-of-work does not define an economic measure other than the traditional economic measure of computing hashes being expensive (in time & money).

While the conventional bitcoin proof-of-work (PoW) and proof-of-stake (PoS) protocols have given rise to the whole blockchain revolution, there are further protocols / methods we can define to further reflect the economic measure.

Proof of Loyalty

Here comes proof-of-loyalty (PoL). Proof-of-loyalty mainly combines 3 mechanisms;

  1. Proof-of-work (PoW)
  2. Proof-of-stake (PoS)
  3. Proof-of-time/age (PoT)

We would have a special focus and innovation of what constitutes work in the proof-of-work (PoW).

In the context of various blockchain platform, “work” can constitute the following activities;

  1. Increasing awareness of blockchain platform
  2. Eliminating foul play
  3. Voting / contributing to blockchain platform.
  4. Getting more users to use platform
  5. Getting merchants as service providers
  6. Serving as off-chain loyalty-explorer.
    See next section for technical requirement

These economic activities are inherently useful for the blockchain platform more than just providing hashing capabilities.

To continue on the tradition of transparency and decentralization spirit of blockchain, there is a need for a blockchain explorer to audit and keep transparent the economic activities that are recorded that form the basis of token distribution.

For most blockchain platforms, there is little allowance for data you can put within a single blockchain transaction that allows you to keep track of of the economic activities to be recorded for the purpose of rewards disbursements of tokens.

There is a need for an off-chain explorer that allows greater amount of data to be recorded.

Off Chain Proof of Loyalty Blockchain Explorer

The Waves blockchain transaction only allows the attachment of data of 140 characters. Barely enough to contain any meaningful indication of what economic activities have been carried out during that block time.

However, 140 characters is sufficient to store a sha256 hash.

For example, this proof of loyalty explorer containing the following data;

Fan ID Activity Media identifier
fan1 Reading id1
fan2 Sharing media id2
fan1 Online node nil
fan3 Install Wallet nil
fan2 Online node nil

Equivalent sha256 hash :


Hashing case study generated from


Formatting the text as follows;

fan1, Reading,id1
fan2, Sharing media,id2
fan1, Online node,nil
fan3, Install Wallet,nil
fan2, Online node,nil

To leverage on the waves blockchain (although the principles here are applicable to any blockchain platform that allows the recording of data on a per blockchain transaction standpoint) to record this proof-of-loyalty economic activities.

You can designate a waves address, for example;


Technically, this waves address can be any other waves address designated for each specific token representing a specific blockchain platform intending to leverage on proof-of-loyalty.

Without the quotes.

The off-chain Proof of Loyalty chain would be kept as decentralised records by willing provider of that disk space, bandwidth and also web / network services.

The Off-chain Proof of Loyalty Blockchain Explorer would access this record via a pointer as follows;


Which would of course display this record;

Fan ID Activity media Identifier
fan1 Reading id1
fan2 Sharing media id2
fan1 Online node nil
fan3 Install Wallet nil
fan2 Online node nil

At the end of displaying that record a sha256 hash would be generated for the above mentioned record. Which is in this case;


This generated hash is then compared to the hash recorded on the waves blockchain. If the hash matches, then the off chain proof-of-loyalty (PoL) blockchain explorer display the right record and that record has never been modified or tampered with before.

Implementing this way allows the implementation of proof-of-loyalty by leveraging on the strong protection afforded by an underlying blockchain platform. Although waves is denoted as an example in this white paper, this principle should be cross applicable in all blockchain platforms.

As far as as theoretical flaws of this method, the only potential criticism is hash collision. That is, 2 totally different record of economic activities producing the same hash. In the first ever [1] cryptographic hash collision of SHA-1, it would take 6,610 processor time, and SHA256 would take exponentially longer time than that. If utilizing longer hashes like SHA512m, would mean that the computing needed to repeat a collision is in the order of millions if not billions of years. In fact, it is probably multiple orders of magnitude greater than billions of years.

Disbursing Rewards

After having an untamperable and public record of proof-of-loyalty, you may implement a reward disbursing algorithm no different from the bitcoin block reward of 50 BTC, 25 BTC, 12.5 BTC. However, the rewarding algorithm may not necessarily follow the methodology of Bitcoin – it should start with a certain criteria and change only after the consensus is achieved for the purpose of changing the rewarding algorithm.

In the above mentioned example, assuming we determine the following criteria;

  1. Total of 50 OToken to be disbursed every block
  2. 3 OToken is to be rewarded to everyone who has an online node.
  3. 10 OToken to be rewarded to everyone who is reading the updates.
  4. 20 OToken to be rewarded to everyone who is sharing the updates.
  5. Balance is to reward to users who have helped another person install the wallet in the blockchain platform.

The disbursing of rewards shall be executed block by block but depending on volume, the disbursing may be done 1 time per hour, per 6 hour, or per 12 hour.  All such disbursing shall be posted on the proof-of-loyalty off-chain, with hash posted to the waves blockchain to ensure that the disbursing of rewards is not tamperable and also at the same time a public record.


[1] ‘First ever’ SHA-1 hash collision calculated. All it took were five clever brains… and 6,610 years of processor time https://www.theregister.co.uk/2017/02/23/google_first_sha1_collision/



Leave a Reply