Mountain of Money Lab
Project status and research

MOM is a collective deposit used by participants for interest-free loans.
App status: under development.
Launch later in 2016.
Status

Roadmap

  • End of July 2016:
    • Meteor.js app fully functional
    • Interaction with bank API working smoothly
    • Establishment of NGO
  • August 2016: Live beta
  • November 2016: Launch

We have decided roughly on the protocol we want to try for the deposits (more in "Theory"), and we've finished two very rough implementations of the application. The app that we'll really use for the prototype is written in Meteor.js and will interact with a bank account through an API such as Figo.io. On the legal side of things, we are founding an NGO that will be responsible for maintaining the application. We've been talking to a bank, and as soon as their API is ready to go, we'll be launching a limited test version.

There's another version in the works as a Dapp (Decentralized Application) based on solidity contracts. Because of the instability of the exchange rate of Ether and of the Ethereum project itself, this is only experimental at present. But nonetheless, a first version of the Dapp, won the "prix technique" at the BlockFest hackathon in Paris, France (press in French: here and here.) Ethereum has a ways to come before we can make any serious use of this app, but the framework was invented precisely for applications like this one.

(The wealthy have been using Bitcoin to dodge taxes and speculate since the beginning. Ethereum has very interesting political and social uses, but we were staggered to see how many proposed uses of Ethereum were simply attempts to enforce intellectual property (one app for authorizing medications, another for authorizing university diplomas, another for wine, another for digital content!), or worse (an AirBNB for renting advertising space P2P, to aggrevate the supersaturation of everyday life with advertising.) Under these circumstances, it seems to us particularly important to keep developing social and even communist use cases on the basis of these new technologies, so that they are not entirely in the hands of capital.)

We will be working with a bank and euros for the main implementation of our project.

Theory

What we want to do

It's easy to see that people who have accumulated large amounts of capital get huge advantages, and people who don't have it are penalized and exploited.

Most people put their spare capital in a bank. The bank pays them a small interest rate in exchange for the use of accumulated capital in investment. So people get more of what they already had – small quanities of money, in the form of 1.4% interest rates – and they resign even more accumulated capital to banks and to investors who already had enormous amounts.

How much would members decide that each could borrow, and how long would they give themselves to pay it back? Many different variations are imaginable: large groups or small groups; friends or friends of friends or colleagues or even strangers; large, short-term loans, or smaller loans paid back more slowly. Not all variations will be useful. The question is how to invent the right form for a situation.

We hope our experiment will incite not only imitation but mutation. There are many different variations on the capital-pool model to try out. Our prototype is very straightforward and moderate. The amount borrowed isn't enormous—maximum ten times the deposit—and the length of time to return it to the pool neither too short or too long—between 15 and 30 months.

Implementation

The idea of pooling capital is very simple, but tricky to put into practice. The banking system, and the law itself, are organized entirely around individuals. But if we're determined enough, we might be able to find new and unexpected ways to use banks and existing laws to make this happen.

The collective should register as a non-profit. Non-profit organizations can give interest-free loans without any special license. That takes care of the legal difficulties.

The trickier question is about hierarchy in this organization: who will be in charge of keeping accounts, and of making wire transfers from the organization's bank account when they are needed? How much trust is required? Who would make emergency decisions, if there was an emergency? Even a non-profit organization needs, legally, to have an official president. Banks only work with collective entities through the intermediary of a representative, who must be trusted completely.

Banks seem to be open to new technologies and practices at present, so it is possible that a new model of interaction will become possible between banks and collectives. “Smart contracts” could be part of this story. Smart contracts are a way of thinking about a computer program as a constitution, or of thinking about laws as a computer program. They eliminate the need for a record keeper and accountant, as well as the need for an interpreter or judge. It's as if the laws themselves, the rules themselves, to which a group of people had agreed, could speak. Since smart contracts make unambiguous judgments about the internal affairs of an organization, they could provide a non-human intermediary between collectives and banks. And what's interesting here isn't that this intermediary (the smart contract) is non-human, but that it isn't an individual.

Banks would have to be willing to take these contracts into account. It isn't unimaginable that they will do so, that, in five or ten years, banks will have some kind of API for interaction with smart contracts. But at present, this isn't the case. Banks in Europe are just starting to offer APIs for interaction over common internet protocol, and common internet protocol is refractory to collective responsibility. You can write a web application that follows the rules you have in mind, but this application will always be easy to modify for whoever is in charge of administrating the server. Automated rules are an alternative to trusting a single individual – but if they are run on an ordinary web server, they require one to trust the administrator.

If projects like Ethereum really take root, then it would be possible to run automated rules without any administrator, in which case the smart contract could really live up to its promise. In that case, the question would be whether banks could be convinced to offer a standardized integration with Ethereum, and whether it would become standard enough that they would do so for cheap or for free (Fidor has been talking about the possibility of implementing the “banking core” as an Ethereum contract – which would be a dream solution for us, if tokens from their “banking core” contract could be bound into a communal use contract, or if the core contract could somehow delegate privileges initiating transfers to some other contract that the user signs.) Maybe banks will never trust a computer program to make wire transfers. But even if they continue to require confirmation from a representative of the organization, it would already be very helpful if they would take Ethereum into account as a check on the power of this representative, so that the representative would really be limited to acting on instructions from the organization's smart contract (and at most, failing to act on them).

This isn't complete speculation, and we'll take a lively interest in these developments as they unfold. But at present, non-profits need a board and a president, and banks require us to place a large degree of trust in these representatives.

We have no choice other than to run our prototype as a non-profit organization (with clear and rigorous bylaws). We'll automate the group's functioning as a web app, so that borrowing permissions will be determined automatically by the application, but we can't eliminate the server administrator or the organization president, whom the participants have to trust for now.

Theory

Protocol

Here's the protocol we've decided to put in place for the initial prototype. In our opinion, the whole model could be forked and experimented with for different uses, but we're going to give it a first try. The peculiarities of our implementation are the following:

  • Nobody participates anonymously, and all transactions are onto or from bank accounts held in the name of the participants.
  • New members can join, and they do not have to get the consent of all existing members to do so; only 5 existing members need to say yes to them.
  • There's a delay of six months between placing a deposit and borrowing more than one's deposit. (Of course one can withdraw the deposit at any time -- the time limit is just for borrowing.)
  • The amount that one can borrow is equal to ten times one's initial deposit.
  • There are no restrictions on whether large deposits can borrow from small deposits if there are no other large deposits to borrow from.
  • At least one "incubator" will participate at the beginning of the project, making sure that there's enough money in the account for things to run smoothly.

Members or users

Let's dispell a dangerous confusion. Nobody is a “user” of the mountain of money, in the sense that it would be a service. It is a collective project, where uses agree to certain rules of use and protocols for the distribution of money in their collective account.

We are creating a prototype of this project, and building a web interface for it. Although there are no “users” of the mountain of money, there are indeed “users” of the web interface. But nobody should get confused, and confuse a collective project with a service, and a member with a customer. In this document, we use the word “member” for participants in the mountain of money.

Conditions of borrowing

Simple version: a member who has deposited a sum of money, and has been invited by enough current members, can withdraw 10 times that amount after six months.

Incubators and maximum deposit size

If the borrowing factor is 10x, and we assume that deposits are all around the same size, the number of people who can borrow at once is 1/10. In reality, things are slightly more complicated because there will some deposits will be bigger than others. If someone has made a deposit that is so big that there is nobody else in their range, it could, in theory, take money out of the pool lower down. One solution would be to add an additional rule: that the deposits on which one borrows have to be at least 80% the size of one's own deposit. Larger deposits would not suffer much from being borrowed on by smaller amounts, but smaller deposits would be protected. This might be a good solution for similar experiments to ours, but it is not the one we have chosen this time.

We won't worry about deposit brackets, because incubators will solve this problem. Incubators are impact investors who put a large deposit in the account and renounce the right to borrow. Their money will be used in withdrawals whenever necessary. They will only be necessary at the beginning.

The other part of our solution are the constraints on loan size. The smallest deposit size we expect to see is around 100 euros, although we won't fix a hard minimum. And although we don't fix a limit on deposit size, we do fix a maximum of 15000 on loans. Members can deposit more than 1500, but they will only be able to borrow as if they had deposited 1500. Since the spread between 1000 and 15000 is only one order of magnitude, we don't have to worry as much about sparse higher brackets squashing lower brackets.

Repayment

The money borrowed will be paid back without any interest over a relatively short period of time. The payment plan is calculated in the following manner:

  • Payments are monthly
  • Full repayment must happen within 25 months
  • If possible, the payments should be less than 600€ per month
  • The minimum payment per month is 150€

The third condition, max payment per month, is less of a priority than the second, max length of time. And given the fourth condition, the minimum payment per month, many loans will be repaid in less than 25 months. When someone borrows, a repayment schedule will be calculated following this formula, and they will promise to pay at least that much per month.

If someone misses a monthly payment, they will be contacted by SMS and by email to be reminded to repay it. If, after five days, they have still not paid, they will receive a message asking them to give a sign of life and to explain what has happened. If they explain, they get more time (one more week before the same process begins again.) If they don't explain, or if this happens again a week later, then the “board of seniors” will have to figure out what to do about the problem.

Board of seniors

The board of seniors will be composed of the three biggest Incubators as well as of three randomly invited long-term members with no history of default, who are renewed whenever they choose to step down.

Registration and membership

At registration, members give their real name, their telephone number, their email address, their full home address, and a scan of their passport. They also pick a password, preferably a very long one.

When they make a first deposit, their name will be compared to the name on the bank account – if there is any discrepency, it will not be counted as valid. That means that it is important that members send money from their own account. Otherwise, we have very little means of verifying that people are who they claim to be.

If something goes wrong with the verification of the name, it will be reviewed by the board of seniors.

“Acquaintance” invitations are worth two points and “distance” invitations are worth one point. A member needs four points total, but at least one of the invitations should be a “distance” invitation. (This rule will be waived during the launch period.)

Existing members get to invite 20 friends a year, if aren't defaulting on anything. Existing members also get unlimited “stranger” invites, under the same condition.

Suspicous inviting

But there is another situation that we wish to avoid. It is the situation in which a very small group of members invite a large group of newcomers without verification from the rest of the project. They might invite people with bad intentions. We won't try to avoid this situation by imposing limits on invitations. Instead, a warning will be triggered when many members who have been invited by the same people around the same time try to borrow simultaneously.

Launch period

The launch period is the first year. During this period, some things will work differently than usual; for example, members have unlimited friend invites to give, and no “distance” invite is required.

Member profiles

Although it is of no particular interest for this document, members will be able to configure their profile pages, with a picture and a paragraph of text, if they wish to do so.

Privacy, transparency

The names of current members is not private, and will be visible to all logged-in members, whether or not they have made a deposit or completed the invitation process. It is important that people looking to join the project be able to see this information.

The history of deposits, withdrawals, repayments, and missed repayments will all be accessible as well, with names anonymized. The invitation tree is also accessible, and not anonymized. All of this information can be seen by any logged-in member.

Finding inviters

For new members who do not know anybody in the project, there are several weekly video chats on http://appear.in/mountainofmoney, to learn about the project and talk with existing members. It is likely that new members can find “stranger” invites in these video chats. Existing members have an interest in giving a hand here, and actually giving some time to the video chats, because it's better for the stability of everybody's money if the project grows.