Forus Token Service

We have assisted Forus in building a service for their US Token and an internal administration interface intended for their own use. This article briefly summarizes why such a service exists and the technologies it is built upon to ensure development productivity and service availability.

Jarmo Pertman — 2023-12-06 (4 minute read)

In-House Service

With KOOS serving as the registrar, one might wonder why Forus needs any in-house intermediary service at all. KOOS has a systematic interface (API) that can be directly connected to any Forus service, eliminating the need for an in-house intermediary service. Nevertheless, the only system directly integrated with KOOS in the current solution is Forus' in-house token service. All other Forus services are integrated with the in-house token service that we developed. Essentially, this means that before tokens are reserved for owners in the KOOS environment, this is done in the Forus in-house service.

The in-house service serves several purposes:

Forus has its own registrar in case something happens to KOOS or it ceases operations.

Forus has an in-house administration interface that provides a clear overview of token distribution exactly as desired, regardless of KOOS's interface functionality.

Specific functionalities for Forus can be easily added to the admin interface – otherwise, Forus would have to rely on KOOS as a general service provider, subject to their responsiveness and pricing.

Forus has better control over its customers' and partners' tokens, and it doesn't need to share as detailed data with KOOS, a third party.

Forus can pre-sell token distribution, as possible token owners can see their balances in applications before officially agreeing to token collection. Additionally, tokens can be issued retroactively after agreeing to the service terms.

Forus has auditability options, both to verify the correctness of token balances compared to KOOS and to analyze potential issues or fraud.

Most changes to KOOS's API do not necessitate modifications to Forus' applications – it only requires enhancements or changes to the in-house token service.

Forus has the theoretical possibility of offering this platform to other service providers, similar to KOOS, in addition to their current operations, albeit with some necessary further development.

KOOS

In the context of Forus, KOOS primarily serves as the official registrar. Furthermore, KOOS has resolved many legal issues related to the distribution of non-traditional company ownership. For smaller companies, KOOS can provide a complete solution, but from Forus's perspective, it doesn't make sense to put all eggs in one basket. Therefore, the in-house token service is justified for risk mitigation.

Collaboration with KOOS has been smooth, and integration with their API has not proven overly complicated. The service's reliability has also been satisfactory.

Token Service

Forus' token service is nothing more than an API middleware for KOOS with an administration interface. The service is built using the Phoenix framework and the Elixir programming language. These are modern technologies that create a highly productive, robust, and reliable environment for development and production.

The service is structured so that Forus services communicate through the API layer, encompassing various activities related to tokens. API development follows a principle where communication with KOOS occurs asynchronously whenever possible. For example, when issuing tokens to owners, the request is accepted, but the information is sent to KOOS later as a background process. This approach ensures that Forus applications can continue functioning smoothly even in the event of KOOS service disruptions, and tokens actually are granted to owners sometime later. A synchronous request to KOOS is only performed in extreme cases and is rarely, if ever, done — for instance, when displaying token balances to individuals who have not yet agreed to the service terms.

Success Formula

Forus' token service has been in existence for approximately 1.5 years and has operated very successfully with minimal development work after deployment. This error-free and robust system can be attributed to technological choices and the use of best practices in software development. The codebase is thoroughly covered by unit and integration tests, the service is extensively monitored (for instance, we have been aware of KOOS system issues before their team), data is replicated between multiple data centers in different countries to ensure availability, and the quality of system logs is high, making it quick and easy to find necessary information.

All of the above may seem self-evident for any software project, but unfortunately, most of the time, these principles are not applied. The reasons for this could be ignorance, sloppiness, lack of time, or simple laziness. Sadly, projects like this are often destined to fail from the start.

In Conclusion

At first glance, it may seem that there is no business need for creating certain software, but thinking outside the box can reveal various advantages (and, of course, disadvantages) that justify the need for software development. In this project, we actively participated in the project from start to finish, creating the necessary software for the client, along with its surrounding ecosystem for all the availability needs to run in production.

To ensure the success of the project, it is essential to use good practices rather than rushing and taking shortcuts. The software has been in use for approximately 1.5 years by now, during which there have been no critical or less critical bugs discovered, and development work has been minimal, mostly due to new business requirements or changes to the KOOS API.