Solutional
Forus offers customers and partners an additional form of value through US Tokens. For example, both passengers and drivers earn tokens from taxi rides. The accumulated tokens are intended to be exchangeable for a stake in Forus in 2027. The underlying idea is that people who contribute to the company's growth should have an opportunity to share in the value they help create.
The official token registrar is the startup KOOS. We helped Forus build an internal token service and administration interface around that external platform.
Why Forus Built an In-House Token Service
Because KOOS provides an API, Forus applications could theoretically integrate with it directly. Instead, only the internal token service communicates with KOOS. Every other Forus system uses the internal service we developed.
This architecture gives Forus several advantages:
- An independent internal register if KOOS becomes unavailable or stops operating
- A purpose-built administration interface with the exact reporting and management features Forus needs
- The ability to add Forus-specific functionality without depending on a third-party provider's roadmap, response time, or pricing
- Greater control over customer and partner data, with less detailed information shared externally
- The ability to show provisional token balances before a user accepts the service terms and to issue tokens retroactively after acceptance
- Audit trails for comparing balances, investigating incidents, and detecting possible fraud
- A stable internal API that shields other Forus applications from most changes in the KOOS API
- A potential foundation for offering a similar platform to other service providers in the future
The Role of KOOS
For Forus, KOOS primarily acts as the official registrar. It also provides a legal and operational framework for distributing non-traditional company ownership.
For a smaller company, KOOS may be a complete solution on its own. Forus has broader operational requirements and chose not to place every dependency in one external system. The internal token service therefore reduces risk while preserving the benefits of KOOS.
Our collaboration with KOOS has been smooth. Its API was straightforward to integrate, and the service has met our reliability expectations.
Token Service Architecture and Technology
The Forus token service is an API intermediary between internal applications and KOOS, combined with an administration interface. We built it with the Phoenix framework and the Elixir programming language. These technologies support productive development and a robust production environment.
Forus applications use the service's API for token-related operations. Communication with KOOS is asynchronous whenever possible. When an owner receives tokens, for example, the internal service accepts and records the request immediately; a background process sends the information to KOOS later.
This design lets Forus applications continue operating during temporary KOOS disruptions. Pending changes can be synchronized when the external service becomes available again. Direct synchronous calls are reserved for the few cases where an immediate external response is genuinely necessary.
Reliability Through Engineering Practices
After approximately 1.5 years in production, the token service had required very little corrective development. That stability came from both the technology choices and the engineering practices around them.
The codebase includes extensive unit and integration tests. The service is thoroughly monitored, and our alerts have sometimes identified KOOS-side issues before their own team reported them. Data is replicated across multiple data centers in different countries, backups are maintained, and structured logs make operational investigation fast.
These practices may sound obvious, yet they are often skipped because of limited time, insufficient experience, or pressure to release quickly. A production system becomes reliable when quality, observability, recovery, and maintainability are treated as requirements rather than optional follow-up work.
The Business Value of an Internal Integration Layer
At first glance, building an internal service around an existing API may appear unnecessary. A wider analysis revealed benefits in resilience, privacy, auditability, product flexibility, and vendor independence that justified the investment.
We worked with Forus from the initial architecture through production operation, delivering not only the application but also the surrounding infrastructure and operational practices required for high availability.
During the first 1.5 years, no critical or minor software defects had been identified. Subsequent development was limited mainly to new business requirements and changes in the KOOS API. The project shows how a carefully designed integration layer can reduce operational risk while giving a company greater control over a strategically important service.
