It doesn't have all the advantages of money, so it could work better as a supplement than as a replacement.
Inspired by Whuffie (right handed Whuffie, from Cory Doctorow's book Down and Out in the Magic Kingdom), the system should be non-zero sum and subjective.
Suppose the system has 3 people, A, B and C.
A does something for B. B assigns some credit to A for this, call it 20 credits. This is only in B's subjective account for A, so A has 20 B-credits but no C-credits, since C isn't involved. It's not a huge effort for A, but it was something, so A assigns B 3 A-debits. Part of the non-zero sum thing is that the two numbers can be different.
Now suppose B does something for A, and for this A assigns B 10 A-credits, and B assigns A 6 B-debits. We don't just subtract A's 6 B-debits from 20 B-credits leaving 14 B-credits, we keep track of both debits and credits: A has 6 B-debits and 20 B-credits. This is also part of the non-zero sum thing. Instead of subtracting, a ratio will sometimes be used. A has 20/6 or about 3.3 B-credits per B-debit.
Like LETSystems and Ripplepay, the system allows two people to enter a trade without requiring a minimum account balance first, that requirement is left up to the discretion of the two participants.
Like BitTorrent, the system is supposed to encourage tit for tat helping. Suppose B feels like doing some work or selling some item and wants to get something back in return. B can look at who has the most B-credits per B-debit. Say A and four others have B-credits per B-debit scores above 3, B can offer the item to any of the five if they want it, with a (very uncertain) expectation of getting over 3 B-credits worth of benefit per B-debit worth of effort. For a bit of safety, make sure they will still have a good B-credits per B-debit score after assigning them B-debits for the item, not just before. For example, A can have 0.66 more B-debits but not 0.67, while still having more than 3 B-credits per B-debit.
My system is intended to have a decay built in. We'll make it a half life of one month. So if a month ago A has 6 B-debits and 20 B-credits, now A has 3 B-debits and 10 B-credits.
Advantages of this:
Slightly risky trades can take place without permanently lowering A's score. Instead, after a few months, A can do something for B and the credit for that can outweigh the old credits and debits. In a regular money system, A would have been in debt and the interest would be increasing the size of the debt.
Recent behaviour may be a better predictor or future behaviour than long past behaviour is. While I am guessing this is true, there's no reason to expect the 1 month half life to be the best model. I will stick with it for now though.
The Whuffie credit system I am designing allows indirect transactions once there are chains of credit (A helped B who helped C) like with Ripplepay. In order for this to happen, debits will affect the decisions of people who aren't part of the transaction that caused the debit. To make this fair, debits require agreement between both parties, so for example, C gets a B debit only when B and C agree to that. Credits can still be recorded unilaterally, so B can decide that C gets a B-credit.
The calculations of credit to debit ratio (total, including direct and indirect interactions) from the directly assign credit and debit amounts got more technical. Wikipedia has a page maximum flow problem which I used when I was working out what I could do with flow networks.
I think I have found a reasonable algorithm to evaluate whether credit debit ratio is above some threshold (i.e., this will define a new indirect version of the credit to debit ratio)
Create a flow network with two subsets:
The credit network has a node for each agent, and the edge capacity will allow flow from X's node to Y's node equal to Y's X-credit, for any agents X and Y.
The debit network has another node for each agent, and the edge capacity will allow flow from Y's node to X's node equal to Y's X-debit, for any agent X and Y.
Convert credit and debit networks edge capacities into common units using the test ratio. For example if you want to see whether A has a B-credit to B-debit ratio of 3:1 or more, you can convert the edge capacities in the debit network by multiplying them by 3 credits/debit.
Add a one-way unlimited capacity edge from every agent's node in the credit network to the same agent's node in the debit network except for the agent evaluating the other one's credit/debit ratio. In the above example, every agent except B.
You can find the maximum flow from B's credit node to B's debit node, and think of this as B-credit that's been repaid by B at the test ratio. Call this amount R (for repaid).
If you can increase the flow by allowing flow from B's credit node to A's credit node, that means A has more indirect credit - A's credit to debit ratio is higher than the test ratio. Check this by seeing if the maximum flow from B's credit node to the combination of A's credit node and B's debit node is higher than R.
If you can increase the flow by allowing flow from A's debit node to B's debit node, that means A has more indirect debit - A's credit to debit ratio is lower than the test ratio. Check this by seeing if the maximum flow from the combination of B's credit node and A's debit node to B's debit node is higher than R.
This entry was originally posted at http://caspian-maclean.dreamwidth.org/57