Deterministic Attribution

This post makes several references to the blog post on the attribution problem. You don't need to have read it for this article to be useful, but it explains the problem in depth, and is used for contrast.

Deterministic attribution is the property of a ledger that guarantees any piece of money can be provably traced back to its origin. Only String Theory's ledger provides this level of attribution. Double entry ledgers have extremely poor attribution, while blockchain ledgers have deterministic attribution until a merge happens, but each merge creates ambiguity that can sometimes be resolved, but not always.

String Theory has many cool properties, but the two rules that enforce deterministic attribution are:

1. Every knot points directly to it's parent
2. Knots can never be merged together

Rule 1 means that every piece of money in the system knows about it previous state, all the way back to when it originally entered the system. This enforces that each knot in the system in part of a thread the connects it all the way to its origin.

Rule 2 is the one that avoids the attribution problem as you see it in double entry. Money is never summed together, the system always keeps of each of the individual parts. You can still effective merge money together and treat it as a single bucket, but behind the scenes String Theory will keep track of each individual piece that's part of that whole.

Diagram: Example of String Theory traceability

1. K1 is the initial deposit of $2,500
2. It is split into into exactly two parts that equal the whole: K2 and K3
3. K2 has a new tag applied, which creates a child K4
4. K3 is withdrawn from the system, leaving K5 as the record of the withdraw

Solving the attribution problem

The traceability is nice, but how does it solve the attribution problem? Let's revisit the example from the previous blog post the attribution problem.

Again we have three buckets In, Held, and Out. We'll make several deposits of liquid then move them into Held one cup of each, vodka, water, kool-aid, and lime juice. Finally, we'll pour a glass for each of our 2 customers.

We need to change up our analogy just a bit, since String Theory doesn't sum like double entry. So instead of pouring glasses of liquid into our bucket, we'll put the entire glass into the bucket, label and all.

Diagram: Liquid analogy, with deterministic attribution

The diagram shows that we can see exactly what was served to each customer. Since we still have each liquid in its own glass its trivial to tell what we're going to give each customer. In the case of customer 1 it didn't much matter what we served them. He might have preference to not get a glass of straight vodka or lime juice, but ultimately he can safely drink any combination of liquids from the bucket. Customer 2 on the other hand, could be be harmed by getting any liquid from the vodka glass. So we actively choose not to serve him from the vodka glass. This ability to actively choose what you withdraw is not possible in other ledgers.

Working with deterministic attribution

You mean I have to actively choose every time I change any money in my system? That sounds like a lot of work!

Not at all! You get to decide how much you care about how the money is chosen. String Theory lets you operate on money like its a bucket of liquid (like to double entry), actively choose money from a bucket, or even choose individual pieces of money directly.

In this section we'll cover some of the most common methods of withdrawing money and when to use them.

Passive choice ("I don't care")

Sometimes when moving money you legitimately don't care which money is chosen. In the earlier example this is true for the customer 1 withdraw. Any of the liquids in the bucket would be acceptable, as would any combination of them.

In cases like these you ask String Theory to withdraw an amount from a group or thread and it will happily give you what you asked for if its possible. However, individual pieces of money are still chosen and deterministically recorded. The system just makes the choice for you. This maintains the ability to trace money end-to-end through the system, even if you don't care about the details when you are moving it.

In the example above if we just asked for "1 cup of liquid" from the held bucket for customer 1 and it decided to give him Kool-aid.

Most money movement starts with not caring. You set up really simple, intuitive accounts, and then over time additional circumstances, regulations, or rules are added that make it more complex. Since String Theory supports both passive and active choice you can seamlessly switch patterns as your business processes evolve without having to re-architect your accounts or your system.

Active choice

Other times, you'll want to choose specific pieces of money. With customer 2 even though we know they should be served out of the Held bucket, it's super important that they don't get any vodka. In these cases you'll want to actively choose what is withdrawn.

Thanks to the uniquely-identifiable trait of String Theory, every piece of money can be individually targeted by a unique id. It also returns these ids whenever it provides a balance, so you can always know exactly parts make up the balance. From there you can choose to withdraw any combination of those pieces.

Let's use a more realistic business example to highlight why you might want to do this, and how to accomplish it.

The setup: You run a retail marketplace business (like Amazon) and you have a seller account (group) for one of your sellers, John. Each time we sell one of John's items we move money into John's seller group to await payout. In order to help avoid fraud, and reduce operating costs, we don't allow any money to be paid out to John until three days after the sale. This gives us time to hopefully get notified of fraud from the credit card company, and also allows us not to pay out for cancelled or returned orders.

John made the following sales over the last week:

• S1: $100 five days ago
• S2: $500 three days ago
• S3: $2,500 today
• S4: $7,500 today
• Balance: $10,600

Now we need to make a payout from John's account. However, the vast majority of money in John's account is not eligible for payout. Thus, the "I don't care" strategy isn't going to work well here. Our business rules are clear we need at least a 3 day wait. So instead of just saying "give me $600" we'll take a couple steps to make sure we get the right money.

1. Get the balance of John's seller group
2. Inspect the individual pieces (S1-S4)
3. Filter out any money that isn't at least 3 days old (remove S3 and S4)
4. Request to withdraw S1 and S2 for John's payout

Now we have successfully paid out John for his two sales earlier in the week, while correctly withholding the money for the newer sales. Best of all, we'll be able to trace the money all the way through our system from the money the customer paid in, to the specific payout made to John for those purchases.

The power of active choice

Active choice while moving money is a truly novel concept that no other ledger is capable of supporting. The combination of active choice and String Theory's ability to attach context to money provide an extremely powerful tool for targeting money in your system. This gives you a large degree of flexibility in how you move your money around.

Notice in the active choice example we didn't need a "pending payout" account, and a separate "ready for payout" account to implement our business rule. We could tell from the context of the money itself which pieces met our business rules. This is just one small example, but if you embrace the pattern you'll find it greatly simplifies your ledger.

Here are some of the benefits you should see if you are using context and active choice:

• You don't need that many accounts. Just the high level ones you use for understanding your money flow. The nuances of subdividing that money for different purposes can come from context.
• You don't need secondary ledgers tracking context. You don't need those secondary systems that try to map a small piece of context and match it to money in specific accounts. (e.g. you don't need a system keeping track of which payouts are more than 3 days old and ready to be sent.)
• You don't need to worry about predicting the future. You don't need to guess how your business will grow and what dimensions you might eventually want to classify your money by. You can create new accounts later based on the context of money even if you start with simple accounts.
• You don't need to care how the rest of your company views this money. Since each piece of money has its own context, and can be explicitly targeted, its fine if another team in your company wants to think about money in a different way than you current accounts are designed to support. You don't need to re-architect anything, or make any changes to support it. They just look at the context and filter the money in the way they want.

These properties greatly reduce development churn in financial systems. If you find new financial rules slow and expensive to implement at your company it's probably because your current ledgering doesn't have these attributes.