Groups (Accounts)

String Theory doesn't have accounts as you would traditionally think of them, instead it has groups. You can interact with a group exactly like you would an account. You can deposit, withdraw, and get balances just like you would expect.

Groups, however, have some additional useful properties that make them different than traditional accounts. We'll break down each of them below

Groups are not exclusive

The same piece of money can belong to more than one group at the same time.

This is a radical departure from traditional accounts, where money must be in exactly one account at all times. This is a powerful tool that allows you to logically group your money in many different ways to support different perspectives and use cases.

For example, let's say that we run a retail marketplace (similar to Amazon) and we have a seller named John. John has a payout group (G1) that represents money we owe him for the products he's sold. Right now G1 contains a single $100 knot K1.

Now, our product team has come up with a great new feature! They want John to be able to use his earnings to buy products from the marketplace if he wants to, instead of automatically making payouts to him.

This puts us in a bit of a bind because we have two different ways we need to think of K1. On the one hand, it needs to be in John's payout account (G1) because we owe him that money, but we also need it to be in his user balance (G2) account so it can be used for purchases.

In a standard account system, we'd need to create a new account that holds money that can be used for both purposes (especially if not all payouts can be used for purchases). And, in fact, we'll need a separate account for all possible combinations of purposes money can be used for.

String Theory, however, keeps all the context with the knot. So you can just add K1 to both G1 and G2 and now it'll be in both accounts. And if only some knots from G1 should also be in G2? No problem at all, you are fully empowered to pick and choose which ones you want to belong to which groups.

Multi-group double counting

If you are worried about accidentally double counting money when it belongs to multiple groups, you are a savvy financial mind. Avoiding double counting is one of the primary reasons for the all-or-nothing account style proffered by double entry systems. It is often becomes a problem again if you introduce hierarchical accounts, or subledgers in double-entry, but that's a topic we won't cover here.

Double counting with String Theory is not an issue. String Theory operates only on knots, which are uniquely identifiable. When providing balances, String Theory looks at the individual knots from the balance and counts each one only once. Not matter how much overlap the groups have in your balance request each knot will be counted only once to determine the combined balance.

Diagram: Multi-group balances

If you are summing balances on your own outside the system, you do need to be careful about double counting. In order to mitigate this any time String Theory provides a balance it also provides a list of every knot that makes up part of that balance. That list of knots will allow you to de-duplicate yourself to avoid double counting. When possible, however, we suggest just asking String Theory for the balance so you don't have to do that step.

Multi-group race conditions

If you are worried about race conditions when a knot belongs to multiple groups you are a savvy technical mind. Double entry system's tout the idea that a balance is a single, lockable row so race conditions are not possible. (It's debatable whether this is actually true, but that's a topic for our blog.)

String Theory provides the same protection, but takes a different approach. The individual locks are on the knots, instead of the balances. Let's illustrate this with an example:

Let's say we have a $75 knot K1 and a $25 knot K2 which are part two groups G1, and G2. We receive two simultaneous requests to withdraw $100 (W1, and W2) from G1 and G2 respectively. What happens?

The withdraw requests race, not for the group balances, but for the knots. Both will try to withdraw K1 and K2, but only one will win, and the other one will be rejected.

Groups do not have context

In a standard account system all the context, description, and metadata for money is stored at the account level. The balance is just a sum, so the number itself has no context, therefore you need to describe everything at the account level.

In String Theory, however, each knot has its own context. Instead of storing any information with the group, any changes made are pushed down to the individual knots. This allows for the knots to be correctly understood even when being viewed as an individual piece of money instead of as part of the group.

As an example let's say we have a $100 knot (K1) that is part of a payout group G1 for our seller John. The most common way to see K1 will be to be looking at G1, and that's certainly what we'll do to answer questions like "How much money do we owe John?". However, what if the treasury team is trying to understand how much USD is in the system? They aren't going to care about G1, they just want all USD knots in the system. Thanks to the context being stored at the knot they can safely view K1 in isolation and still have all the context of the group it belongs to.

This might seem like a contrived example, but particularly for larger companies it is very common for different teams to need to be able to understand the same money in different ways. Keeping the context with the knots makes it so can ask questions about money in the way that makes sense to you, without having to understand how every other team at your company thinks about it.

Side note: this is where a lot of churn happens in financial systems. No matter how you choose to model your accounts, it's always going to have one specific perspective which will be good for someone, and bad for everyone else. Every few years or so the people who it wasn't designed for will get really vocal about the pain, or you'll get a new CFO who knows "the right way" to do it and end up restructuring all your accounts, only to end up with the same amount of pain, but distributed differently.

Groups are optional

Knots can exist without being part of any group. Since the String Theory system tracks every piece of money individually there is no requirement for money to be part of a group at all. However, all knots in the system are required to have an owner, so that there is never money in the system that doesn't belong to anyone.