Open sourcing financial primitives!

Last week, we had introduced the set of preliminary libraries that we were to publish this week. Right on cue, our team open-sourced the 1st set of financial primitives on Github yesterday.

There were a few nomenclature changes and additions to what was mentioned in our previous story. We have defined the financial primitives as the following set of libraries. Would love to hear your feedback so that we can improve them. Feel free to raise pull requests when you improve the libraries and we will add them.

Financial primitive — Resource
We define ‘resource’ as an independent financial entity that can be used to represent any physical or virtual component of value. A resource can be stored or used as a medium of exchange to create any use case in centralized and decentralized finance. This library can be used to programmatically define and manage resources.

Financial Primitive — Store
We define ‘store’ as a financial module that can contain and assign ownership for the value that is transacted in a financial use case. There are two entities — Store and Owner.
Store — Holds the value that is managed in the usecase.
Owner — This entity can be used to maintain the owner details.

Financial Primitive — Transaction
We define ‘transaction’ as a financial component that contains a ledger and records whenever there is a movement of a resource from one store to another (resource/store can be internal or external). Any financial use case will have the need to maintain the list of transactions performed. This is the primitive library to manage them. There are two entities — TransactionGroup and TransactionEntry.
TransactionGroup — This can be used to dictate the type of transaction and provide the scheme for the entries.
TransactionEntry — These are the actual transactions that occur in the usecase.

Bonus library — LSUUID
LSUUID is a lexicographically sortable identifier with format similar to UUIDv4. UUID has some limitations which are already listed and addressed by ULID.

LSUUID provides the following improvements over ULID :-

• The timestamp component in ULID is in milliseconds whereas LSUUID uses nanoseconds so that chance of collision is reduced 10⁶ times
• Ability to bucket the generated identifiers with a prefix is provided by LSUUID
• LSUUID adheres to the UUIDv4 format there by allowing the storage of the identifier in the UUID datatype of data stores which is more efficient than a string which is required for ULID.

Note: For use cases where format of the identifier is not a matter of concern, using ULID over LSUUID might be a better choice.

We are aware that these libraries will not scale and we went to Ruby on Rails & Postgresql due to the comfort level with Ruby for our existing team. (Please do consider this as a v0.001). We will be updating the libraries frequently and add support for additional languages and data stores as soon as possible.

Over the next week, we will be launching our 1st connector library — which would be a Hypto payment aggregator (PA) connector library. We would also be creating a ‘Payment-operations library’ that will orchestrate the 3 financial primitives and the connector primitive to automate your payins through virtual accounts and payouts. This means if you have signed up on the Hypto PA product, you can deploy this library on say, your AWS EC2 with a RDS, and you need not write a single line of backend code. We will also build a front end demo app that helps you understand what we mean by this.

Our goals with open sourcing the primitives are —

1. Build a community of smart and motivated people in finance to solve problems incrementally instead of re-solving the same problem again and again.
2. Reduce build time to create financial products and start assembling libraries instead of writing them from scratch
3. Create new financial use cases that were not possible before due to the lack of infrastructure that democratized access to primitives or orchestrations
4. Forget about managing the infrastructure and leave scalability to our web-services that would be built from these primitives. We will take care of handling querability, idempotency, performance, latency, concurrency and scalability with guaranteed SLAs — this is our monetization engine but we are not focused on this at the moment.

Our goal is right now to create a community that makes finance into a positive sum game from a zero sum one

Please do write to engineering@hypto.in with your thoughts, feedback, criticisms, use cases or anything that you can think can add value and we would get back right away. We would love to see your contributions and pull requests directly on the libraries as well :)