A Look Back at jl777’s Blockchain Declaration of Independence, 4 Years On

DanielFebruary 21, 2020


Four years ago, on February 21, 2016, James ‘jl777’ Lee published the Blockchain Declaration of Independence. The ideas James expressed in this open letter were far ahead of their time and eventually served as the foundational concept upon which the Komodo Platform was born.

Today, the Komodo Team would like to reflect on all of the growth and development that Komodo has accomplished. It’s been four years of non-stop innovation and, every now and then, it’s helpful to take a step back and appreciate the amount of progress that’s been made. 

Much has happened in the time since James published the declaration, but, to tell the full story, we need to go even further back in time. The story of James’s declaration of independence actually begins six years ago, in February 2014.

A banner image for the blockchain declaration of independence blog post

Setting The Scene: The Blockchain Industry In Early 2014

Let’s recall the state of the blockchain industry back in 2014. The Bitcoin blockchain had been humming along for a full five years and was just beginning to gain mainstream popularity. A significant amount of recent media coverage of Bitcoin generated curiosity among the general public. This created an influx of new users and investors, sending the price of Bitcoin skyrocketing in late 2013.

In October and November of 2013, the price of Bitcoin exploded, shooting from $125 per BTC on October 8 all the way up to $1,126 on November 30. That’s an increase of 900% in just seven weeks. It was the first time that the price of BTC had reached four figures, and the last time the price of BTC would ever sit below $180. 

The price retreated quickly in December, spiked briefly in January, and then continued to fall through all of February and the rest of the year. Despite falling sharply from the highs of late November 2013, the price of BTC fluctuated between $840 and $530 in February 2014, still an increase of more than 500% in the four months since October 2013.

Price of BTC in 2013 and 2014

In the midst of the excitement and bullish price action, there was a catastrophe within the Bitcoin community: the hack of the Mt. Gox exchange. While exchange hacks have become routine over the years, the attack on Mt. Gox was different. It can be easy to forget how massive the Mt. Gox hack really was. 

Hackers stole an estimated 850,00 BTC from Mt. Gox. A total of 750,000 of those BTC belonged to users (the remaining 100,000 belonged to Mt. Gox). Even if we only take users’ funds into consideration, the theft of 750,000 BTC makes the Mt. Gox hack the largest in history by an enormous margin.

Let's put things into perspective. The second-largest Bitcoin heist on record resulted in a loss of 125,000 BTC from the Bitfinex exchange in August 2016. At the time, that was a theft of $65 Million— a staggering loss, but nothing compared to the Mt. Gox hack.

The Mt. Gox hack was about six times larger, both in the quantity of BTC stolen and in the fiat value of the BTC stolen. The 750,000 BTC stolen represented a full six percent of the BTC supply at the time. The value of the 750,000 BTC stolen in the Mt. Gox hack— even back in February 2014, when the price was comparatively low— was around $450 Million. Today, that same sum of BTC would be worth about $7.2 Billion.

The Bitcoin community had already withstood a few exchange hacks throughout 2012 and 2013. In the spirit of decentralization and in the name of security, many within the Bitcoin community were already discussing the need for trading methods that didn’t require a trusted third-party. However, prior to the Mt. Gox attack, there were few serious attempts to create such a technology.

The Mt. Gox hack was significant enough that the need for decentralized trading could no longer be ignored. If everyone was storing their BTC on the same centralized exchange, it became the perfect target for hackers. No level of security would be sufficient to ward off attackers; the incentives are simply too strong. 

James ‘jl777’ Lee among the first to recognize the need for decentralized trading, and he was also among the first to build the technology that made decentralized trading possible. 

The Early Days: MultiGateWay (MGW) & SuperNET

The first project that James ‘jl777’ Lee ever led was called MultiGateWay (MGW). Built on the NXT platform, one of the earliest platforms in the blockchain space, the MultiGateWay allowed users to lock Bitcoin and other UTXO-based assets into a multi-sig wallet, withdraw NXT-based tokens that represented those real assets at a 1:1 ratio, and then trade the tokenized derivatives in a peer-to-peer manner on the NXT Asset Exchange.

While MGW didn’t provide fully non-custodial trading, it was the one of the first proxy token decentralized exchanges in the blockchain space. Users had to lock their coins in a multi-sig wallet, thus forfeiting sole custody of those funds, but at least all user funds were not sitting in a single wallet controlled by a single person, as was the case with Mark Karpelès and Mt. Gox.

The initial proposal for the Multi-GateWay was made over six years ago, on February 12, 2014. James stated the purpose of MGW very clearly in this first proposal:

I want to have a way for everyone to be able to trade cryptos in a decentralized way with a minimal amount of trust required.

This seems like a commonplace comment in the context of the present day, but it was visionary in 2014. If Komodo’s leadership with respect to decentralized trading technologies are ever in question, one can simply read through these old forum posts for confirmation.

The first commit to the MGW GitHub repo was made on February 28 and things took off quickly from there. James posted an update thread in late March to inform the community that the deposit side of MGW was “almost fully coded.” A guide to MGW was published in late May and a MGW bounty campaign to bring in new users was launched in July.

Not long after, in August 2014, James announced a second project that he would be spearheading: SuperNET. SuperNET was a separate project from MGW but the two worked together in tandem to create a decentralized trading ecosystem. As the name implies, the MultiGateWay served as the gateway between various Bitcoin-protocol coins— BTC, LTC, DOGE, etc.— and the NXT tokens that represented those real coins.

SuperNET was the entity that created and issued the tokens on the NXT platform. They took names like SuperBTC, SuperLTC, and SuperDOGE to both indicate that they were SuperNET-issued proxy tokens and to state clearly which real coin they represented. 

It’s important to note that these SuperNET assets were just tokens created on the NXT blockchain, in exactly the same way that ERC-20 tokens are created on the Ethereum blockchain. The developer who creates the tokens does not have a sovereign blockchain; instead, they are paying fees to use someone else’s blockchain. Fees are always paid in the platform’s coin, not in the token that the developer created. 

This was also true of MGW and SuperNET; they were simply third-party applications built on the NXT blockchain. The assets that SuperNET issued were NXT tokens. All fees were paid in NXT to the NXT platform. James Lee was not part of the NXT team, nor did he have a hand in the development of the platform itself. At that time, he was a third-party dApp developer.  

It’s also worth pointing out that the NXT Asset Exchange, where users could swap their SuperNET assets with one another, was very similar to Ethereum token exchanges like 0x and Loopring. These exchanges are not centralized, as they use smart contracts to enable peer-to-peer trading, but they only support tokens created in the Ethereum ecosystem. The same was true for the NXT AE— it only supported NXT tokens, but users could make swaps without a trusted intermediary. 

For over a year, the dApp ecosystem that James had built was thriving. MGW and SuperNET were both experiencing a significant amount of adoption and usage. Everything was going well, until the NXT Dev Team announced version 1.6 of the NXT code base.

NXT Platform Pushes A Non-Backward Compatible Update

On October 21, 2015, a Core Dev from the NXT team named Jean-Luc announced that two new versions of the NXT code base were coming soon: v1.6.2 and v1.7.1. He stated that the update to v1.6.2 was optional but the update to v1.7.1 would be mandatory. 

Just a few days later, members of the NXT community began to notice various bugs with the updates. It soon came to light that the update contained changes to various API calls, making the update non-backward compatible with apps built on previous versions of the NXT code base. This, of course, included both the MGW and the SuperNET projects. 

Regrettably, it was not the first time the NXT team had pushed an update that was not backward compatible. About a year before, the NXT team released a mandatory update that broke a number of important API calls. This caused problems for MGW and SuperNET but, after some discussion with the NXT team, James fixed the software. The NXT team promised to never again push an update that was not backward compatible. As it turns out, this promise was not honored.

On November 3, 2015, one community member asked, “Why do you break backward compatibility? I thought everyone agreed that you should not do it without prior notice.”

James chimed in not long after, referencing the NXT team’s previous promise to keep all future updates backward compatible:

The agreement was to not break [backward compatibility] period, short of severe security issues. Notice is meaningless when there are dozens of websites that real customers are using that all break and show very distressing numbers about people's accounts.

Saying that all that is required is to change how an API is issued is not acceptable as there are many websites that use the API and updating all of them is not practical.

PLEASE DO NOT BREAK BACKWARDS COMPATIBILITY.

That same day, a different Core Dev from the NXT team responded, saying that the NXT team would “post a detailed explanation of the reasons for these changes and detailes [sic] about more upcoming changes - tomorrow.”

On November 6, NXT Core Dev Jean-Luc posted a thread explaining the rationale behind the latest updates to the code base. Ultimately, he confirmed that “all clients of the APIs that are affected by the changes must be updated, and we will document in detail which APIs have been changed to make that easier. There will be no reversal in 1.6.3.” In other words, Jean-Luc confirmed what everyone already knew— the promise of backward compatibility had been broken. 

Weeks of discussion and debate ensued. Ultimately, the NXT team stuck to their guns and refused to reverse the updates or to make adjustments that would preserve backward compatibility. 

This left both MGW and SuperNET in ruins. Not only would it require hundreds of hours of work to make the two projects compatible with the new API, but the NXT team had introduced a new fee structure that was ten times higher than the previous versions of the software. 

With this new 10x fee structure in place, it was unlikely that MGW and SuperNET would remain economically viable in the NXT ecosystem, even if James had spent the time updating them to be compatible with the latest version of the NXT software. Nobody would want to use the apps because the fees would simply be too high.

So, rather than rebuilding within an ecosystem that pushed non-backward compatible changes and increased fees tenfold without prior warning, James decided to find a new environment in which to build his future projects:

The NXT devs lack a fundamental understanding about business reality and I am extremely disappointed in the breaking of the promise to keep things backward compatible. The ONLY exception is if there is an attack vector. Local node performance is not any excuse. …

Due to this, I am rethinking my reliance on NXT for SuperNET…. I cannot rely on NXT for any important SuperNET functions.

While this event was a catastrophe at the time, it ended up being a blessing in disguise. It showed James that a single-chain platform architecture would never be successful. Businesses need full sovereignty over not only their finances but also over development decisions. 

jl777’s Blockchain Declaration of Independence

For a brief time after leaving the NXT ecosystem, James joined the BitcoinDark project. James had previously collaborated with the BTCD here and there while working on MGW and SuperNET, but now he was joining the team in an official capacity. It was also the first time James had been in a core blockchain development role, rather than a dApp development role.

At first, BTCD seemed like a good candidate for a new environment in which to build future apps and decentralized exchange technologies. BitcoinDark offered significant privacy features and offered a blockchain to build upon without fear of incompatible changes or fee hikes. 

Ultimately, James realized that building third-party software or applications on any single blockchain would always be a problem, regardless of which blockchain it was. The solution was to design a platform that gave every business an independent, application-specific blockchain with full autonomy. Not just a dedicated blockchain for himself, but one for everyone and anyone who wanted to use blockchain technology.

This is what led to the Blockchain Declaration of Independence.

We the asset holders hereby declare our independence from any single blockchain.

An open and jointly developed specification on cross chain atomic asset transfers will be developed. Any current or future blockchain is invited to join. … 

The reality is that everything in crypto trades against BTC. One of the conditions for cross chain assets is the ability to trade directly against BTC, preferably native BTC and not a derivative. I will be working on a reference implementation as a first draft and look forward to collaborate with all other asset oriented projects.

This is an interop standards effort and it needs to be blockchain agnostic and asset centric.

This statement is significant for a number of reasons. First and foremost, it served as the foundational idea for Komodo. Eventually, the BTCD core dev team, small though it was, all migrated to the Komodo project. BTCD holders were also allowed to swap their coins for KMD. 

Second, it introduces ideas that are now commonplace but, at the time, were not part of the industry conversation. Very few people were talking about blockchain interoperability standards and atomic swaps in early 2016, but James Lee was one of them.

Now, of course, these are everyday topics of interest in the blockchain space. Fast forward to 2018, and giant companies like Accenture, IBM, and PwC were all talking about blockchain interoperability standards. 

Atomic swaps have become a technology that nearly every DEX project claims to be working towards, although none but Komodo have ever released a product that allows users to make these elusive atomic swaps. In 2019, Forbes published a full-length article on atomic swaps, citing Komodo as “an atomic swap early adopter.”

On top of all that, the declaration also demonstrates the collaborative and open source ethos that Komodo has always embraced. Komodo has always desired cooperation over competition and celebrates the technological advancements of all blockchain projects.

Lastly, the declaration shows that James understood the challenges facing the blockchain industry long before most developers. And not only did James understand the limitations, he had a vision for the solution. What was that solution? A multi-chain design that gives every third-party business an independent, application-specific blockchain.

The Necessity of Multi-Chain Architecture 

While NXT was one of the earliest blockchain platforms, it implemented the same design of pretty much every other smart contract platform. The model works as follows.

There is one blockchain with one decentralized peer-to-peer network. This one blockchain has several features that allow third-party developers to build on top of it. For instance, businesses can launch tokens or run dApps on the platform’s blockchain. These businesses may not have their own blockchain, but they automatically receive security from the platform’s blockchain network and they don’t need to worry about developing or maintaining a complex code base. This makes smart contract platforms the easiest methods for adopting blockchain technology.

However, this model is full of fatal flaws. The first is that third-party businesses have no control over the platform’s development. Changes to the code base could potentially render a business’s product completely unusable, as was the case with MGW and SuperNET after the NXT platform pushed the mandatory update to v1.7.1. 

Even if the platform’s development team never pushes non-backward compatible changes, there are several serious limitations. For instance, each third-party businesses must pay fees in the platform’s coin, rather than in their own currency. This includes ordinary transaction fees.

Suppose that a developer creates a token and builds a dApp on Ethereum. Suppose the token is called Exempli Gratia Token and uses the ticker EG1. Imagine that Bob is using the EG1 dApp and holds EG1 tokens. He wants to send a few EG1 tokens to Alice so she can start using the dApp, too. In order to send Alice the tokens, he must still pay the transaction fees in the platform’s coin. The fees would not be paid in EG1. This severely restricts the economic sovereignty of all third-party businesses and projects building on a smart contract platform.

Making matters worse, most smart contract platforms require applications to pay a fee for every process in the dApp. In some ways, this makes sense— it creates incentives for dApp developers to write efficient code and it prevents a poorly (or maliciously) coded dApp from sending the network into an infinite loop of pointless operations. 

At the same time, it makes very little sense because it becomes prohibitively expensive for any business or developer to run even moderately complex applications on a smart contract platform. The only dApps that can be run profitably are extremely rudimentary and don’t offer much in the way of utility or user experience. 

Worse still, neither the price of the platform’s coin nor the transaction fees themselves are static. In fact, both can fluctuate wildly. This makes it impossible to predict operating costs, which is a non-starter for any serious business. The price of the coin can suddenly shoot up in a bull market. 

Transaction fees can also go through the roof if congestion increases due to an increased number of projects building on the platform. This is exactly what happened to the Ethereum network when the CryptoKitties craze kicked off. The network came to a grinding halt, as it couldn’t process enough transactions to keep up with demand. Transaction fees skyrocketed and simple, ordinary transactions took hours to complete. 

While the economics at play might make sense for the platform and platform’s coin holders, it doesn’t make any sense whatsoever for third-party businesses and dApp developers. Let’s consider things from both angles to fully grasp the conflict of interest here.

The ideal scenario for any blockchain platform is to have as many businesses building on it as possible. This provides economic benefits to the platform. After all, each business building on the platform needs to pay fees in that platform’s coin for their projects to function properly. 

As more projects build on a particular platform, the price of that platform’s coin is pushed up by both increased demand and speculation from investors who view the increased number of projects building on the platform as a bullish indicator. At the same time, the increased number of businesses creates congestion, driving up the cost of transaction fees on top of the rise in value of the platform’s coin. The platform’s network benefits again, as the volume of fees being collected rises. 

Now, let’s consider things from the perspective of a business or dApp developer. These third-party projects want low fees, maximum performance, and predictable operational costs. They also want to be able to scale if their product becomes popular and experiences a large increase in usage. 

In other words, the ideal situation for any business built on a smart contract platform is for it to be the only project on the platform. In this way, the project enjoys low and stable fees, avoids congestion, and can scale their product without running into excessively high operating costs. 

This scenario— a single project having a dedicated blockchain all to themselves— is precisely what Komodo was designed to provide. With a multi-chain architecture, Komodo gives an independent, application-specific blockchain to every business. Transaction fees are always paid in each chain’s native currency. Nobody shares a blockchain so there is never any congestion to worry about.

Recall that James began his blockchain development career as a dApp developer on the NXT platform. He was never a part of the NXT team and never did any core development on the NXT blockchain. As such, James knows firsthand what kind of environment third-party businesses and dApp developers are looking for. And that is what he set out to build with Komodo.

The Komodo Platform Is Born

The initial announcement of the Komodo Platform was published on the BitcoinTalk forum on September 1, 2016. The initial coin offering (ICO) began six weeks later, on October 15. 

Bitcoin was the only accepted form of payment in the Komodo ICO (although Bitcoin Dark holders were allowed to exchange their BTCD for KMD coins). The ICO ended on November 20, 2016.

During the 37 days of the ICO, the price of BTC fluctuated between $628 and $756, with an average price of $691.62. KMD was sold at a rate of 7747 KMD for 1 BTC (roughly 12K satoshis per KMD). This means that investors paid, on average, $0.09 USD per KMD coin during the fundraise.

One-hundred million KMD coins were issued, with 70% of the initial KMD supply swapped to BTCD holders, 20% sold to investors, and the remaining 10% held as working capital for Komodo’s development and marketing.

Over the course of the ICO, Komodo Platform raised a total of 2,639 BTC. The closing price of BTC on November 20, 2016 was $731.03. Using that same price, we see that Komodo raised just under $2 Million, bringing in a total of $1,929,188 USD.

It’s worth taking a moment to put this figure into context. Next to most other blockchain projects that held an ICO in 2016, 2017, or 2018, Komodo raised a very modest sum of money. Here is a visual image of ICO data from 2015 to 2018 collected by CoinDesk to help you to put Komodo’s fundraise into perspective. 

CoinDesk ICO Tracker image

While thousands of cryptocurrency projects have emerged and held ICOs, with many of them raising huge amounts of capital, very few have delivered any functioning products over the years. In fact, a study released in May 2018 by researchers at Boston College showed that around 56% of crypto projects that hold an ICO fail within four months

Other researchers have put this figure even higher. Satis Group LLC, a NY-based ICO consulting firm, released a report estimating that around 81% of ICOs were "scams." While Statis Group used a rather broad definition of “scam” to arrive at this result, their findings are actually on par with research on the percentage of venture-backed startups that fail.

Let’s also compare these figures to the traditional tech startup sector. Shikhar Ghosh, a Professor of Management in the Harvard Business School, estimates that 75% of VC-funded startups fail. Between 30% and 40% of those deceased startups take all of their investment capital with them, leaving not a penny behind for the investors who gave them life.

It should also be emphasized that the BTC Komodo raised in the ICO is primarily used to pay the transaction fees required for the delayed Proof of Work security mechanism to function. Every ten minutes, Komodo’s Notary Node network notarizes block data from the KMD blockchain onto the BTC ledger, which requires paying a transaction fee in BTC.

Now, with all of this information in mind, let’s have a look at everything Komodo Platform has accomplished since James issued the Blockchain Declaration of Independence four years ago..

A Timeline Of Komodo’s Tech Milestones

Composable Blockchain Solutions

Komodo was the first blockchain platform built with a multi-chain design. Over the years, other projects, like Cosmos Network and Polkadot, recognized the advantages of a multi-chain design and have built similar platforms that offer application-specific blockchains to third-party business. The Komodo team is pleased to see this adoption of the multi-chain platform architecture that James Lee and the Komodo team pioneered.

Of course, Komodo’s development has never stopped. After delivering the blockchain industry’s first multi-chain design platform, Komodo’s technology continued to evolve. Over time, the vision shifted from offering sovereign, application-specific blockchains to offering fully composable blockchain solutions. 

Composability is a design principle that on providing a wide array of components, which can be activated as needed and used in different configurations to meet the unique demands of a specific use case. It also emphasizes modular solutions that can be deployed quickly and independently of the technology provider. Now, Komodo offers composable Smart Chains that can be customized and independently launched in a matter of minutes

While other projects have followed down the same developmental path that Komodo forged, these other multi-chain platforms have yet to achieve composability. For instance, the only consensus mechanism available with Cosmos or Polkadot is the Tendermint BFT consensus engine. It’s an excellent consensus mechanism, to be sure, but the fact that users have no choice is limiting nonetheless.

With Komodo’s technology, every project can easily customize their Smart Chain. This includes choosing the variety of blockchain consensus protocol employed on the chain. Options include Proof of Work, Proof of Stake, or any combination of the two. If a business chooses Proof of Work, they even have a choice of hashing algorithm— they can choose between five different variations of the Equihash algorithm or they can choose the VerusHash algorithm.

There are additional options, as well, such as setting the Smart Chain’s premine coin supply, block time, block rewards, frequency and magnitude of reductions in block rewards, privacy settings, and much more. This level of customization is not available on other multi-chain platforms. 

The next level of composability for Smart Chains is the Antara Framework, which makes a library of built-in modules available to every Smart Chain project. The Antara module library includes tokens, a decentralized stablecoin solution, a trustless oracle module, a quantum security module, gateways, instant micropayments channels, and much more. All a business needs to do is activate the modules they want to use and leave the others inactive. 

Komodo is continuing to develop and increase the composability of the blockchain solutions that the technology offers. If you’re interested in learning more about where Komodo’s development is headed in 2020, see Komodo’s technical roadmap here.

To get all the latest updates from Komodo, join the monthly email list. On the first Friday of every month, you'll receive a newsletter with information about all of the most important developments from the previous month. You can also join Komodo's Community Portal to chat with other community members and the Komodo team.

Join us as we continue to lead the blockchain revolution.