Using Crystal to power the IOU economy

Client

Sikoba is an IOU (“I owe you”) platform that automates the creation, tracking and finally clearing of debt between its users. While Sikoba can be used in a wide array of settings, like business to business contracts and clearings, its design is a great fit for small communities with struggling economies. In many situations where there is a shortage of money, Sikoba can help re-activate local economies. Alex Kampa, founder and director of Sikoba, puts it in very compelling terms: “there is a lot you can do without money, as long as you have credit”.

Think about it like this: in communities where people know each other, the trading of goods and services is operated through currency, but based in bonds of trust. When there is a shortage of currency, the actual physical money is no longer there, but trading goes on smoothly because there is still trust among people. Sikoba builds on top of those trust-based systems, and allows communities to thrive without constantly resorting to money: instead, people can agree to set longer intervals --say, 3 or 6 months- to sort accounts and settle eventual debts, dramatically reducing the necessity for cash.

Requirements & Context

Due to the combination of its high performance and clarity of code, Sikoba’s founder felt the Crystal programming language was a perfect fit for developing the underlying infrastructure for the Sikoba platform. With that in mind, Alex Kampa reached out to Manas.Tech, creators of Crystal, to partner up in the creation of the Sikoba network and app.

Manas kicked-off development in December 2018, for the blockchain infrastructure and mobile app, to bring the Sikoba vision to life. The main challenge in this endeavour was to bridge the complexity that powers the trust-based economic models to a simple and friendly UX. Manas brought to the table over 15 years of experience in complex, unconventional, high-tech software development in scientific and mathematical domains, and human-centered user experience design.

User indicates they have store and want to accept Sikoba

Store owner enters store name

User receives a file with a poster to identify their store and prints it

Store owner hangs the poster with Sikoba brand and QR Code on the store

Approach

To start things off properly, we welcomed Alex from Luxembourg to our offices in Buenos Aires and held a hands-on kickoff. We guided Sikoba through the product design process we use with our start-up partners, going from product vision to a clear roadmap, including effort estimates. The process includes articulating jobs-to-be-done, user story mapping and several rounds of triaging, to distill an MVP. Once we had arrived to that stage, we pressed on together to sketch some preliminary designs for the first prototypes.

The three members of the development team estimated the scope of work in detail following our best practices, and we got to a pickle: the estimated effort for the full-product vision was around three times what Sikoba was allocating as budget to the initial phase. This was not, as it usually happens, a deal-breaker. Good dialogue leads to great results, and we were able to draft a plan that would get us to a functional product that could be of use to Sikoba to go out and get more funding.

So, the first step in the roadmap was a round of spikes that significantly reduced uncertainty in the largest estimation areas. This allowed the team to reevaluate the original timeline and estimate the remaining body of work again. On December 18th, the team determined that they would have the first version ready by March 15th.

Results

For stores, the setup is quite straightforward: they indicate in the app that they have a store, they register the store’s name, and they receive a poster file with a QR code they can print and put on display, so people know that the store accepts Sikoba.

On the customer’s end, it’s also quite simple: when a customer wants to use Sikoba to buy at a store, they ask the store owner about getting a credit line. The store owner then looks up the customer in the app and sets the credit line amount (that is, how much credit you have in this store, and over what period of time). That’s it!

And what goes on under the hood? Well, that’s not as simple, but still pretty elegant. The model that commands all of this is a graph that represents every relation between users. That graph is in constant evolution, as those relations go through different activities, such as:

Barbara grants a credit line to Andy

Andy buys from Barbara using Sikoba

Andy’s purchase from Barbara automatically generates a credit line on behalf of Barbara, that she can use to purchase from Andy

If Brabara and Frank are not in a direct credit relation, the application finds trust paths to enable the transaction, supported by other users in Andy and Frank’s mutual networks of trust.

Everything that happens in the Sikoba app is controlled by an application called Tx Processor. Every time a transaction is created, either by a user or by the app itself, it’s queued in a shared service between Sikoba and the Tx Processor. Transactions are then executed asynchronously by the Tx processor, and their final state is registered. The backend server was built entirely on Crystal, and the mobile app was built on React Native. The platform uses a PostgreSQL database and Redis to handle all transactions, thus effectively separating the data provision from the backend application to the mobile app, from the handling of transactions. This processing was built separate from the application for two reasons: first, it allows more freedom for different components to interact, especially when they don’t have the same response time, and second, because, in the future, the architecture will incorporate blockchain technology.

Also in the future, the app’s roadmap holds the implementation of a graph algorithm to perform a clearing of the entire credit line network: this reduces all transaction values to the minimum equivalent, while still maintaining net positions for every user.

One of the goals of the project was to design a strong architectural foundation that could allow Sikoba to evolve healthily over time. That’s why we built a model that followed the open/closed principle, that states that "software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"; that is, such an entity can allow its behaviour to be extended without modifying its source code.

The team, Gus, Sol, Fran and Mauri, managed to deliver a first functional version of the product on March 14th, one day sooner than they had estimated three months before, after executing the plan with extraordinary precision: 7% ahead in time and 4% in budget.

Impact

The main advantage of the Sikoba platform is that it reduces the amount of money needed to transact. Sikoba brings back to life thousands of years of an economic model that we need to re-learn, married with modern technology to enable trust-based networks at a scale that was impossible before.