Our Archive

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

NuFi > 2018 > September

How does the Kin Consensus Protocol (KCP) work?

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.

Ratification:

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:

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.

Notice:

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

A Warning to Blastchat Users – Your Information May Be Compromised

Update 09/13/18: Since the publishing of this article, a number of developments have taken place:

  • The author of the post has chosen to reveal their identity. Known online as “Chancity,” he is the creator of the Kin Blockchain Explorer and a developer on the KinTipBot team.
  • Blastchat founder Jhamar Youngblood has acknowledged the incident and posted an additional update to Medium detailing his plans to secure the application, after permanently wiping all previously stored data.
  • The Kin Foundation has acknowledged the incident and stated that they will now be reviewing the security of all apps under the Kin Developer Program prior to approval after ‘demo day’ on October 2nd.

NuFi has recently received multiple anonymous tips regarding a security vulnerability in the mobile app ‘Blastchat.’ The following is a responsible disclosure warning. NuFi has chosen not to reveal the author of the post, but has independently verified their claims.

Blastchat, a mobile chat app and recently announced participant in the Kin Developer Program, has been:

  • Storing passwords in plain text.
  • Storing emails, phone numbers and passwords in plain text associated with a username.
  • Not encrypting communication between devices and their servers.

As a result, anyone running a packet-monitoring firewall on their network, or any third-party who decided to packet sniff the app, could look at the app’s “Leaderboard,” and in turn, collect the username, password, email and phone number of all users in plain text.

Additionally, this means that the creators of Blastchat also had access to all usernames, passwords and emails in plain text.

The vulnerability was first reported to Blastchat a few days ago, and has likely been present since the app’s initial release.

As of the publish date of this article, September 12th, 2018, Blastchat has not alerted users to this issue and the potential risk of breach, nor emailed them encouraging them to change their passwords. Instead, the Blastchat team has taken their app offline, citing their Kin integration work as the only reason for doing so.

Knowing that the servers are now offline, and in consideration of the Blastchat team’s decision to forego alerting its own users, we have chosen to disclose this vulnerability. It is unclear if this information was ever accessed by malicious parties or not, but users should take precautions.

Users should:

  • Change their password on any website that they used the same password for Blastchat (remember to try and use unique passwords).
  • Consider changing their email address on any website related to cryptocurrency. Third-parties may now have your email address and phone number, which are often the only things required to do social engineering attacks to gain entry to 2FA authenticated accounts.
  • If you don’t currently use 2-Factor Authentication (2FA), consider setting it up wherever possible. Use on-device 2FA like Google Authenticator rather than SMS-based 2FA, as the SMS method is more vulnerable.

Users should not:

  • Update to a secure password in Blastchat as soon as the servers go back online. Users should await further updates and independent verification that the vulnerabilities are resolved.

This vulnerability should serve as a reminder of the importance of user data security and privacy in the modern world. Recent data breaches have cost even high-profile companies billions of dollars in liability, annually.

Participants in the Kin Developer Program, many of whom are building applications from scratch, will face the additional challenge of securing users’ cryptocurrency wallets. The security of user data is critical when merging the consumer app experience with decentralized currency, which can not be recovered if stolen.

The NuFi team hopes Blastchat can resolve these issues and disclose them to users. At such a time, NuFi is committed to updating the article to let users know there is no longer any jeopardy.

Notice:

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

Five Problems Kin Needs to Solve to Become the Most Used Cryptocurrency by EoY

The Kin Foundation set the lofty goal of “becoming the most used Cryptocurrency by End of Year” in 2018.

Depending on their measure of success, they’ve either got a long way to go, or an incredibly long way to go.

There are also some key problems that stand in their way that will need to be resolved – but shipping solutions to these challenges would send strong signals that Kin is poised for growth in Q4.

The Most Used Cryptocurrency:

To reach the status of the “most used cryptocurrency” by the end of year, Kin would likely need to compete on transaction numbers, transaction volume or total number of wallets. Kin is a long way off on all these fronts, but the most likely measure is in terms of transaction count (especially given Kin’s focus on micro-transactions).

So where does Kin sit currently? As of September 5th, during a slow bear market, here are the top transacting blockchains based on Blocktivity’s reporting of a 7 day average:

Transactions Per Day, Per Blockchain:

  • EOS – 4M transactions/day
  • BTS – 1.2M transactions/day
  • Steem – 1.1M transactions/day
  • ETH – 600k transactions/day
  • BTC – 230k transactions/day
  • KIN – 20k transactions/day

While there is some debate as to the legitimacy of how transactions are counted for “EOS,” “BTS,” and “Steem” (all of whom are made by the same dev), even if we were to discount them entirely and leave ETH as the leader with 600,000 daily transactions, this is still very far from Kin’s 20,000 transactions a day – many of which are automated account creation transactions performed by the Kin Foundation.

So, let’s examine some of those key problems.

Problem #1 – Restricted Integration (SDK):

Even though the Kin Foundation is focused on building an “open and fair” ecosystem on an open source technology, they’ve taken a very restrictive approach to their early integrations.

While the Kin team launched a $3 million Developer Program and accepted 40 different participants to that program, the ability to build on the Kin blockchain is not yet available to anyone else.

Right now, developers who are interested in Kin are stuck:

  • Building for the ERC20 Kin token, which is unsupported. It’s also unclear if these apps will count towards the KRE.
  • Waiting for the Kin SDKs to have a public launch in the future.

At this point in time, developers have no real ability to develop for the Kin ecosystem and so Kin is turning away party guests before they even have a chance to knock on the door.

If Kin hopes to be the most used cryptocurrency by EOY, they will need to play a volume game with developers and not be too dependent on current apps, which could face serious challenges with integration, legal and user education.

Problem #2 – Isolated Ecosystems (Identity Layer):

One of the most important aspects of the Kin Ecosystem, that we’ve yet to hear any official discussion about, is the “Identity Layer” solution.

In order for users to move their Kin in and out of apps without creating multiple wallets, Kin will need to provide some sort of “Login with Kin” button (likely through Kinit) allowing people to receive compound value for their Kin by earning it in one app and spending it anywhere.

This is one of the core tenants for Kin and their “rebel alliance” – without this ability, apps are just isolated ecosystems that are no different than current in-app “rewarded video” experiences.

Rather than create a work-around, Kin has chosen that the first batch of apps will not be able to have users transfer their Kin outside of the app until some unknown future date.

An identity layer is crucial for Kin’s long term success, but the ability for users to transfer their Kin from apps to a public blockchain is table-stakes for truly being the most used cryptocurrency by end of year.

Problem #3 – Centralization (No Public Blockchain):

Kin has positioned themselves as a private, single-product focused blockchain, which wins them no friends within the cryptocurrency community.

Right now, Kin’s nodes are all run by the Kin Foundation or other private members of the ecosystem. It is currently not even possible to run your own node for the Kin blockchain mainnet as:

  1. The GitHub code is not up to date with the mainnet nodes.
  2. The network passphrases are not publicly released.

This means that the Kin Foundation fully controls the Kin blockchain network and could rollback any transaction or change a transaction at any time.

Blockchains are designed for decentralization through ‘trustlessness,’ and Kin won’t be able to become the most used cryptocurrency without building that trust with the blockchain community. Until Kin launches public nodes and decentralizes the network, then they can’t claim to be the most used cryptocurrency, as they would really just be a highly used in-app currency from a private company.

Problem #4 – Trapped Value (No Atomic Swap):

Currently, nearly all the Kin in existence is sitting on the Ethereum blockchain as ERC20 tokens.

The Kin Foundation shifted from Ethereum to their own private Kin Blockchain and left their tooling for the Ethereum blockchain unsupported.

This means there is no real purpose to the Kin ERC20 token (KIN1), and its value is entirely based on speculation until there is an “Atomic Swap” option to bring the Kin back over to the Kin Blockchain.

The Atomic Swap was originally targeted to go live in Q3 of 2018, but has been pushed back until at least late Q4 of 2018. With Kin’s track record of deadlines it is unclear if we’ll see the functionality released by end of year, but, it would be a crucial component to reaching their goal.

Problem #5 – Kik Engagement:

The Kik team has been disappointingly quiet on the progress of integrating Kin into Kik.

While Kik is supposed to act as a core beacon of the Kin Ecosystem, so far we’ve seen mostly idle wallets, minimal updates to the user experience and low engagement rates.

We’ve received minimal insights into the progress here, or future plans/timelines. The one communication we have from the Kin team on the “progress of the Kik integration” left us with vague answers, no hard data or concrete details.

Perhaps Kik is just playing their cards close to their chest – but the article doesn’t instill confidence. Coupled with the low volume of daily active users (and the lack of clarity around Kik wallet creation numbers), it breeds concern that the Kik integration may be under performing.

Integrating Kin into Kik could single handedly result in Kin being the most used cryptocurrency in the world by the end of year, if the engagement and retention rates are strong. This is Kin’s main lifeline for delivering on that goal, and yet the community has mostly been left in the dark here.

TL;DR Recap: How We Become Most Used:

What can Kin do to become the most used cryptocurrency by end of year? Any of these launches would signal good things:

  1. Launch public SDKs.
  2. Launch an Identity Layer.
  3. Launch public blockchain nodes.
  4. Launch the Atomic Swap.
  5. Roll out Kin into Kik.

[thrive_leads id=’3175′]

Read More

What Critics Have Right About Kin

Recently, we published our 5 part series on “What Critics Fail to Understand About Kin.” While we firmly believe that there is a lot of unfair criticism about Kin, there are also many points that critics got right.

At the end of the day, successful projects are often successful not because of the things they do well, but instead because of their ability to identify their short-comings and work to correct them.

We already know the “5 Challenges that Kin Must Overcome to be the Most Used Cryptocurrency by EoY,” but these related primarily to technical and product hurdles.

Given that, it is important for the Kin community to know what critics have right about Kin.

#1 – Kin’s Communication is Either Confusing or MIA:

When it comes to communication from the Kin Foundation team, the community feels they have three choices:

  1. No information.
  2. Confusing and vague statements that don’t get clarified.
  3. A response of “I’ll look into it and get back to you!” that goes unanswered.

The Kin Foundation has struggled in the past to meet their deadlines and fulfill previous production promises. Rather than adjust their goal-setting practice, the Kin Foundation stopped giving updates.

There is no official resource for answers and the community has no insights or updates on:

  • The Kin & Kik Integration.
  • The KRE.
  • The Identity Layer.
  • The Atomic Swap.
  • Partnership integrations with Unity, IMVU or others.

Kin continues to operate like a private company, rather than a blockchain project with community stakeholders – and leaving people in the dark has left a sour taste in the mouth of many community members.

It’s also a misaligned behavior for a company that says its operations will one day be managed by a non-profit foundation where the community is supposed to have a strong voice.

#2 – The Community is Unkept:

Kin’s community is the overgrown garden that no one wants to love or nurture.

In the Kin subreddit, many posts, questions or requests for help are answered by the community members (when they have the information to do so) – but the content remains largely unfiltered. In fact, spammy advertisement for other cryptocurrencies, and referral links to exchanges have often sat on the front-page of the subreddit for days on end leaving the community to wonder where the mods are.

In Telegram the situation is even worse. Users frequently use Telegram to get answers on new projects they are exploring. When they come to the Kin chats, they are instead met with an onslaught of aggressive (and sometimes offensive) memes, and given misinformation by multiple sources. In fact, multiple new people have come into the Kin Telegram in the past day only to be told that Kin is crashing because it’s “an exit scam.”  (Note: The one saving grace here is if that if something is really bad and in need of moderation, you can often ping Benji and he will get to it in the next day or so).

The rare times we do hear from the community team, it’s with odd questions like:

The Kin Foundation has at least 3 full-time community managers, and yet, it’s unclear to the community exactly what they are doing. The community feels ignored and taken for granted and that needs to be resolved.

#3 – Kin Wants Free Labor:

Kin is the cryptocurrency that is supposed to be all about rewarding users who create value. Creating a rebel alliance so people can earn their fair share.

At the same time, Kin has shown on multiple occasions that they want free or underpaid labor themselves – such as with the creation of their Ambassador program, where they wanted tremendous community management commitment and content creation from their Ambassador team in exchange for prizes such as T-shirts or online badges (which are still undelivered weeks after the conclusion of the pilot program).

The team has even gone as far to float the idea of volunteer community moderators to help manage Reddit and Telegram.

It isn’t uncommon in the world of crypto to have users step up and help moderator and manage the community – what is uncommon, and in this case hypocritical, is not paying them.

In most communities, the community member moderators are rewarded with bounties paid out in the tokens they’re working for.

Given that Kin has raised $100 million in an ICO, and sits on trillions of vested Kin tokens, they should ensure they “walk the walk” when it comes to rewarding users who create value.

#4 – The Kin Rewards Engine is Broken:

The real core of Kin is in the KRE. Given that developers are essentially replacing their monetization methods with Kin, they need to be able to be dependably rewarded for their users actions.

Right now, all previously released information about the KRE is considered inaccurate and out of date and the KRE is back on the drawing board.

Kin has realized that:

  1. The KRE would cause too much downward pressure in an early market that is highly illiquid.
  2. The KRE will have challenges in identifying fraud.

There are some other problems they haven’t yet acknowledged:

  1. The KRE doesn’t give a reliable way to predict income per user action (as compared to “Rewarded Ad Views”).
  2. The KRE may open up developers to double-taxation events as it requires both receiving the token (income tax) and then selling the token for fiat (capital gain/loss).
  3. The KRE’s declining reward model, instead of a growing reward model, means early adopters win big, but later adopters will depend on the market growth matching the KRE output.

There are a number of complexities surrounding the KRE, but if developers don’t get clarity on their potential earnings, they simply won’t be willing to take that risk.

Woah, this sounds bleak, do you still believe in Kin?

After writing this article, and addressing “The 5 Challenges Kin Must Overcome to be the Most Used Cryptocurrency by EoY.” I know a lot of people are going to ask if I think Kin can still be successful.

The answer to that is, yes.

I still think they can be successful, although I am also less confident than I was before.

In order to get there, they have to acknowledge and work on correcting the challenges they face both as a team and as a product. Weak teams defend their actions, good teams correct them.

I still own the Kin I’ve purchased – but I’m certainly looking for a change in the status quo.

Why do you think these things are problems for Kin?

While I can appreciate that in any startup you need to “pick what you are best at” and cut corners on other aspects to move quickly, Kin can’t continue to cut corners on community and communication. Success in the blockchain world will depend on a strong community that supports the project, and potential partners will look at how Kin treats their community as a litmus test of how Kin would treat them.

Do you think Kin will be the most used cryptocurrency in 2018?

I highly doubt they will be able to achieve their goal of being “the most used cryptocurrency” by the end of the 2018 year – and I think Kin is going to be a long hold in order for it to be a success.

I think users who are dreaming of a $0.01 Kin (or higher) in 2018 are simply wishful thinkers. I think we have a long journey ahead of us to build a robust ecosystem.

At the same time, I would love nothing more than if the Kin Foundation proves me wrong. This is one case where I’d love to eat my words.

But, I think it is fair, healthy, and constructive for us to admit that there are a few things that critics have right 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.

Close
of

Processing files…