Non-Fungible Currencies

Oops, I created a currency!

I’ve spent a lot of time building financial systems for companies, and one of the most common things I run into is that companies have created their own custom currencies that are core to their business.

But… almost none of them realize it.

If you are creating $SCAM meme coins it would probably be pretty obvious that you are creating a currency. Most of the time it’s more subtle though. The business comes up with cute names for the currencies that make them seem like something unique: loyalty points, referral credits, LLM tokens, frequent flyer miles, maybe even seats.

It might even be something really common that we don’t usually think of as a financial asset like hours worked, or PTO.

Though the names might vary they all have some things in common:

They hold value that can be spent later
They can be exchanged for cash at some kind of exchange rate
You can have multiple of them

These are all properties of what makes something mechanically a currency, without the social or cultural context generally associated with currencies.

There is one more important property of currencies that I left off the list, and that’s what I want to focus on in this post: that they are fungible.

Fungible means that the value of each unit is the same as every other unit. You can trivially do math on collections of fungible things because of this property. For example, if your bank account has $100 in it and you deposit an additional $50, you now think of it as just $150 (not $100 + $50). Since dollars always have the same value as every other dollar there is no need to keep track of individual dollars, or subsets.

Some of the examples above are fungible and some are not. Let’s break them down:

Example	Fungible	Reason
US Dollars	Yes	Every dollar has exactly the same value as every other dollar.
Referral credits	Yes	Credits like this are usually pinned to a specific real currency value. Giving them the same properties.
Loyalty points	Yes	Each loyalty point is worth the same amount as every other loyalty point.
Frequent flyer miles	Yes	Each frequent flyer mile is worth the same amount as every other frequent flyer mile.
Seats	No	The value of a seat varies by the event and often the seat location.
Hours worked	No	A worked hour’s value varies depending on the pay rate of the worker.

An interesting note here that might not be obvious is loyalty points and frequent flyer miles being considered fungible. It’s common for both of these to accumulate and spend at variable rates. For example. you might get double miles when you pay for a specific flight. Alternatively, you might get a bonus to the value of your miles when you redeem them for specific things. However, the frequent flyer miles themselves are completely interchangeable. It doesn’t matter how you got the miles when determining how much they are worth.

In contrast, seats and hours worked have intrinsic value that is dependent on their real world context. For example, a front row seat at a concert is worth more than a seat in the nosebleed section behind a pillar. Even if you buy 100 seats, at no time does your front row seat have the same value as a bad seat. Even though they are the same category of thing, each one is fundamentally different and has a different value.

So how can we tell if something is fungible currency or not?

Identifying non-fungible currencies

Simply put, a non-fungible currency is an asset where each group of units has a variable value.

Here are the properties of a non-fungible currency:

It can be held and spent later
You can have multiple units of them
You can break down multiple units into smaller groups
The value of each group of units is fundamentally different from other groups

Just as important as the properties of a non-fungible currency is what it means to work with them. Since they are fundamentally not fungible, you can’t sum them together into a single number. While you can break larger groups of units into smaller groups, you can (almost) never add two of them back together.

Hours worked, PTO, and event seats are all pretty common examples of non-fungible currencies I’ve seen in the wild.

For the rest of our examples we’ll primarily focus on hours worked since its the most ubiquitous, but the principles apply to all non-fungible currencies.

Sort of. We have a square is a rectangle, but not all rectangles are squares situation going on. NFTs are a special kind of non-fungible currency that generally has a maximum amount of 1 and cannot be subdivided. Technically NFTs also have to be stored on a blockchain (although this part of the definition is built on the idea that only a blockchain can properly enforce NFT restrictions). While NFTs do have variable values the focus for the product is more about uniqueness and ownership.

Real estate is a good example of a non-fungible currency that could be considered an NFT, since each property has a unique value (even among similar properties) and cannot be subdivided.

Wait, so is hours worked a currency?

Let’s evaluate hours worked based on the non-fungible currency properties:

Can it be held and spent later?

Yes, it’s normal for hours to be “held” until payday

Can you have multiple units of hours?

Yes, you can have multiple hours worked

Can you break down multiple units into smaller groups?

Yes, you can break down hours into smaller groups like fewer hours, minutes, seconds, etc.

Is the value of each group of hours fundamentally different from other hours?

Yes, the value of each hour is fundamentally different from other hours based on pay rate, even though the unit of time is the same.

It seems like hours worked is an example of a non-fungible currency, but does it actually have these properties in your system? Unless you have a very savvy financial engineering team, probably not. However, that doesn’t mean it isn’t a non-fungible currency, it just means you aren’t treating it as one.

Working with payroll/payout companies I’ve seen an obscene amount of time and effort go into building systems that try to reverse engineer the value of hours worked after summing them into totals and thus losing the individual value of each hour. In at least two cases the majority of code at the company was dedicated to ways to work around this problem.

The “solutions” often involve:

Large data pipelines that try to reverse engineer which hours in a bucket stemmed from which employee
Application of consistent guessing logic like “First in first out”
Keeping sub-ledgers of hours which are supposed to roll up into buckets
Manual investigation and reconciliation of hour buckets/payouts

In each case, if the hours being tracked had been identified as a non-fungible currency and treated accordingly, none of this work would be required.

Why don’t we think of it as a currency then?

The two major reason for this are:

Most operational financial systems are home-grown and custom built by companies
Traditional financial systems don’t work for non-fungible currencies

Let’s take a deeper look at each of these.

Home-grown financial systems

It’s really common (particularly for smaller companies) to have your financial model start out as an amount field in a relational database, usually tied to a product model. It doesn’t make sense for most start ups to hire experts in building financial systems, so they ask their product engineers to build it, and they build it like a normal product feature.

Product models aren’t financial data, they are just rows in a database like all your other data. Nothing special about them, and no need to treat them in a special way.

There’s nothing wrong with this, and in fact I think it’s almost always the only way to approach it. Startups need generalist engineers to thrive, and unless you are specifically selling a financial product it almost never makes sense to hire someone specifically for financial engineering.

However, without recognizing that you’ve created a currency, you are going to run into a lot of common currency problems. These will seem to be unique to your company, but are actually solvable with established patterns for dealing with non-fungible currencies (and financial data in general).

Bad support for non-fungible currencies

Traditional financial systems are built on the concept of accounts and/or use double-entry ledgering as their primary model. These systems are fundamentally about summing things together into buckets (accounts). Double-entry ledger, in particular, is fundamentally based on everything being summable and relying on those sums to validate the system.

This makes it really difficult to represent non-fungible currencies in most financial systems. Even if someone at your company identified something as a non-fungible currency they probably found it impossible to represent in your financial system. This is why so many companies end up building their own custom systems to track non-fungible currencies.

What now?

Maybe from reading this article you’ve realized that your company does handle some non-fungible currencies, what do you do now?

You are likely suffering from a number of problems related to the root cause of not treating your data as financial data. The good news is that these problems are very common, and at least mitigable. Fully solving these problems though, will take concerted effort and structural changes.

What you need to do is start applying patterns and properties to the models that represent your non-fungible currencies. We’ll cover some of the most important ones here.

Principle 1: Embrace non-fungibility

This is the most common mistake we see. Accept that fact that no two sets of hours are the same and stop trying to add them together. It’s fine to have roll-ups or aggregates, but make sure you are always keeping track of the individual parts that make up those totals.

Remember that the core difference for non-fungible currencies is that context is critically important and you need to keep track of it. Summing is the death of context by definition and has to be avoided.

Your currencies might be very complex based on your business model, but a basic rule to follow that will help you move in the right direction is: “Non-fungible currencies can not be represented by only a number”. Any time an operation results in a single number as a data point you’ve lost context.

Principle 2: Make it immutable

Immutability is a common practice in financial systems, and for good reason. Your currencies have value and we are going to exchange them for cash. It’s important that when we do those calculation we know the exact state of the hours we are working with. The only consistent way to do this is by making the data itself immutable.

No immutability means no auditability; so if you are often struggling with trying to explain why your system made a particular calculation, a lack of immutability is likely the root cause.

Principle 3: Model exchanges

The non-fungible currencies you are tracking all get exchanged to a fiat currency at some point. This is an important event for your finances when you take something you made up, and turn it into real money. A common mistake is not to capture this transition in your system. This often leads to an inability to explain why your system made a particular calculation or where money came from.

You should explicitly model when that happens in your system. Capture exactly when the exchange took place, then exchange rate used, and how you calculated that exchange rate.

For example you might have a product model of hours worked and a field for amount or amount paid, but often the model doesn’t transition to a new state at the point that you make the exchange. This is crucial because your made up thing becoming real money is a critical operation for your company and you need to be able to track that.

Principle 4: Define a single source of truth

Non-fungible currencies need to be tracked in very granular detail by their nature. Figure out what your most detailed model will be and position that to be the single point of reference for everyone to base their calculations and decisions on.

For example, let’s say that you are a Temp Company providing workers to clients on a per-hour basis. You now have two discrete calculations you need to be able to make based on hours worked:

Calculate how much money to pay the employee that did the work
Calculate how much money to bill the client for the work provided

It is crucial that all of these calculations are based on the same underlying number or you are going to start racking up lots and lots of manual reconciliation hours trying to figure out where the discrepancies are coming from. This will manifest as complaints for your workers, your clients, and your accounting team.

Conclusion

Non-fungible currencies are extraordinarily common, but are frequently misidentified. By embracing the properties of non-fungible currencies, you can start applying patterns and practices to your systems to make them more accurate, to reduce operational work, and ultimately to create more robust financial systems.

Postscript: String Theory can help

String Theory views all money as non-fungible. Our core belief is that the context associated with value is always important and distinct. From ensuring distinct parts are never summed together, to easy handling of single-use exchange rates, String Theory is built to handle non-fungible currencies in a way that is easy to understand and maintain.

If you are feeling overwhelmed by the complexity in your systems, or just want to improve your financial systems, we’d love to chat.

Request a demo → Contact sales →