Mutual currencies
Last updated
Last updated
A currency type that emerges in these ecosystems is "Mutual Currency". It is based on two agents within a community making a transaction based on trust, in which one of them leaves to owe the other an amount in exchange for a product or service. After that transaction, the accumulated balance in the account of the two is the same, for one it changes into negative, and for the other into positive. If we extrapolate it to an entire community, the total accumulated balance is always zero. The total money supply is directly proportional to the community's capacity to generate products and/or services, and also to the maximum amount of accumulated debt that all the agents are allowed to have. Every time a debt and a credit are generated in favor of the other party, the money supply increases, and when a debt is paid off then it contracts. The process of a transaction is simple. One agent sends a transaction request to another, and if the recipient approves it, the balance of each of them is updated directly. This type of monetary system with point-to-point transactions could be developed natively with agent-oriented systems, although certain mechanisms to be implemented must be taken into account to ensure confidence in loans. For example, when one agent receives a credit request from another, the latter can check the applicant's history and attributes. Each agent has his history and his balance saved and can make it available to the rest. In addition, applications can save attestations of each transaction in their decentralized storage (DHT), so that agents can confirm with a second source of information. It should be remembered that if an agent does not follow the rules of an application, his transactions are marked as invalid, and even, she can be blocked within that application. If we extrapolate it to communities with massive use cases, we find the following typologies and operating mechanisms that I will explain based on examples:
Here, all members offer products or services and also consume them, let's imagine a vacation property owners club. 100 members rent their 100 houses to each other. Each rental day is one unit of the supposed RNT currency. 50 houses are rented on the first day in such a way that the balance of 50 of them is +1, while that of the other 50 is -1. The maximum negative balance of each agent is -15 according to the rules of this community. If this happens for 15 days in a row we would reach the maximum level of RNTs money supply which would be 50*15=750. Now only those with the maximum negative balance can rent to others, so for each day of rent, the money supply is reduced until it tends to a maximum equilibrium point that is 50 or close to 50. In these cases, simple rules can be implemented such as that if a member with a negative balance does not offer his product/service for a while, he may be left without the possibility of requesting more credit or even be blocked. If an agent leaves the community with a negative balance, depending on the rules that have been established, it could happen that it would be necessary to make a readjustment of the balance of all the members of the community so that the total accumulated credit is zero. Another option could be to increase the number of community agents and for new members to assume that negative balance as a registration fee, this already depends on the governance mechanisms or set of rules that are defined in each case. This type of community usually has a strong KYC process, that is, there are some requirements that each agent has to meet to become a member, and that are reviewed by the community before accepting each agent.
We can think that the above case is not optimal because only 50 of the 100 houses are rented at the same time. If we give the option to rent to agents who are not owners, we could optimize this. But here, the mechanism changes. We need a type of agent in the first instance that can create and destroy coins, as well as reserve them. For the above case, this agent would create the 50 units that are missing initially. We are also going to need an exchange platform, where consumers can buy those 50 coins. This means that the supposed RNT obtains a market value in other types of assets. Depending on the capacity of the community to rent properties and the existing demand, depending on whether these parameters rise or fall, reserve agents will be able to create or destroy RNTs units. This means the RNT is backed by the community asset, in this case, a rental property, and its market value is stable in this sense. This is a very important feature of mutual currencies. Consumers are not allowed to have a negative balance. The only RNTs that can be sold on the exchange platform are those created by the reserve agents or those obtained by the products and/or services of the community, in this case, those obtained by the owners by renting. Once the 50 coins were created and purchased by 50 users, there would be 100 coins and all 100 houses could be rented on the same day. We could interpret now that the entire community is in debt to the reserve agents and the developers of the system, so it is possible to establish the payment of a commission on each transaction that would go to them. This is the mechanism that Holo uses in its DePIN network to support the infrastructure with an asset backed by the computing power of the entire network. The community is financed by the initial sale of coins, the variation of the same (both positive and negative), and the fees. This is an important incentive to keep the community functioning properly. We see this mechanism with an example flow so that it is better understood. Alice and Bob are owners and Carol is a consumer. We see each agent's information right after each event.
In this example, the total money supply of RNT is always 2, corresponding to the capacity of the community for renting properties. If we add commissions of 0.1 RNT to each transaction, it would look like this:
If the cycle continues the same way until the 9th day, and on the 10th it is Bob who rents his property instead of Alice, the balances would be as follows:
It is important to keep in mind that after 10 cycles, the results of each agent are as follows: - Alice. He has sold 8.1 RNT and bought 0.1 RNT. He has spent a day at Bob's property and has a positive balance of 0.9 RNT. - Bob. He has spent nine days at Alice's property with a bottom line of 0. - Carol. She has rented a property for 10 days for 10 RNTs. - The reserve agent and developers. Has sold 3 RNT and has a balance of -0.9.
With this simple example, it can be seen that all participants win in this ecosystem based on mutual agreements. This case serves to show the operation of Mutual Currencies, but DMASs allow the development of greater complexity. Frameworks such as Holochain allow for customized developments.
TAKEWAY: These decentralized mutual credit systems are good in cases where the value of the credits is small, or the community has enough members to absorb a debt default by an agent. It is necessary to analyze the risk that agents run before opting for such a design. That is why DIMCredits improves these systems providing insurance and mitigating risks in P2P transactions.
