What is a mutual credit currency?

Learning Library FAQs
#24

Any consideration of limits depends entirely on the application, and what it needs to be viable - why limits? to generate what? guard against what? why is that a concern? what is the actual risk? to whom? are there other (better) remedies?

With clear analysis that examines particularly the presumption / perception of the inevitabilty of free riders and how they will cause falling skies there’s generally not an issue.

But who would believe a bicycle easy to ride if they had never seen one before? - clearly unstable, just look at it.

All of this and more can be explored at LETSplay the game with additional materials and guides.

In our co-vestment model however, designed to introduce a $:cc convertibility (for entry, not exit) there is a restricted set of issuers, so a zero credit limit on all other user accounts.

Other than that special case I’ve not yet seen reason for limits in any system I’ve used, nor indeed in many that do have them and I think suffer accordingly. However, looking forward to networks like, say, player trades in professional sports or large scale land deals, the currencies of record will likely require more substantial and effective governance than simple limits, perhaps that every transaction in that net requires sign-off by all.

On “logical validators” our openmoney specifications/ (search “journal entry” and thank John Waters) seem to match yours and be likewise holo compatible.

5 Likes
#25

@bhaugen what measures are being taken to enforce the agreed-upon credit limits?

#26

I don’t know if the current Holochain mutual credit experiments have credit limits or not, and @mwl , who knows a lot more about mutual credit than I do, doesn’t believe in them. All of the existing mutual credit systems that I know about use centralized software, so the server enforces the credit limits. But if a Holochain mutual credit network wanted to have credit limits, they would need to be enforced in the transaction validation, I think as one more agent (a group agent) involved in the validations.

But regardless of how implemented, the transaction validation would need to consult the credit limits.

Does that make sense to everybody else?

#27

Yup, I understand what you’re saying. And one thing to keep in mind is that the credit limit might want to be changed over time. So I’m picturing (from the implementation POV) a credit limit entry that gets written to the DHT and has an expiry date. For a transaction to be valid, the spender’s new balance must be within the credit limit specified by the credit limit entry whose applicable date range encompasses the transaction’s timestamp.

(As for the governance of changing the credit limit, Holochain’s multiple-perspectivism isn’t as much of a barrier as you would think. You could designate a benevolent dictator to write the credit limit updates, or have an update require a quorum of authorised signers, or what-have-you.)

2 Likes
#28

Great discussion.
I’d be interested to know, how many here in this forum actually use an mutual credit exchange?
There are a few around, with varying levels of success.

I have experience with the CES software in Australia www.communityexchange.net.au

#29

I’ll go with Ryan - that Ripple isn’t mutual credit.

Ryan Fugger specifically uses the term “mutual credit” to describe Ripple though, here on page 3 in his second whitepaper from 2004,

There’s no reason why many mutual credit networks in different denominations couldn’t operatesimulaneously on the same servers.

and page 7 on his 2003 whitepaper,

If two people wanted to set up mutual credit, but didn't want it used to relay others' transactions in “regular” currency, then they must use their own private currency, so their connection doesn't appear on the graph of regular currency connections.

I always interpreted mutual credit as that the balance is positive on the account receiving IOU, and negative on account issuing IOU. This is the definition often given, credit recorded in mutual balance changes.

Ripple is the evolution of your LETS, built on shoulders of giants :slight_smile: Incredible invention. I see it as one of the most important inventions of this century. It is a bit strange that there isn’t any true implementation of it yet though. Since it can operate with just simple peer-to-peer messaging.

1 Like
#30

Thanks for these references to Ryan’s papers Joan.

Paul wrote "Interesting thing about Ripple: neither @mwl nor Ryan Fugger describe it as mutual credit, but the Trustlines documentation does (Trustlines is basically Ripple on Ethereum). Could create a lot of controversy if we wanted to talk about the distinctions; am I right, Michael? "

Sorry - Paul’s comments rang true, so I confirmed them. But I now recall (quite vaguely) that when Ryan showed me the first version I asked (quite firmly) that he take my name off it.

IOU means I Owe You - in which frame A’s transfer to B is NOT considered payment and a debt still exists. Which is NOT money as I know it - it’s just another form of debt-factoring.

And I consider that LETSystems (and other such form of mutual commitment) are money, issued by users. No debt happens.

The problem is compounded when the interests of those in “credit” are presented as entitlement to be paid, and applicable (in theory) to any on the negative side of the ledger.

For me that breaks autonomy, accountability, choice, contribution, pattern, purpose, ethics and adds in reification of risk and accelerates extraction. Ryan’s idea seems to me about getting what he wants out of community, not about supporting it.

On “true implementations” of an “incredible invention” I think in the word “incredible” shows much of the problem. Ryan didn’t (and likely still doesn’t, nor cares to) really understand what LETSystems are about, how they work and why. So he fixed what for him was a problem. That’s ok in general principle of course but in particular practice it can be less so, and here I see Ripple as degenerative rather than evolutionary.

But I do agree Joan that all sorts of useful things can be done by simple peer-to-peer messaging.

Money is a patterning technology. Now, do we want our money entropic or syntropic? https://psychology.wikia.org/wiki/Syntropy

1 Like
#31

“Joan Dark” was just a username based on a video game I used in that chat channel where you said the same thing a year or two ago, "That literally sucks. Ripple doesn’t evolve from mutual credit, it simply departs from it. So there’s irony in Ryan’s attribution, no doubt unintended. " Actual name Johan. I like multi-hop mutual credit a lot. I was cc:ed in this chat because I work on a proof-of-unique-human system. The topic was how to prevent fake accounts in a mutual credit system, a problem that was solved 15 years ago by Ryan Fugger.

Isn’t your money system idea also using a design where “the total amount of credits in existence is always technically 0”?

"An example of how the issuance of your own currency would work could play out like this; every member starts with a 0 balance. By placing a transaction within the system, one account will always go up and the other down by the same amount. So if Bob builds me a shed and charges me 50 “LETS Credits” his account will go up by 50 and mine down by 50. This does of course mean that inflation within the system is non-existent, as the total amount of credits in existence is always technically 0 due to the negative balances. It also means that negative balances are a necessary part of the system and can’t be viewed as “bad”. " (source)

#32

Syntropic!

#33

@pauldaoust have you heard of bright id? apparently they are working on anonymous proof of personhood…

1 Like
#34

Some social graph analysis systems have a notion of seeds , which are people who serve as centers of trust. Seeds are used by the system to differentiate between
honest regions of the graph and sybil regions created by attackers to resemble
honest regions.
Selecting seeds is especially important during the rapid growth phase of the network
when subgraphs of users may arise that are not well-connected to the main graph.

BrightID Main DAO will promote the research of different seed selection methods and
also the creation of tools that make seed selection scalable. Some principles to
consider when creating a seed selection process are outlined below.

All too fishy… Just as corrupt as the SSL certificate-authority infrastructure of the present day… Truth being told, the very central problem of personhood verification has no solution! It’s a chase in vain!

Ryan’s Ripple is the only thing that comes anywhere close; either all ‘users’ in a region/colony are bots or they’re all humans; why the hell should the protocol care!

#35

Don’t know if I have, but their branding looks familiar. Looks interesting; I’ll look into it!

I like this conclusion :slight_smile:

That said, I think all forms of squishy human trust involve some concession to a little bit of centralisation. So maybe the question is, can we embed disciplines into our shared norms that allow us to reach the ‘just right’ level of centralisation and go no further? What does ‘just right’ even look like? I do believe it’s possible to make this inquiry fruitful, but I don’t think it will be easy.

I appreciate this too. There are some things I really like about Ripple. I guess what concerns me is not being able to see beyond my circle of friends to see what kind of company friends-of-friends-of-friends are keeping. Maybe they’re more lax about connecting with bots; how do I even know? I also appreciate @matslats’ observation that it tends to atomise the players in the system, preventing them from coordinating on the greater good.

1 Like
#36

I’m getting myself understand more about mutual credit.

It seems the hard part is how to identify a person/stuff that can own such a credit, and lend the credits to others.

This means a onchain (not blockchain) identify system is a necessary, to make this identify system resilient and fair enough, actually we can make a life simulation,

  • each account/agent need two parent accounts;
  • parent accounts can funding/lending credits to child accounts;
  • child accounts needs to solve puzzles from parents account to get further credits;
  • child accounts get no more credits after a period of time;
  • to get more, the child account needs “work”, like how many transactions it makes, how frequent it interact with other systems;
  • the accounts has hard cap on the credits, if an account holds more that the maximum credit, the extra will distribute to the system;
  • an account could mark as deal after no activities, and transfer its credits to its children and system treasury based on the distribution rule.

Let me know if this is interesting to you.

1 Like
#37

Welcome to the forum @kaichao and it makes me happy that your first engagement with us is talking about mutual credit systems – one of my personal favourite subjects :slight_smile:

The thing that determines how to identify a person who can create credit for themselves is, what works best for the community? Some systems, like LETS, let everybody spend as much as they like (that is, create as much credit as they like), and let the seller make the decision of whether to honour that credit. Other systems put credit limits on accounts, even giving different limits per account class. For example, HoloFuel will give anonymous users 0 credits, but HoloPort owners (who both have a known identity and a known ability to create value) will be able to create/spend credit based on their earnings history.

One of the keys of a mutual credit system is that your credit should be based on your ability to give value back to the marketplace. Your scenario brings up some interesting questions – when parent accounts can give their own credit to child accounts, what does that mean? I think it would mean that the parent is telling the network “Even though <child x>\ has no standing in the system yet, I can vouch that they will provide value to the economy equal to the credit I’m giving them – and if they don’t, I will take responsibility to do the same.”

One thing I like about your experiment is that it doesn’t actually require anybody to reveal their real-world identity: as each parent takes on responsibility for child accounts, they make themselves liable for their children’s (and children’s children’s) economic activities. That’s what removes the incentive to create fake agents or let unreliable people into the system.

There are concerns – for instance, if designed poorly it could create situations of debt bondage. One way of tackling this is to have children pay the parent back as they build up their own credit limit; then the child is not owned by the parent and the parent is not responsible for the child anymore.

This actually brings up an objection my dad made about mutual credit. He works with mentally and physically handicapped people, and his question was, “what about the people who can’t provide any economic value to the system?” I see your scenario as a good way to do this – basically a ‘parent’ (caregiver) promises to be a patron of a ‘child’. Maybe the whole network of economic actors even joins in to each support those people a little bit.

Here’s some more information on how mutual credit fits into the world history of money and debt. My research wasn’t rigorous or perfect, but I think it’s still a useful introduction to how mutual credit works: https://hackernoon.com/a-cryptocurrency-as-old-as-civilisation-mutual-credit-part-i-sh1y3xn2

3 Likes
#38

I have never seen any actual game theory solution in the “Bright ID” project. They started their “verification sessions” concept a month after I launched a first test net for Online Pseudonym Parties, I think. This might be me being biased, but I was sharing the test net directly to their founder, exchanging messages in a chat group about it, and I then saw “our social graph is now for some reason doing random verification sessions!”. But, they do have a following. Either because they are onto something or because people are so deep into double-thinking at this point that they feel comfortable following nonsense. What do I know.

I agree on Ryan’s solution. But I also think Online Pseuedonym Parties might solve the thing, at the largest scale, the exact opposite of Ryan’s trust lines. But it has in common with it that the unit of trust is two people. I prefer Ryan’s solution though, I’m more for grassroots organization I just happened to end up working on two systems.

#39

It does not matter for the credit network though. You would only ever have your own credit cleared if you yourself actually produced value in a way that ended up, via a chain of people, impacting the person you had an IOU to. Same in the other direction.

#40

A resilient and fair identity solution to mutual credit was invented in 2003 by Ryan Fugger. It adds “multi-hop” to the mutual credit system. Ideal identity mechanism. His original whitepaper, http://library.uniteddiversity.coop/Money_and_Economics/decentralizedcurrency.pdf. @The-A-Man also likes Ryan’s mechanism (besides myself, I mean. )

1 Like
#41

forgive the noob question… what stops an adversary from going deep in debt and then creating a new account and starting from scratch?

KYC for every participant with every party? who handles and audits that process?
how long does it take?

and each person has a credit score?

who regulates the intermediary banks?

#42

I don’t think this was a reply to my comment but I got an email saying so. But, with multi-hop mutual credit, the answer to your question is that there is nothing to gain. Without multi-hop and just traditional so-called mutual credit (that is actually mostly just like a bank system but with a different story, and this different story is actually important because it led to the multi-hop solution), there needs to be central identity control yes, which is what is actually used already in bank systems. Also in multi-hop approach, each person is an intermediary bank, regulated by their peers who are also intermediary banks.

#43

yes it was a reply, and thank you for the response :slight_smile:

where could I find more information about ‘multi-hop’?

is Ripple centralized, pseudo-centralized, or decentralized?

I would like to make sure that I have all the accurate information. I’m just a bit confused and don’t want to explain the wrong thing to others.
Any links outside of the whitepaper that you think are helpful would be great.

Cheers!