SDK-Specific Technical Roadmap Through Migration Completion
The purpose of this post is to detail the technical roadmap to complete Kik’s work on the base developer tools to support the migration to the Solana blockchain. The primary audience for this post is Kin developers.
As shared in the latest migration update, over 99% of the total Kin supply has been migrated to the Solana blockchain (excluding ERC20 Kin). Token holders with a balance greater than $1 USD have been migrated, all active wallets across the Kin ecosystem have been migrated, and there is a system in place (“On Demand”) that will trigger a migration of any inactive legacy wallet that becomes active. The combination of these properties ensures that anyone using Kin can do so, and that is all happening on the Solana blockchain.
Kin transactions are currently executing in ~2 seconds, down from 6-8 seconds pre-migration. This is a good step forward from the performance of the Kin blockchain but there is still room for improvement. Additionally, the SPL token standard on Solana introduces some nuance, and as is expected in a migration of this size with a diverse set of independent apps with their own peculiarities, there will be issues that emerge.
Now that all targeted apps have migrated to the Solana blockchain we have an updated view of the required technical improvements that will address these emergent issues and get Kin to the level of performance that we expect on the Solana blockchain. This post enumerates the outstanding issues and the fixes being implemented to address them.
Note: This post will focus on the developer tools specific to ecosystem apps. It does not cover exchange updates. The latest on those can be found at kin.org/token-migration
With everything now running on Solana the next step on the technical roadmap is to address all outstanding issues to tighten up the developer tools and user experience.
This roadmap has two phases:
- Phase 1: Efficiency
- Phase 2: Clean up
The goal is for the following two phases to be complete by the end of March. Once these phases are complete, the foundational tools for the ecosystem will be stable and our hope is that the Kin developer community could continue to build on the open source library to advance the toolset for the collective ecosystem.
Phase 1: Efficiency
There are two primary issues addressed in the “Efficiency” phase:
Issue 1: Kin Ecosystem apps have the ability to proactively create a wallet for a user, even if that user hasn’t been sent any Kin. This wasn’t as big an issue on the Kin blockchain because there was no hard cost to doing this. The challenge is that on Solana there is a hard cost to do so because of the “Rent” requirement (a small minimum balance of SOL). While the amount of SOL required for an individual wallet is relatively small, with the size of the Kin Ecosystem this is a material cost in the aggregate. With that in mind, it is always in the best interest of everyone to be as efficient as possible with account creations.
Fix: An update to the SDK that will trigger account creations when a user is sent Kin. This is referred to as “Sender Create”. This means that accounts will not be proactively created but instead created when they receive Kin. The operation of creating an account can be batched in the same transaction as the sent Kin so it won’t cause any extra delay. This increases the efficiency of network capacity and the allocation of subsidies.
Note: the total time for account creation and receipt of Kin is also reduced in this format because it all happens in one transaction as opposed to two. Going forward, the Kin Foundation will monitor potential abuses in wallet creations and will have the option to apply remedies as needed.
Issue 2: Solana introduces the concept of a “Token Account”. A user’s wallet can own multiple token accounts, each with their own unique address, called an “Ancillary Account”. There are some instances where a user has had multiple Ancillary Accounts in addition to their migrated Token Account. This has created some confusion for this subset of users because they are only seeing the balance of their new Ancillary Account.
Note: The funds are not lost, they are just not displayed to the user.
Fix: Implement a consolidation flow for all SDKs that will merge Token Accounts to show a consolidated balance.
Issue 3: Presently the previous Backup and Restore functionality resides in the Base Compat module of the SDK. However, it is not clear that this exists or how to implement it with the Base SDK.
Fix: Add documentation for Backup and Restore implementation with the Base SDK.
When phase 1 is complete:
- A user will no longer have multiple accounts where they don’t see their consolidated balance
- Sending Kin to an uninitialized wallet will no longer fail
- Developers will no longer eagerly create accounts, alleviating the drain on network capacity and subsidies
- Developers implementing the base SDK will have a simple solution to add backup and restore
Phase 2: Clean Up
There are five primary issues addressed in the “Clean Up” phase
Issue 1: Because of proactive account creation there are wallets that have a rent subsidy but no Kin. This has a hard cost in both SOL and network capacity, which creates constraints on the offline migration and the subsidy pool.
Fix: Implement a “Garbage Collection” system that will collect the rent sitting in a zero-balance token account and return it to the subsidy pool. In the event that the wallet needs to have a token account created, the sender will re-initialize the account. This wallet address will remain associated with that user so if they receive Kin in the future that wallet will be created using the Sender Create function. This should not impact the user experience.
Issue 2: Right now, Agora, the service that acts as the endpoint for SDKs, handles all basic functions like account creation and transaction submission. This makes for a simple developer experience but presently it abstracts away the signing on account creation. Currently, Agora does not track app attribution when creating wallets, which makes it difficult to see which apps are creating new wallets. Having better attribution will unlock better measurement and enable the Foundation to have better visibility on the allocation of subsidies.
Fix: Implement Webhook Signing to give visibility on which app is triggering a new wallet creation.
Issue 3: Under certain network conditions, clients are currently unable to easily check the status of a transaction when a remote subsidizer is used. This is due to the fact that the transaction ID is the signature of the fee payer of the transaction, rather than being a hash of the transaction body.
Fix: Internally split the Submit flow into two phases, Sign and Submit. This allows the client to obtain the transaction ID before the submission occurs. This change will be at the lower API levels, so changes on the SDK and webhook components should be minimal to non existent.
Issue 4: The SPL Kin Ledger app is currently in “Developer Mode”. This is because it currently requires “blind signing”
Fix: Add transaction details to the signing flow.
Issue 5: Agora is a robust system that has helped enable a smooth migration and the ongoing growth of the Kin Ecosystem. Because it has served many functions and gone through multiple iterations it inherited some complexities that are no longer required. This was an expected part of the development process.
Fix: Simplify the Agora system to remove any unnecessary components. This will make it simpler for a developer to run their own self-hosted Agora service.
When Phase 2 is complete:
- Zero balance accounts will have been cleaned up, unlocking more offline account migrations and returning excess rent to the subsidy pool to be used for active accounts
- There will be attribution between apps and created accounts, unlocking better reporting
- Ledger wallet app will be in the queue for the Ledger team’s review for public release (official ledger support, no longer in Developer Mode)
- It will be simple for anyone to manage or self host their own Agora system, which will enable apps to run their own subsidization system
Beyond This Roadmap
The Kin Ecosystem is continuing to mature. Existing developers are leaning in, new developers are joining, and the Kin Foundation is continuing to invest resources in this maturation process. The goal is that once these two phases are complete, the Kin Ecosystem can take these foundational tools and continue to build on them. Kin is a decentralized ecosystem with talented developers and a diverse set of user experiences that has made Kin the most used cryptocurrency by mainstream consumers. The migration to the Solana blockchain has unlocked even greater opportunities to continue to expand.