Digital Money: A Different Approach

In the previous article, I discussed why I think the current approach to cryptocurrencies is deficient. My statement was that the choice of technology dictated many of the system’s properties. Blockchain undeniably was a breakthrough that allowed us to address the problem of double-spending in a distributed system, but it has also shaped the way we think about cryptocurrencies. Now that we have a mighty hammer like this, all digital currencies’ problems look like nails. But what if ledger-type accounting is not what we need to create a functional digital currency?

What could be an alternative? Last time I stated that every type of money is based on trust, but it’s even more than that. As Pierre Bourdieu pointed out, it’s quite possible to turn honor into money, but it’s almost impossible to convert money into honor. David Graber presented an interesting glimpse into this mentality in his book “Debt: The First 5000 Years”. He comments on the biography of William Stout, who lived in 18th-century Great Britain:

“In this world, trust was everything. Most money literally was trust, since most credit arrangements were handshake deals. When people used the word “credit,” they referred above all to a reputation for honesty and integrity; and a man or woman’s honor, virtue, and respectability, but also, reputation for generosity, decency, and good-natured sociability, were at least as important considerations when deciding whether to make a loan as were assessments of net income. As a result, financial terms became indistinguishable from moral ones. One could speak of others as “worthies,” as “a woman of high estimation” or “a man of no account,” and equally of “giving credit” to someone’s words when one believes what they say (“credit” is from the same root as “creed” or “credibility”), or of “extending credit” to them, when one takes them at their word that they will pay one back.”

So trust can be converted into money in the form of debt. With that approach, money exchange can be viewed as a problem of exchanging trust. But there is no way to do this reliably. I don’t know about you, but I cannot imagine any technical trick that would convince me to trust someone I otherwise wouldn’t. Trust cannot be created like that. That is what makes it precious.

Are there any exceptions to this rule? Well, yes, to some extent. If a friend vouches for someone, I could give that person the benefit of the doubt (in the Polish language, we have a different idiom that can be translated into “credit of trust”), but this would probably be limited in scope. And if that person asked me to trust someone else, it probably wouldn’t work. So, trust can be partially extended, but its strength diminishes quickly.

If a friend asked me to lend money to someone else, would I? Possibly, but in that case I would say “ok, but you will be the one who owes me instead”. This often happens in casual situations, like a loose group of friends settling a restaurant bill. There are even apps to help with this, like Splitwise.

Can we somehow turn this into a large-scale system that would work across the whole population?

The idea

Typically, when we talk about “sending money”, we think about the transfer of tokens. It can be a physical transfer (e.g. sending $100 in a letter) or a digital one (e.g. an online bank transfer). Either way, the owner of the tokens changes.

The system we will discuss is different as “sending money” through it does not involve any real funds transfers. Instead of money, we send the promise of payment; the whole system is based on the exchange of such notes.

If I want to “send money” to someone who I trust and who trusts me, I can create a certificate of debt (IOU — I owe you) saying who I owe and how much. Then, I sign it with an electronic signature and send it to the recipient. If the amount does not exceed the receiver’s debt limit, he accepts the IOU and saves it. That’s all.

A more problematic situation arises when I want to send money to a stranger.

To do that, we need a graph of trust relationships between people, similar to a typical social graph. You might have heard about the six degrees of separation — the idea that all people are at most six social connections away from each other. In social graphs like Facebook or Twitter, this number proved to be closer to four. Hopefully, in our system, this chain also won’t be too long. To build this graph, every client needs to define who they trust and to what extent (expressed as the amount of money they are willing to lend). This would give us a directed graph with weights in which clients are nodes and debt limits are weights.

We can now use this graph to find a chain of people that trust each other, thus connecting us to the recipient. I will be referring to this chain of trust as a connection chain. Money needs to go through every client inside a connection chain, from the sender to the receiver. But remember that money in our system is just a promise of payment. So, the first client in the chain needs to issue such a promise to the next one. The following client verifies that this debt does not exceed its debt limit. If everything is ok, it acknowledges the IOU and proceeds to create its own IOU for the next client in the chain. The process continues until the last client in the chain (the receiver) is reached.

Let’s look at some examples to make it clear.

We have directed graphs with three nodes (clients) and four edges.

The amount above/below the arrows denotes the maximum debt that the clients will accept, e.g. client A can issue an IOU to client B for no more than $50. Client B will reject amounts larger than this.

Scenario 1: A wants to ‘send’ $70 to C.

Client A starts by creating an IOU for client B for $70, but client B is not willing to accept debt from client A that is more than $50. Therefore, client B rejects this IOU and the transaction cannot be completed.

Scenario 2: C wants to ‘send’ $70 to A.

Client C starts by creating an IOU for client B for $70. This is under the allowed debt limit ($200), so client B happily accepts it. Now client B issues an IOU to client A, also for $70. Since it’s under the limit ($100), it is accepted. The transaction is successful.

Scenario 3: C wants to ‘send’ $50 to A, but B already owes $60 to A.

Client C starts by creating an IOU for client B for $50. This is under the allowed debt limit ($200), so client B happily accepts it. Now client B issues an IOU to client A, also for $50. Client A verifies it and discovers that client B already owes it $60; so, together with the new $50 IOU, it would exceed the $100 limit. Therefore, client A rejects this IOU and the transaction fails.

As you can see, the sender issues only one IOU, and the recipient receives only one. All the clients between the sender and the recipient both issue and receive IOUs for the same amount of money, so their balance does not change. Although this system does not involve a global ledger, all transfers in a single transaction should happen atomically. If this were not the case, we would create the risk that some clients have already signed and sent an IOU but have not received anything in return. How could we make such a transfer atomic?

The simplest method would be to store a description of all the IOUs in a single file. All clients should sign this file if they agree to accept the IOUs, and the sender signs last. This guarantees that the sender knows whether the transaction completed successfully and won’t double-spend by starting the transaction again. At this point, the sender can still cancel the transaction by not sending the signed file to the other clients.

Otherwise, if any other client receives the signed file, the IOUs will eventually propagate to the rest. This will happen because lenders need to show these IOUs to borrowers to claim what is due. When a borrower receives this file from a lender, it’s in his interest to pass it on to his own debtors. Because every client in the chain (except the sender and the receiver) is both a lender and a borrower, the signed file will eventually reach the receiver.

If that sounds complicated, imagine that the aforementioned file is just a letter saying in plain English how much everyone owes to whom. This letter circulates between all participants until all of them have signed it. The borrower then receives it and signs it last. Then, he creates a photocopy of the letter and sends it back to all other participants (or just to some chosen ones who should forward it further). All we need the technology for is to do this in a matter of seconds instead of weeks.

But this method has a severe flaw. Although delayed disclosure of IOUs cannot negatively impact the balance of any client except the sender, it can lead to violations of debt limits. To avoid this issue, we would need to guarantee that all clients receive the signed IOUs simultaneously. However, fair multi-party contract signing is not a trivial problem, so I will discuss possible solutions in a separate article.

Practical examples

If you are wondering if such a system could work in practice, look at hawala (Arabic: حِوالة‎ ḥawāla, meaning transfer or, sometimes, trust). It is based on a similar principle and has been working successfully for the last twelve centuries. It uses a network of hawala brokers to facilitate “money transfers without money movement”, as its definition says.

If you need to send money across the world, you can give it to your local broker, and someone else can obtain it from a different broker elsewhere. Brokers trust each other due to the history of the business they are doing together or some personal connections they have. There is no immediate cash exchange between them. At some point, debt can be settled in cash, property, or services.

In our system, every client works like a broker. Thanks to technology, we can utilize a much bigger trust network that is effectively not limited in size. Records of all transactions are kept automatically, so no tedious manual labor is required. Money that we are owed may be used to pay other people. Unless one has an urgent need to collect the cash, a debt can circulate indefinitely.

Scalability and performance

What about the scalability and performance of such a system?

Because it does not use a global ledger, the amount of involved parties is much smaller. A connection chain created by a few people is all that is needed to process the transaction. Separate transactions are processed in total isolation, so an increased number of transactions does not negatively affect system scalability. On the contrary, the bigger the trust network, the more the transactions that could be processed simultaneously.

Lack of a global ledger also means less wasted resources. Every client stores only information about the transactions it is participating in.

How much resources would be needed to store all data?

Let’s assume that every client in the network does two transactions per day, and the average length of the chain is as high as five connections. If the single file containing the IOUs that represents a transaction takes around 10 KB of data, then the amount of data stored in a year is approximately 40 MB per client. A lifetime history of transactions could easily fit on an average smartphone or memory card.

Storage requirements wouldn’t change, even if every single person in the world were using this system. Now, compare this with BitCoin, which currently needs 319 GB to store the blockchain. With increased usage, that number will grow significantly.

What about storing the trust graph? Assuming ten connections per client and a 128-bit client ID, that gives us 160 megabytes per million users. That is almost 1.3 terabytes for the entire population of the world. Initially, it could be stored locally without any dedicated disk memory, but this wouldn’t work in the case of worldwide adoption.

However, this is not a big problem because the trust graph is public and is the same for every client. Dedicated external services could easily store it and facilitate finding connection chains for a small fee. For everyday operations, a client could cache common connection chains, so finding a new one would not be needed very often.

Such an external finder service wouldn’t create security issues because every client needs to validate a connection chain before using it. Clients would simply deny a faulty proposition. Thus, the only concern with third-party services would be privacy. That said, with most cryptocurrencies the register of transactions is public and visible to anyone. In the case of our system, only the clients (and possibly one third-party service) know about the transaction’s existence. Details of the transaction are known only to participating clients and are never stored globally.

So, even considering the potential privacy problems with third-party services, we are improving the state of things significantly.

Basket of goods

How do we express how much money one has or is due? Our system is not token based: we do not have a unit of account like the dollar or BitCoin. We need to use an existing way of measuring the value. This could be either an existing currency or a basket of goods of our choice.

An obvious drawback of choosing an existing currency is that we lose some control over the system. For example, if we decide to use the dollar, its fluctuating value affects the amount one needs to pay back after some time. This makes us heavily dependent on external institutions and their monetary policies.

Alternatively, we could use a selected basket of goods. We could create a new unit of account and tie it to the value of some chosen commodities, such as various industrial metals. For ease of writing, I will refer to this abstract unit of account as BAG (from Basket Of Goods). Sadly, using BAG would not be natural or practical for anyone, at least initially. Also, choosing a BAG wisely would not be easy. It should cover a market area that is big enough to not be easily manipulated, but ideally its value should also be easy to check. Furthermore, its price volatility should be relatively low compared to other commonly used products.

To keep the whole system user friendly without compromising its principles, we could mix both approaches. Under the hood, all IOUs would be based on BAG. However, when showing account balances or the prices of goods, client applications could automatically convert them to the local currency. Depending on the user’s preferences, the system could display the value in BAG, local currency, or both. When accepting a new debt (or “paying” for the product), the local currency’s value at that moment is used to calculate the amount of debt expressed using BAG. Internally, all transactions use BAG as a unit of account.

This makes the system partially dependent on the exchange rates between BAG and local currencies, which need to be imported from external sources by the client application. However, this does not threaten the system’s integrity or independence as, on the system level, all IOUs are issued using BAG. Users are free to choose the client applications they trust regarding the presented exchange rates. They can also verify the exchange rate during every transaction or switch to using BAG directly.

The obvious benefit of this solution is independence from national currencies. No third-party actor can inflate or deflate a currency, and obligations will hold their value. It also makes international trading easy, as all clients use one unified currency.

One more thing worth noting is that national currencies rarely hold their value. That means the client balance can change over time when expressed in the national currency. Today’s commitment to $100 could be, for example, $105 in the future. This is because it’s internally calculated using BAG, not national currencies. From the user perspective, this would be similar to using a foreign currency account denominated in BAG.

Free banking

What if someone doesn’t want to rely on personal trust relations or does not have anyone who trusts them? This scenario would create a natural space for all kinds of financial institutions that could be part of the network and work as proxies for their clients.

Wouldn’t this allow these institutions to create new money in the form of debt? To some extent, yes, but any other person would have the same right. If people trust a bank, they do not ask to be repaid immediately, which allows the bank to profit from its debts. However, this works only as long as a bank’s finances are sound and people trust it. Trust can be almost directly converted into money, which is a huge incentive not to violate it. If someone does, it’s in the best interest of competitors to expose it.

The existence of highly trusted entities would also reduce transaction costs. Due to the vast number of relations they have, the network’s average connection length would decrease. Between two clients that are big institutions, it could often be as short as three.

Still, people who don’t want to use banks or other external institutions wouldn’t be forced to do so; everyone would have an equal right to create new money (new debt) proportional to the amount of trust they have.

Safety & fraud prevention

I think that this system would be safer than most other cryptocurrencies.

To undo a fraudulent transaction, the coordination of just a few people is needed. If everyone in the connection chain (except the offender) agrees to cancel the transaction, they can create a new transaction that transfers the money back to the original owner. In that case, the offender still holds the IOU of one of the clients that promised the payout. But if that IOU was obtained dishonestly, it will be practically impossible to enforce. This would be even more true if the attacker was not a real trusted client but had been fraudulently added to the network.

Of course, this mechanism requires human interaction. There are no automatic transaction rollbacks or suspension of accounts: they are based on consensus and negotiations. This means it might not be trivial to roll back transactions in practice, but I think that’s a good thing. If consensus cannot be reached, the transaction should remain valid.

What if the IOU is valid but someone doesn’t want to pay? There are various ways of dealing with this problem: from personal and social pressure to legal proceedings. Remember that IOUs are issued only between trusted parties that most likely know each other and live in the same jurisdiction. This is a far better situation than having a problem with a stranger on the other side of the world. As a society, we have developed various laws to help us to deal with situations like this. There is no reason to drop all this legacy just because we are dealing with cryptocurrencies.

One could say that this system has two ‘modes of operation’. The first is fully digital and automatic. It works as long as everyone agrees IOUs are valid; however, if something goes wrong, the system enters ‘real-world’ mode. In this mode, enforcing claims requires external means like social connections or judicial and executive powers. This provides an additional layer of accountability and control over the technical layer.

Charges and interest rates

What about transaction costs? It would probably make sense to introduce small transaction fees to prevent wasteful usage of the system. Every operation requires cooperation between a few clients, and this should be paid for. But since the disk space and computational power requirements of the system are very low, the fees could be insignificant.

A more interesting question is whether there should be interest on debts. We can try to dodge this problem by leaving this decision to the clients. But if every client could specify how much it charges on a loan, this would create issues during the creation of a connection. Clients would lose money on facilitating loans for which the interest rate they charge is lower than the interest rate they are charged by other participants. And if we allow clients to reject connections that are not profitable, soon we might not be able to establish any at all.

To mitigate this, we could introduce some kind of interest rate negotiation. For example, we could calculate the average interest rate for all clients in the connection; this rate would be automatically accepted if it does not differ by more than X% compared to any single client’s preferred rate. This is still not perfect, but it would give all clients control over interest rates without blocking the whole network.

An interesting side effect of having interest rates specified directly in the system would be the ability to estimate the natural interest rate.

Growth strategy and incentives

The biggest issue with the broader adoption of this system might be the incentives for early adopters. Most cryptocurrencies are deflationary, at least in the initial phase of growth. This means that creators and the first users have a chance to benefit immensely if the given crypto is successful. It creates the incentive to invest in new cryptocurrencies, which is one of the reasons there are so many of them.

This isn’t really the case with our system. The value stored using it is constant for a chosen basket of goods, which is a beneficial but not very exciting property. So, is there any way to make it popular?

One way would be to start small. Initially, it could be used in a limited, local scope, e.g. by groups of friends for keeping track of minor debts. These groups could be tiny. In that context, you can consider it as similar to the Splitwise app that was mentioned before. It would be just a tool, but tools like this have already proved themselves to be useful and popular.

With increased adoption, connections between small groups using the app would form, and the groups themselves would grow. At that level, you would be able to “pay” some people you don’t know personally. Of course, to make this possible the connection chain between two clients needs to exist, and some clients and groups could still be separated. But this problem would disappear with time. Also, the denser the network grew, the shorter the connections that would suffice to complete a transaction.

Not the final word

I find the idea of such an alternative system entertaining. It is different enough from existing cryptocurrencies to give us a new mental model of the problem. By no means is it a silver bullet that solves all the issues of cryptocurrencies, but it has some interesting properties: stability of value, control in users’ hands, and its potential usefulness in e-commerce would be just a few worth mentioning.

All in all, I think it deserves a bit more attention. In the following articles, I will explore some of the topics I have touched on here. I will also try to sketch out a practical implementation of such a system. Stay tuned!