How CHSB turned into BORG: Token Migration from the perspective of Engineering, QA, and DeFi Teams

Introduction

The evolution of the cryptocurrency landscape over time has made us think about updating our SwissBorg token ($CHSB). Launched in 2018, CHSB was created at a time when smart contract technology was in its early days and best practices were still being established. This led to the CHSB contract becoming cluttered over time, incurring high gas transaction fees required to transact with it.

In addition, the DeFi revolution, which emerged well after the CHSB was created, provided a set of features that were nearly impossible to do with the original token’s smart contract. In order to fully utilise DeFi’s capabilities and unlock the potential of business models on the blockchain, at SwissBorg we made the decision to migrate to the $BORG token.

Let’s dive into the details of the migration process:

Engineering Outlook

How we prepped for the migration

The Borg migration involved a broad set of our systems such as accounting, transaction processing, on-chain migrator the SwissBorg app, designs and logos, and marketing materials among many other components. . Due to its complexity, we had to leverage the specialised expertise of engineers responsible for particular systems, as well as the general oversight of the most experienced and tenured engineers at Swissborg.

Mobile feature flags

For mobile, since the migration was a multi-phase process, we leveraged feature flags to dynamically alter the user experience in the app. To handle the possibility of migration stages changing while users were using the app, feature flags were additionally integrated into API calls. This ensured that the mobile app displayed the correct UI elements corresponding to the current stage of migration whenever users navigated between screens.

Backend feature flags

Backend feature flags have proven to be very useful to control whether deployed features are enabled or not. Once we decide to enable the feature, we just switch the flag in our deployment configuration. For example, one purpose of these flags was to stop displaying the CHSB account and start displaying the BORG account once the migration was executed… Feature flags allowed us to follow an approach of incremental delivery. This approach helped keep code changes relatively small and testable as single units of functionality. The downside of this approach is that it’s easy to lose track if too many feature flags are active at the same time. Hence, we keep them constrained to specific use cases like this migration.

Mobile force update

To ensure a smooth migration, it was crucial that all users had downloaded the latest version of the app. However, this could inconvenience users who might face issues updating, such as requiring a system update that is not available for their phone model. Fortunately, the force update encountered minimal issues. Users were only required to update the app, not their operating systems, and our support team effectively addressed any user-reported problems.

Tech debt

While minimising technical debt is always optimal, we recognize that certain situations, particularly time-sensitive migrations, may necessitate including a certain amount of technical debt. This doesn’t imply compromising on overall quality, but rather accepting temporary code introduced specifically for this unique event. However, it’s crucial to commit to regular maintenance within our codebase to remove this accumulated technical debt and ensure long-term sustainability.

QA Outlook

In order to ensure that QA covered as many migration-affected “parts of the system” as possible, a meeting with all QA stakeholders was held well ahead of the migration rehearsal (more on this below). In that meeting, each stakeholder claimed responsibility for the corresponding migration-affected part and worked within their squads to polish/finetune all migration features.

Early Access

One key aspect to highlight was the fact that all QA engineers had early access to all the required information and functionality on the stage environment: designs, UI flows, actual migration swap scripts, the actual new token ($BORG), other migration related scripts (delete/migrate Auto-Invest, delete/migrate Price Alerts, etc.), and the possibility of updating feature-flags at any time to test the different stages of the migration.

Thanks to that, QA Engineers were able to organise multiple squad-scoped migration rehearsals and find potential problems early.

Migration Rehearsal

Another key aspect was the creation of a “flight-check” script ahead of the actual migration.

The idea of having such a “flight-check” originated from the shared feeling that many squads and teams were involved in the migration, but there was not much communication between them on the topic, not to mention information about how the actual migration process was going to be done.

So, we created a draft with around a dozen sequential steps required to perform the migration, and shared it with everybody involved. A few days later, that initial draft became a proper list of a couple dozen sequential steps, added from all involved teams.

Having the “flight–check” with details from all stakeholders allowed us to perform a migration rehearsal, which discovered required updates that were implemented for the actual migration. Furthermore, from the results of the rehearsal, we understood that a bigger test, in a “production-like” environment with “production-like” data was required.

Acceptance Environment Tests

All the testing mentioned above was done from a single user point of view, so we complemented that with further tests on the Acceptance environment, with a production-like state, running a migration scenario for a big amount of users with production-like data.

That exercise let us understand what kind of issues we may have faced if running the migration on production and gave us more confidence in the overall performance of the execution.

DeFi Outlook

The BORG token comes with a bunch of improvements, making it a significant advancement to empower its usage in DeFi by everybody!

One of the standout features of this new token is its implementation of “real” burns, a departure from previous methods where tokens were sent to an address that effectively rendered them irretrievable. In the past, burning tokens involved sending them to an address like 0x000…000, making them inaccessible to anyone. However, with the new token, the total supply can diminish organically, offering a more transparent and secure mechanism.

Moreover, the enhancements extend to efficiency gains as well. Gas usage, a crucial consideration in blockchain transactions, has been substantially reduced for both approval and transfer processes. This optimization not only improves the overall user experience but also contributes to lower transaction costs, a factor that can greatly benefit DeFi participants. Approvals can now also be done gasless with permits, eliminating the need for users to pay gas fees upfront.

Furthermore, the migration process for existing token holders has been made permissionless, aligning with the ethos of decentralized finance. This ensures a seamless transition for users and underscores the commitment to inclusivity within the ecosystem.

All migrated tokens, including CHSBs, and unmigrated ones like BORGs, now coexist in the same ecosystem, on a single smart contract. This consolidation fosters unity and cohesion within the community while maintaining the integrity of the network.

Importantly, the new token is designed with interoperability in mind, aiming to bridge across different blockchain networks and integrate seamlessly with existing DeFi platforms. More on this in the coming months!

Conclusion

The successful migration marks a significant milestone in our journey towards enhancing user experience and efficiency in DeFi. The meticulous planning and execution across all facets, from engineering and QA perspectives to DeFi considerations, underscore the dedication and collaborative spirit of our team.

The implementation of feature flags, both in the mobile apps and backend systems, allowed for seamless updates and dynamic UI adjustments, ensuring users remained informed and engaged throughout the migration process. Despite potential challenges with forced app updates, our support team adeptly navigated any user-reported issues, resulting in minimal disruptions.

The introduction of BORG brings significant improvements, including transparent burns and reduced gas usage. Looking ahead, the consolidation of CHSB and BORG within a single ecosystem paves the way for further innovation and integration across blockchain networks, promising exciting developments in DeFi.