Author’s Note—April 2023

In late 2017, I was hired by the Komodo Platform, a startup company that uses Bitcoin-based technology for various consumer-oriented products.

Within a few weeks of my hiring date, I received the task to map out the entire company project in written form. The goal was to create a master narrative, as it were, that would allow the team and users to work together under a more unified directive.

The resulting ninety-three page documentation was well received by both the Komodo developers and the user base. The administrators decided to use my work as the company’s foundational whitepaper.

The document was originally finished in 2018, but over the course of the years I worked at Komodo, it was also adapted into several different forms to serve a variety of purposes.

The content presented below is the most recent version that I can find. The date it was created appears to be around March 2020.

This version of the whitepaper was included in a section of the Komodo website that was intended to help users who were comfortable with the C/C++ programming languages, but new to Komodo and fairly new to blockchain technology.

For Select Excerpts, Please See My Technical Writing Portfolio

If you would prefer to read only a few highlights, turn to the Technical Writing section of my portfolio. There are several key moments that can give you an idea, without needing to read all ninety-three pages.

A Note on Broken Hyperlinks

The links provided in this documentation are for display purposes only. They are relative to the website where the documentation was originally housed.

In ripping the documentation out of its home website and displaying it here as a blog post, the links no longer function. I am leaving them because they provide context and meaning to the discussion, even though they no longer work.

Thank you for reading. As always, if you have questions, please reach out to me at golden@bluesanta.io

Introduction

---

Advanced Blockchain Technology, Focused On Freedom

---

The Komodo project focuses on empowering users with Freedom through blockchain technology. There are many forms of Freedom that Komodo can provide, and we currently focus on empowering two types of users: the blockchain entrepreneur, and the average cryptocurrency investor. Together, our community of entrepreneurs, investors, and other users form an economic ecosystem.

The foundational pillar of the Komodo ecosystem is security. Komodo provides a unique and innovative form of security that is as strong as the Bitcoin network, yet does not require the incredible cost. Every member of the Komodo ecosystem receives the benefits of this security. The investor relies on it for everyday use. The entrepreneur relies on it to protect their blockchain innovation at a cost that is affordable even to small businesses and startups.

Another of Komodo’s powerful technologies is a new method of trading cryptocurrencies directly from one person to another. It is a new kind of “decentralized exchange.” Our decentralized exchange removes all forms of middlemen, vouchers, and escrow services. It relies on an underlying concept called the “atomic swap”, and we are the leaders in this technology.

Our atomic-swap powered decentralized exchange serves both the investor and the blockchain entrepreneur.

For the investor, they can trade cryptocurrencies without having to pass through a centralized exchange, which can be an arduous and even dangerous process. They also do not have to use an escrow service, voucher, nor even an intermediary coin—not even Bitcoin. Furthermore, there is no registration process required, nor are there any withdrawal limits. We currently support approximately 95% of the cryptocurrencies in existence, including Bitcoin-protocol based coins, Ethereum, and Ethereum-based ERC20 tokens.

For the entrepreneur, our decentralized exchange enables the release of new products to the world without middleman involvement. Furthermore, even entrepreneurs who have previously built other blockchain projects outside our ecosystem can easily feature their coin on our decentralized exchange. The only requirement is that the blockchain product have the proper security elements in the core of the blockchain’s code.

Komodo also has powerful privacy features built into our platform. When activated, these features allow the investor to trade and purchase goods and services within their right to privacy. This also allows the entrepreneur to release their product, and to crowdsource funds, from an audience that may prefer to maintain this privacy.

There are many other technologies and features in the Komodo ecosystem, and we are experiencing a rapid growth of both entrepreneurs and investors.

The documentation in the Core Technology Discussion section provides an in-depth discussion about Komodo’s unique security features, our decentralized exchange, the method of releasing new products on it, and our native privacy features.

We welcome feedback from our readers. If you have any questions or concerns over the course of reading this material, please reach out to our team directly. You may find our contact information on our accompanying website: https://komodoplatform.com

Note on Changes Since Whitepaper Creation (cr. 2019)

The documentation in this section is based on the Komodo whitepaper that was written in 2017. The content was updated in July 2019 to ensure technical accuracy. We recommend that all newcomers read this documentation to enhance their understanding of the nature and design of Komodo.

Since 2017, the Komodo team has greatly advanced the technologies on the Komodo Platform, and these new technologies are discussed in other areas of the technical-documentation website.

Also, zero-knowledge transactions are still available on Komodo-based blockchains, but they are no longer available on the KMD main chain. This change was made largely in response to community feedback and industry developments.

Delayed Proof of Work

A Foundational Discussion of Blockchain Security

Komodo’s form of providing security is called Delayed Proof of Work technology (dPoW). It builds on the most advanced form of blockchain security in existence, Proof of Work technology (PoW). The latter form of security is the method that the Bitcoin network utilizes.

To understand the value of Komodo’s dPoW security, we must first explain how PoW works and why it is the most secure method of maintaining a decentralized blockchain. We must also examine PoW’s shortcomings, so that we may understand the need for Komodo’s dPoW method and the advantages it provides to the blockchain community.

To understand how PoW technology functions, we begin by explaining the roots that make the Bitcoin protocol a viable means of securely transferring value.

What Is A Consensus Mechanism?

The “Double Spend” Problem

The creation of blockchain technology stems from the early mathematical studies of encryption using computer technology.

One such example is related to the information-encoding device, “Enigma,” invented by the Germans at the end of World War I. Alan Turing, a British Intelligence agent, famously beat the Enigma device by inventing the world’s first “digital computer.” This provided enough computing power to break Enigma’s encryption and discover German secret communications.

This early affair with encryption set off a race throughout the world to develop myriad forms of securely transferring information from one party to another via computer technology. While each new form of computer encryption provided more advantages, there remained one problem that prevented encryption from being useful as a means of transferring not just information, but also financial value.

This challenge is known as the “Double Spend” problem. The issue lies in the ability of computers to endlessly duplicate information. In the case of financial value, there are three important things to record: who owns a specific value; the time at which the person owns this value; the wallet address in which the value resides. When transferring financial value from one person to another, it is essential that if Person A sends money to Person B, Person A should not be able to duplicate the same money and send it again to Person C.

The Bitcoin protocol, invented by an anonymous person (or persons) claiming the name of Satoshi Nakamoto, solved the Double Spend problem. The underlying math and computer code is both highly complex and innovative. For the purposes of this paper we need only focus on the one aspect of the Bitcoin protocol that solves the Double Spend problem: the consensus mechanism.

The Consensus Mechanism Provides Security Against a “Double Spend”

The consensus mechanism created by Nakamoto is perhaps one of the most powerful innovations of the twenty-first century. His invention allows individual devices to work together, using high levels of encryption, to securely and accurately track ownership of digital value (be it financial resources, digital real estate, etc.). It performs this in a manner that does not allow anyone on the same network (i.e. the Internet) to spend the same value twice.

Let us suppose a user, Alice, indicates in her digital wallet that she wants to send cryptocurrency money to a friend. Alice’s computer now gathers several pieces of information, including any necessary permissions and passwords, the amount that Alice wants to spend, and the receiving address of her friend’s wallet. All this information is gathered into a collection of data, called a “transaction,” and Alice’s device sends the transaction to the Internet.

There are several types of devices that will interact with Alice’s transaction. These devices will share the transaction information with other devices supporting the cryptocurrency network. For this discussion, we need only focus on one type of device: a cryptocurrency miner.

Note: The following descriptions are simplified explanations of a truly complex process. There are many other strategies cryptocurrency miners devise to out-mine their competition, and those strategies can vary widely.

A Miner Competes to Add Blocks to the Network’s History, in Exchange for a Reward

Step One: Preparing the Preliminary Information

This cryptocurrency “mining” computer captures Alice’s raw transaction data. Typically, this mining device is owned by a tech-savvy miner. In this discussion, we name him Bob.

Bob wants to add Alice’s transaction to the permanent history of the Bitcoin network. If Bob is the first person to properly process Alice’s transaction he will receive a financial reward. One key part of this reward is a percentage-based fee, taken from Alice’s total transaction amount.

The Mempool is the Collection of All Raw Transactions Waiting to be Processed

Furthermore, Bob does not have just one transaction alone to mine. Rather, he has an entire pool of raw transactions, created by many people across the Internet. The raw data for each of these transactions sits in the local memory bank of each miner’s mining device, awaiting the miner’s commands. Miners call this pool of transactions, the “mempool.” Most miners have automated systems to determine the transaction-selection process, based on estimated profit.

Creating Transaction Hashes

After Bob makes his choices about which transactions he will attempt to mine (and we assume that he includes Alice’s transaction), Bob’s mining device then begins a series of calculations.

His device will first take each individual transaction’s raw data and use mathematical formulas to compress the transaction into a smaller, more manageable form. This new form is called a “transaction hash.” For instance, Alice’s transaction hash could look like this:

b1fea52486ce0c62bb442b530a3f0132b826c74e473d1f2c220bfa78111c5082

Bob will prepare potentially hundreds of transaction hashes before proceeding to the next step. One important thing to understand about the compression of data in the Bitcoin protocol, including the transaction hash above, is that calculations herein obey a principle called, The Cascade Effect.

The Cascade Effect: Changing One Bit of Data Changes the Entire Result

The Cascade Effect simply means that were Bob to attempt to change even the smallest bit in the raw data—whether from a desire to cheat, or by mistake, or for any other reason—the entire transaction hash would dramatically change. In this way, the mathematical formulas in the Bitcoin protocol ensure that Bob cannot create an improper history.

Were Bob to attempt to create an incorrect transaction hash, other miners on the network could use the raw transaction data from Alice, perform the proper mathematical formulas in the Bitcoin protocol, and immediately discover that Bob’s hashes are incorrect. Thus, all the devices on the network would reject Bob’s incorrect attempts and prevent him from claiming rewards.

Step One Continued: Finishing the Preliminary Calculations

Now, using more mathematical formulas, Bob takes the transaction hashes he is attempting to process and compresses them into a new manageable piece of data.

This is called, “the merkle root.” It represents all the transactions that Bob hopes to process, and from which he hopes to gain a reward. Bob’s merkle root could look like this:

7dac2c5666815c17a3b36427de37bb9d2e2c5ccec3f8633eb91a4205cb4c10ff

Finally, Bob will gather information provided from the last miner that successfully added to the permanent blockchain history. This information is called, “the block header.” It contains a large amount of complex data, and we won’t go into all the details. The one important element to note is that the block header gives Bob clues about how to properly add the next piece of information to the permanent Bitcoin history. One of these hints could look like this:

"difficulty" : 1.00000000

We will return to this clue further on.

Having all this information, Bob is nearly prepared. His next step is where the real challenge begins.

Step Two: The Race to Finish First

Bob’s computer is going to gather all the above information and collect it into a set of data called a “block.” Mining this block and adding it to the list of blocks that came before is the process of creating a “chain” of blocks—hence the industry title, “blockchain.”

However, adding blocks to the blockchain is not so easy. While Bob may have everything up to this point correctly prepared, the Bitcoin protocol does not yet give Bob the right to add his proposed block to the chain.

The consensus mechanism is designed to force the miners to compete for this right. By requiring the miners to work for the right to mine a new valid block, competition spreads across the network. This provides many benefits, including time for the transactions of users (like Alice) to disseminate around the world, thus providing a level of decentralization to the network.

Therefore, although Bob would prefer to immediately create a new valid block and collect his reward, he cannot. He must win the competition by performing the proper work first. This is the source of the title of the Bitcoin-protocol consensus mechanism, “Proof of Work” (PoW).

The competition that Bob must win is to be the first person to find an answer to a simple mathematical puzzle, designed by Satoshi Nakamoto. To solve the puzzle, Bob guesses at random numbers until he discovers a correct number. The correct number is determined by the internal complex formulas of the consensus mechanism and cannot be discovered by any means other than guessing. Bitcoin miners call this number a “nonce,” which is short for “a ‘number’ you use ‘once.’”

Bob’s mining device will make random guesses at the nonce, one after another, until a correct nonce is found. With each attempt, Bob will first insert the proposed nonce into the rest of his block. To find out if his guess is correct, he will next use mathematical formulas (like those he used earlier) to compress his attempt into a “block hash.” A block hash is a small and manageable form of data that represents the entire history of the Bitcoin blockchain and all the information in Bob’s proposed block. A block hash can look like this:

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

Recall now The Cascade Effect, and how it states that changing one small number in the data before performing the mathematical computations creates a vastly different outcome. Since Bob is continually including new guesses at the nonce with each computation of a block hash, each block-hash attempt will produce a widely different sequence of numbers. Miners on the Bitcoin network know when a miner, such as Bob, solves the puzzle; by observing the clues that were provided earlier. Recall that the last time a miner successfully added data to the blockchain, they provided these clues in their block header. One of the clues from the previous block header can look like this:

"difficulty" : 1.00000000

This detail, “difficulty,” simply tells miners how many zeros should be at the front of the next valid block hash. When the difficulty setting is the level displayed above, it tells miners that there should be exactly ten zeros. Observe Bob’s attempted block hash once again, which he created after making a guess at a nonce, adding this proposed nonce into his block, and performing the mathematical formulas:

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

The block hash above has ten zeros at the beginning, which matches the number of zeros in the difficulty level. Therefore, the hash that Bob proposed is correct. This must mean that he guessed a correct nonce. All the miners on the network can prove for themselves that Bob was correct by taking all the same information from their mempools, adding Bob’s nonce, and performing the mathematical calculations. They will receive the same result, and therefore Bob is the winner of this round.

On the other hand, due to the Cascade Effect, if Bob’s attempted nonce had produced a block hash with the incorrect number of zeros at the front, his block hash would be invalid. The network would not afford him the right to add an incorrect block hash to the network, and all the miners would continue searching.

Step Three: Bob Finds the Nonce

Once a miner discovers a nonce that produces a valid block hash, the miner has “found a new block,” and can send the signal across the Internet. The consensus mechanism running on every other mining device can verify for themselves the calculations. Once verified, the consensus mechanism grants the miner the right both to add the proposed block to the blockchain, and to receive the reward.

Let us return to Bob’s machine, having just guessed a correct nonce, and thus holding a valid block hash. Bob’s machine instantly sends out the winning information across the Internet, and Bob collects his reward from the Bitcoin network. All the other miners must readjust. Earlier, they were searching for the correct nonce based off the information from the previous block header. However, Bob’s new valid block includes a new block header. All the other miners on the network abandon their current work, adopt Bob’s new block header, make many recalculations in their underlying data, and begin their search for the next nonce.

There is no sympathy in the Bitcoin protocol for any miner’s wasted efforts. Suppose another machine on the network was also trying to mine Alice’s transaction, and lost to Bob in the race. Only Bob earns the reward from Alice’s transaction, and the other miner receives nothing in return for their costs and time.

For Alice, this process seems simple. She first indicated the wallet address of her friend and sent cryptocurrency. After a certain amount of time, her friend received the money. Alice can ignore the byzantine process of the miners that occurred between these two events. Alice may not realize it, but the PoW consensus mechanism provides the foundation of security upon which she relies.

The Dominance of the Proof-of-Work Consensus Mechanism

Proof of Work (PoW) Fosters Ever Increasing Security

There are several reasons why PoW networks, especially Bitcoin, continue to dominate in terms of security and blockchain success.

A simple, preliminary reason is that PoW networks foster ever-increasing speed and computer power. Miners must constantly update and innovate above their competitors to continue earning rewards.

Speed and Power are of the Essence

Among miners, having a faster and more powerful computer can mean earning rewards more frequently. For miners seeking to maximize profit, competition requires constant upgrades to machinery and to a miner’s customized underlying code.

The frequency at which a device can create proposed block hashes is called “hash power.” The more hash power a collective PoW network has across all miners mining the blockchain, the more secure the network. This competitive pressure provides one important advantage in security to PoW networks, when compared to alternate consensus mechanisms.

The Network Effect: Bitcoin’s Ability to Dominate Begins

A high level of security fosters a sense of trust among users, and this can grow a PoW network’s audience. As the audience grows, both the number of transactions and the price of the coin increase. This attracts more miners. The rising level of miners provides greater overall hash rate to the network, which in turn fosters a stronger sense of trust. This increased sense of security can raise the number of users on the network, which can increase the number of miners, and the cycle repeats.

In economics, this is classified as a “Network Effect,” where a cycle of behavior encourages more of the same behavior, with compounding interest. Due to the Network Effect, and the fact that Bitcoin is the oldest PoW network, Bitcoin is increasing its security at a rate faster than the rate of other PoW networks.

Furthermore, consider the effect caused when the price of a PoW-blockchain coin rises. Before the rise, assume the blockchain coin is worth one dollar. A miner is justified in spending the necessary money (on equipment, upgrades, and electrical costs, etc.) to justify one dollar’s worth of hash rate. If the price shifts upwards to two dollars, the miner must upgrade their entire business to justify two dollars’ worth of a matching hash rate. If the miner does not upgrade, their competitor will, and then the miner will no longer be able to compete for rewards.

The Longest Chain Rule: The True “Secret Sauce” of Pow Domination

There are many more reasons why PoW networks continue to dominate in security. Yet, for our discussion, there is one element that rises above all others. It is called, “The Longest Chain Rule,” and some blockchain developers argue that it is “the secret sauce” that fuels PoW’s strength.

The Longest Chain Rule is the determining factor whenever two competing versions of the blockchain history arise on the network. The rule simply states that whichever of the two versions grows longer first, wins. The other version is overwritten, and therefore all transactions and rewards on that version are erased. The simplicity of this rule is a key to understanding why PoW consensus mechanisms continue to outperform their competition.

The Simple Effects of The Longest Chain Rule

On a surface level, this rule prevents a double spend by a network user. For instance, consider a husband and wife accidentally attempting to spend the same money at the exact same time, while each person is traveling in a different part of the world.

Note: For the sake of the discussion, we are oversimplifying the following actions so that they take place within only a few milliseconds. We also oversimplify the technical details, for clarity. The full explanation of this process is provided in the Bitcoin wiki, for those who would like to gain a deeper understanding.

A Tale of Two Blockchains

Let us suppose that the husband is in Asia and the wife is in the Americas. Both are purchasing a car. The husband uses all the funds from the family Bitcoin wallet to purchase a car at precisely 8:00 PM (UTC). The wife makes her purchase at the exact same moment, for a similar amount.

After making his purchase, the husband’s transaction hash is immediately sent to a mining device in China, where it is held in the miner’s local mempool (recall that a mempool is a collection of all raw transaction data across the network).

Let us suppose that the husband’s transaction arrives in the Chinese miner’s mempool at the exact moment that the Chinese mining equipment finds a correct nonce and a valid block hash. The Chinese miner declares the winning information, mines a new block, and collects a reward. All the miners in his local (Asian) vicinity (who receive the winning information faster than in the Americas, due to proximity) complete the block verification process, increase the length of the blockchain, and begin searching for the next valid block hash.

On the opposite side of the world, essentially the exact same actions happen. The wife’s transaction is sent to the nearest miner, this time located in Washington state of the United States. Just as the transaction enters the Washington state miner’s mempool, the miner discovers a valid block hash. He sends out the signal, mines a new block, and also collects the reward (this is the same reward that the Chinese miner is attempting to claim). All the miners in the local (US) vicinity verify the information immediately and begin searching for a new valid block hash based on the Washington state miner’s recent block.

An Internal Conflict of Interest Arises Within the Bitcoin Network

Note the paradox here. There are now two versions of the Bitcoin history that are valid, yet different.

These two versions make their way across the Internet, around the world, each to the other side. When the competing messages arrive, the Bitcoin protocol sees that there is a conflict: the same money was spent twice.

Consider how on each side of the world the miners are spending their financial and temporal resources to further their own interests. There is no economic incentive for either side to submit to the other, by nature. Therefore, there is a conflict of interest within the Bitcoin network itself. The Bitcoin network would swiftly fail, were it not for The Longest Chain Rule.

The Longest Chain Rule: The History Which is Longer First, Wins

The Longest Chain Rule simply declares that whichever of the two competing blockchains grows longer first, wins. The consensus mechanism erases the other version.

Let us suppose that the Chinese mining equipment is superior in this instance, and the Chinese miner manages to discover the next valid block hash and send out the signal before the Washington state miner can do likewise. Across the world, the moment the information arrives that the Chinese miner completed yet another valid block, the Bitcoin protocol erases the Washington state miner’s version of the Bitcoin history.

There is no sympathy for any wasted efforts, nor for any misunderstandings between the wife and her car dealer. The Bitcoin protocol’s consensus mechanism simply presses forward. The Washington state miner’s rewards disappear, as though they never occurred. The wife’s purchase of a car likewise evaporates.

(Typically, a normal and prepared car dealer utilizing cryptocurrency would not consider a customer’s transactions acceptable until several new blocks were added to the blockchain. In this manner, cryptocurrency users can ensure that a transaction is beyond contestation before the customer can, for example, drive a new car off the lot.)

The Washington state miner gets a raw deal in this scenario, but the network benefits as a whole. The Longest Chain Rule provides the necessary security to prevent a Double Spend. The network accurately recorded one family member’s purchase of a car, prevented the mistaken double spend, and ensured that the most competitive miner received a just reward.

This example illuminates the importance of The Longest Chain Rule. However, there is a dark side to this rule for the unsuspecting and unprepared blockchain developer.

The 51% Attack

Here’s where intrigue enters the picture. The “easiest” way to steal money on a PoW blockchain (such as Bitcoin) is to perform a 51% Attack.

In this attack, the malicious actor first spends cryptocurrency in exchange for something of value, which they take from their victim. Next, the malicious actor creates an alternate version of the PoW network’s history wherein those transactions never took place. Using advanced mining equipment, the malicious actor then “attacks” the PoW network by mining blocks to this “false” history faster than the rate at which other miners on the PoW network can mine blocks to the “true” history.

Assuming the malicious actor has a sufficient hash rate, as this “false” history grows longer than the “true” history, the Longest Chain Rule will cause the consensus mechanism to overwrite the “true” version. The earlier transactions the malicious actor made would be as though they never occurred. Therefore, the malicious actor would keep both their original funds and whatever item of value they exacted from their victim.

This is known as the 51% Attack. The number 51% derives from the fact that to successfully perform this attack, the attacker must add enough hashing power to the overall PoW network to form a majority of the hash rate.

Size is Yet Another Reason Behind Bitcoin’s Current Success Among PoW Networks

Today, Bitcoin’s overall hash rate is enormous. The collective of computers around the world mining Bitcoin is effectively the largest supercomputer ever created by man. As of the writing of this paper, some estimate that the Bitcoin network consumes more electricity than the entire country of Denmark, and the number of miners continues to grow.

Therefore, to attempt a 51% Attack against the Bitcoin network could cost millions, if not billions of dollars in computer hardware. It would also require a sustained consumption of electricity that is likely unfeasible for a single geographical location, and would be expensive even for a decentralized-hardware network. So long as the miners of Bitcoin remain interested in the Bitcoin network, therefore, Bitcoin has a level of security that is nigh impenetrable.

We will return to the proposition of the miners’ ability to choose a different network to mine later in our discussion.

The Genesis Attack

A Genesis Attack on the Bitcoin Network

Recall that according to the original version of the Bitcoin protocol, sometimes called the “vanilla” version, the Longest Chain Rule only requires that the blocks in the longest chain all be properly mined. Furthermore, recall that computers can endlessly duplicate code.

Finally, note that during our explanation, when describing a malicious actor’s attempt to create an empty, meaningless blockchain history, we use quotation marks when employing the word, “false.” Likewise, when describing the blockchain history trusted by the people on the network, we include the word “true” in quotations.

We do this because at the core level, the consensus mechanism is purposefully blind regarding any human user’s preference between “true” and “false.” The code only sees “truth” in terms of properly mined blocks, and overall blockchain length. Nothing more.

Now suppose the existence of a supercomputer a thousand times more powerful than the entirety of the Bitcoin-miner network. This supercomputer could, in theory, stealthily re-create and execute the initial code that spawned the very first block of the Bitcoin blockchain—the “Genesis Block.” The supercomputer could then grind out block hashes, one-by-one, mining meaningless blocks and adding them to this empty, “false” version of the Bitcoin history.

Once this meaningless blockchain’s length sufficiently exceed the so-called “true” blockchain used today, the supercomputer could then release its “false” version to the Internet.

Throughout the world, (assuming the vanilla protocol) the Bitcoin network would automatically recognize the “false” blockchain as the correct blockchain! This would all be according to the code. The so-called “false” blocks would be properly mined, and the length would be longer than the chain that users currently trust. The vanilla protocol would, in theory, replace the so-called “true” history with the empty variant.

It might seem to users like a virus being uploaded to the Internet. It could destroy all human trust in the current version of the Bitcoin protocol, wreaking financial havoc throughout the cryptocurrency realm. While users of the Bitcoin protocol would naturally protest, the entire operation would be entirely in agreement with the underlying code.

When observing Bitcoin’s current hash power, the creation of such an anti-Bitcoin supercomputer is clearly not feasible in the immediate future. Assuming Bitcoin miners remain interested in the Bitcoin network, the risk of a Genesis Attack on Bitcoin is essentially non-existent.

However, consider the implications of the Genesis Attack on unsuspecting or underprepared smaller PoW blockchain projects.

The More Realistic Dangers of The Genesis Attack

Let us assume a naïve blockchain entrepreneur building a new product. They are generally aware that malicious actors throughout the world are likely to attack their blockchain, stealing funds and otherwise causing trouble. Therefore, the naïve entrepreneur decides to implement what they believe is the most secure method of a blockchain consensus mechanism, PoW, and they offer ample financial rewards to miners to incentivize a secure network.

The entrepreneur and their entire audience may not realize it, but so long as their network’s overall hash rate remains below the threshold of an attack by even an average supercomputer, their entire blockchain history is vulnerable to complete annihilation. A technically astute competitor, seeing the vulnerability, and possessing ownership of the requisite computer hardware, would be able to create an empty and longer version of the same blockchain code and vaporize the blockchain’s financial records.

The cryptocurrency industry is young, and few but the most advanced of developers understand the many ways in which blockchain competition can be technically eliminated. Therefore, we have seen but a few serious cases of the Genesis Attack.

One notable instance occurred when an original Bitcoin developer, Luke-jr, used a variation of the attack to destroy a blockchain project called Coiledcoin. Luke-jr performed this attack out of a belief that Coiledcoin was a disingenuous project. Setting aside any human sentiment on either side of the event, the fact stands that Luke-jr’s variation of the Genesis Attack was the end of the Coiledcoin network.

The complexity in establishing a secure PoW blockchain remains a challenge for would-be entrepreneurs. Furthermore, there are existing PoW developers that are not fully aware of their vulnerability. Likewise, there are would-be malicious actors that have yet to realize the many methods available to cause frustration. The potential danger surrounding the issue of the Genesis Attack shows the relative youthfulness of the cryptocurrency industry.

For a PoW blockchain network to maintain Bitcoin-level security, therefore, it must maintain a hash rate that is high enough to constantly mine blocks faster than a potential competitor could either perform the 51% Attack (destroying the most recent of transactions), or the deadly Genesis Attack (complete annihilation).

The Financial and Eco-Unfriendly Problems With All PoW Networks

The problems with young PoW networks do not stop there, and furthermore, even Bitcoin’s PoW network has issues: the security of a PoW network comes at a high cost to the environment, and miners have no obligation to mine any particular network.

PoW Networks Are Expensive

Some estimate that by 2020, the Bitcoin network alone will consume more electricity than the entire world currently consumes (as of 2017.) Having just one PoW network in existence, therefore, is already strain enough on our environment. It is also a burden on our infrastructure and our worldwide economy.

On the one hand, adding additional PoW blockchains to the world can serve the purpose of forcing free-market competition on the Bitcoin developers, encouraging ethical and innovative behavior. Therefore, some competition among PoW networks is likely useful.

However, as a human species, we can consider that there are more financially sound and eco-friendly methods of innovating with blockchain technology without always directly competing with Bitcoin PoW security. Our innovation, delayed Proof of Work, is one response to this fact, as we will soon discuss.

Miners are Free to Mine Other Networks

Another inherent weakness of the PoW consensus mechanism to discuss is the ability of miners to choose alternate networks.

In November of 2017, for a few hours the majority of Bitcoin network miners switched their hash power to a competitor’s PoW network, the “Bitcoin Cash” network. This switch was the result of clever software engineering on the part of the Bitcoin Cash team.

The team recognized that most miners on the Bitcoin network choose to mine whichever network is most profitable. Therefore, the team conducted a calculated change in their underlying protocol that caused the profitability of the Bitcoin Cash network to dramatically increase. The majority of the world’s Bitcoin miners recognized the higher profitability and switched to the Bitcoin Cash network without further thought.

While Bitcoin Cash’s play for a majority hash rate proved effective only for a matter of hours, their accomplishment raised awareness to a tacit principle in the network: Bitcoin’s hash rate is not bound to Bitcoin. The miners are free to serve any compatible network the miners choose.

At the time of the writing of this paper, between Bitcoin and Bitcoin Cash, ~80% of the available hash rate is aligned with the former, and ~20% with the latter. There is speculation in the industry that if the Bitcoin Cash network creates a more favorable position, the balance of hashing power could change on a long-term basis. Furthermore, there are many other blockchain competitors who may gain the attention of Bitcoin’s miners in the future.

Were a shift in the balance of hash rate to occur, Bitcoin would no longer be the leader of security in the cryptocurrency realm. The price of Bitcoin would likely drop as users realized the resulting lack of security leadership. This might cause more miners to switch to a more profitable network to cover the cost of operating their expensive hardware. As miners abandon Bitcoin, and as users continue to leave, the situation becomes a reversal of the Network Effect. The Bitcoin network would come crashing downwards at an ever-compounding rate.

This is all theoretical, but it raises yet another concern: the security of a blockchain depends on many things, including the potentially fickle support of human blockchain miners. Our innovation, delayed Proof of Work (dPoW), takes this fact into account as we empower members of the Komodo ecosystem with Bitcoin-level security. Before we finally turn to our own solution, we must discuss the primary competitor to the PoW consensus mechanism, Proof of Stake (PoS).

The Primary Alternative: Proof of Stake

Perhaps the most popular alternative consensus mechanism is Proof of Stake (PoS). In this mechanism, blocks are mined not by miners performing work, but rather by any user “staking” their coins on the open network for the right to mine blocks.

The meaning of “staking” has different variations depending on the specific rules set forth by the developers of the unique variant of the PoS consensus mechanism. In general, staking one’s coins means placing them as collateral on the open network in exchange for the right to mine new blocks.

Users who stake their coins, thereby, can periodically extract a portion of the mempool, mine new blocks, and earn rewards. There is no need to perform any hardware-expensive proof-of-work calculations, as the user’s incentive to be honest is encouraged by the fact that their own wealth hangs in the balance.

The Security Risks and Shortcomings of PoS

The downside to PoS is that a user who simply leaves a large portion of wealth staked (and therefore continually claims rewards) gradually becomes a centralized point of wealth through the power of compound interest. On PoS networks, monopolies are a constant danger. The owner of a monopoly has power over the well-being of the network.

Once a majority of the supply is obtained, the owner gains a position known as “Nothing at Stake.” The owner can mine “false” blocks to the PoS blockchain and use their own majority supply over the network to declare these “false” blocks valid. All other stakeholders on the network must adopt these “false” blocks, lest the majority holder use their strength to declare competing blockchain versions as invalid.

If a non-majority holder attempts to challenge the monopoly holder’s version, the non-majority holder can achieve little more than the loss of coins they placed at stake. Compare this with non-majority holder in a PoW system: the question over the “truth” of the blockchain history depends not upon ownership of wealth, but upon the miner’s innovation and performance. PoW-based systems do not suffer from the risk of monopolies, therefore, as majority stakeholders gain no unique control over the mining of new blocks.

Variations of PoS, including the popular Delegated Proof of Stake (DPoS) and Delegated Byzantine Fault Tolerance (DBFT) systems, do not resolve the underlying issue of monopoly ownership and centralized manipulation. In a vanilla PoS system, the malicious actor needs only to purchase a majority supply of the coin to mine “false” blocks. In a DPoS/DBFT type system, wherein the ecosystem stakeholders elect and endow delegates with the responsibility to mine new blocks, the malicious actor has only to compromise most of the delegates. Thereafter, the compromised delegates can mine “false” blocks, and the users of the ecosystem have no direct means to retaliate, beyond abandoning the network.

This is not to say that PoS and its variants have no use cases. Indeed, there are scenarios in which PoS can be useful for entrepreneurs. In the Komodo ecosystem, our dPoW consensus mechanism can provide security to networks that use either type of consensus mechanism.

After the following section summary, we finally turn our attention to our dPoW consensus mechanism.

A Summary of the PoW Consensus Mechanism

In short, the PoW consensus mechanism, as designed by Satoshi Nakamoto, is currently the soundest method of blockchain security. It solves the Double Spend problem and creates a secure network, capable of transferring financial value. Furthermore, competition among miners and the Longest Chain Rule create fairness on the blockchain. The combination of features provides a high level of defense against two of the most dangerous methods of blockchain destruction—the 51% Attack and the Genesis Attack—assuming a strong overall hash rate on the network.

New PoW blockchains can opt to compete directly with Bitcoin’s hash rate, and some level of competition is good for the ethical values and innovative power of the cryptocurrency industry. However, it is not necessary, cost-effective, nor eco-friendly that every new blockchain innovation requiring security should attempt to compete directly with Bitcoin. Not only is this unsustainable, but it is also unreliable, as it depends on the arbitrary choices of the decentralized network of miners around the world.

The Komodo Solution: Delayed Proof Of Work (dPOW)

Komodo presents a technology, the delayed Proof of Work consensus mechanism, that solves the problems described above. Komodo’s unique consensus mechanism provides the same level of security as the strongest PoW network, without attempting direct competition. Instead, Komodo’s consensus mechanism uses the chosen PoW network as a storage space for “backups” of Komodo transactions. By this method, in the event of an attempted attack on Komodo’s blockchain history, even a single surviving copy of the Komodo main chain will allow the entire ecosystem to overwrite and overrule any of the attacker’s attempted changes.

In a key difference separating Komodo from regular PoW networks, our dPoW consensus mechanism does not recognize the Longest Chain Rule for any transactions that are older than the most recent “backup” of the Komodo blockchain. For conflicts that may arise which refer to transactions that are older than the most recent “backup,” our consensus mechanism looks to the backups in the chosen PoW blockchain to find the accurate record.

Furthermore, entrepreneurs who build independent blockchains (Smart Chains) in the Komodo ecosystem can likewise elect to have backups of their own records inserted into the Komodo main chain. In this manner, the records of the entrepreneur’s chain are then included in the backup that is pushed into the protective hash rate of the main PoW blockchain (Bitcoin). Thus, entrepreneurs and developers in the Komodo ecosystem can have their independent blockchains protected by the chosen PoW network’s hash rate.

Therefore, to destroy even the smallest Smart Chain that is employing Komodo’s dPoW security, the attacker would have to destroy: a) all existing copies of the Smart Chain; b) all copies of the Komodo main chain; c) the accompanying PoW security network into which the dPoW backups are inserted (Bitcoin). This endows the Komodo ecosystem with higher than Bitcoin-level security, while avoiding the excessive financial and eco-unfriendly costs.

In addition, the dPoW security provided by Komodo is not only greater than Bitcoin, but is also more flexible. The Komodo security services are performed by notary nodes, chosen through a stake-weighted vote. Notary nodes have the freedom to switch notarization to another PoW network. Reasons the notary nodes might elect to switch networks could include an event where worldwide miners’ hashing power changes to another PoW network, or the cost of notarization to the current PoW network becomes more than necessary. Through this flexibility, the Komodo ecosystem maintains both a superior level of security and a more flexible and adaptive nature than Bitcoin itself.

A Note About Komodo’s Iguana Core Technology

All the following processes are supported by a deeper Komodo technology called Iguana Core. Readers of this entire documentation may note that Iguana Core is featured in each section. This is because Iguana Core is the heart of the underlying technology that enables the vast Komodo ecosystem to work together. The Iguana Core code itself is complex and to fully explain would require a separate whitepaper.

In short, Iguana Core is a collection of code that serves many purposes. One function of Iguana Core is to empower the blockchain technologies Komodo either builds or adopts to act in coordination with each other. Often, Iguana Core can advance their initial capabilities beyond original expectations. In the case of dPoW, the code that underlies notary-node functionality spawned from Iguana Core technology.

Iguana Core is coded in the C programming language—the language of choice of our lead developer, JL777. The C language is designed to enable computers to process high volumes of information in a secure manner at high speed. This aligns with Komodo’s directives to provide security and scalability to our users.

A Brief Discussion on the Security Provided by the Notary Nodes

Security is the foundational aspect of the Komodo ecosystem. Therefore, for the reader, we must first discuss the nature of the security the notary nodes provide. More detailed explanations on individual components will follow.

The Komodo ecosystem uses a stake-weighted vote to elect parties who run sixty-four separate “notary nodes.” These notary nodes perform the “backup” process via automation provided by the Iguana Core software that runs at the heart of our system. These backups are called “notarizations.” Each notarization performed by the notary nodes acts as a marker of the “true” history for the Komodo ecosystem, and this marker’s accuracy is secured by the hash power of the chosen PoW network.

The notary nodes work together in a decentralized and trustless manner both to create each notarization and to write it to the chosen PoW network (Bitcoin). Frequency varies between two to six notarizations per hour, and the yearly cost to perform this service is ~180 BTC. Funds for this service were raised as a part of our initial Komodo ICO, and our holdings allow us to continue this method for many years before we will be required to implement a business model to replenish our reserves.

With our dPoW mechanism, each confirmation on the chosen PoW network is also a confirmation of the entire Komodo ecosystem’s history. The only sacrifice that is made is the time it takes to push the Komodo ecosystem’s records into the protection of the main hash rate. For this reason, we name our consensus mechanism, “delayed Proof of Work” (dPoW).

Our consensus mechanism is designed to keep the advantages provided by the PoW system, circumvent the excessive financial and eco-unfriendly overhead costs, and avoid the security risks found in a PoS system. We accomplish these measures by several means. The most important measure is that all actions a notary node takes are publicly verifiable, and the Iguana Core software running on the users’ machines verifies notary nodes’ actions. The notary nodes themselves are not arbiters of “truth.”

Therefore, the only type of “false” behavior a malicious notary node can perform is to withhold notarization. There are sixty-four notary nodes. The minimum number of notary nodes required to maintain the Komodo ecosystem is thirteen. Thus, a malicious actor would have to compromise fifty-one notary nodes to shut down the Komodo ecosystem. Such an action would be uneconomic, as this would be destroying the access to the financial rewards a notary node receives for performing its duties. By this design, notary nodes have only one economically favorable position: to properly transfer the records of the Komodo ecosystem into a secure location and to increase Komodo’s market share and value.

For the average user, when performing a trade of goods and services where security is desired, the user simply needs to wait until the notarization process is complete. After the notary nodes are finished, the only way to break the security protecting their transaction history requires breaking the security of the chosen PoW network (Bitcoin). The Iguana Core code running in the main Komodo software automates the verification process. Entrepreneurs and developers should be aware of this information as they design business models and services for their users.

Thus, Komodo’s dPoW consensus mechanism maintains the security innovated by Satoshi Nakamoto, and because it enables the Bitcoin hash rate to serve more independent blockchains than just the single Bitcoin blockchain, dPoW even expands on Nakamoto’s original design.

The Notarization Process

Step One: Gathering the Appropriate Data

The process of notarization is simple. Roughly every ten to twenty-five minutes, notary nodes perform a special block hash mined on the Komodo blockchain and take note of the overall Komodo blockchain “height” (i.e. the number of total blocks in the Komodo blockchain since inception). The notary nodes process this specific block in such a manner that their signatures are cryptographically included within the content of the notarized data.

All examples herein are estimated based off an actual KMD notarization to the BTC network, linked here.

The pieces going into the notarization process could look like this:

The Block Hash

0a88371cc63969d29492110592189f839557e606db6f2b418ecfe8af24451c07

This is the “block hash” from the KMD blockchain—mined and cryptographically signed by the notary nodes

Block 607240

This is the blockchain “height” of the Komodo blockchain at the time of notarization (i.e. the total number of KMD blocks ever created)

KMD

The letters “KMD” are added into the notarization mixture to indicate the name of the blockchain to which this notarization belongs

Creating a Notarization

The notary nodes will take these three pieces of information and compress them into a format that is more computer-friendly. The result looks like this:

6a28071c4524afe8cf8e412b6fdb06e65795839f189205119294d26939c61c37880a084409004b4d4400

The above number can be said to be a cryptographic representation of all that has happened on the Komodo blockchain up to this point in time. According to the Cascade Effect, were an attacker to attempt to go back in the history of the Komodo blockchain and change even a single character of data, and then perform the same hashing formulas in the Komodo code, the number above would dramatically change.

This makes the notary nodes’ notarization a useful backup, assuming this number is in a safe location where anyone on the Internet can view and verify it. It enables a single surviving copy of the “true” Komodo main chain to identify itself to the rest of the Komodo network, as only the “true” data can produce the same result.

On the other hand, an incorrect history of the Komodo network will not be able to produce the same notarization. Through the automation in the Iguana Core software that underlies the Komodo ecosystem, all users will align with the “true” blockchain history and ignore any malicious actors’ “false” attempts.

Step Two: Notarizing the Data to a Secure Location

Naturally, for security purposes this number cannot simply be saved to one person’s local computer, or be written down on a piece of paper. Were the number to be in such a centralized location, a would-be attacker could simply destroy the backup, or replace it with a “false” version.

For the number to be useful, it must be placed in a secure and decentralized location. Here is where Komodo adopts security from another network: Komodo will perform a simple transaction in which it writes the above number into the data history of the strongest PoW blockchain (currently Bitcoin). This location is as secure as the miners’ hash rate makes it, and the location is decentralized, by nature.

To place this information in the accompanying PoW network, the notary nodes use a feature that exists at the core of the Bitcoin protocol when making a transaction. The feature is called “OP_RETURN,” and it allows for a message to be added to the blockchain, permanently, as a part of performing a transaction.

A notable use of the ability to write messages to a PoW blockchain is found in the first actions of Satoshi Nakamoto himself (themselves). In the first Bitcoin block ever mined, Satoshi used a feature like OP_RETURN to include this message:

03-Jan-2009 Chancellor on brink of second bailout for banks

Note: Nakamoto used a feature called “coinbase,” which is similar to OP_RETURN. A primary difference between coinbase and OP_RETURN is that coinbase is used by miners when mining a block, whereas OP_RETURN can be used by any user when performing transactions.

Readers who have downloaded the Bitcoin blockchain to their local computer, and who possess the knowledge necessary to inspect the raw Bitcoin data, can discover these very words written to their own hard drive. The important thing to understand for our discussion is that any message written to a secure and decentralized PoW blockchain is viewable and verifiable to all.

The permanence and security of OP_RETURN messages are a core aspect of dPoW’s security. In the event of a powerful attack on the Komodo network, there need be no argument over the correct notarized marker upon which the ecosystem members should rely. The Iguana Core code running at the heart of each user’s Komodo software can continue securing, decentralizing, and distributing the accurate version of the Komodo history as though the attack never occurred.

Step Three: Notarizing the PoW Network Information Back to the KMD Main Chain

One final step remains to complete the loop of security between the KMD main chain and the chosen PoW network. The KMD blockchain must record within its own records the specific location where it placed this backup into the PoW blockchain. This enables the Iguana Core software to identify the location of the most recent notarization.

To create this reminder, the notary nodes will now gather one more piece of information, this time drawn from the accompanying PoW network: the transaction hash (txid) identifying the location of the first notarization. This information could look like this:

313031a1ed2dbe12a20706dff48d3dffb0e39d15e3e4ff936d01f091fb3b8556

The notary nodes will combine it with all the information that has come before. The result will be transformed, again, into a computer-friendly version:

6a28071c4524afe8cf8e412b6fdb06e65795839f189205119294d26939c61c37880a0844090056853bfb91f0016d93ffe4e3159de3b0ff3d8df4df0607a212be2deda13130314b4d4400

This number is a compressed cryptographic representation of everything that has happened in the Komodo ecosystem up to this point in time. The notarization is placed as a transaction message directly into the KMD main chain itself. It enables the Komodo ecosystem to know how to find a reference of its own history.

As each notarization is built upon all the notarizations that came before, Iguana Core does not need to monitor each notarization. Rather, it only needs to observe the most recent iteration. This is favorable for Komodo security, as there is always a possibility that the chosen PoW network (Bitcoin) could fail. In this event, the notary nodes would place their next notarization in a competing PoW network (such as Bitcoin Cash) and the entire Komodo ecosystem would remain secure. The notarizations in the failing PoW network would no longer be required to verify ecosystem accuracy.

Understanding Security and Economic Incentives

The nature of mining in the Komodo ecosystem serves as an incentive to motivate the notary nodes to perform their job well. This setup is also a principle method by which the Komodo ecosystem dramatically reduces the overhead costs necessary to function. Portions of the mining rewards are available not just to the notary nodes, but also to all members of the Komodo ecosystem, through various means.

The Komodo network on a surface-level is a minable network, like other PoW networks. Any technically savvy user can activate a device capable of mining the Komodo network, and thereby process users’ transactions, mine blocks, and receive rewards. For these miners, the Komodo protocol functions in almost the exact same manner as the Bitcoin blockchain’s mining rewards function.

Understanding the similarities will explain to the reader the motivations for the notary nodes and other Komodo miners to secure the Komodo network. The differences, on the other hand, are explained in Part V of this paper. (See the section regarding the 5.1% rewards allocated to all users who hold at least 10 KMD in their wallet address. This 5.1% reward is given to users out of the funds that would normally be given to a Bitcoin miner as a method of minting new Bitcoin coins.)

“Easy Difficulty” in dPoW: The Key to Notary Nodes’ Financial Incentives

The foundational similarity to understand is that with each block header, clues are provided for miners to find the next valid block hash. The specific clue, “difficulty,” changes with each block header.

Under normal circumstances on a PoW blockchain, with each block header the difficulty level can change. The Bitcoin protocol itself decides what the difficulty for the next valid block should be.

The difficulty is decided based on the amount of overall hash power mining the network. If many miners are active, then the hash rate is high, and the Bitcoin protocol sets the difficulty to a higher number. On the other hand, if the hash rate is low, then the protocol sets the difficulty to a lower number.

Recall that the “difficulty” level determines the number of zeros at the beginning of the next valid block hash. The more zeros at the beginning of a valid block hash, the more unlikely each attempt at finding a valid block hash will be.

When the Bitcoin protocol was in its infancy, the difficulty setting was easy. In fact, the block hash we used earlier as an example is, in truth, the very first block hash ever created—by Satoshi Nakamoto himself (themselves).

000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f

He (they) designed the difficulty setting to encourage the network to find new block hashes once every ten minutes, on average.

For a computer, to guess within ten minutes a nonce that will produce a block hash beginning with ten zeros is relatively easy. It is so simple, in fact, no special computer is required. Early Bitcoin miners could use nothing more than the average desktop machine, having the CPU—the small heart of the computer—performing the calculations.

As more miners joined the network, however, the Bitcoin protocol automatically increased the difficulty. This maintained the speed at which the pool of all miners discovered new blocks, despite the increased size of the pool. Stabilizing the speed created several benefits, including an amount of economic predictability upon which users can rely.

Today, at Bitcoin’s current level of overall hash power, a valid block hash requires a much higher level of difficulty. Here is a recent successful block hash:

0000000000000000002d08398d6f21f038019600266b419bad5ab88add5b638d

There are seventeen zeros, and to find a valid block hash at this level requires a prodigious effort.

In the race to win blockchain rewards, miners all over the world have built entire farms of specialized equipment for mining. The small CPU of a desktop is no longer useful, and the time of “easy difficulty” on Bitcoin has passed.

The dPoW System offers “Easy” Mode to the Elected Notary Nodes

Here is where our dPoW consensus mechanism diverges from the Bitcoin protocol’s limitations. In addition to performing the notarizations of the Komodo ecosystem, notary nodes are also a special type of blockchain miner. They have a certain feature in their underlying code that both enables them to maintain an effective and cost-efficient blockchain ecosystem and provides the notary nodes with a financial incentive. The combination of benefits prevents the Komodo ecosystem from falling into the trap of directly competing with other PoW networks for hash-rate security status.

Each Notary Node Gets One Chance Per Every Sixty-Five Blocks to Mine on Easy

Each individual node periodically receives the privilege to mine a block on “easy difficulty.” In other words, while the rest of the miners in the Komodo ecosystem are mining at a calculated difficulty level, the notary nodes occasionally receive the chance to mine as though they are alone on the network.

The notary nodes’ “easy difficulty” setting operates in a cyclical manner, with each notary node on its own cycle. At the start of the cycle the notary node holds the “easy difficulty” ability until it mines one “easy” block. Then the Iguana Core code removes the ability for the next sixty-four blocks. After the sixty-four-block period passes, the notary node can once again attempt to capture a block on “easy difficulty.”

Therefore, while everyone else on the network mines at an adjustable level of difficulty according to the normal PoW consensus mechanism (which keeps the overall speed of the Komodo network stable) the notary nodes have a chance to step outside the normal rules. For every sixty-five-block period on the Komodo blockchain, the odds that a block will be mined by a notary node, as opposed to a normal miner, are essentially 3:1.

Since the rest of the miners have an adjustable difficulty ratio, it does not matter how many more miners attempt to mine Komodo. Most of the valid blocks will always be found by the sixty-four elected notary nodes, even were the entire hash power of the Bitcoin network to switch all its attention to mining Komodo.

The mining rewards that a notary node receives through this feature are ~50 KMD per day. This reward occurs regardless of KMD’s popularity, market value, or even of the competition from normal KMD miners. The reward notary nodes receive creates an economic incentive for each party controlling a notary node to support and protect the Komodo ecosystem, and to increase the relative value of this daily ~50 KMD reward.

Komodo’s Protective Measures in Action

There are myriad ways that an attacker can assail a blockchain project, and the Komodo ecosystem is well prepared. In this foundational paper, we only discuss two of the most crucial attacks—the 51% Attack and the Genesis Attack.

In a separate technical whitepaper, written by our lead developer, we provide several more discussions on how Komodo responds to many other forms of attack.

Some mentioned therein include the Sybil Attack, the Eclipse Attack, and more. We encourage any reader searching for information about the deepest levels of Komodo security not only to read the accompanying whitepaper, but also to reach out to our team directly.

Note (2019): The whitepaper referred to above was written in ~2016 and is now obsolete, and therefore is no longer posted here. Please reach out to our team directly for a copy, if interested.

Notarizations Provide a Defense Against Both the 51% Attack and the Genesis Attack

By relying on the notarizations in the chosen PoW network’s hash rate (Bitcoin), users in the Komodo ecosystem are well protected from both the 51% Attack and the Genesis Attack. Recall that in a 51% Attack, the attacker first makes a transaction and then erases it by providing 51% of the total hash rate to a “false” blockchain where the transaction never occurred. In the Genesis Attack, the attacker recreates the genesis block of a blockchain and mines an entirely false history. For either of these attacks to play any part in the Komodo ecosystem, the successful attack would have to destroy every transaction at every level it is recorded.

First, let us consider the implications of the notarization process provided against the Genesis Attack. Once an independent blockchain has even just a single transaction pushed through the notarization process into the chosen PoW network, that notarization protects against the Genesis Attack. To successfully complete a Genesis Attack against a Komodo-built blockchain, the attacker would have to destroy the chosen PoW network’s records from that moment going forward. The attacker would also have to destroy the KMD main chain from that moment forward, and the entire independent Smart Chain. The likelihood of achieving this task is effectively as probable as performing a Genesis Attack on the chosen PoW network itself.

The Komodo ecosystem is also well protected against the 51% Attack, so long as users wait for a desirable number of notarizations. Consider a transaction that is recently performed on a Smart Chain in the Komodo ecosystem. While the notary nodes have not yet notarized the transaction into the KMD main chain, then it is plausible that during this approximately ten-minute period an attacker could successfully perform a 51% Attack on this transaction. The attacker would simply make a transaction, and then provide 51% of the total hash rate to a “false” version of the independent Smart Chain to erase the transaction. Therefore, users should always wait until they receive at least one notarization to the KMD main chain before considering any transaction final.

Note (2019): Additionally, Komodo’s new (2019) Antara Framework provides additional options that allow Smart Chain users to greatly reduce the required wait time for notarizations. In some instances, the wait time can be effectively eliminated.

An introduction to the Antara Framework is discussed in this linked Core Technology Discussion section.

On the other hand, for the full Antara documentation, click here.

(End Note)

Once the transaction reaches the KMD main chain, at this point, the attacker would have to successfully perform the 51% Attack against both the KMD main chain and the independent Smart Chain. This is already quite difficult to achieve, as it would require overcoming the notary nodes and other KMD miners, while simultaneously attacking the independent chain. Entrepreneurs, developers, and users should decide for themselves how much trust they wish to place in the system at this point of the notarization process.

When considering large sums of money, the need for protection grows. A large sum of money can be both a single large transaction, or it can be the collective value of many small and normal-sized transactions that build up over hours, days, and years. These transaction histories need protection against the sophisticated blockchain attacker. It is for this reason that the notarization process exists.

Once the notary nodes have pushed the most recent version of the Komodo ecosystem’s history into the chosen PoW network (Bitcoin), the entire ecosystem relies only on that notarization as the arbiter of truth. All transaction records that have been pushed into the chosen PoW network can only be rescinded by altering the chosen PoW network itself (while simultaneously altering the histories of the KMD main chain and the independent Smart Chain). Accomplishing such a task is highly improbable (though we warn the reader never to consider any attack impossible).

Therefore, any record that has been on the Komodo main chain for at least one notarization has a fortress of hash rate and other security measures at its guard. So long as users and developers are mindful to wait for the desired number of notarizations to secure their payments, both the 51% Attack and the Genesis Attack are highly unlikely either to be successful, or to provide economic value to the would-be malicious actor.

Nevertheless, we remind all users of our ecosystem to consider their own vigilance and mindfulness as the most effective protection against the would-be attacker. Users, entrepreneurs, and developers utilize all aspects of the Komodo network at their own risk.

Considering an Attack on the Notarization Process

To create a notarization for the KMD main chain, the minimum number of notary nodes required is 13. If the notary nodes themselves come under attack and must work to maintain access to the Internet, just 13 of the full 64 are required for the Komodo ecosystem to continue its operations.

In the possible event of a disconnect from the minimum number of notary nodes, chains in the Komodo ecosystem should simply be on the alert. Users, developers, and entrepreneurs would simply need to wait for the notary nodes to regain access to the Internet and resume the notarization process before considering any transaction final.

For this reason, the position of a notary node is held with high importance, and the parties which gain these positions are measured foremost by their Information Technology experience and capabilities. Komodo stakeholders are responsible to vote for candidates that are the most qualified to perform in the notary-node duties.

The dPOW Consensus Mechanism is Inherent in all Komodo Smart Chains

These security features extend to any Smart Chain relying on the notarization process. The primary difference between a Smart Chain and the main chain is that the main chain notarizes to an exterior PoW network (Bitcoin), whereas the Smart Chain notarizes to the KMD main chain.

The notarization for the Smart Chain is performed by the notary nodes as a service to the independent developer and entrepreneur. Notary nodes create a notarization of the Smart Chain and write it into the KMD main chain. Then they write their actions into the Smart Chain itself. This allows Iguana Core (running at the heart of the Smart Chain) to identify where its most recent notarization can be found. The notarization process cycles every ten minutes, assuming the Smart Chain’s network is consistently active. If the network has periods of inactivity, the notary nodes halt the process (to save against unnecessary notarization costs) and reactivate as soon as new transaction activity appears on the Smart Chain’s network.

There is also a difference in the number of notary nodes required to notarize a Smart Chain as compared to the KMD main chain. Whereas with the KMD main chain 13 notary nodes are required, only 11 notary nodes are required to notarize a Smart Chain. This difference is based on the underlying math that ensures that the number of Smart Chains in the Komodo ecosystem can scale into the tens of thousands.

We invite the reader to consider the fact as each Smart Chain can support thousands of transactions per minute, this makes the combined ecosystem capable of supporting millions of transactions per minute. This includes cross-blockchain interoperability, via our atomic-swap powered technology and our Antara Framework. This makes Komodo among the most scalable of financial-technology solutions in existence, and capable of competing with the transaction volumes of fiat networks.

Naturally, as each level of notarization takes time to perform, there is an additional delay for Smart Chains as compared to the KMD main chain. A Smart Chain’s history is notarized into the KMD main chain approximately every ten minutes, assuming constant activity. This notarization will then be pushed through the notarization process into the chosen PoW network (Bitcoin). We estimate that a transaction performed on a Smart Chain will receive the KMD main chain’s protection within approximately ten minutes, and will receive the Bitcoin hash rate’s protection in approximately twenty to thirty minutes.

Another difference between the KMD main chain and a Smart Chain is that the notary nodes only mine the KMD main chain. Asset-chain developers are responsible to create any required network of miners to process their Smart Chain’s transactions. This does not need to be a full network of mining farms, such as those in Bitcoin. Rather, it only needs to be enough computing power to process transactions, and to provide any desired level of hash-rate security to cover the ten-minute waiting period. For a small business with intermittent periods of transaction activity, a single, dedicated, full-time server may be enough. Larger businesses can scale as desired and can also work to attract a network of freelance miners.

It is also possible that a network of freelance miners will naturally arise within the Komodo ecosystem, to observe and manage transaction-processing services wherever and whenever they are required, through automation.

This setup dramatically reduces the overhead costs and effort the entrepreneur and developer would otherwise have to allocate to a network of high-hash rate miners. These freed resources of the entrepreneur and developer can therefore be allocated to other uses in their business models.

The total yearly cost for the Komodo notary nodes to notarize the KMD main chain into the currently chosen PoW chain, Bitcoin, is approximately ~180 BTC/year (a value of ~$1.5M USD at the time of the writing of this paper). Funding for the notary nodes to perform this service was raised during the Komodo ICO, and current BTC holdings give us many years to come before we will be required to implement any business models to replenish our BTC funds.

On the other hand, the total cost for the Smart Chain developer to notarize their independent chain into the KMD main chain is but a fraction of the cost. This security mechanism is not limited to Smart Chains created within the Komodo ecosystem. In fact, Komodo’s Blockchain Security Services are available to any existing blockchain. With Komodo, any blockchain can be protected with the power of the Bitcoin hash rate for a tiny percentage of the cost.

Thus, an entrepreneur in our ecosystem can have their own independent blockchain that is backed up by the hash rate of the Bitcoin mining network, at only a fraction of the cost. In the following sections, we discuss the formation of a new Komodo Smart Chain, the method of distribution and trading using our atomic-swap technology, AtomicDEX, and our “smart contract” like technology, the Antara Framework.

Creating and Distributing a New Komodo Smart Chain

Abstract

There lies a great power in the idea that any person, regardless of nationality, creed, or background, can obtain funding to innovate and prosper. An integral tenet of blockchain technology is “decentralization.” By decentralizing systems, we reduce the number of control points that can be compromised and manipulated.

Decentralization plays a more common role in our new cryptocurrency economy, but there is one area of the market that remains centralized and vulnerable: the initial coin offering (ICO). The cryptocurrency industry needs a solution, and Komodo presents an answer with our decentralized initial coin offering (dICO).

In today’s common ICO model, the high level of centralization creates many problems. Third-parties can block or manipulate entrepreneurs’ efforts to innovate and prosper. The centralized location of releasing the ICO blockchain product is vulnerable, allowing whales, hackers, and human error to corrupt or destroy an entrepreneur’s efforts. The negative experience of users in these situations can also impact the perception and adoption of cryptocurrency. Furthermore, the traceable nature of an ICO prevents society from crowd sourcing and purchasing within makind’s inherent right to barter in private.

The dICO model, as created by the Komodo project, overcomes these challenges. It provides the necessary technology to create and release a blockchain product to the world with the full power of decentralization.

Entrepreneurs building on our platform begin by creating a Smart Chain, and our technology simplifies this process. One need only install the necessary software, execute a few commands on a command prompt, and then establish a connection between two or more Komodo-enabled devices. Komodo’s core technology will do the rest of the work necessary to create a fully independent blockchain, empowered with an array of Komodo features.

Our dPoW technology is a key feature. dPoW provides the necessary security to protect the integrity of the blockchain. Use of dPoW is optional, and since Smart Chains in the Komodo ecosystem are independent by nature, entrepreneurs can discontinue dPoW services at will.

Having thus created the blockchain, the entrepreneur then uses our software to release the project to the world. Our decentralized exchange, AtomicDEX, is a useful software solution to conduct their decentralized initial coin offering. Because AtomicDEX relies on “atomic swaps,” no third-party manipulators can prevent the entrepreneur from their crowdsourcing and innovative endeavors.

Through the privacy technology available on Komodo Smart Chains, dICO participants can purchase the product within their inherent right to barter in private.

The Challenges in Current ICO Platforms

Specific Weaknesses in the Centralized ICO Model

There are many weaknesses present in today’s Initial Coin Offering (ICO) model. Several notable weaknesses include third-party discrimination, the vulnerability to theft and human error, and a lack of privacy.

Third-Party Discrimination

An entrepreneur seeking to serve their intended audience may experience adverse intervention from a third party. The antagonists may display personal and malicious intent, regardless of the value of the entrepreneur’s innovation.

Centralization of Technology: Theft and Human Error

Today’s ICOs are typically conducted in escrow, where the purchasers must transfer money to one location for holding. This typically occurs through a single website, and the cryptocurrency funds are held on a centralized collection of server(s).

The user must wait while the ICO administrators first verify the transactions and distribute the coins. During this time the funding is centralized, and therefore vulnerable to thieves and human error.

Lack of Privacy

Because ICO transactions are highly traceable it is difficult, if not impossible, to perform ICOs within our right to barter in private.

Third-Party Discrimination via the Centralized ICO

One weakness of the ICO process is, paradoxically, rooted in a great strength of blockchain technology: its borderless nature. A key power of any blockchain is that any human capable of accessing the technology can activate the blockchain, regardless of their geographical location or social status. Thus, anyone can provide yet another verifiable record of the transaction history, and this decentralization provides a crucial element of security to the blockchain.

An ICO innovator, therefore, may prefer to use a blockchain platform that transcends man-made barriers, to protect their innovation. Circumventing man-made barriers could be integral to the blockchain’s survival, because the element of decentralization prevents malicious actors from creating subjective borders around the blockchain records and then using authority to falsify and manipulate.

This creates a conundrum, however. As a human race, we also find strength and empowerment in subjectively defining our own demographics for various reasons, whether they be to form companies, cultures, communities, etc.

While we find the ability to create subjective demographics useful, it contrasts with the borderless nature of blockchain technology. Members of one demographic may desire to participate in a specific ICO, but another demographic may find this unfavorable. Therefore, the second party might try to forestall progress. The paradox lies in the fact that for the underlying blockchain product to maintain its integrity, it must serve both communities without regard to any man-made barrier between them.

The problem compounds even further as we observe that on a decentralized blockchain platform, a new ICO product is capable of functioning anywhere there is access to the underlying technology. On a decentralized platform, once a new blockchain product is released any person from either demographic is now able to utilize it. The sentiment of either demographic is irrelevant. The problem becomes most pronounced if members of a competing group attempt to even maliciously prevent an innovation out of selfish reasons. Thus, it is imperative that the innovator have the option of protection against would-be malicious competitors.

The overall centralized nature of today’s ICO process, therefore, presents a problem. Entrepreneurs who are not able to navigate the adverse effects of an inhibiting third party may be unable to realize their creative potential.

Centralization of ICO Technology: Hackers and Human Error

Yet another issue plaguing ICOs is that the technology upon which an ICO is released is also centralized. This presents a vulnerability to human foibles.

Hackers and Human Error

Because all coins of an ICO typically process through one centralized point during the purchasing period, the entire supply is vulnerable to any person with access to the node. Therefore, both malicious and clumsy human agents can destroy an ICO. The data holding the cryptocurrency can be damaged, stolen, or simply lost through incompetence.

An entrepreneur can also consider that in today’s ICO model both the funding provided by the purchasers, as well as the actual ICO coins that the entrepreneur intends to sell, remain on the centralized node for a long period of time. It is not just one side of the crowdsourcing endeavor that is at risk, but both.

This central point of failure can be catastrophic for all participants.

The Right to Barter in Private

Finally, the lack of current privacy options in the ICO process inhibits blockchain participants from purchasing within our right to barter in private. This right to privately exchange goods and services extends further into history than the written word. We have, as a species, utilized this right to organize into communities, institutions, and even nations.

Many of humanity’s most meaningful advancements in art, technology, and other human endeavors began in situations where the creator had the security of privacy in which to explore, to discover, to make mistakes, and to learn thereby.

The right to barter in private, however, is under modern threat as the recent monumental and historical phenomenon, “The Internet of Information,” permits many kinds of people to quietly and without inhibition; monitor other people’s shopping and bartering behavior. This is a dangerous development, as it destroys the privacy that empowers much of humanity’s personal growth. We must reserve our right to barter in private, for we observe that there are myriad ways in which a common person may explore personal growth in an economic environment.

Yet, the highly traceable nature of today’s centralized ICO model is in direct contradiction to this human need.

The Blockchain Industry Needs a Solution, and Komodo Presents an Answer

Together, these issues show that the current state of the ICO market is plagued with limitations that inhibit freedom, security, entrepreneurship, and even human growth. The cryptocurrency industry needs a solution to these problems, and Komodo presents an answer.

The Decentralized Initial Coin Offering

The Komodo ecosystem presents a solution, the decentralized initial coin offering (dICO), that solves these issues and even adds new possibilities to the cryptocurrency market.

The decentralized nature of the dICO enables the entrepreneur to release a blockchain product beyond the reach of a malicious third-party influencer.

Furthermore, through our decentralized exchange, AtomicDEX, the dICO allows an entrepreneur to release their product in a manner that mitigates and even eliminates many of the issues regarding hackers and human error.

With the advantage of Komodo’s privacy technology, the participants in a dICO are empowered with their right to barter in private.

The Process of Creating a New Blockchain in the Komodo Ecosystem

Formerly, coding and generating the blockchain itself were a most difficult aspect of the development process. Now, the Komodo team has simplified the process into easy steps. Through Komodo’s Iguana Core technology (introduced in Part I), the entrepreneur can create a new independent blockchain by entering just two simple commands in the command prompt of their computer.

The following steps rely on one of Komodo’s underlying software processes that run in the background on a user’s computer. The name of this software is the “Komodo daemon,” or komodod, for short. komodod is rooted in Iguana Core technology.

The First Command to Create a New Coin

./komodod -ac_name=[ENTREPRENEUR'S COIN] -ac_supply=[TOTAL COIN SUPPLY] -gen

The first part of the command, ./komodod, initiates a new instance of Komodod.

By default, the initial ./komodod command executed alone would launch the Komodo main chain, KMD, on the user’s computer. However, the next part of the command tells komodod to behave differently.

-ac_name=[ENTREPRENEUR'S COIN]

This command tells komodod to look for a coin with the inserted name.

-ac_supply=[TOTAL COIN SUPPLY]

This tells komodod how many total coins there should be in this chain.

-gen

This tells komodod that the user desires to mine this network.

The underlying code of Komodo’s Iguana Core technology can now make several decisions. First, it will check its connection to the Komodo ecosystem to see if there is a coin with the given name and supply. If no similar coin is found, komodod will assume that the user is attempting to create a new coin, and the -gen command tells komodod that the user wants to mine it.

Komodod now begins the automated process of creating a new Smart Chain in the Komodo ecosystem. Komodod will first make a fresh and empty clone of the KMD main chain (though it will not yet generate the actual coins), with only a few differences to the underlying nature of the chain.

The Features of the New Smart Chain

There are several primary differences between a Smart Chain and the main Komodo chain. For example, the Smart Chain will not automatically generate 5.1% rewards for all wallet addresses holding coins, unlike the main chain. Furthermore, the Smart Chain’s dPoW consensus mechanism is built to notarize to the KMD main chain.

Some of the differences reveal strong advantages held by members of the Komodo ecosystem. By design, this Smart Chain is capable of automatically adopting any updates that the Komodo core development team add to the framework. The Smart Chain also has a built-in capacity within the framework to allow the entrepreneur to code new rules.

For example, the entrepreneur may decide not to use a PoW consensus mechanism, but may instead prefer PoS. Other changes can also be made, according to the entrepreneur’s imagination and developer knowledge. So long as the new code that the entrepreneur adds to the Smart Chain does not interfere with the overall framework, the Smart Chain will smoothly integrate with the rest of the Komodo ecosystem.

For the purposes of our discussion, this new Smart Chain is otherwise the same as the Komodo main chain, including the features to communicate natively with other blockchains via AtomicDEX. The reader may note that this new Komodo Smart Chain is not a colored-token running on top of a parent blockchain, as is often the case in other blockchain ecosystems (consider the ERC20 token of the Ethereum platform). Instead, this Smart Chain is an entirely unique and independent blockchain unto itself.

This empowers the entrepreneur with significant advantages over other blockchain ecosystems. The Smart Chain can run on its own nodes, act according to whatever rules the entrepreneur can imagine, and can scale according to its own audience. Should a Smart Chain in the Komodo network experience a sudden explosion of activity, the sudden change will not negatively impact the overall Komodo ecosystem. This independence grants a significant competitive advantage in the form of overall security, speed, and ease of use.

Consider the advantage of developing an entrepreneurial product as a fully independent blockchain. Should the entrepreneur desire at a future point to leave the Komodo ecosystem for any reason, they are free to take their blockchain product with them.

Generating and Mining the New Coins

Let us return now to the moment after the entrepreneur executes the first command in the command prompt, and Komodod creates a fresh and empty clone of the Komodo main chain. While the instance of the Komodod program (running on the entrepreneur’s local computer device) will create the necessary code for the new Smart Chain, Komodod will not yet generate the coin supply itself. Komodod instead will wait for the next few steps to occur.

The reason for the wait is that a blockchain’s essence depends upon existing not in isolation, but in a network of multiple devices. This is the nature of decentralization. Komodod will wait until it receives a signal from another device, thus indicating that it has a peer with which to form the Smart Chain network.

The Entire Coin Supply is Distributed in the Genesis Block

Typically, the entire coin supply for the dICO is created and distributed immediately to the device that mines the first block, the Genesis Block. The code performs this distribution as a one-time reward for discovering the first valid block hash.

Having established a secure connection with a second device, the entrepreneur will enter the following command on the second device.

./komodod -ac_name=[ENTREPRENUER'S COIN] -ac_supply=[TOTAL COIN SUPPLY] -addnode=[INSERT IP ADDRESS OF FIRST DEVICE]

Note that the first three elements of the command, ./komodod, -ac_name, and -ac_supply, are the same. It is important that the parameters inserted into these commands match exactly. Otherwise, the instances of Komodod running on the separate devices will ignore each other, and the coin will not be mined.

Note: In the second VPS, the -gen command is not present. In this circumstance, we are assuming that the entrepreneur wants to capture the entire coin supply on the first device. Technically speaking, assuming the entrepreneur has ownership over both devices, it does not matter if both devices initiate the -gen command. Both devices will attempt to mine the first block and the superior device will receive the coin supply.

There is another key difference in the command.

-addnode=[INSERT IP ADDRESS OF FIRST DEVICE]

With the execution of the IP address command, the second device knows to look across the available connection (the Internet, VPS service, etc.) for the first device, which is already running an instance of Komodod and the new coin. The command here simply tells the computer the proper IP address of the first device.

As soon as these two devices connect, having all the proper Komodod software running and set in place, the mining begins. One of the devices will mine the first block and instantly receive the total coin supply of the entire blockchain into the user’s chosen wallet.

Both devices sync this information to each other, and the ENTREPRENEUR’S COIN now exists in the world. The entrepreneur can also add more and more devices to the network.

Notarizing to the Komodo Main Chain

To receive the security of the dPoW consensus mechanism, the entrepreneur simply needs to have the elected notary nodes add the ENTREPENEUR’S COIN to their internal list of coins to notarize. This will empower the entrepreneur’s product with the same verifiable and decentralized security of the Komodo parent chain.

The process of adding a new notarization service can be executed by the notary nodes with just a simple command. While we are at this early stage of development, this sign-up process for new dICO products is not yet automated. In the future, we intend to automate as much of this process as possible.

There is a fee for receiving notarization services. This helps to cover the business costs associated with notarization (recall that all notarizations are financial transactions, by nature).

Entrepreneurs are thus able to use the Smart Chain’s native dPoW consensus mechanism to notarize to the Komodo main chain to create a secure backup of the coin’s history. Even in the event of an attack at this early state of existence the entrepreneur can rest assured that their product will survive, so long as one copy of the blockchain’s history exists.

Everything is set on the backend for the entrepreneur, and they are now fully prepared to begin the dICO process. Naturally, we understand that for many potential entrepreneurs in the Komodo ecosystem, this process is unfamiliar territory. We encourage interested entrepreneurs to reach out to our team for guidance during development.

The Distribution of Coins

The Trials and Travails of the Centralized ICO Method

Previously, the entrepreneur at this point would have been required to go through a centralized ICO process.

This could have required several cumbersome and possibly dangerous steps. For example, the entrepreneur would begin gathering cryptocurrencies from their audience to personally hold in escrow while the process of matching purchases to the new blockchain coin were verified.

To distribute these coins, the entrepreneur had two primary options. They could have created and distributed a digital software wallet capable of holding the entrepreneur’s coins. This would require their audience to download the software. The entrepreneur would then have to send all the appropriate coins to each wallet address, according to the process they established during their ICO.

Or, the entrepreneur would have to make formal arrangements with another service to manage this process, such as with a centralized exchange. This would require a successful negotiation with this third party, likely paying fees as a part of the agreement.

The entrepreneur would then be required to act within the centralized exchange’s arbitrary framework.

The centralized ICO process can be arduous and, at times, disastrous.

Enter the dICO

Powered by Komodo’s AtomicDEX & Privacy Technology

The Komodo dICO model is an extension of Komodo’s AtomicDEX technology. AtomicDEX is an atomic-swap powered, decentralized exchange. It enables users to directly exchange cryptocurrencies from one person to another without third-party involvement (i.e. no centralized exchanges, escrow services, vouchers, etc.). Furthermore, as the dICO model is entirely decentralized, anyone can use it at will. There are no centralized authority figures capable of creating artificial control points that can be manipulated at the expense of the users

To begin the distribution process, the entrepreneur first chooses how many nodes they would like to use for the distribution. Nodes can be any type of machine capable of connecting to AtomicDEX. Typically, a small-business entrepreneur may choose to use server machines. Server capacity can be rented online, and the servers can be distributed geographically throughout the world, if desired.

While renting a multiplicity of servers may be the method of choice for an established small-business, it is not a requirement. An owner of an even smaller business, operating on a low budget, can simply use their own computer(s), geographically stationed nearby for convenience. On the other hand, a large corporation could use the server capacity they already own. The number and strength of the machines is a choice made by the entrepreneur.

Having decided the method of distribution, the entrepreneur will then prepare the total supply of coins. (We are assuming the coins are still located on the first device that mined the entrepreneur’s Genesis Block.) The entrepreneur will first break down the total collection of coins into smaller digital pouches. These small collections of coins are ultimately what will be traded on AtomicDEX with their audience.

The size of the collection is chosen by the entrepreneur, and therefore the entrepreneur can choose a size that is agreeable to their outlook on any KYC legal requirements.

Having created these collections of coins, the entrepreneur then sends them to all chosen nodes throughout the AtomicDEX network. Coins are distributed to each node’s wallet(s) by a normal transaction. With the coins distributed as desired, the entrepreneur sets the time and date when each collection of coins will be available for purchase. When a bag of coins becomes available on AtomicDEX for trading, members of the Komodo ecosystem simply purchase the coins.

The Many Solutions of the dICO Model: Security, Privacy, Decentralization, and Freedom

This method of conducting a decentralized initial coin offering mitigates and circumvents the issues found in a centralized ICO. The entire process is conducted in a decentralized manner. The dICO entrepreneur has direct access to their audience, as there are no centralized human authorities acting as middlemen.

Concerning theft, the dICO provides solutions to both methods of theft in the centralized ICO. Unlike the centralized ICO, once the distribution of the bags takes place the effect of their distribution adds a layer of security from a would-be hacker. The hacker can only steal funds at the node they manage to penetrate. Were the hacker to steal coins before the actual dICO, the entrepreneur would have the option to simply create a NEW ENTREPRENEUR’S COIN again, without losing any personal wealth.

Furthermore, since the trades happen instantaneously with each collection available for sale, the entrepreneur is only in possession of either their own ENTREPRENEUR’S COIN, or the cryptocurrency funds provided by the dICO participants—but not both. The entrepreneur is never at risk of losing both their own funds and the funds of their audience, which is a strong advantage over today’s ICO model.

Regarding human error, should one of the node’s databases be corrupted by accident or hardware failure, only one node’s coin supply is lost.

Since the coins are immediately available on the AtomicDEX exchange for trading, the entrepreneur’s audience has an immediate trading market. This stands in contrast to today’s ICO model, where users often wait weeks or even months before liquidity for their ICO product arises in a centralized exchange.

Finally, through Komodo’s inherent zero-knowledge technology, participants have the option of privacy when purchasing the dICO product. This enables them to support the crowdsourcing efforts of the entrepreneur within their inherent right to barter in private.

Upon conclusion of the distribution of the dICO coin supply the entrepreneur has successfully and immediately completed all the crowdsourcing-related steps that could have taken months in today’s typical ICO model.

Komodo’s dICO model is significantly easier, freer from manipulation, more flexible, and more secure.

AtomicDEX and Atomic Swaps

Introduction

Komodo’s decentralized exchange, AtomicDEX, allows people to trade cryptocurrency coins without a counterparty risk. The protocol is open source and trading is available for any coin that any developers choose to connect to AtomicDEX.

Our service fully realizes decentralized order matching and trade clearing. The order-matching aspect relies on a peer-to-peer network to build public orderbooks, and the trade clearing is executed through an atomic cross-chain protocol, also called an “atomic swap.”

Current Problems in Cryptocurrency Exchange

Centralized Exchanges are Popular, but Limited

The current, most practical method for cryptocurrency exchange requires the use of centralized exchange services.

These centralized solutions require vouchers to perform the exchange, wherein the user sends their funds into the care of a corporate entity and receives “I Owe You” (IOU) statements in return. The user then uses these IOUs to trade within a controlled environment and, when finished, returns their IOUs to the corporate entity for reimbursement.

Centralized exchanges carry great risk. Among many dangers present in this system, users are under the constant risk of their assets being stolen either by an inside theft or an outside hack. Furthermore, the operators of centralized exchanges are under intense legal and social pressure, as the operators are responsible both for the safety of thousands of users’ funds and for the users’ behaviors on their platforms.

To eliminate such dangers and limitations requires the creation of a decentralized alternative, wherein either the entity holding the funds during the trading process is not centralized, or the users are allowed to trade directly without middleman involvement.

The Beginnings and Travails of Decentralized Exchanges

A decentralized exchange (DEX) allows users to trade funds within an environment that is at least partially decentralized.

Decentralization of an exchange can take many forms. For example, in 2014 Komodo began one of the earliest instances of a decentralized exchange, called “The MultiGateway.”

In this DEX, users sent their blockchain coins not to a centralized entity, but rather to a decentralized “gateway.” The gateway was owned and controlled by several cooperating entities who were chosen from the online community. The gateway automatically distributed IOUs (called “proxy tokens”) to the users, who then traded within the partially decentralized environment.

When finished, users sent their proxy tokens back to the gateway, and the gateway managers collectively signed for the release of the users’ blockchain funds. The underlying technology of this solution is still in use by many blockchain platforms, and is sometimes referred to as a proxy-token protocol.

This form of a DEX is too limited to compete with centralized exchanges. Among many drawbacks, a proxy-token decentralized exchange must still have a storage center to hold the external cryptocurrencies represented by the proxy tokens. At best, this storage center is only distributed across several authority figures, and therefore users must still surrender control over their assets for the duration of the trading process.

As of today, no decentralized exchange has successfully replaced any of their centralized counterparts.

AtomicDEX — A Complete Solution

We now present a fully functional, new decentralized technology that makes a competitive decentralized exchange possible. We call our technology AtomicDEX, and it allows people to freely and safely exchange cryptocurrency coins from one person to another.

The AtomicDEX decentralized exchange creates a competitive method for bartering cryptocurrencies, combining the key components of order matching and trade clearing.

These components are combined into a single integrated system that allows users to make a request to trade their coins, find a suitable trading partner, and complete the trade using an “atomic swap.”

Unlike previous DEXs, AtomicDEX does not require users to send funds to either a centralized or decentralized party during the trading process. Rather, users maintain full control over the private keys of their funds at all times.

The Decentralized Orderbook

The first component of AtomicDEX is Order Matching. This is the process of pairing a user’s offer to buy with another user’s offer to sell. The data of these offers form an orderbook.

The process of matching orders is not the actual trade itself, but is only a digitally created promise between users stating that they will perform their parts of the trade.

AtomicDEX features several technologies to facilitate order matching, including a peer-to-peer network, a decentralized orderbook, and a multicoin passphrase.

Order Matching with Full-Relay and Non-Relay Nodes

To create a decentralized orderbook, AtomicDEX creates a custom peer-to-peer (P2P) network.

In this network, when a node places an order, other nodes on the network collaborate to distribute the data until all nodes are informed. Each node utilizes the data to build the orderbook locally. No centralized server is required.

To manage this P2P network, AtomicDEX utilizes two separate types of nodes: a full-relay node and a non-relay node.

The difference between a full-relay node and a non-relay node is that the former is typically a high-volume trader who provides liquidity to the network in exchange for being a trading hub on the network. This puts the trader in the position of being able to complete trades more quickly than their competitors.

The latter type of node (non-relay) is the more common user, and these nodes rely on the full-relay nodes. A non-relay node has all the same available trading options. We expect that most nodes joining the network will be non-relay nodes.

There are no requirements or payments necessary to become either type of node, and so anyone desiring to become a high-volume full-relay node will find no restrictions.

One Passphrase, Many Addresses

As a part of order matching, AtomicDEX features a specialty wallet that can manage and trade among a multiplicity of different blockchain coins. In this technology, the user creates a single passphrase and uses this to unlock all public addresses associated with their desired coins.

The complexities of this process are managed by Komodo’s Iguana Core technology.

Atomic Swaps

For trade clearing, AtomicDEX implements our own unique variation of atomic swaps.

An atomic swap is a technology that allows two users to trade cryptocurrencies across two separate blockchains without requiring an intermediary third party.

The original concept of an atomic swap was created in 2013 by Tier Nolan and many other Bitcoin enthusiasts on the Bitcointalk.org chat forum. In 2014, this conversation inspired members of the Komodo development team to experiment with atomic swaps, and they have remained a key technology in our strategy ever since.

The Value of the Atomic Swap

To understand why the atomic-swap protocol is necessary, one must first recall that computer code is executed in linear fashion. Even if we were to assume that both parties in a trade may be honest, on a computer the process of taking money from each digital wallet and pulling the money into the open must happen one wallet at a time.

Therefore, one person must release control over their money first. The atomic-swap protocol protects that person from vulnerability. Without the atomic swap, any malicious party involved would be able to destroy the fairness of the trade.

A key aspect of a proper atomic swap is that at each stage of the trade-clearing process, each user has incentives to proceed to the next step in the proper manner and disincentives to avoid abandoning the procedure. With this structure in place, regardless of a failure by either user to complete the protocol, each user receives a proper reward.

AtomicDEX Manages a Public Trading Profile for Bob and Alice

In addition to the atomic-swap protocol, AtomicDEX also allows users to track the behavior of trading partners on the network via a Trust API.

The Trust API is not based on personal identity, but rather on behavior as associated with public addresses.

As a user practices good behavior on the network while maintaining a consistent public address, their network trust can increase, thus improving their odds of a willing trading partner.

Use of the Trust API is optional for all users.

Introducing Alice and Bob

There are two parties in an atomic swap: the liquidity provider and the liquidity receiver. We call the provider “Bob” and the receiver “Alice.”

Alice Makes a Request

The process of an atomic swap begins with the person who makes the initial request. Typically, this is Alice.

Alice will need two transactions to perform her swap. One transaction will cover the protocol fee, which is roughly 1/777th the size of her desired order. We call this fee the <dexfee>, and its primary purpose is to serve as a disincentive to Alice from spamming the network with rapid requests.

The second transaction required of Alice sends the actual amount she intends to swap. AtomicDEX first verifies that she has these funds, but for the moment she retains these funds in the safety of her own digital wallet.

Bob Answers Alice

On the other side of the atomic swap, we have the liquidity provider—we call this person “Bob.” Bob sees the request on the network for Alice’s atomic swap and decides to accept the trade. Now his part of the process begins.

To complete the trade, he must also perform two transactions, but with one important difference.

The first transaction sends to the AtomicDEX network an amount equal to 112.5% of the amount that Alice requested. This acts as a security deposit. The network’s encryption holds the deposit safely in view, but untouchable. We call this transaction, <bobdeposit>.

When Bob completes his side of the bargain in full, or should Alice’s request for a swap time out, Bob will receive <bobdeposit> in return from the network.

The second transaction Bob makes will be worth 100% of what he and Alice intend to actually trade. The second transaction does not yet take place, however. Instead, the protocol requires that the transaction wait for Alice to continue with her part.

Note that Bob must hold liquidity of 212.5% of the total amount of the currency that he and Alice intend to trade.

Alice and Bob Are Committed

Assuming Alice and Bob are successfully connected, the process from this point forward becomes quite simple:

Here is a summary of the procedure, starting from the beginning.

1. Alice requests a swap and sends the <dexfee> to the AtomicDEX full-relay nodes.
   • The full-relay nodes receive her request and publish it to the network
2. Bob sees the request on the network, accepts it, and sends out <bobdeposit>
   • <bobdeposit> enters a state of limbo on the AtomicDEX network, held safely by encryption, awaiting either Alice to proceed, or for the swap to time out
   • If the latter occurs, <bobdeposit> is automatically refunded to Bob via the AtomicDEX protocol
3. Alice now sends her <alicepayment> to Bob
   • She does not send the payment to Bob directly, but rather into a temporary holding wallet on the AtomicDEX exchange
   • Only Bob has access to this wallet, via the set of private keys that only he owns
   • However, the AtomicDEX code does not yet allow Bob to unlock this temporary holding wallet; he must continue his end of the bargain first
   • The <alicepayment> will remain in Bob’s temporary holding wallet for a limited amount of time, giving him the opportunity to proceed
4. Bob now sends his <bobpayment> to Alice
   • Again, this is not sent to Alice directly, but rather into yet another temporary holding wallet
   • Likewise, only Alice has access to the necessary private keys for this wallet
   • The <bobpayment> will automatically be refunded if she does not complete her part of the process
5. Alice now “spends” the <bobpayment>
   • Here the word “spends” simply means that she activates her private keys and moves all the funds to another wallet—most likely to her own personal address
   • AtomicDEX registers that Alice’s temporary holding wallet successfully “spent” the funds
6. Bob “spends” the <alicepayment>
   • Likewise, Bob simply moves the entirety of the <alicepayment> into a wallet of his own—again, it will most typically be his own address
   • AtomicDEX now knows that Bob also successfully received his money
7. Seeing both temporary holding wallets now empty, the AtomicDEX protocol recognizes that the atomic swap was a complete success.
   • AtomicDEX now refunds <bobdeposit> back to Bob and the process is complete

While it may seem inefficient to have seven transactions for a swap that could be done with two, the complexity of this process provides us with the requisite “trustless-ness” to maintain user safety.

Incentives and Disincentives to Maintain Good Behavior

As we will now explain, at every step along the way there are incentives for each side to proceed, and there are various financial protections in place should one side fail.

Also, because payments are sent to these “temporary holding wallets” that exist within the AtomicDEX protocol, the protocol itself can assist in the process of moving money at the appropriate steps.

Let us now examine what is happening after each step.

1 – Alice Sends <dexfee>

If Bob accepts the offer to trade, but does not send <bobdeposit>, Alice only stands to lose her <dexfee>. This is only 1/777th of the entire transaction amount, so she loses very little.

Bob, on the other hand, stands to lose more. Since Bob did not follow through with his end of the bargain, the AtomicDEX network indicates on his public AtomicDEX trading profile that he failed in a commitment, thus decreasing his profile’s reputation. If Bob continues this behavior as a habit, he may find it difficult to discover trading partners.

So long as the frequency of “Bobs” failing is low, the occasional extra <dexfee> paid by an Alice is a minor issue. However, if there is a sudden spike in misbehavior, the AtomicDEX code has built in contingency plans which can provide refunds to Alice(s).

2 – Bob Successfully Sends <bobdeposit>

If Alice does not follow with her next step, the <alicepayment>, then Alice loses not only the <dexfee>, but she also receives a mark on her public AtomicDEX profile. She gains nothing, and Bob has no reason to fear as <bobdeposit> will automatically return to him via the AtomicDEX protocol.

3 – Alice Successfully Sends <alicepayment>

If Bob does not proceed with his next step, the <bobpayment>, then after 4 hours Alice can simply activate an AtomicDEX protocol that will allow her to claim <bobdeposit>.

Recall that <bobdeposit> is 112.5% of the original intended trade; Bob has every incentive therefore to continue with his end of the bargain, and Alice has nothing to fear should Bob fail. She even stands to gain a 12.5% bonus, at Bob’s expense.

4 – Bob Sends <bobpayment>

Now, if Alice does not follow by claiming the <bobpayment>, then after 2 hours Bob can activate an AtomicDEX protocol that allows him to reclaim his <bobpayment>. Furthermore, four hours later Bob may activate a refund of <bobdeposit>.

For Alice, the AtomicDEX protocol allows Alice to reclaim her <alicepayment> after Bob reclaims both of his payments.

At this integral stage of the process, every step of the path is intricately interconnected and maintains various levels of protection.

5 – Alice Spends <bobpayment>

At this point, Alice is entirely through with any risk to her reputation, her <dexfee> payment, or the loss of her time.

If Bob does not follow by also “spending” the <alicepayment>, it is of no concern to Alice because she has already received her funds. If Bob is simply sleeping and forgets to spend the <alicepayment>, he can only hurt himself.

Naturally, for Bob this is slightly dangerous. Bob’s best course of action is to remain alert and spend the <alicepayment> once it is received.

If after four hours, Bob is still sleeping, Alice can still activate the protocol that allows her to claim <bobdeposit>. In this scenario, she receives both the <bobpayment> and <bobdeposit>, at only the costs of the <alicepayment> and <dexfee>.

Bob can still make a later claim for the <alicepayment> when he regains his awareness.

6 – Bob Spends <alicepayment>

Assuming all has gone according to plan, and having spent the <alicepayment>, Bob may now reclaim <bobdeposit>. Just as before, if Bob does not refund his own deposit, it is his loss; in four hours Alice will be able to activate a claim on <bobdeposit>.

7 – Bob Reclaims <bobdeposit>

The process is complete. Alice received the <bobpayment>. Bob received the <alicepayment>. Bob has the <bobdeposit> back in his own possession. The entire process only cost Alice the original <dexfee>.

At each step along the way, the side that needs to take the next step is motivated to do so, with greater and greater urgency until the process is complete.

Additional Details

Always Manage Risk Appropriately

Naturally, users must understand that outside forces can disable the process and thereby damage one of the users. For instance, an Internet outage for Bob could be particularly dangerous. Therefore, users are advised only to trade manageable sums that they are willing to put at risk, and only with nodes that have reliable reputations.

The Connection is the True Challenge of an Atomic Swap

Performing a successful connection between Bob and Alice, and verifying their funds, is the most complex and difficult aspect of creating the AtomicDEX network.

Myriad factors are involved in a successful attempt for Bob and Alice to connect: human motivation; the experience level of the users; economics; connection technology; user hardware setups; normal variations within Internet connections; etc.

We emphasize to users here that the process of performing these actions over a peer-to-peer network has almost an artistic element to it. An attempt to successfully connect Bob and Alice can be thought of more like fishing, where we must simply cast and recast our line until we successfully connect with our target.

If a user attempts a trade and no response returns from the network, the user should slightly adjust the parameters of their offer and try again. As AtomicDEX continues to iterate and improve, and as the number of users increases, we expect any required effort to lessen for users, the network, and the AtomicDEX GUI apps.

The DEX Fee

People will notice that there is a small <dexfee> required as part of the AtomicDEX protocol. This is 1/777 of the transaction amount and it is calibrated to make spam attacks impractical. The 1/777 fee is about equal to 0.1287% of the <alicepayment>.

By forcing a would-be attacker to spend real money, attacking the network becomes costly. Without this spam prevention, the AtomicDEX could otherwise be attacked at the protocol level by any person performing a plethora of trade requests.

It is possible that some atomic swaps can initiate, and then fail to complete, which raises questions about what happens to the <dexfee> in this scenario. The <dexfee> is the first charge in the protocol; in this sense, there is a <dexfee> charged for these failed atomic swaps.

However, this failure should not be looked upon in isolation. The AtomicDEX protocol is based on statistics. Statistically speaking, there will be some percentage of atomic swaps that start and will not complete.

Let us suppose a 15% failure rate at this stage of the atomic swap (15% is three times higher than the rate of failure we currently observe in our testing). Even in this scenario, the effective <dexfee> cost is still only 0.15% to all Alice-side requests across the entire network.

If you experience the loss of a <dexfee> transaction for an atomic swap that fails to complete, know that this is all part of the statistical process. If you find yourself paying more than 0.15% of your completed trades in fees, please let us know.

As an organization, when speaking generally to our audience online, we state that the <dexfee> is just 0.15%. In this manner, we hope to create the expectation that 0.15% is normal; if the network performs perfectly, on the other hand, users will get a blessing in the form of a lower fee, 0.1287%.

Dealing with Confirmations

Since AtomicDEX is trading permanently on blockchains — as opposed to updating an internal database of vouchers — both sides of the trading pair need to wait and watch as miners on the respective blockchains calculate transaction confirmations.

Because the payments that occur on one blockchain will proceed regardless of the actions on the other blockchain — a confirmation failure on one chain will not stop with the other blockchain performing its duties as normal — it is therefore important that the AtomicDEX protocol observe and adjust as necessary.

Each side of the AtomicDEX protocol (Bob-side and Alice-side) watches and attempts to provide a level of protection for the human users. AtomicDEX achieves this protection by an array of <setconfirms> API calls, which gives each side the option to specify how many confirmations they expect before the automated process should be satisfied on behalf of the human users’ interests.

If the users have differing preferences for the total <numconfirms> they prefer, the AtomicDEX protocol automatically sets the larger of the two preferences as the requirement for both parties.

Furthermore, this feature also includes a <maxconfirms> value to prevent one side from specifying an unreasonable or malicious number of required confirmations.

Zero Confirmations

AtomicDEX also supports a high-speed trading mode. Using this feature, a user can activate an extremely fast mode of trading: <zeroconf>. This initiates a form of atomic-swap trading that does not wait for any confirmations at all. When using this feature, atomic swaps can be completed in as little as three seconds. This is a high-risk endeavor, naturally, and users should exercise extreme caution when implementing it.

AtomicDEX is Entirely Experimental, and Should Be Treated As Such

We should warn our readers, nevertheless. Every element of the Komodo ecosystem is still considered to be highly experimental. We provide no investment advice, nor any guarantees of any funds utilized on our network. Use our products only at your own risk.

The AtomicDEX API

We created an API model that is generally the same for all coins.

For more information, please turn to the AtomicDEX documentation.

The Antara Framework

Introduction

Antara is an adaptable framework for end-to-end blockchain development. This framework allows developers to build blockchain-based applications in a more simple, quick, and less resource intensive manner than ever before. The framework reduces the barriers to adopting blockchain technology and opens up a universe of possibilities.

The Three Layers of the Antara Framework

There are three layers to Komodo’s Antara Framework.

Generating Customizable Smart Chains

The first layer allows for the generation of a customized, independent chain called a Smart Chain.

Core-Level Antara Modules

Modules are inserted into the consensus mechanism of a Smart Chain that allow the developer to change the nature of the chain.

Antara Application Programmable Interface

The third layer is the technology that integrates a Komodo Smart chain with other software. This includes an open API for language-agnostic, blockchain-based application development, an atomic-swap powered DEX, and more.

Antara Smart Chains

Chains launched with Antara are not ordinary blockchains. They’re “Smart Chains.” They’re smart because they’re customizable, completely independent, scalable, and modular.

Smart Chains are customizable along 18 different parameters, allowing for customization of block time, block rewards, consensus rules, algorithm, privacy settings, and much more.

Smart Chains are also infinitely scalable, as multiple Smart Chains can be clustered together to function as one. Moreover, each Smart Chain comes with built-in modules that accelerate development. This leads to the second layer of the Antara Framework.

Antara Modules

Each Smart Chain comes with a library of powerful modules built-in. These modules include features like tokens, oracles, stablecoins, quantum security, lightning payments, and more.

Antara Modules are activated prior to launch to meet the unique needs of every project that builds with Komodo’s Antara Framework. They provide an enormous boost in performance and drastically reduce the workload for a new project, ultimately leading to a faster product launch.

Advanced developers can optionally program new modules, giving the developer complete freedom over their Smart Chain’s behavior.

Antara Integration Layer

The third layer of the Antara Framework is the Integration Layer. The Integration Layer offers a series of white label products, including a multi-coin wallet, a fully decentralized exchange, a decentralized crowdfunding application, custom block explorers, and SPV server integration.

The Antara Integration Layer also provides an open API that can be used to write blockchain-based applications and software in any programming language. All custom-built apps and software run natively and at the consensus level of each individual Smart Chain.

Antara Smart Chains

Antara Smart Chains are completely independent and sovereign.

Each Smart Chain has its own consensus rules, decentralized network, and currency. The consensus rules are decided prior to launch and the network validates transactions and blocks according to those rules. Transaction fees are always paid in each Smart Chain’s coin, not in the Komodo Platform’s native currency. Smart Chains never pay any gas fees to the platform.

While multi-chain platforms are on the rise, many of Komodo’s competitors do not offer true sovereignty. The chains offered on other prominent multi-chain platforms are “child chains” or “side chains.” Those types of chains are almost always forced to rely upon the platform’s parent chain in some way.

Antara Smart Chains never depend on the Komodo Platform, the Komodo blockchain, or the KMD coin. Komodo believes that this open model is the only way to create an ecosystem in which blockchain startups can thrive. Further, a forced dependence on the Komodo blockchain or the KMD coin may provide short-term demand but is sure to be self-defeating in the long run.

In addition, Smart Chains can also choose to participate in delayed Proof of Work (dPoW) security and Platform Synchronizations to enable interoperability and scalability features.

Antara Smart Chains are customizable along 18 different parameters, offering hundreds of billions of different configurations to all projects that build with Komodo’s Antara Framework.

Customization	Description
Name	the name of the Smart Chain and the ticker symbol for the chain’s coin
Block Time	the number of seconds that elapse between block generation
Consensus Rules	Proof of Work (PoW) or Proof of Stake (PoS) or a combination
PoS Implementation	VerusPoS rules or PoS64 rules
PoW Hashing Algorithm	Equihash or VerusHash
Privacy Settings	mandatory privacy, optional privacy, or complete transparency
Interoperability Settings	choose which chains your Smart Chain will communicate with
Pre-Mine Supply	the number of coins mined in the first block of the Smart Chain
Block Rewards	the number of coins awarded to a miner or staker for finding a block
Reward Reductions	the number of blocks between reductions in block rewards
Block Reward Decay	percentage by which block rewards decline at each reduction
Reward Eras	an optional feature to fully customize a chain’s coin emission schedule
Time Locking	the option to make block rewards frozen for a set number of blocks
Taxation	an optional, inflationary feature that generates a small tax for all transactions
Founder’s Bonus	optional feature that makes periodic payouts to the chain’s founder
Pub Key	designate the address to which pre-mine supply, tax, and bonuses are paid
Multi-Signature	the option to designate a multi-sig address to receive pub key payouts
Antara Modules	choose which Antara Modules that you would like to activate

Antara Modules

Antara Modules act as the foundation upon which advanced blockchain-based applications and software can be built. They offer an enormous level of functionality and cut down on the amount of time a new blockchain project needs to spend on development before going to market.

As they run natively on every individual Smart Chain, Antara Modules are faster and more secure than traditional smart contracts. They also run at the consensus level, meaning every module is verified by every node in the network upon each use.

In addition, Antara Modules are written in the C and C++ programming languages. Therefore, they are Turing complete and can be coded to perform any functions that any existing software performs.

Significantly, Antara Modules do not require any gas fees. Instead, a single use of a module requires just one ordinary transaction fee, which is always paid in each respective Smart Chain’s coin. This makes it far more practical and profitable to build and run a complex blockchain-based applications on Komodo than on any other multi-chain platform in existence.

All Smart Chains come with a library of powerful, built-in modules to choose from.

Module	Description
Tokens	create tokens (fungible or non-fungible) on your own Smart Chain
Oracles	use an aggregated data oracles solution to bring off-chain data on chain
Proxy Token DEX	trade tokenized representations of foreign blockchain assets
Instant Micropayments	a channel for secure and instant micropayments
Funds Recovery	allow users to designate a backup address to safeguard funds
Stablecoins	an algorithmic stablecoin solution with optional digital asset backing
Trustless Price Feeds	bring price data on-chain in a trustless, decentralized manner
Rewards	give users the option to earn rewards by locking coins for a set time
Quantum Security	make all transactions on your Smart Chain quantum secure
MuSig Payments	enable private, fast, low-data multi-signature payments
Faucet	an automated crypto faucet feature with built-in spam prevention

The option to code custom modules is also available to all Smart Chain projects. While coding custom modules is an advanced development task, it offers an unparalleled degree of flexibility and customization. Any processes imaginable can be coded into an Antara Module, which will then run natively and at the consensus level of a project’s Smart Chain.

Antara Integration Layer

The third and final layer of Komodo’s Antara Framework is the Integration Layer, which consists of an open API and a selection of white label applications to accelerate development.

Each Antara Module activated on a Smart Chain provides a number of remote procedure calls (RPC). Each individual call executes a different process and offers a unique functionality. Together, these RPCs from all of the Antara Modules make up the open API.

The Antara open API is language agnostic. Developers can use it to code blockchain-based applications in the programming language of their choosing. This makes Komodo’s Antara Framework the fastest, easiest, and most cost effective way to adopt blockchain technology.

Further still, the Antara Integration Layer comes with a series of white label products, available to every Smart Chain project.

• A multi-coin wallet that offers storage of more than 250 different digital assets
• A peer-to-peer crowdfunding app that allows every project to choose which digital assets they would like to accept in the fund raise. New coins are distributed immediately.
• A decentralized exchange powered by Komodo’s industry-leading atomic swap technology. This product allows peer-to-peer trading with unrestricted trading pairs.
• A custom block explorer to make your Smart Chain’s ledger publicly visible.
• Integration to SPV servers, which allows users to access their assets on mobile devices.

These products can be adjusted to fit any project’s branding, accelerating a go-to-market.

Additional Information

Details Regarding KMD Main Chain

Circulating Coin Supply:	~100000000
Total Coin Supply (yr. 2030):	~200000000

The foundational coin of the Komodo ecosystem is named after the ecosystem itself, Komodo (KMD).

Rewards

Those who hold KMD may earn rewards of up to 5.1% annually. Any wallet address that holds at least 10 KMD is eligible. KMD holders must simply move their KMD once a month—even if the funds are sent back to the same address from which they originated—in order to earn their reward. This reward is built into the core code of Komodo.

The reward comes from an opportunity provided by our unique security system, dPoW. The nature of the reward is rooted in the financial incentive that is typically given to miners on a normal PoW chain. On a normal PoW, when a miner mines a new block, the blockchain mints new coins and delivers them to the miner’s indicated wallet. For instance, on the Bitcoin blockchain, the reward for mining a new block is currently ~12.5 BTC. In dPoW, we do not need to allocate such a high incentive to miners, as we already maintain access to the hash rate of our chosen PoW network, Bitcoin. Therefore, when we created the KMD main chain, we recoded this coin-minting reward to distribute 5.1% annual rewards to all holders of at least 10 KMD.

To earn rewards in the full amount of 5.1%, users must move their funds on the blockchain at least once per month. The reward is calculated as a part of the utxo transfer process. The KMD code only calculates rewards for utxos up to one month, and then stops. By simply sending the full balance of a wallet to the same receiving address, a user can generate a new utxo. In this manner, the user can claim their current rewards, and continue receiving them for at least one month.

The KMD 5.1% reward will continue for a period of approximately twelve to fourteen years. When Komodo’s overall coin supply reaches ~200M, this reward will also discontinue. Specifically, the reward will cease when the KMD chain reaches a block height of 7777777.

Note that no one is forced into using KMD in our ecosystem. We are often asked why we chose this route, as the free nature of the Komodo ecosystem can be in direct contrast to the philosophies of many other ecosystems and exchanges. Other ecosystems often require users to use the developer’s coin.

The reason why we follow a more open practice is that we strive to adhere to the guiding principles of decentralization and open-source technology. We want to create a blockchain platform where people are free to use whatever is most useful for them in their entrepreneurial endeavors. Keeping KMD as an optional element empowers the members of the Komodo ecosystem with freedom.

The Nature of Privacy Features in the Komodo Ecosystem

The Option of Privacy is Essential

One primary goal of the Komodo ecosystem is to provide our users with the highest levels of security. The option to enable oneself with privacy is an inherent part of a strong security system. Privacy empowers users with the ability to make choices without being directly controlled or observed by a third-party actor.

Many of humanity’s most meaningful advancements in art, technology, and other human endeavors began in situations where the creator had the security of privacy in which to explore, to discover, to make mistakes, and to learn thereby.

Privacy Issues in Popular Privacy-Centric Blockchains

Across the entire cryptocurrency industry, current pathways to obtain privacy in the blockchain industry have many problems.

One of the most popular methods to obtain privacy is the use of a centralized mixing service. In this process, users send their cryptocurrencies to service providers, who then mix all the participants’ coins together, and return the coins according to the relevant contributions. With this method, the most dangerous issue, among many, is that for the duration of the mixing period users lose control over their currency. The funds, therefore, are subject to theft and human error.

Other decentralized coin-mixing methods, such as the coin shuffle, require coordinating with other human parties. This also introduces the potential for the same issues of theft and human error, and adds yet another risk: the coordination between human parties can result in the disclosure of a user’s privacy.

Some cryptocurrencies support mixing as a part of the normal transaction process out of a desire to provide constant anonymization. Varying methods for randomizing these transaction-mixing patterns exist among the many different brands of relevant cryptocurrencies, and each feature strengths and weaknesses in their approach.

Komodo’s Approach to Privacy Technologies

The roots of the Komodo ecosystem stem from the seminal work of Satoshi Nakamoto and his Bitcoin protocol. One of the key challenges in this technology is that the original protocol does not make any account for privacy. Therefore, Komodo began not as a fork of the vanilla Bitcoin protocol, but rather as a fork of Zcash. The latter is a privacy-centric fork of Bitcoin, and therefore Komodo inherits technology from both Bitcoin and Zcash by this action.

The Komodo Smart Chain software, komodod, retains the inherent privacy features of Zcash. These primarily consist of the ability to convert money from a transparent address to a private address, and then to transfer money from one private address to another. When sending money that is already private to an address that is also private, Zcash technology allows the funds to move without leaving a public data trail for later analysis.

This is one of the most powerful forms of blockchain privacy in existence, as the provided privacy is effectively permanent.

Private and Non-Private Addresses

On any privacy-enabled Smart Chain, there are two types of addresses. One is transparent, the other is private.

Transparent Addresses

We call a transparent address a “T address.” These are fully accessible to the user, and they are the means of conducting normal transactions. All currency entering and leaving a T address is fully visible to the network.

The user must use these addresses for most interactions on-chain, including most, if not all, of the Antara Module transactions, and when using AtomicDEX.

Private Addresses

We call a privacy-enabled address a “Z address,” as they utilize the Zcash parameters and zk-SNARK technology.

Z addresses often have RPCs that are separate from the RPCs used for T address. For example, z_gettotalbalance is separate from getbalance.

The cost of interacting with Z addresses is often higher than the cost of interacting with a T address. This is due to the fact that Z transactions require more block space, due to their demands for increased levels of encryption.

Method of Moving Funds Privately

There are three types of transactions that can take place in respect to privacy technology.

Transparent to Private

---

T -> Z

---

A user uses the z_sendmany RPC to send funds from a T address to a Z address.

This is not a private transaction. An observer of the blockchain can observe both the T address from which the funds are consumed and the Z address to which the funds are sent.

Private to Private

---

Z -> Z

---

This is a private transaction. Using zk-SNARK technology inherited from Zcash, this transaction moves funds from one address without leaving any data available in the public domain for later observation.

So long as the user does not reveal any information regarding this transaction, no other party may ever know the amount, specific time, or destination of funds in this transaction. The user may also consider enhancing their privacy through services such as Tor.

All privacy from zk-SNARK technology is derived solely as a part of this type of transaction.

Private to Transparent

---

Z -> T

---

This is not a private transaction. Rather, this is the transaction wherein funds again become public, and therefore usable for services such as a typical Antara Module or an AtomicDEX exchange.

Observers on the blockchain can observe both the Z address from which the funds are consumed and the T address to which the funds are sent.

Additional Privacy Considerations

Although the anonymization process provides a measure of privacy and may appear to be sufficient, there are still more precautions a user must take. Two main attacks are available to a would-be sleuth.

The Timing Attack

In this attack, the sleuth simply studies the time the funds disappear from a T address and looks for funds to appear in another T address soon thereafter. If the privacy-user persistently chooses predictable timing for initiating and completing their transfer of funds from a T address, through a series of Z addresses, and back to a public T address, a determined sleuth may deduce the user’s trail of funds.

For effective privacy, the user should wait for other users on the Smart Chain to exercise privacy transactions, and thereby conceal their own privacy behavior. The more users using privacy features, the more private the transactions become.

The Knapsack Attack

The Knapsack Attack is similar to the Timing Attack, but as applied to amounts. For example, if there is only one KMD address that sends 1000000 KMD from a T address to a Z address, and later 1000000 KMD emerges from a Z address to a T address, the sleuth can easily discern the user’s trail of funds.

To protect against the Knapsack Attack, users can vary their amount of funds in both T -> Z and Z -> T transactions.

A Word on Risks Inherent in zk-SNARK Technology

Zero-knowledge transactions rely on the Zcash parameters as put forth by the Zcash team. The Zcash parameters are a “zero-knowledge” form of technology. This is a powerful form of privacy, and arguably superior to other forms as it is effectively permanent. Relying on the Zcash parameters allows us to turn our creative resources to other blockchain-technology challenges, while still empowering members of the Komodo ecosystem with the option of privacy.

To create the Zcash parameters, the original Zcash developers had to create a series of keys that, when combined, created a master key that could unlock and lock the parameters. After using the master key to create the parameters, the team destroyed every individual key. The team conducted this endeavor in a public manner. We encourage interested readers to view the “Zcash Ceremony” explanation, and to search for other viewpoints as well.

To briefly summarize the security measures, the Zcash team used several layers of protection including: multi-party computation, air-gapped compute nodes, hard-copy evidence trails, a uniquely crafted distribution of the Linux operating system, and the physical destruction of each piece of hardware that held an individual key. The resulting layers of defense would be of the highest level of difficulty for an outsider to penetrate. Furthermore, the method of creation and destruction ensured that the internal security of the project was faultless, so long as at least one member of the entire Zcash team was honest.

By our observation, the team performed this endeavor with sufficient competence and due diligence. Furthermore, given the nature of the project, the longstanding reputation of the Zcash developers, and the modus operandi of their lives’ work, we believe they were properly motivated to perform the creation and destruction in a capable and honest manner.

Nevertheless, there are privacy advocates in the cryptocurrency industry who maintain a degree of suspicion over any project that requires an element of human trust. This suspicion extends to the Zcash parameters. These observers continually scrutinize the Zcash project, searching for more and more processes by which the creation ceremony could have failed. Yet, while various theories have been put forth, no actual failure in the Zcash parameters has been discovered.

In adopting the Zcash parameters, we receive frequent questions regarding how they affect Komodo-based currency. The answer is that the privacy in the Komodo ecosystem is permanent, regardless of any potential fault by the Zcash team. Furthermore, we can adopt any updates the Zcash team releases to the parameters.

In the unlikely event that someone was able to retain a complete copy of the master key, the only power the holder would have, would be the ability to create new private money in the currency of any Smart Chains utilizing zero-knowledge transactions.

This holder could then shift that value into transparent, spendable money. This could negatively impact any affected Smart Chain’s local community, and we would be required to adapt our platform. If a fault in the Zcash parameters were to be discovered, the Komodo team has various contingency methods at our disposal to remove the Zcash parameters and replace them with a new set of parameters.

Though in Komodo we do not see this as a realistic threat, we nevertheless include the information here in our documentation to provide complete transparency for any user who seeks to invest their resources in a privacy-enabled Komodo Smart Chain.

The Utxo: An Elusive, Yet Fundamental Concept

All Bitcoin-based software relies heavily on a technology called the “utxo,” short for Unspent Transaction. This technology was invented in the original Bitcoin protocol. Yet despite the technology’s age, even the most active of cryptocurrency users rarely know what utxos are or why they exist.

To better understand utxos, let us first examine the language of a common user when describing how much cryptocurrency money they have and how they perceive those funds. We will therefore need to understand the concept of “satoshis,” the way a blockchain handles the collection and distribution of funds, and how we utilize these core technologies when trading on AtomicDEX.

Comparing the Utxo to Fiat Money

Let us assume a cryptocurrency user, whom we name Charlie, has $10,000 in his physical wallet. Naturally, when Charlie thinks about the amount of physical (or “fiat”) money he has, he says to himself, “I have $10,000.”

However, there is no such thing as a $10,000-dollar bill. Instead, Charlie actually has a collection of smaller bills stacked together. For instance, he could have a stack of $100-dollar bills, the total of which equals $10,000 dollars.

If Charlie goes to purchase an item that costs $1, and he only has $100-dollar bills in his wallet, to make his purchase he will take out a single $100-dollar bill and give it to the cashier. The cashier then breaks that $100-dollar bill down into a series of smaller bills. The cost for the item, $1, remains with the cashier, and the cashier then provides change—perhaps in the form of one $50-dollar bill, two $20-dollar bills, one $5-dollar bill, and four $1-dollar bills.

Charlie now thinks to himself, “I have $9,999.” Specifically, however, he has ninety-nine $100-dollar bills, a $50-dollar bill, two $20-dollar bills, one $5-dollar bill, and four $1-dollar bills.

We emphasize that not only does he not have ten thousand $1-dollar bills, he also does not have one million pennies ($0.01). Furthermore, because pennies are the smallest divisible unit of value in Charlie’s wallet, we could point out that each bill is a collection of its respective units of pennies. For instance, a $1-dollar bill in Charlie’s wallet we could describe as, “a bill that represents a collection of one hundred pennies and their value.”

Understanding Cryptocurrencies and Their Utxos

A Satoshi is The Smallest Divisible Unit of a Cryptocurrency

Continuing with our explanation of utxos, we next need to understand the concept of “satoshis.” The name “satoshi” is derived in honor of Satoshi Nakamoto, author of the original Bitcoin whitepaper. By convention in the cryptocurrency community, one satoshi is equal to one unit of a coin at the smallest divisible level. For instance, 1 satoshi of Bitcoin is equal to 0.00000001 BTC.

Let us suppose now that Charlie has 9.99000999 BTC (Bitcoin) in his digital wallet. Assuming Charlie correctly understands the concept of satoshis, Charlie could say to himself, “I have nine hundred and ninety-nine million, nine hundred and ninety-nine satoshis of bitcoin.” This is how Charlie might mentally perceive the collection of money that exists in his digital wallet, like he perceives the $9,999 in his fiat wallet.

A Utxo is a Collection of Satoshis, just as a Fiat Dollar Bill is a Collection of Pennies

Recall now that with fiat money, Charlie did not think about how his original $10,000 was comprised of smaller individual $100-dollar bills. Similarly, Charlie also does not think about how his 9.99000999 BTC could be comprised of smaller collections of satoshis.

Furthermore, just as Charlie did not carry around fiat money as a collection of pennies, he also is not carrying around a raft of satoshis. Were he to try to carry a million pennies in his physical wallet, the weight of the wallet would be unmanageable. Similarly, if the Bitcoin protocol were to attempt to manage nine hundred and ninety-nine million, nine-hundred and ninety-nine satoshis, the “data weight” would be so heavy, the Bitcoin protocol would be enormous and unmanageable.

To optimize “data weight,” the Bitcoin protocol therefore bundles up the satoshis into something that is like the example of dollar bills earlier, but with one important difference. In fact, here is where the Bitcoin protocol exercises a superiority over fiat money by deviating from the limitations fiat money must obey when bundling smaller values into larger values.

In fiat money, one hundred pennies are bundled into a one-dollar bill, which can then be bundled into a larger bill, and so on. All the sizes of fiat money are preset and predetermined by the issuer of the fiat money when they print their bills and coins.

The Bitcoin protocol, however, does not need to pre-plan the sizes of “bills” (i.e. the collections of satoshis) in the owner’s wallet. Bitcoin is freer in this sense; it can shift and change the sizes of its “bills” at will because there is no need to accommodate for the printing of physical coins and paper.

Instead, the Bitcoin protocol allows for the developer of digital wallets to write code that can optimize how bitcoin satoshis are packaged into “bills,” and thus the community of developers can work together to keep the data weight of the blockchain manageable. The better the digital-wallet developer, the more efficient the size of the “bills” (a.k.a. the collections of satoshis).

The Bitcoin protocol does have one limitation, however: It must keep track of how these satoshis are being collected into larger “bills” in everyone’s digital wallets. After all, a key idea of Bitcoin is that everything happens under the public eye, where it can be verified.

Because the Bitcoin blockchain must keep track of the sizes of these collections of satoshis, the only time the collections can be assembled or disassembled into larger and smaller sizes is at the moment when the user is spending money on the public blockchain. It is at this time that the user is under the public eye, and therefore his actions can be verified.

To compare this limitation to fiat money, consider the effect created were Charlie to cut a $100-dollar bill into smaller pieces. The $100-dollar bill would no longer be respected as a valid form of currency.

As the word, “utxo,” is not a sonorous word, some users in the Komodo ecosystem simply refer to utxos as “bills.” The concept is effectively the same. However, as the rest of the blockchain industry primarily uses the word “utxo,” we frequently must use this word to maintain a common line of communication. The word utxo will be used throughout the rest of this documentation, to keep in line with industry practices.

The utxo collection can be any size, and the developer of the GUI software decides on this process. Most importantly, and to reiterate, a utxo can only be resized during the process of spending, as this is the moment when the user interacts with the public blockchain.

To further clarify this, let us return to Charlie’s example with fiat money. Recall that when Charlie went to purchase a $1-dollar item, he only had $100-dollar bills in his wallet. He had to give out one $100-dollar bill, and then receive a broken-down collection of dollar bills in return.

This is exactly how it works with utxos. Charlie has a collection of utxos in his digital wallet. When he goes to buy something, he will give out utxos until he surpasses how much he owes, and then the extra change from the last utxo used will be broken down and returned to him.

For example, let us suppose that Charlie’s 9.99000999 BTC is comprised of three utxos worth the following values:

Utxos in Charlie’s Wallet	Value
Utxo #1:	0.50000000 BTC
Utxo #2:	0.49000999 BTC
Utxo #3:	9.00000000 BTC
Total	9.99000999 BTC

Charlie now desires to purchase an item that costs 0.60000000 BTC. He will have to hand out enough utxos from his wallet until he covers the costs of this transaction, just as he would if he were using fiat money. The Bitcoin protocol calculates the change from the transaction and then returns his change to him.

Remember that there is a fee when spending money on a blockchain. Since we are using Bitcoin in this example, the fee would be paid to cryptocurrency miners. Let us imagine that the fee the miners charge Charlie is 999 satoshis.

We begin by looking at how Charlie would see the process of making the purchase, assuming he does not understand the concept of utxos. For now, Charlie only understands how much is in his wallet at the satoshi level as he conducts his transaction.

Value	Description
9.99000999 BTC	The amount Charlie initially owns
(-) 0.60000000 BTC	The amount Charlie sends to the digital cashier for his purchase
(-) 0.00000999 BTC	The network fee paid to miners
——————	—————————————————————–
9.39000000 BTC	The amount left in his wallet

This deduction for his purchase all appears very simple to Charlie—a testament to the Bitcoin protocol’s effective design.

In the background, however, the digital wallet handles the utxos and the change process in a manner as determined by the programmer. In Charlie’s example, let us assume that it proceeds this way:

Value	Description
0.60000999 BTC	The total amount that Charlie owes to the cashier and network
(-) 0.50000000 BTC	The wallet sends the full value of utxo #1 to the digital cashier
————————	————————————————————————
0.10000999 BTC	This is the remaining total amount that Charlie still owes

The wallet now brings out utxo #2, which is worth 0.49000999 BTC:

This utxo is broken down or shattered into smaller pieces.

Value	Description
0.49000999 BTC	The size of Charlie’s utxo #2, now in the process of change
(-) 0.10000000 BTC	This shatter of utxo #2 goes to the cashier (payment fulfilled)
(-) 0.00000999 BTC	This shatter of utxo #2 pays the network fee to the miners
——————–	———————————————————————-
0.39000000 BTC	This last shatter now returns to Charlie’s wallet as a new utxo

Charlie now has one new utxo in his wallet, and it is worth 0.39000000 BTC:

Charlie’s New Wallet State	Value
Utxo #3:	9.00000000 BTC
Utxo #4:	0.39000000 BTC
—————————-	—————-
Total	9.39000000 BTC

If Charlie wants to buy something later, these utxos will have to be broken up once more, according to the costs and programming of the digital wallet. Again, whatever is left over from his last utxo comes back to his own wallet as a new utxo.

Now let us suppose that Charlie receives 0.4 BTC from someone else. In Charlie’s wallet, he will see a total of 9.79 BTC. However, in his wallet there are now actually three utxos:

Charlie’s New Wallet State	Value
Utxo #3:	9.00000000 BTC
Utxo #4:	0.39000000 BTC
Utxo #5:	0.4000000 BTC
Total	9.79000000 BTC

As a result, the number and sizes of utxos in Charlie’s wallet will vary over time. He may have many smaller utxos that make up his full balance, or sometimes he might just have one large utxo that comprises all of it. For Charlie, it is normally possible to ignore this since the wallet developer could handle everything automatically.

However, a developer in the Komodo ecosystem will likely encounter the concept of utxos in the course of software development, and therefore we encourage developers to practice their understanding.

Conclusion

This concludes a thorough explanation of the foundational technologies of the Komodo ecosystem. We are working diligently to improve the user experience. While some may say that the cryptocurrency industry is but a bubble, at Komodo we believe we have not yet begun the fight. We hope that the innovations we provide will be a meaningful contribution to the remarkable advent of blockchain, decentralization, and open-source technologies.

Acknowledgements and References

• BarterDEX – A Practical Native DEX ( https://github.com/SuperNETorg/komodo/wiki/barterDEX-Whitepaper-v2 )
• Nakamoto Satoshi (2008): Bitcoin: A peer-to-peer electronic cash system. ( http://www.bitcoin.org/bitcoin.pdf )
• Mtchl (2014): The math of Nxt forging ( https://www.docdroid.net/ahms/forging0-4-1.pdf.html )
• King Sunny, Nadal Scott (2012): PPCoin: Peer-to-Peer Crypto-Currency with Proof-of-Stake ( https://peercoin.net/assets/paper/peercoin-paper.pdf )
• Delegated Proof-of-Stake Consensus ( https://bitshares.org/technology/delegated-proof-of-stake-consensus/ )
• Miers Ian, Garman Christina, Green Matthew, Rubin Aviel: Zerocoin: Anonymous Distributed E-Cash from Bitcoin ( https://isi.jhu.edu/~mgreen/ZerocoinOakland.pdf )
• Ben-Sasson Eli, Chiesa Alessandro, Garman Christina, Green Matthew, Miers Ian, Troer Eran, Virza Madars (2014): Zerocash: Decentralized Anonymous Payments from Bitcoin ( http://zerocash-project.org/media/pdf/zerocash-extended-20140518.pdf )
• Ben-Sasson Eli, Chiesa Alessandro, Green Matthew, Tromer Eran, Virza Madars (2015): Secure Sampling of Public Parameters for Succinct Zero Knowledge Proofs ( https://www.ieee-security.org/TC/SP2015/papers-archived/6949a287.pdf )
• NXT Community: NXT White paper ( http://wiki.nxtcrypto.org/wiki/Whitepaper:Nxt )
• Larimer Daniel, Scott Ned, Zavgorodnev Valentine, Johnson Benjamin, Calfee James, Vandeberg
• Michael (March 2016): Steem, An incentivized, blockchain-based social media platform.( https://steem.io/SteemWhitePaper.pdf )
• BitFury Group (Sep 13, 2015): Proof of Stake versus Proof of Work White Paper ( http://bitfury.com/content/5-white-papers-research/pos-vs-pow-1.0.2.pdf )