Context Around IPLv2

Many of the teams at Kik are working on pre-Kin roadmaps, mostly on improving Kik Messenger and preparing it to be an appropriate launch pad for Kin. There are also teams working on projects like the Kin Rewards Engine, partner programs for developers, bots, etc. Many of these projects are longer term, but my team is fortunate to work on a shorter term one.

The project is called IPLv2, and its purpose is to let a group of Kik power users experiment with real Kin tokens inside of Kik Messenger so we can study their usage patterns.

The fact that there’s IPLv2 means that there was also IPLv1. This project launched when the Kin token distribution event (TDE) ended and showed TDE participants their balances inside of Kik.

IPLv2 is different because it isn’t geared primarily towards TDE participants. There are significant differences between TDE participants and Kik users. The average Kik user knows nothing about crypto, and they don’t understand security, private keys, tokens, exchanges, etc. Targeting TDE participants would have been the easy way out because they’re already crypto experts, but this wouldn’t have brought us closer to our goal of making Kin the first mainstream adoption of cryptocurrency, which is where the product and UX challenges lie.

The project has several goals:

• Focus on a group of Kik power users. We don’t want to focus on users with expertise in cryptocurrencies (like TDE participants). Among “regular” Kik users, we want to start with ones that are easier to engage since optimizing engagement isn’t a direct goal of this specific project.
• Real Kin, no test nets, off-chain or staging environments. We want users to actually use the same Kin that TDE participants have purchased. It’s harder to examine usage when the tokens are fake.
• Experiment with an example use case of a two-sided economy (both earn and spend). We want to see the full cycle in motion, where a user starts by earning Kin and then spends it within the same digital service. Finding optimal use-cases is not our priority at this point.
• Minimize wallet UX friction so people can focus on using Kin and don’t worry about issues like private keys. We’re not focused on trying to figure out an optimal product for a mainstream wallet that supports all best practice security measures. We have separate teams with dedicated projects that focus on that.
• Minimize time to production. We are willing to make a lot of simplifying assumptions so we can launch this specific project faster. Other projects are focused on longer-term solutions that do not require making these assumptions.

Choosing an appropriate blockchain layer for the project

Our infrastructure teams are working to support multiple blockchain infrastructures for Kin. The TDE was performed on Ethereum, but we know that Ethereum has several limitations that will prevent us from scaling Kin in the long term.

Nevertheless, we have to choose an appropriate infrastructure based on the goals mentioned above. Launching this project on Ethereum has several benefits:

• It is the fastest time to production, which is one of our goals since Kin is already available over Ethereum.
• Because we’re looking to use real Kin, relying on Ethereum will avoid a token migration. It is possible to migrate tokens between blockchain solutions, but this is not a process we want to get into prior to this project.
• Staying on Ethereum will avoid additional compliance aspects with regarding to blockchain behavior, see below for more details.

There are several big problems with using Ethereum:

• Fees are the biggest issue. Kik power users will need to have an ETH balance to pay fees. This is difficult because they’re not crypto experts and most of them aren’t even familiar with the field. The fees on ETH are also relatively expensive (several cents per call) and consumers will find them extreme for micro transactions.
• Long confirmation time. It may take several minutes (or longer) until a transaction is processed and confirmed. This is much beyond what consumers are willing to accept. Imagine waiting 30 minutes after paying for an app in the App Store before being to able to download it.
• Down time during high demand periods — for example, during a popular ICO.

We are trying to bring Kin to the masses. To consumers who are uneducated about crypto and have expectations for responsiveness set by centralized systems they’re used to. We can’t plan according to ideal conditions and the average case.
When designing systems for consumers, we have to plan for worse cases and non ideal conditions of the network. The volatility is high and the network may become congested. We need to make sure that even under these conditions the product still behaves in an acceptable manner.

One of the alternatives for Ethereum is using an off-chain solution. Off-chain solutions are relatively easy to implement and have been discussed in the Kin whitepaper. However, upon further compliance review, our infrastructure teams have come to the conclusion that relying on an off-chain solution will have a high risk of being classified as money service business (MSB — a business that transmit or convert money) or requiring money transmitter license (MTL — a business entity that provides money transfer services or payment instruments). I assume that this compliance issue will be discussed in detail in a separate post by our compliance team. Since the licensing regulations involved are far from simple and would contradict this project’s goal of minimizing time to production.

Let’s assume then, that for the sake of this specific project, we should make the effort to use Ethereum. In order to do so, we are willing to resolve the above issues by making these simplifying assumptions:

• Fees will be subsidized for these users. They will not be required to pay for Ethereum fees out of their own pockets. ETH will be given to these users as an award after on-boarding, and a special budget will be set aside for this purpose. How can we protect ourselves against fraud? Since we focus on Kik power users, we have the luxury of choosing them in advance. If we approach them to be part of this project instead of them approaching us, we assume fraud will be minimal. However, the budget for fees will limit the number of users we can invite. Let’s assume for now that this limit is 10,000.
• The use cases that we will design for earning and spending in this project cannot rely on short confirmation times. Product will have a challenge to overcome.

We can also assume that a migration from Ethereum to another blockchain infrastructure is likely down the road, since introducing digital services outside of Kik to Kin will not be possible under the above limitations.

Dealing with private keys

One of our stated goals for this project was minimizing wallet UX friction so these users can focus on using Kin and not be concerned with the security and storage of their private keys until those issues have been resolved. So how can we do this and still provide a working Ethereum wallet that can operate on-chain?

If we don’t expect users to remember private keys or type them in, the user’s private key will need to be stored somewhere. Storing private keys on Kik’s servers is off the table because this would make us a custodian, which has compliance implications. One alternative is storing the private key on device in persistent storage.

This will work well as long as we’re creating the Ethereum wallets in-app for users during on-boarding. Since we’ve already decided to focus on Kik power users who aren’t crypto enthusiasts with existing wallets, this isn’t a big issue.

One problem with this approach is that users who lose their mobile device or delete the app will lose access to their private key and lose their Kin wallet. This is a severe limitation, but we’re willing to make this simplifying assumption for this specific project. If we compare the Kin wallet in this scenario to an actual physical wallet, it also makes sense. If a person loses their physical wallet, they lose the money in it as well. Since we’re focusing on Kik power users and not crypto enthusiasts who have been gifted Kin, the amount of Kin in these wallets will likely be very small.

We have other teams focused on wallet UX that are actively working on challenges like making private keys manageable by mainstream consumers, but this is outside the scope of this project.

Follow up posts

The next post in the IPLv2 series will revolve around product, showcasing some screenshots of the various flows and covering the requirements in more detail will probably be interesting.

More on that soon.