Anything which alters its environment to increase production of itself is playing the game of increasing returns. – Kevin Kelly, Out of Control

I’ve been thinking for a while about introducing a currency into #PunkMoney, which would make it possible to account for value created between its users. Such a currency could, in theory, do a lot to help #PunkMoney scale, by encouraging participation through a positive feedback loop. After some weeks of thinking, I came up with a tentative solution which I’d like to develop here.

First of all, some groundwork. I’d like this currency to adhere to certain principles – explored elsewhere on this blog:

- It must be tied to a
*social gesture*

Like a +1 vote or a retweet, it will be created through a simple and effortless social gesture. In #PunkMoney terms, this is likely to be a *thanks* tweet created ad hoc, or in reply to a specific promise. [1]

- It must be
*asymmetric*, and therefore, abundance-based.

There should be no material cost associated with creating and awarding this currency to another user in the network. Its creation will not entail any further obligation or commitment from the issuer. [2]

- It must be
*karmic*

By ‘karmic’, I mean the principle of increasing returns. Receiving this currency will make it more likely that you will, in turn, receive value back from other users. In this way, the currency will enable effort, attention and resources to flow to the people according to *merit*, as determined by the network’s users.

- It must be
*un-gameable*

It should be impossible or impractical for any conspiring group to artificially award each other this currency, and divert the network’s value to themselves as a result.

- It must support
*gradients of value*

It should be possible to award the currency conveniently in different amounts to different users, based on the perceived value they have delivered.

It might seem like I have defined a wish list for something so perfect it could not exist. Certainly, if this problem were to be approached from a narrow monetary perspective, it would be completely intractable. There is no way money could be created by a user without an obligation or commitment backing it. I am however using ‘currency’ in a broader sense, to describe a trusted symbol in a network which acknowledges and shapes the flow of value through it. [3]

The approach I’ll develop uses some simple secondary school maths. It’s meant to outline the bare structure of a system which could work. No doubt a mathematician with a grasp of network theory could devise a more refined version of what follows. (If you are one, I’d be grateful for some feedback.)

*Thanks* as social gesture

As mentioned, the basic gesture which we will use to create this currency will be a #PunkMoney *thanks* tweet. The ‘thank you’ note can be created in two ways: by replying to a promise with

@someone thanks #punkmoney

or by creating a new tweet from scratch, for example

@someone thanks for the beer #punkmoney

This new functionality has already been added to the tracker, so this building block is already in place. In the proposal that follows, *thanks* basically stands for any gesture from X to Y which constitutes an acknowledgement of value created by Y. We can represent this as an edge between two nodes:

X -> Y

The approach will in fact be agnostic to the type of gesture used, as long as it means the same. All my examples will rely on the #PunkMoney thank you gesture as this is the context the currency is being defined for.

**Perspectivalism**

A naive approach would be to simply count the number of *thanks* a person received over a given time period, and represent this as a karma score. The basic problem with this is that it is trivial to game: just tweet someone a lot of *thanks *to inflate their score.

The solution is to take a perspectival approach. [4] According to this way of looking at things, no user in the network has an intrinsic score or balance which is the same to all other users. Instead, Y’s karma will look different depending on where you stand in relation to Y in the #PunkMoney network.

Let’s assume the following graph of A’s basic network. We arbitrarily normalise A’s karma to 100, representing the total amount of karma which will be shared out to users as A sends *thanks* to others.

In this *thanks* graph, we can calculate a perspectival karma score for every user from **A**‘s point of view, using some simple maths. Since **A** has sent two *thanks*, each of them is worth 50% of his starting balance of 100. As a result, **A** will see **B** and **C**‘s karma as 50 respectively (50% of 100.) Since **B** has thanked **D** and **E**, their karma will be equal to the product of the ratios (times 100) down the branch to either user. We also want karma to decay with distance, so that after a certain number of hops through a branch it fades out, rather than continues indefinitely. To achieve this, we can divide the ratio for each hop by its distance from the origin of the calculation, **A**.

In this case, D’s karma from A’s perspective can be calculated as follows,

**K _{A->D}** = (1 x K

_{A->B}) x (1/2 x K

_{B->D}) x 100

= (1 x 50%) x (1/2 x 50%) x 100

= **12.5**

E’s karma from A’s perspective:

**K _{A->E}** = (1 x KA->B) x (1/2 x KB->E)

= (1 x 50%) x (1/2 x 50%) x 100

= **12.5**

Finally, F will have a karma score equivalent to:

**K _{A->F }**= (1 x KA->B) x (1/2 x KB->F)

= (1 x 50%) x (1/2 x 100%) x 100

= **25**

The defence against gaming is the subjectivity of a perspectival score. The karma a user has depends on the person who is looking at them, and their relationship to them. If a group of conspirators decided to award each other a lot of karma, they would form a closed loop. No other users would be connected to them, and hence, each conspirator’s karma would appear as zero to the rest of the network.

A different gaming strategy would be to first try and earn some *thanks *from other users in the network, and then to start artificially inflating the karma supply to some co-conspirators. On closer inspection, though, this is impossible because the supply of karma cannot be inflated: the more *thanks* a user create, the less karma each one* *confers. A user who wants to game the system could never give away more karma than they have in fact earned. Another way to put this is that total karma received is always equal or greater than karma awarded [5]:

k_{in} <= k_{out}

**Karma**

At the beginning of the post, I defined one of the principles this currency must adhere to as that of *increasing returns*. Receiving karma should make it more likely (in a non-trivial sense) that other users will want to provide value to them. Perhaps this value provision will take the form of fulfilling specific requests, or sending them new promises for things they might need.

To achieve this, we need the value of a person’s *thanks *to be proportional to the amount of karma they have. We’ve established that from **A**‘s perspective, **F** is the user with the highest karma score (50.) If our currency is karmic, and deserves to be called karma, it must be the case that when **F** thanks someone, it’s worth more to their karma score than when **D** or **E** (with 25 each) do.

This definition presents some issues. First of all, karma is perspectival, rather than an intrinsic property of a user. So a statement such as “**F**‘s *thanks* is worth more than **E**‘s *thanks*” needs to be qualified accordingly. There is no objective sense in which **F**‘s and **E**‘s thanks are *worth *anything: it’s only from the point of view of users connected to either **F** or **E** that those gestures mean something. However, to make sense of this statement we need a neutral way of comparing the value of **F** and **E**‘s *thanks*. We can do this by assuming a neutral observer **O**, who is connected to both **F** and **E** in the same way.

Let’s add **O** to the graph in relation to **F**:

In this graph, the theoretical user **O** (he doesn’t actually need to exist to make this point) can be connected to both **F** and **E** in exactly the same way: via a single *thanks *from either **F** and **E**, to him. That is, from **A**‘s point of view, the only factor which could create a difference in **O**‘s karma would be **F** and **E**‘s relationship to **A**, not to **O**.

Clearly, **F**‘s *thanks* to **O** is worth more to **O** than **E**‘s, from the perspective of **A**. Assuming **F** thanked **O**, **O**‘s karma from **A**‘s perspective is calculated as follows:

**K _{A->O} **= (1 x K

_{A->C}) x (1/2 x K

_{C->F}) x (1/3 x K

_{F->O}) x 100

**= **(1 x** **50%) x (1/2 x 100%) x (1/3 x 100%) x 100

= **8.25**

In comparison, if **E** thanked **O** instead, his karma from **A**‘s perspective would be lower:

**K _{A->O} **= (1 x K

_{A->B)}x (1/2 x K

_{B->E}) x (1/3 x K

_{E->O}) x 100

**= **(1 x** **50%) x (1/2 x 50%) x (1/3 x 100%) x 100

= **4.12**

In other words, from the perspective of a neutral observer, it would be better to receive a *thanks* from **F**, in order to win favour with **A**, than it would **E**. This is significant because it establishes that this currency is karmic: due to **F**‘s better position than **E**, his thank you has more value. It’s more likely that **O** will want to help **F**, as a result of his relationship to **A**, all else being equal. Value flows according to merit.

**Weighted thanks**

The final constraint we defined for this currency was the ability to express gradients of value. I’d like to be able to send a *thanks *to person **A** for putting me up in their home for a night worth a hundred times the *thanks* I’ll send **B** for retweeting my blog post. This is also no problem given the definition outlined above.

In practical terms, instead of requiring a #PunkMoney user to send a hundred thank you tweets, we’ll allow them to add a number to the thank you note, for example:

“@someone thanks for putting me up +50 #punkmoney”

Now all we have to do is divide up the user’s karma proportionately. A single thanks will be worth 1/50th of this one. The total value will be equal to 100. Assuming two *thanks, *where one is worth 1/50th of the other, we simply adjust the ratios accordingly:

K_{A->C}** **= 50 x K_{A->B}

K_{A->B} + K_{A->C} = 100

50 x K_{A->B} + K_{A->B} = 100

**K _{A->B} **= 100/51 =

**1.96**

**K**= 100 – 1.96 =

_{A->C}**98.04**

Plugging these weighted ratios into the graph will allow us to take into account that A intended his *thanks* to B to be worth a great deal more, and to cause a greater impact on his karma score.

**Conclusions**

This defines the basic approach. As I mentioned before, it’s a bare structure which could probably be significantly improved upon, assuming its logic is sound. I’ve deliberately left out factors like time-decay, how to represent a user’s karma back to them, and the computational cost of calculating karma in a large, densely connected network. I’ll hopefully address those in a second post. In the meantime, I’d be grateful for feedback.

To summarise: the basic idea is to introduce a peer-to-peer accounting mechanism which is debt and commitment-free, but which helps to allocate value in a network efficiently, according to merit. If it worked, it might reasonably replace money in some situations. Karma would not have the full force of a monetary claim: having it only makes it more likely that a value will flow back to a user through incentives, but won’t guarantee it. Still, if it works the implications are good enough for #PunkMoney.

**Notes**

[1] See Splitting the Social Currency Atom for my take on social currencies, and a potential ambiguity in the way the term is used.

[2] The term asymmetric accounting was coined by Gregory Rader, to describe “systems that record and track the provision of value rather than the volume of money transacted.”

[3] See A Broader Definition of Currency for a discussion on expanding the concept of currency beyond money.

[4] First explored in a A Perspectival Trust Metric for Ripple. Thanks to Jordan Greenhall for pointing me in this direction.

[5] This is similar to the approach taken by PieTrust for resisting “reputation inflation.”

Well, I’m still wading through this, but my initial impression is that you may have outdone Ripple with this. Which is about the highest compliment I know how to pay.

If Karma is portioned out amongst all my network, I would want more control than just adding one point at a time. I would want to re-apportion it.

Your point is partly addressed by the fact that I can weight a ‘thanks’ gesture however I want. I didn’t mention time but if you were to factor this in it would be an additional level of control, as thank you’s would only have force for a certain period.

solid stuff Eli

Great stuff!

A comment on dividing the karma score by the distance from the origin; this is fine as long as the sum of the scores over subsets of nodes doesn’t matter, but if it does (and it does if this is being used as i think you are suggesting, because a group’s ability to call in favors would increase linearly with the sum of their karma), then dividing the karma score by the distance of the origin would allow a colluding group (or one user with multiple pseudonyms, same thing) to accumulate an arbitrarily large proportion of the total karma.

Proof: imagine one “bad” user who makes a zillion pseudonyms and then gives 100% of their thanks to their own pseudonyms; and then each pseudonym gives 100% of its thanks to other of the same users’ pseudonyms, etc. If the bad user were k hops from the root, then let BAD := the amount of karma they were given, and the total karma amassed by all of the pseudonyms would be BAD*(1/(k+1) + 1/(k+2) + 1/(k+3) + …) . But that is the tail end of a harmonic series, which diverges. So the bad user and hir pseudonyms could accumulate, in sum, as much karma as they want.

If the karma decreases geometrically, rather than arithmetically, with hops, then you’re safe. E.g. you could say that the maximal karmic boost that any node can provide its recipients is 1/2 of its own karma; in which case the maximum that a node n hops from the root could get is 1/(2^(n-1)) of the total (and the maximum amount that it and all of its descendants can get via collusion is twice that).

Also, what happens with cycles? Our approach at PieTrust is to allow cycles and to think in terms of an iterative algorithm rather than an algorithm that visits each node only once. In this case, what we do is to decrease karma each time it travels over a hop, rather than assigning a fixed factor to each node based on distance from the root.

If you know that there are no pseudonyms in your user population, then you can take a different approach involving disallowing cycles.

Also, for readers who followed the link in the blog post to http://www.pietrust.com but wanted more detail, it’s here: http://devwiki.pietrust.com/FunSpec and here: http://devwiki.pietrust.com/IteratedGiving (pages with more details are linked from those).