Primitives in finance — part I

This is our first ‘Build in public’ story.

Until now, we have been posting stories that help you get to know us better. This is our first product post that we are posting in public. We are documenting what we are building now and would love to hear your thoughts on this approach. We are building a product for developers by developers and so it’s important for us to build together with our potential users.

Our vision is to build the primitives in finance so that developers can create new and innovative financial products/use cases by assembling those primitives in ways that are not possible today.

Over the past few weeks, we had broken down multiple existing financial products and applications including our payment aggregator application to understand what the underlying primitives were. To look at it from computing perspective, what AWS considered as primitives were ‘storage’ and ‘compute’. These services were respectively S3 (Simple Storage Service) and EC2 (Elastic Compute Cloud). Even something like a RDS (Relational Database Service) ended up spinning EC2 instances in the backend so while every developer uses a RDS today, they are not technically a primitive.

We were thinking along similar lines in finance. After weeks of brainstorming and multiple engrossing debates, we said that a primitive in finance is composed of 2 things

1. A way to store value — Wallet web service
2. A way to record movement of value — Transaction ledger web service

Having decided the above, I walked in to the office today and found Thols and Karthick Vinod (KV) in an engrossing discussion about how we should be building the Ledger service. They were fine tuning the feature set for the ledger service when I went to get my 1st coffee of the day. After their discussion, KV and I sat down to close the MVP feature set for the ledger service.

As soon as we started discussing those features, something did not feel right. We were saying we needed to build primitives but something about a ledger did not feel like it was a primitive component. That’s when it clicked for us — we were looking at AWS primitives in the wrong way. The primitive component of AWS was actually a unit of computing power. So, when someone spins up an EC2 instance, they were actually booting up ‘X’ units of compute/processing power. It was not EC2 itself that was the primitive but what it actually represented that was. When a developer deploys a code to run on EC2, she is basically using up units of computing power to run the code and process a request to provide an appropriate response.

For those of you who read our daily stories, you might have seen the below image that we had shared 2 days back —

Well, this is incorrect.

Value is something that is completely notional in nature. It is an abstract concept and it makes sense for something to have value only when there is a counterparty who is ready to exchange that something for another thing.

This was kind of an eureka moment for our entire team. As we went down this rabbit hole, we started to understand what could be the potential primitive in finance. It was not the value itself as we mentioned above. But before we arrived there, we went on a tangent of considering ‘value’ as the primitive and thought of building a “Value web service”

The above diagram explains some of the potential operations or functions that one could do on something of value apart from standard CRUD. We initially thought it made sense and then started exploring the properties of the ‘value’. Here some of the properties that we thought of — fungibility, divisibility, perishability (will explain what each means later in this story) took us on another path. We were thinking of the starting point of the operations one would do on ‘value’

hypto.com/fin-web-service/create-value
hypto.com/fin-web-service/create-store
hypto.com/fin-web-service/store-value
hypto.com/fin-web-service/create-owner
hypto.com/fin-web-service/assign-owner

While we understood ‘infrastructure’ requires us to provide client libraries and SDKs, we started off thinking in terms of API endpoints as mentioned above to start with. Here, Thols joined us and we started off on the entity modeling which required us to understand what maybe the different permutations of use cases.

Can you create value out of nothing
Can you create value without storing it anywhere
Can you create value without an owner
Can you store value without an owner
Can you own value without storing it

…and so on. We started to go slightly philosophical in universal terms — when we create value out of nothing that is similar to say how Oxygen exists in the universe. And changes in value drew parallels to how changes operated in the universe. This led us to some ideas on how changes in the universe can be seen only at the appropriate timescale at appropriate zoom levels. What this means is that, at a micro level, which is say a normal human eye’s vision, we are able to see changes at a 100+ms level. If you zoom in even further to say an insect, it can see changes at 1mn level and if you zoom out to a continental level, changes can be observed only at millennia levels and zooming out even further to galaxies, you can observe changes only at millions of years.

We went on this to see how this could be replicated as technology infrastructure for finance. Then somehow we got back to the ground zero level by starting to focus on the MVP version which we are planning for a November release (a sandbox).

That is KV started to design the entities and had an initial framework in mind when he started hitting some stumbling blocks. He wanted to check with me on how to solve some of them but being a complete novice in tech, I was way out of my depth here. I just had a thought that some of these problems seemed to have been solved by web3 through blockchain and why not leverage those here. This is when we brought in the big guns — VK, who is our resident expert on web3 and breaks down technology at a level even a 10 year old can understand.

Before going into the problem statement itself, he started by giving us a summary of the problems which blockchain solved — 1) distributed consensus algorithm and 2) double spending

For a centralized system, the distributed consensus algorithm does not make sense since all the servers are within the same network. These are solved by Amazon, Google and a few other companies already. So, if we are starting off building a centralized system, then it does not make sense to actually use a blockchain was the short summary.

But along with this summary was where we kind of understood we were again thinking about it in a roundabout manner. First, we started to break down what value meant. The discussion was about how decentralized world breaks down value in terms of computing power — in an ideal world, the value of the reward for the 1st bitcoin block that was mined (50 bitcoins) should have been equal to the value of the energy consumption it took to mine that block. But, when you bring in a free market system, then you automatically make value as a notional abstract concept that purely is based on what many people are willing to exchange it for (need not be many, even 1 could suffice as long as that 1 person can exchange the value in full).

So, when we came to the conclusion, that is when it struck as — what we are creating is not the actual value itself but ‘some thing/item’ that people would assign a notional value to. Finally, we felt we had landed on the primitive building block of finance which is ‘a financial item’ for lack of a better word as of now.

There needs to be a way to do CRUD on an item with multiple possible properties that can be defined. We started listing down a few of those and don’t think this is anywhere close to an exhaustive list —

1. Fungibility — Is the item unique or not
2. Transferability — can it be transferred or exchanged
3. Perishability/durability — will the item increase/decrease over time and if so, how
4. Divisibility — can the item be split or multiplied
5. Shareability — can the item be shared with another (maybe a sub component of above)
6. Lending capability — can the item by lent or not
7. Convertability — can the item be converted to another item
8. Real world connection — can the item be linked to a physical real world product

By thinking on these lines, what we were essentially doing was changing the frame of reference in finance from who was making the transaction to what is being transferred.

So after the eureka moment about ‘item’ being the primitive in a tech infrastructure for finance, the next primitive would be a simple mathematical variable — which is defining ‘unit of an item’. Here is where we see multiple properties getting flushed out —

1. Scarcity — is the unit created out of thin air or does it have an artificial scarcity
2. Divisibility — what is the number of decimal places allowed (defining the basic unit of the item)
3. Fungibility — Is one basic unit of the item same as another basic unit of the item — this is a very important property as it can define multiple other downstream paths
4. Covertability — plugin to our conversion connector service to provide the real time conversion of the basic unit (only if the item itself is convertable)

This was a very good exercise in helping us documenting majority of our discussion today. We still had some significant conversations around the next level primitives (2nd order primitives) which were storage of items and ownership of items with linking to identity of owners. But, I definitely need some breathing space to start writing that down. Most probably should do it this weekend.

And rather than saying we are building in public, we are unashamed to admit that we need help. We need the smartest people who are excited about solving the hardest problems in finance using technology primitives that basically has the potential to change the way the world works. It is a bold statement to make and we are also humble to call out for folks to come solve this together.

Excited to have an initial chat? Want to brainstorm with us? Participate and be a soundboard to help us out? Or just have a coffee? Write to bestdaysofyourlife@hypto.in