Lucas Huber suggests that the Interledger Protocol would be a suitable technology for implementing the credit commons. This post is a space to explore that more fully.
Credit commons was originally conceived as a ledger between the all the ledgers on all the separate platforms of the complementary currency movement, and the actual function of the interledger protocol is the same, to ensure that one transaction in one ledger is equivalent to another transaction in another ledger, thus that money/credit are not created/lost by mismatches in ledgers.
However when we regard money as credit relations between members of a trusted group, rather than as a commodity actually changing hands then the interledger protocol seems less suitable to me.
- With the mutual credit approach, there is really only one ledger in the middle which embodies the single contract which all members have entered into. But I think Interledger implies that connectors have to be set up between every possible pair of ledgers. As the network grew, an exponentially growing number of connectors would be needed. That means only within Community Forge Community Forge that would mean managing potentially thousands of connectors, many of which would never be used.
- That array of connectors would then need to be running a with a common policy around minimum and maximum credit limits, which would need to be updatable.
- Since Interledger doesn't create a ledger of ledgers, the nesting described in the Credit Commons white paper would be impossible.
- Interledger uses escrow methodology and assumes that transactions are irreversible, which is how money-as-a-commodity works in law. This approach just seems inappropriate for managing credit relations.
Comments2
Hi Matt, You're more the
Hi Matt,
You're more the expert on on the Credit Commons, but I want to clarify some of the points about Interledger.
Interledger uses the term "ledger" to refer to the accounting system for a single type of asset.
I think you could represent credit relationships in two ways: a) a community of people could all have balances on a single ledger, such that there would be one set of rules for the whole community and all of the units would be equivalent or b) individuals could extend one another credit, up to whatever limits they define, and each credit relationship would be tracked and managed separately.
For option a, the only connectors you would need would be those that connect different communities (ledgers). Option b would be more flexible but obviously more complicated (and you would need more UI to manage these relationships than we have built thus far). In the latter case, every individual would track their balances with one another separately and set their min/max limits on their own (this would be more similar to the "trustlines" concept from RipplePay and the Ripple Consensus Ledger).
We don't really use the term "ledger of ledgers" for Interledger, because we're trying to stick to the concept of a ledger as having only one type of asset that can be transferred between all accounts on that system, but the idea is not too dissimilar. The goal of Interledger is to efficiently discover and securely utilize connections between different ledgers. You do not need an exponential number of connectors between different ledgers because with secure multi-hop paths, each ledger only needs a small number of connections to others in order for the whole world to be connected.
On the Interledger layer transactions are irreversible, but you could implement reversibility either on a higher or lower layer. If you implement it on a lower layer, that would mean that individual ledgers may have reversible transfers. The only potential problem with this is that malicious users could scam connectors to other (irreversible) ledgers by sending interledger payments and then reversing the first leg of the payment. If that is not a concern because it's a small community where people trust one another, that may not be a problem. You could also implement reversibility in a higher level scheme. All parties to this scheme would agree that under some set of conditions the receiver of a payment would return the funds by sending a new Interledger payment to the sender. People in this scheme would not be able to transact with others outside it, because you would not be sure the recipient would send back the money.
Best,
Evan
In addition to to Evans
In addition to to Evans comment I will just try to clarify some of the four of Matthew arguments.
His arguments are describing how Interledger is shaped to transact FIAT money or cryptocurrencies. Of course this wouldn't really fit for mutual credit systems, as described in the credit commons. But when we reshape some parts of the present implementation towards our need you get a slightly different model how Interledger can work too. For instance it shouldn't be a big problem to organize the connectors and the exchanges in a hierarchic structure. So nesting of connectors is also possible. Interledger is flexible and does so far cover only the minimal core of a transaction protocol. So for different use cases or implementations different addons and enhancements are necessary.