Our Archive

Welcome to your Archive. This is your all post. Edit or delete them, then start writing!

NuFi >

One of the great debates in blockchain centers around what it means to be decentralized, whether it’s a necessary trait for the application you’re developing, and how a blockchain’s centralization should affect the regulatory status of the cryptoasset(s) running on top of it. While many followers of the blockchain space would identify as decentralization ‘maximalists,’ touting the utopian anarchic virtues of their favorite project, others would argue that centralization is a sliding scale, and that none of the major blockchains in production today are truly as decentralized as they claim to be. Take Bitcoin, for example, where the world’s longest-running and most valuable blockchain has one-third of its hashpower consolidated under one mining pool operator, Bitmain, nearly putting one multi-billion dollar entity in control of the protocol.

Or take two of the other top 10 cryptocurrencies by market capitalization, XRP and Stellar, which have been criticized relentlessly since their inception, for adopting federated Byzantine fault-tolerant models of consensus, as opposed to the more popular ‘trustless’ Proof-of-Work (PoW) or Proof-of-Stake (PoS) models. Where PoW grants power and incentives to the users that run the most powerful machines supporting the network, and PoS grants power and incentives to the wealthiest users supporting the network, federated models optimize for network efficiency by employing ideas like flexible trust and quorum slices. While I’m not savvy enough to go much deeper into consensus theory, the short story is that decentralization maximalists typically aren’t fans of consensus models that require ‘trust’ in any specific node on the network, regardless of the blockchain’s application.

Consensus and Kin

So when the development team behind the Kin cryptocurrency, the Kin Foundation, announced several months ago that it would ‘fork’ the Stellar blockchain to use in parallel with the existing ERC20 token, and that the ONLY node operator at the outset of the new blockchain’s production network would be Kik, the chat app that launched the cryptocurrency, the crypto community’s negative reaction didn’t come as much of a surprise. While Foundation (and Kik) CEO and Founder Ted Livingston later clarified that this wouldn’t be a problem for the blockchain’s end-users because they already trust the app’s developers, and that the network would grow to be more decentralized as additional apps and partners joined the ecosystem, the maximalists didn’t want to hear any of it.

Fast forward five months, after the maximalists and some pre-sale investors have exited a large portion of their Kin position, bringing down the value of the Kin token in conjunction with an extended bear market, and the topic of nodes has surfaced once again. After the release of the atomic swap between ERC20 Kin and the token on the new blockchain was indefinitely delayed, despite already having the technical procedure developed and audited, the project’s followers wondered why. And in recent updates posted by Livingston and community manager Yoel Rivelis, it was revealed that the atomic swap won’t be cleared for release by the Foundation’s legal team until the Kin blockchain federation has assembled at least seven full nodes (operated by independent entities) to run the network. In other words, the Foundation has come to the conclusion that based on their blockchain’s consensus model, they can’t reasonably claim that the blockchain is decentralized enough to link to the ERC20 token until they have seven nodes. I’ll say more on why that probably is, in a moment.

This revelation, which comes at the tail end of a Q3 which saw several major announcements from the Kin Foundation, including the launch of the Kinit survey rewards app, the launch of Kin inside of beauty app Perfect365, and the hiring of former Twitch exec Matt DiPietro as CMO, may also explain other undelivered promises from the project.

The Liquidity

For example, a recurring problem for early adopters and followers has been the available market liquidity of the Kin token. During the token’s “distribution event,” community staff assured prospective investors that they had received indication from multiple exchanges that planned to list the token shortly after launch. The Jaxx wallet even formally announced they would support Kin (and presumably, would offer it on their built in Shapeshift exchange as well). And in the year following those statements, the largest exchange overall that has listed the token, HitBTC, only offers one trading pair, and they aren’t even Kin’s largest exchange by volume.

While Livingston claimed that the Foundation had de-prioritized listing the token on exchanges until there was a call to action for developers and advertisers to buy and sell the asset, according to the community staff, it had become a priority as early as late July. And yet, two months later, the token remains unlisted on any additional major exchanges, despite the project’s high profile and connections to various exchanges at the board of directors level.

While many high-volume cryptocurrency exchanges, both in the United States and around the world do not have very strict criteria for asset listing, other than substantial application fees (to the tune of millions of USD), others hold themselves to a high standard of eligibility based on the project’s fundamentals. Perhaps the most sought-after exchange, for its retail customer base and direct pairs to fiat currency, Coinbase publishes strict eligibility criteria (which they call the Digital Asset Framework), which include concepts such as decentralization and token utility. While the ERC20 version of the Kin asset is fully decentralized (at least, as far as the industry at large is concerned), without at least seven nodes, the Kin blockchain is not. And without the aforementioned atomic swap, the ERC20 Kin asset has arguably zero utility, as it isn’t connected to the app ecosystem where Kin is earned and spent.

The Regulators

Coinbase isn’t the only organization involved in crypto that has a problem with tokens that lack the combination of decentralization and utility. The Securities and Exchange Commission of the United States (SEC) regulates the sale of securities assets to and from citizens of the US. The SEC has recently developed a greater interest in enforcing securities laws in the cryptocurrency space, particularly with respect to tokens sold in an initial coin offering event (ICO), which is how the Kin Foundation raised their development funds. After issuing guidance on non-compliant token sales such as The DAO, and taking enforcement action against sales in-progress like Munchee, and completed token sales like Centra, the SEC has been intensely deliberating amongst themselves and other US regulatory bodies to develop a better framework for how the laws should apply to crypto assets.


William Hinman, SEC Head of Division of Corporation Finance

In June, the head of the SEC’s Division of Corporation Finance issued an unofficial statement that Bitcoin and Ethereum are not securities, and that the decentralized status of their blockchains was a key determining factor in reaching his conclusion. The SEC, which has had an open investigation into Kin’s token sale since shortly after the conclusion of the sale (alongside investigations into dozens of other tokens), is keeping a close eye on how the Kin Foundation conducts itself, and may be watching how it proceeds towards decentralizing its blockchain, and whether it succeeds in providing meaningful utility to the Kin token. Exchanges based in the US, such as Coinbase, Gemini, Bittrex and others, are likely to be wary of listing assets that may fit the SEC’s fuzzy criteria for a security token. And even if the atomic swap were achieved with only one node running the Kin blockchain, the utility of the token would remain limited to that centralized chain, therein not qualifying the ERC20 asset for real utility.

The Partners

Kin has also had a hard time onboarding major partners, as well as smaller developers in the absence of any programmatic incentives for integrating their cryptocurrency. It is plausible that some app companies, who likely follow the crypto space to some degree, aren’t sold on the idea of implementing a currency over which so much power is held by one or two entities, or which is still lacking so many of the fundamental infrastructural features necessary to make it all ‘work.’ This presents something of a ‘chicken and egg’ scenario, in which exchanges, regulators, apps and investors are hesitant to partner with a blockchain so centralized and feature-incomplete today, which means they won’t run nodes for Kin, which means the blockchain won’t become decentralized enough to unblock those missing features.

Naturally, the ‘seven nodes’ requirement raises several key questions, the first of which we (at NuFi) feel we already know the answer to.

So, why does Kin need at least seven nodes?

I’ll defer to Adam to comment on this:

While it’s important that Kin not be recognized as a security, it is also important that the network not be recognized as a Money Services Business (MSB) by FINCEN.

As we noted within “How Does the Kin Consensus Protocol (KCP) Work?” the Kin network will need a series of federated validator nodes within the network to create balanced quorum slices who can ultimately ensure >66% accepting votes in a network consensus.

So why seven?

Having 7 nodes ensures that no entity controls more than 20% of the vote. Which seems to be the magic number the Kin Foundation believes results in the network not being considered a money services business.

What is so special about 7 nodes and the 20% number?

For the Kin Consensus Protocol to successfully validate a transaction, the network must reach a consensus of >66% of votes. These votes are voted on by overlapping quorum slices, where within each one of those quorum slices a >66% or greater vote must take place.

Since members who follow a quorum slice can have their vote changed by the quorum slice they follow, it actually takes significantly less than 66% of voting power to influence the network.

In fact, if a single actor (entity or user) were to control 20% of the votes in a Federated Byzantine Agreement network (like Kin or Stellar), and all quorum slices within that network overlapped, that it is almost mathematically impossible for the network to vote the same way as the actor who controls 20%. In order to defeat the vote of the 20% actor, every other tangential quorum slice would have to cast their primary vote against the vote of that actor. If any single node within the network that is in a tangential quorum slice were instead to vote in favor of that vote, or vote to accept that vote, or to fail to vote, it would create a domino effect of quorum slices changing their votes due to the level of influence this node has.

The only other way around this would be to isolate that node (or those nodes) in a specific quorum slice, which runs the risk in turn of leaving us with disjointed quorums which result in a broken network.

Given this, anyone who controlled more than 20% of the federated nodes that were default to a Federated Byzantine Agreement network would have the power to:

  1. Always get their vote approved even if it was the initial minority vote.
  2. Hold the network hostage with fractured quorum slices.

In any scenario in which a minority entity (or entities), or a minority of the voting nodes can exercise control over the majority, the network is no longer decentralized and therefore can not be considered exempt as a money services business.

At 7 federated nodes, we are able to create interdependent quorum slices, where no one node has excessive voting power and the majority favor always plays out within these votes.

Who is running a node today?

As mentioned above, the only confirmed node operator to date is Kik Interactive, developers of the Kik chat app (and current parent company of the not-for-profit Kin Foundation). It’s possible that the two other apps that have partnered with the project, IMVU and Perfect365, are also running (or planning to run) nodes, but we aren’t clear on that.

Who will run nodes in the future, and when?

It’s possible that the Foundation has stipulated in its terms of partnership with apps like IMVU and Perfect365 that they are to run full nodes for the network as soon as they’re ready for integration, but this has never been stated. As for smaller developers and followers of the project, the Foundation hasn’t yet made it clear what the operating costs to run a node will be, and they also haven’t published all of the code necessary to get a full node running on the new blockchain. A preliminary documentation FAQ uncovered on Github a month ago estimated a cost of upwards of $2000/month for Kin blockchain nodes. So, in the meantime, Kin may need four additional major app partners to run nodes in order to achieve their goal of seven.

Other blockchains have thousands of nodes. How does the Kin blockchain have fewer than seven nodes after a whole year since raising $100 million and beginning development?

While Kin started raising funds over a year ago, they didn’t shift blockchain strategy to forking Stellar, thus needing to build their own network of nodes, until May. And because these nodes need to be sufficiently independent of each other in order to truly decentralize the network, they can’t just buy Amazon AWS instances around the world and claim decentralization. They also may be bound by what incentives or funding they can offer node operators, as the Foundation paying for others to run nodes could easily raise eyebrows over the threat of collusion. Still, with nearly five months behind them, and a major fundraise completed, it is concerning that the Foundation hasn’t yet been able to onboard more than just two apps to participate in the ecosystem, and presumably, in consensus as well.


NuFi.io is an independent publisher aimed at providing quality journalism in the cryptocurrency space. NuFi is not associated with, paid by, or employed by any cryptocurrency project. We rely on subscriptions from readers like you!

To help keep NuFi.io ad-free and creating quality content consider:

[thrive_leads id=’3175′]

Read More

As we move towards the launch of the Kin blockchain main network launch, there have been a lot of questions regarding the need for ‘7 federation nodes’ to start the official decentralized network.

At the core of that need sits some mathematical and regulatory theory, based on how Kin’s Consensus Protocol (KCP) works.

What is a Consensus Protocol?

Every blockchain is made up of entities we call “nodes.”

Nodes are essentially computers that have chosen to download and run the network software. Each of these nodes monitor transactions on the network and choose to validate or invalidate each transaction based on a series of mathematical computations. (For a more in-depth look at how nodes work, consider reading our guide: “What is a Blockchain?“)

Each of these nodes are given a vote within the network, and with those votes we aim to reach a ‘consensus,’ or decision. In any situation where voting occurs, we have a ‘consensus protocol’- a formal set of rules that help us to decide when a satisfactory decision has been made.

The most common consensus protocol that most people are familiar with is “majority rules.” We might use this in a classroom setting when a teacher is asking her students which activity they wish to do. She’ll ask for a show of hands and the activity with the most votes wins.

However, in our every day lives, we do deal with much more complicated consensus protocols, such as voting in elections, where all votes may not be voted equally.

When it comes to a blockchain network, consensus protocols are very important as they need to:

  1. Validate the authenticity of transactions and balances infallibly.
  2. Define a ‘safe’ majority that both prevents network attacks, but also prevents a tyranny of the majority.
  3. Create a network that can be considered fair and decentralized from a regulatory perspective.
  4. Ensure that no minority (counted either by votes, or by entities/people) can control the will of the network and out vote the majority.
  5. Prevent stalemates or failures.
  6. Prevent breaks or hard forks within the network.
  7. Incentivize good actors (users).
  8. Disincentivize bad actors (users).

Each of these criteria result in an increasingly complicated set of rules being applied to reach consensus. The challenge is that reaching consensus is costly. If you had to poll 100% of nodes in the network each time and figure out the majority vote it would be extremely resource intensive- and depending on how you define a node (such as by hashpower, or number of computers run), it could be easy to manipulate the votes financially.

Given all this, nearly every blockchain network in development currently has set out with the goal of creating a unique consensus protocol that they feel can address these challenges.

What is the Kin Consensus Protocol (KCP)?

Our understanding of the Kin Consensus Protocol is still forming. As of right now, we know that the Kin network is based on a fork of Stellar and the Stellar Consensus Protocol (SCP).

The Kin team is currently discussing and exploring additional features they aim to implement regarding the ability to incentivize good actors, and disincentivize bad actors, but beyond this, we believe that the KCP will operate in a manner very similar to Stellar’s SCP model.

But, we can walk through the features of the Stellar Consensus Protocol and look at how they interact.

Understanding the Landscape of Kin Consensus Protocol (KCP):

#1 – Byzantine Fault Tolerance (BFT):

A “Byzantine Fault” or “Byzantine Failure” is when an individual node, or nodes, act arbitrarily or unexpectedly within a network.

Imagine a scenario with four voters: “User A,” “User B,” “User C” and “User D.”

All four voters are told they can pick between ‘Chocolate’ or ‘Ice Cream’.

A, B and C all pick between the choices that were provided to them. User D, however, says their vote is for ‘Potatoes.’

Now we have a very basic byzantine fault within the network. Luckily, we don’t need full unanimous consent in order to reach consensus. But, if we don’t require complete consensus, then we must have a specific model in place to decide what the minimum consensus is and how we deal with byzantine faults.

In a BFT system, validators send messages back and forth, and will confirm a transaction to be true if more than 66% of the validators vote in favor of the issue. (The BFT model is much cheaper and faster than ‘Proof of Work,’ but it does sacrifice decentralization in favor of a more centralized authority.)

Classic BFT, which is used by blockchains like Ripple, require a pre-set validator list, which is often defined by the company behind the blockchain. Anyone can create a validator, but you can only partake in consensus if the central authority adds you to the list.

While blockchains like Stellar attempt to shift away from this model, they still often ship with a recommended list of validators in the node code in order for a new node to connect to the network, who become overly powered and essentially mimic classic BFT behavior.

Kin will likely use the Stellar alternative to BFT, called “Federated Byzantine Agreement (FBA),” which we’ve outlined below. But this still relies on principles of BFT, and is likely to ship with a starting list of validators that most people won’t change, making it much closer to classic BFT models.

#2 – Federated Byzantine Agreement (FBA):

The specific model for dealing with byzantine faults within Stellar, and therefore Kin, is a Federated Byzantine Agreement (FBA). FBA is a decentralized alternative to BFT.

Within an FBA network, rather than relying on a list of approved validators, each node decides which validators it wants to trust. These validators are referred to as a ‘quorum slice.’ Quorum slices of each validator overlap throughout the network, and eventually result in a quorum (or network wide consensus) on any decision.

The important part of an FBA model in its pursuit of decentralization is the ability for anyone to create a validator on the network, and for users to be easily able to change and manage their own quorum slices.

FBA models have received some criticism due to the complexity or cost associated with both of these tasks. Some blockchains that are being run on FBA models have changed the functionality of their validator nodes to make it cost prohibitive for the average user to run a node, thus centralizing this process.

Configuring a quorum slice within your validator node’s configuration file is also a complicated process that requires knowing the IDs of various nodes, and listing mathematically balanced quorum slices. Since most users are not capable of this, the validator code that users run on their system often ships with a set of pre-defined quorum slices set by the developer. Since most users do not change from the default (or can’t), and tools are not provided to allow users to easily create their own slices, these default nodes become very powerful within the network.

#2 – Vote & Accept:

In most voting systems, we’re used to two scenarios:

  1. We can vote for or against something (“Do we want to ratify this agreement? Yes, or no?)
  2. We can pick one choice within a set (“Do we want to go to Germany, France, or Mexico for Vacation?)

In the byzantine agreement system used by blockchains like Ripple, Stellar, and Kin we actually have a third option. We can choose to vote for a specific answer, as well as note which answers we will accept.

So, if it was the vacation question, I could cast my vote as “I vote for Germany, but would accept going to Mexico.” This becomes a critical concept as we delve into quorum slices.

#3 – Quorum Slices:

In any decentralized network, we have something called a “quorum,” which is the set of nodes that is sufficient to reach an agreement.

In our example above, perhaps we decided that as long as 75% of users placed a valid vote, then we met our minimum quorum. This means we could simply ignore the invalid vote from “User D.”

Within Ripple, Stellar, and now Kin, we’ve shifted from simply using quorums to using ‘quorum slices.’

A quorum slice is a subset of a quorum, a trusted group that can convince one particular node to agree with it.

Four nodes on our network, three of which make a quorum slice

Within this example, the yellow node (the first circle in our diagram) has the other three nodes within a quorum slice.

From these slices, it can create a series of rules where the yellow node says:

  • If two-thirds (66%) of nodes within this quorum slice agree with an option I “accept,” then change my vote to that option.
  • If 100% of nodes within this quorum slice agree with an option I didn’t accept, then change my vote to that option.
  • If 66% of nodes within >66% of the quorum slices I follow agree with an option I didn’t accept, then change my vote to that option.

Quorum slices are essentially groups of nodes that the user trusts. The rules a user sets for their quorum slices allow different layers of trust and influence for each quorum slice.

Perhaps within the Kin network, a node decides that they are going to create three quorum slices they trust. One consisting of the nodes hosted by Kik, the Kin Foundation and IMVU. The second slice consisting of all the developers from the Kin Developer Program, and the third consisting of community hosted nodes.

When a transaction gets made, the node sees that Kik and the Kin Foundation are voting “No” on that transaction, but IMVU is voting “Yes.” At this initial stage, the node assumes that “Yes” is the accurate vote.

As it checks with the two other quorum slices that are within its defined Byzantine Fault Agreement, it realizes that 100% of these other two quorum slices are voting “Yes.” At this point the node changes its mind, realizing there must be an issue with the votes from Kik and Kin, and it now decides to vote “Yes” as well.

#4 – Quorum Slice Overlap:

The final important factor for us to note before we can walk through an example of a Kin Consensus Protocol decision is ‘quorum slice overlap.’

As we’ve noted, each node will ultimately have multiple quorum slices that it trusts. In order for the network to operate, these quorum slices all need to layer together in a manner that allows the entire network to reach a quorum consensus (>66%).

However, if users are able to create their own validators, and define their own quorum slices, we can run into what I call “the faction trust problem.”

The faction trust problem is when a portion of the network trusts one quorum slice, but no nodes outside that quorum slice, and another portion of the network trusts a different quorum slice but none outside of that.

These two opposed quorum slices could both reach different conclusions on a vote and leave the network stuck at a standstill. We refer to these quorums as “disjointed quorum slices.”

Disjointed quorum slices with no overlapping trust.

Given the fact that these quorum slices are disjointed, it is impossible for the network to come to a complete consensus. Even though 5 nodes are voting one way, they only add up to 55% of the network vote. Since their quorums do not overlap there is no way to convince one of the other three nodes and reach 6/9 votes (66%).

In some blockchains, this type of situation could cause a hard fork wherein the blockchain splits into two chains that diverge and continue to process separately. This would ultimately produce a risk of a double-spend attack and other challenges.

Since protocols like Stellar and Ripple are designed to be used by real-world financial institutions and support tangible underlying assets, it is crucial that the chain never splits. For this reason, the Stellar network (and all FBA networks) are designed to halt any new transaction until a network consensus (>66%) is achieved.

This is why it is crucial for the quorum slices to overlap, so there is always a connection between slices, and the network can never be divided into two camps.

Three overlapping quorum slices, ensuring the network can always reach a point of consensus.

The Journey of a Kin Transaction:

For a very simple example of how a Kin transaction might work within the KCP, let’s pretend that Dillon and I have invited Ted out for a coffee. We’ve decided to vote on where we want to go for coffee using the Kin Consensus Protocol and our Kin validator nodes. Each node is named for the person it represents.

In this scenario, we will assume:

  • Dillon has voted for Starbucks. He has not voted for, nor voted to accept any other answers.
  • Adam has voted for Starbucks. He has also voted to accept Tim Horton’s.
  • Ted is undecided at the start of our scenario.
  • Ted’s quorum slice consists of Dillon and Adam’s nodes.

Voting and Accepting:

When Ted is asked to place a vote, he sees that the options before him are “Tim Horton’s,” “Coffee Time,” and “Starbucks.”

Being the true Canadian that he is, Ted decides to vote for Tim Horton’s- but he also decides he can accept going to Starbucks as it is near his office and provides good quality coffee. He decides that he isn’t willing to accept Coffee Time because, quite frankly, it’s terrible coffee.

Ted is now broadcasting the following to any quorum slice that he is a part of:

  • Vote(Tim Horton’s)
  • Accept(Starbucks)
  • Reject(Coffee Time)

Now he checks the quorum slices he follows (which consist of Dillon and Adam). Ted’s node notices that both of the nodes in his quorum slice (100%), are voting for Starbucks. Since Ted has listed that he is opening to accepting Starbucks, he won’t argue against it.


Once every member of a quorum slice has voted for the option, they in turn “ratify” the decision. The ratification of a decision means that that entire quorum slice is now represented by the vote. So in this case, because >66% of the quorum slice voted for Starbucks, and Ted noted he would accept Starbucks, the vote is ratified. In this case, anyone who follows Ted, Dillon and Adam as one quorum slice would now see that the slice is voting for Starbucks.

Voting for Starbucks doesn’t assert Starbucks as the right option. Instead, Starbucks will be accepted as the right option only if it is ratified.


Confirmation is the final step of the voting process, and is used to ensure system-wide agreement (quorum consensus).

Once there is an agreement, the nodes begin to exchange confirmation messages. Each node is asked to agree to an statement, and once sufficient messages are delivered and processed to show that the network has reached consensus then every live node on the network after that is forced to accept the decision.

In our example, Adam and Dillon may send out the message “accept(Starbucks).” When Ted sees that more than 66% of nodes within the network are agreeing with “accept(Starbucks),” his node is now forced to do the same, and begins to broadcast the message “accept(Starbucks).”

The BFA system has additional features for dealing with breakdowns among quorum slices and other bad actors, but this process of vote, ratify and confirm outlines the basic model of BFA in a consensus protocol, and the primary model we expect the Kin blockchain to be using.


NuFi.io is an independent publisher aimed at providing quality journalism in the cryptocurrency space. NuFi is not associated with, paid by, or employed by any cryptocurrency project. We rely on subscriptions from readers like you!

To help keep NuFi.io creating quality content consider:

[thrive_leads id=’3175′]

Read More

Missed the rest of the series? Check out “Part #1” “Part #2“, “Part #3” and “Part #4

When I first started this series critique number 5 was “The Kin team hasn’t done anything since the ICO.” A lot has happened since then, including the launch of the Kinit app, and so we’ve heard less and less of this critique over time.

Instead, a new negative narrative has surfaced that we’re going to combat, one that I call “the two blockchain problem.”

It seems whenever Kin related news gets shared around cryptocurrency communities we consistently hear:

Kin can’t decide which blockchain they’re on.

Kin keeps flip-flopping on blockchains.

There are two subtle points that people are misinterpreting here, that we should clear up.

Critique #1 – “Kin Can’t Decide Which Blockchain They’re On!”

At first, when I heard users complaining about this decision, I thought it was in reference to the migration from the Ethereum blockchain to the Stellar blockchain, and then to their own Kin blockchain. However, after taking the time to have in-depth discussions with these users, I’ve realized instead they are (surprisingly) upset that Kin is a token that lives on two blockchains.

While cross-chain projects like ChainLink and Bitcoin-to-Ethereum Atomic Swaps have been celebrated, people seem to think that Kin’s chain-duality is a negative, rather than a positive.

The Case for Two Blockchains

Ethereum Scaling

When Kin first launched, they were focused on the Ethereum blockchain, as most new ICOs and blockchain projects from 2017/18 were.

At the time, Ethereum was yet to face some of the platform’s worst scaling challenges, such as the CryptoKitties craze, and the upper bounds of Ethereum’s transactions-per-second capacity had been mostly untested.

Shortly after Kin’s launch, the Ethereum network was hammered by the launch of CryptoKitties. Seeing how few transactions were needed to clog the Ethereum network, Kin realized that they could not possibly implement their project on Ethereum blockchain in the short term.

They even went as far as to calculate what would happen if Kin were to ‘airdrop’ a little bit of Kin to each Kik user, and realized that if they did this, they would take down the Ethereum network for days.

Rock and a Hard Place

At this point the Kin Foundation knew they had to explore other options, including their own blockchain.

The challenge became that moving to your own blockchain means:

  • Losing out on existing Ethereum infrastructure like web wallets, hardware wallets and decentralized exchanges.
  • Exchanges have less incentive to list your coin, as they now have to run a node of your blockchain rather than just add a smart contract token.
  • Increased overhead, as you now need to create your own software wallets and node tools.
  • Decreased security at the initial launch of the network, as you lose access to Ethereum’s global network of validators.
  • Decreased liquidity for investors, as they can no longer easily move tokens within the Ethereum network.

We’ve seen examples of these challenges faced by other popular projects. Consider RavenCoin, a mine-able community token that launched around the same time as Kin. They’ve faced a tremendous uphill battle with their token, and even though they have a large and highly involved community, they are only listed on a few small unknown markets, have a market cap of only $39M and get less than $600k/day in daily turn over. Beyond that, a significant portion of the developer’s time is spent upgrading and maintaining software wallets, which takes away resources from their main vision.

The Decision

The Kin Foundation, realizing that they didn’t want to put their users in that position, decided to do something new. They decided that they would continue to explore other blockchains while still keeping the Kin token available on the Ethereum network, so that users could take advantage of the existing ecosystem for liquidity.

While this introduced significant confusion, especially in messaging surrounding “KIN1” and “KIN2” (Read: “What the heck are KIN1 and KIN2?“)

Critique #1 – Conclusion & TL;DR

Kin isn’t split between blockchains, and they don’t have two tokens. The Kin Foundation is focused on building the Kin Blockchain, a highly-customized fork of the Stellar blockchain that supports 0-fee transactions and high-rate TPS.

Since Kin knew that moving to their own blockchain might result in reduced liquidity for token holders, they allowed Kin to remain active on the Ethereum blockchain for trading.

Kin is not building tools to support the Kin token being used on the Ethereum blockchain. Their tools are focused on the Kin blockchain, and users will be able to move their tokens over via Atomic Swaps.

Critique #2 – “Kin Keeps Flip-Flopping on Blockchains!”

In recent years, especially in political-spheres, changing your mind has been demonized with the word “flip-flopping.”

Before we get to the Kin Foundation specifically, let’s first clear this up.

  • “Flip-Flopping” is changing your answer to a question, or your position on an issue without substance (or without meaning), primarily to take advantage of a current benefit. (i.e. lying to a crowd for votes).
  • Changing your mind is what happens when you learn new information that disproves your previous position. It is not flip-flopping, it is not bad, it is actually the most healthy thing to do when presented with new information. (In startups this is often called a “pivot.”)

To that end, the Kin Foundation has never once “flip-flopped” on which blockchain they are going to use. Instead, they’ve learned new information as time went on and changed their minds.

Leaving Ethereum

As we mentioned earlier, Kin’s decision to leave Ethereum was based on challenges around scalability.

The inability for the Ethereum blockchain to scale to the level that Kin needed for integration into their own Kik app, let alone into multiple enterprise partner apps, meant that they simply couldn’t complete their vision on the Ethereum blockchain.

While Ethereum is rapidly moving towards scaling solutions, even optimistic estimates put these as being implemented sometime in 2020, which would delay Kin’s timeline far too long.

This initially lead to Kin exploring Stellar.

Aside: Ethereum Vs Kin

It’s worth noting, that many have argued that if Ethereum won’t have scaling before 2020 then there is no way Kin will be able to create their own blockchain that will have scale.

The important distinction here is that Ethereum is trying to create a scaling system on a live blockchain, while managing a number of existing features, none of which were designed for this scaling system.

Kin, on the other hand is trying to implement scaling by building a blockchain of their own, and only having the features they want/need within it. They are two very different products, with different challenges.

Leaving Stellar

After leaving the Ethereum blockchain, the Kin Foundation began to explore Stellar’s blockchain as an alternative, due to its focus on high scalability and low cost fees. Stellar achieves those goals by using a more efficient consensus model and removing the overhead of a “Turing Complete” smart contract language, like Ethereum has.

While Stellar proved to be advantageous from an underlying technology perspective, it introduced a unique set of challenges in terms of user experience.

To create a new wallet on Stellar, a user must first fund the wallet with at least 1 Lumen (Stellar – XLM), and whenever they send a transaction the user must burn 100 Stroops (0.0000001 of a Lumen).

This meant that in order to use Kin, users would first need to purchase and load their wallets with Stellar, and make sure they have a balance of Stellar in their wallet at all times in order to make transactions.

Since most users would be using Kin via third-party apps, they wouldn’t be aware of background processes like this, and certainly wouldn’t be familiar with how to use exchanges to purchase Stellar and load it into their wallet.

This would drastically increase either the financial load on developers (requiring them to spend around $0.50 for each new account activation) or increase the education friction on new users. Either of these options would ultimately lead to less adoption in the Kin ecosystem.

This finally led the Kin team to decide they needed to pursue their own blockchain.

The Kin Blockchain

Kin obviously wanted to avoid making their own blockchain to start, as building a blockchain from the ground up is a tremendous cost and comes with its own headaches.

But, given that no other blockchain technology was ready to perform at the scale they needed without sacrificing user experience, the Kin team pivoted and decided to build their own based on a fork of Stellar.

Building their own blockchain comes with a lot of advantages. It will allow them to create the exact infrastructure that they and their partners need without worrying about third-party developers and other complications.

It also means that Kin has the potential to expand beyond their initial ambitions and offer other features in the future including smart contract support (like we learned in their recent Engineering AMA).

Critique #2 – Conclusion & TL;DR

Kin didn’t flip-flop. They learned new information, and pivoted in response.

They had to do this twice. It wasn’t their initial plan to build their own blockchain, but, now they are doubling-down on that, and this brings a lot of benefits.

They aren’t going to be changing their blockchain again.

A Final Note

There has been a lot of fuss about Kin’s journey with multiple different blockchains, especially in the messaging around KIN1 and KIN2. The fact that the Kin Foundation is a blockchain company that is willing to change course when learning new information is a good thing.

Adaptation is key to success in startups. Far too many blockchain projects seem to worry that admitting you were wrong is a point of weakness, and so they cling blindly to their statements. In the end, that will be the downfall for a number of these companies.

If there is one thing Kik has proven they are good at, it is evolving to stay in the fight. For the last decade they’ve had to continually evolve to stay relevant, and that’s something that’s foreign to most blockchain startups.

I personally believe that Kin should go all in on their new blockchain, building it first as a platform for themselves, then supporting other projects that want to live within the ecosystem, because Kik is one of the few companies with the expertise to help deliver on a project at this scale.

Whatever lays ahead for the Kin blockchain, I think it’s clear that their decision to change blockchains was the right choice for them and that many of the critics who disliked that choice were kind of like baseball fans refusing to cheer for anyone other than the home team.

There is a lot that Kin hasn’t done right to date, but, the project has an incredible potential and has shown they have the ability to bring real partners into the fold and help make crypto adoption mainstream – and in the end, that’s why we had to examine “What Critics Fail to Understand about Kin.”

[thrive_leads id=’3175′]

Read More

Hey there!

Forgot password?

Forgot your password?

Enter your account data and we will send you a link to reset your password.

Your password reset link appears to be invalid or expired.


Processing files…