Kin Pushing Ahead: Next Steps on the Migration to Solana

Published in

Kin Blog

11 min readOct 8, 2020

On May 22 the Kik team, in collaboration with the Solana team, put forth a public proposal to the Kin Ecosystem for Kin to migrate to the Solana blockchain. That proposal outlined that in Kik’s view, Solana was the best option to support the increased scale of the Kin Ecosystem. It also outlined a grant for 1% of the total SOL supply that the Solana Foundation was offering to the Kin Foundation for the migration. Following that proposal, the Kin Ecosystem came together to vote on a move to Solana that was ultimately ratified by the Kin Foundation.

Since then, our teams have been hard at work building out a migration plan and the requisite infrastructure to make that as seamless as possible. We are sharing that plan today.

Following the drafting of this plan, the Solana Foundation has indicated that they are no longer willing to offer a grant to the Kin Foundation for the migration. This comes after the Solana Foundation indicated at the end of September that they were planning to reduce the size of the grant. Then earlier this week they indicated a full cancellation of the grant after the ruling against Kik Inc. for its role in the sale of Kin in 2017. This is in spite of the fact that the ruling against Kik does not impact the Kin token, the Kin Ecosystem, or the Kin Foundation.

While this is disappointing for the Kin Ecosystem, we continue to believe that the Solana blockchain is the best option for Kin going forward and after consulting with the Kin Foundation, we plan to move forward with the migration. We will continue to work hard to find a win-win, including further education on the implications of the ruling against Kik.

Kin went live just over three years ago and in that time it has been encouraging to see the ecosystem continue to expand and developers continue to lean in. We are excited to enter this next leg of the journey with everyone in the ecosystem as we continue to accelerate the reach and impact of Kin together.

Summary

This document outlines the proposed migration strategy from the Kin Blockchain to the Solana Blockchain. The document summarizes the migration for three cohorts: (1) Kin App Developers, (2) Kin Holders (wallets, exchanges), (3) ERC20 Kin Holders.

This document is intended to outline the strategy to provide clarity on the process and timing for migration.

Definitions

Kin1: First generation of Kin running on Ethereum
Kin2: Second generation of Kin running on Stellar (non-mainnet).
Kin3: Third generation of Kin running on Stellar (non-mainnet), where Kin is the base asset.
Kin4: Proposed fourth generation of Kin running on Solana (mainnet).
Marketplace Server: A hosted service that developers may use to manage earns and spends on their behalf, using special SDKs. Also used to help coordinate kin2 to kin3. Deprecated in favour of developers managing their own earns and spends.
Marketplace Server
Android SDK
iOS SDK
Migration Server: A service that a user client interacts with to migrate from Kin2 to Kin3.
Agora: A blockchain agnostic frontend that new SDKs will use instead of the Marketplace Server, or Horizon directly. It allows for the transition off of Stellar onto Solana, as it abstracts away blockchain specific details from the developer. Further documentation can be found here.

App Developers

Previous Migration Process (Kin2 to Kin3)

Due to the limitations of transaction throughput on Stellar, the rate of migration had to be controlled. This was done by gradually migrating users from Kin2 to Kin3.

1. A user/client is marked for migration.

For applications using the Ecosystem SDK, the Marketplace server was used to control this process. Applications not using the Ecosystem SDK had to control this process themselves.

2. Client requests for the migration server to create a Kin3 account.

When a client becomes active, it requests its migration status from the system marking accounts in Step 1. If it is marked for migration, a request is made to the migration service to create a Kin3 account with the same address as the Kin2 account of the user.

3. Migration server looks up the Kin2 balance, and burns the Kin2 wallet.

The migration server checks the current balance of the kin2 account before instructing the user to set the priority for their key to 0 on the kin2 blockchain, making their kin2 account unusable from then on.

4. Migration server funds the same Kin3 wallet.

Once the migration server verifies that the Kin2 account has been burned, it funds the newly created kin3 account with the same amount of Kin as was previously held on the kin2 blockchain.

Challenges With The Previous Migration Process

Peer-to-peer operations fail during migration

Since distinct clients may be communicating with two disconnected blockchains, the current SDK and migration system leave any users transacting kin2-to-kin3 or kin3-to-kin2 in an unusable state until both users have migrated. This ends up being the majority of users due to churn in accounts for an extended period.

No batching of transactions

Since migrations happen on a per-user basis when the user is online, the transactions are distributed according to the usage patterns of each app in the ecosystem. This means that migrations cannot be reasonably batched to decrease blockchain load. Since burning the previous wallet requires the user to sign the transaction, this operation also cannot be batched and must be client-initiated, further increasing load.

Accounts must be online

If a user account must be online to migrate, then the user needs to be active on the service which is attempting to migrate. If that user has churned, as a majority of users have for any service, or if a user was subject to the very-prevalent Kin SDK bug which caused many duplicate Kin accounts to be created for a user, those accounts will never be able to migrate.

The migration is never complete

There are a number of ways in which a wallet can become abandoned. Either a user voluntarily leaves a service or has lost their private seed due to a bug or other issue in the user experience. We will never be able to complete migration from the kin2 blockchain fully leaving many abandoned Kin accounts on the kin2 blockchain permanently. Eventually, we will need to decommission the kin2 blockchain and we will need to be finished with the migration for that to happen.

Proposed Migration Process (Kin3 to Kin4)

The general idea behind the new migration plan is to place the Kin2/Kin3 blockchains into a read-only mode, and have accounts be migrated using both batched and on-demand processes (as described below). The migration of an individual account involves allocating a new account on Kin4, and funding it with the same balance as observed on Kin2/Kin3 [1]. The initial funding will come from a migration/minting wallet. At no time during the migration process would anyone but the user have access to their private seed.

There are two fundamental pieces that make this migration strategy possible. First, both Solana and Stellar use Ed25519 for keypairs. The migration process can re-use an accounts public key to allocate a new account on Solana, while the account owner can continue to use the original associated private key to sign for their transactions. Second, Solana’s transaction throughput is orders of magnitude higher than Kin3’s Stellar blockchain. While this strategy is possible for a Stellar to Stellar migration, there is very little bandwidth on Stellar to support both regular transaction traffic as well as a batch migration.

The migration will be run for both kin2 (Stellar) to kin4 (Solana), and kin3 (Stellar) to kin4 (Solana) migrations. In order to prevent double migrations, burned wallets will not be migrated from kin2, as a burned wallet indicates they migrated to kin3.

1. Disable Kin2/Kin3 Transactions

A quorum of the validators for Kin2/Kin3 must agree at a given point in time to disable the processing of transactions [2]. At this point, no new transactions can be submitted, but account data can still be queried.

2. Set the blockchain version to 4 on the Agora Service

The centralized agora service will need to indicate (via the GetBlockchainVersion() RPC [3]) that the current blockchain version Kin4 (Solana). This can be hard coded from this point on as there is no returning to kin2/kin3 once the process is initiated.

3. Support on-demand migrations

On-demand migration support removes the need to wait for every account to be migrated before Kin4 can be enabled. An on-demand migration has the following flow:

Upon interaction with a Kin account (GetBalance, SubmitTransaction), check to see if the account has been migrated.
If an account exists on Kin4, and has a migration transaction, it is considered migrated.
If the account has not been migrated, perform a migration [1]
Perform the requested operation if possible, or request the caller to re-do the operation with Kin4 primitives.

4. Begin batch migrating all wallets from Kin2/Kin3.

To expedite the migration process, a background process will iterate over the entire set of accounts on Kin2/Kin3, performing a migration [1] for each account.

The order in which the accounts are iterated on can be tuned based on last use. This reduces the probability of an “on-demand” migration being required.

Benefits

The process can begin and end while users are offline.
The migration will complete deterministically. Since we know all wallets which exist and all wallets which have migrated, we can know when we’re done. Once the process completes, all wallets will exist on Solana.
No one but a user can spend their Kin. Since the user is the only one with their private seed, no one but the user can transfer their funds. The owner of the Solana Token account will match the public key on Stellar.

Kin Holders (wallets, exchanges)

Proposal (Kin3 to Kin4)

The goal for the migration of exchanges and wallets is for this to be as seamless as possible for the end-user — ideally resulting in no action required. Kin2/Kin3 and the Solana Blockchain both run on the same elliptic curve, which means that Kin public keys can be recreated on Solana and holders will be able to continue using the same private key.

The batch migration outlined above will have migrated all of the wallets used by exchanges and wallet applications. We will be working with wallets and exchanges to support the Solana migration. A list of exchanges and wallets that will support Solana will be published and continually updated. If you hold Kin in a wallet or exchange that is not identified on the list, we recommend moving your Kin to one that is listed to ensure you are able to initiate transactions after the migration.

Wallets that interact with https://www.mykinwallet.org/ will continue to work, as the site will be upgraded to support the Solana migration.

ERC20 Kin Holders

Proposal (Ethereum to Solana)

There are still a number of people who hold Kin on Ethereum. The migration from Ethereum to the Kin Blockchain has been open indefinitely following a burn/mint process. This process is still available through Coinswitch today so if you are a holder of Kin on Ethereum, you can follow the process here to move your Kin to the Kin3 Blockchain ahead of the migration noted above. This is the recommended path for ERC20 holders.

If a holder of ERC20 Kin does not move their Kin to the Kin3 Blockchain ahead of the Solana migration there is an option to go from Ethereum to Solana directly. This will follow a similar burn/mint process between Ethereum and Solana. A service holds tokens on Solana equivalent to the balances of all remaining ERC20 accounts. To migrate to Solana, a holder of ERC20 burns their Ethereum tokens and submits the signature to the service. The service confirms the burn and transfers that amount of tokens to the user’s new account on Solana.

Fees and Subsidization

Unlike Kin3, where transactions could be whitelisted to avoid fees, Solana requires fees. Additionally, every Solana account requires a minimum balance of Sol to avoid being deleted [4].

To address this, the Agora service will introduce subsidization infrastructure, whereby the operator of an Agora instance can choose to subsidize both transactions and accounts [4]. The community hosted Agora service will subsidize both account creations and transactions. This subsidy will remain in place at the current scale of the ecosystem for the foreseeable future. Any change to this subsidy will be communicated well in advance.

There will be, however, quality of service mechanisms in place to avoid the abuse of subsidization. For example, there may be rate limits on how many transactions a user can perform, or how many accounts can be created. For developers who wish to have increased limits, they can run their own Agora instance, subsidizing Solana operations themselves.

Next Steps

The team has already begun technical preparations for the migration of the three cohorts and has started conversations with exchanges and wallets to support this proposed migration strategy. The recent launch of Agora and the rest of the Milestone 2 tooling is the beginning of the technical work for App Developer stakeholders. Changes to Agora that will complete the above migration processes are underway and will ship as a part of Milestone 4 later this fall. Preparations for the other two stakeholder groups are also underway. The Solana team has been responsive to questions and concerns about the right ways to approach migration for these groups and we will continue to work with them to make sure the right information is shared.

In the meantime, developers should be looking to upgrade their SDKs to the latest version of their platform:

The migration will take place on December 8, 2020. To ensure a smooth and timely migration, the Kin Foundation is offering an incentive of 2,000 Kin per MAS to all developers who have updated to the latest version of the Kin SDK within three business days of its release, which is currently projected to be released on November 9. MAS for this incentive will be measured as of October 31. Verification of the update will be required prior to receiving payment.

If you have any questions in the interim, please join the #kin-migration channel on Discord: https://discord.gg/3xgm4Td

Appendix

Account Migration Process

The process for migrating an account from Kin2/Kin3 to Kin4 is as follows:

Allocate a Kin4 account, where the owner of said account will match the address on Kin2/Kin3.
• If an account already exists, check to see if a “migration” transaction has been performed. This can be verified by searching for a transaction where the source is a “migration” wallet.
Fund the newly created account with the balance on kin2/kin3.

There are various optimizations that Agora can make to optimize (1). For example, bloom filters or other caching techniques can be used to avoid extra lookups.

Read Only Stellar

In order to ensure that Stellar is placed into a read-only mode for all users, the Federation must agree at a point in time to stop processing transactions. This can happen in one of two ways:

Shutdown a quorum (or all) validators: At this point, the network will cease to process transactions as there will no longer be a consensus. This is the easiest approach.
Modify validator code to not allow transactions: This approach involves creating a modified Stellar core, where a configuration parameter is introduced that would disable the processing of transactions without shutting down the cores. This change would be deployed in two steps:
• Have (at least) a quorum of nodes in the federation upgrade to the modified core.
• Have (at least) a quorum of nodes accept the “disable transactions” configuration.

GetBlockchain() RPC

Currently, the SDKs have a hardcoded GetBlockchain() method that is used to determine which blockchain primitives to use when performing operations. A new GetBlockchain() will be introduced to Agora, which the SDKs can query on startup to infer which primitives they should be using.

Account Subsidization

In order to prevent token accounts from being garbage collected, a minimum number of Sol must be present in the token account. Account subsidization involves providing Token accounts with the Sol.

In order to prevent users from stealing the Sol used for rent, the token program is configured to only allow the Sol to be returned to the subsidizer. The Sol can only be returned to the subsidizer if there is zero Kin in the account.

Accounts with zero Kin that have been subsidized are subject to garbage collection, whereby the subsidizer may close the account and retrieve it’s Sol. If the user wishes to use the same account again, they can simply recreate it with the same keys.