Tokenizing Debt on the Ethereum Blockchain

The Ethereum developer community uses the ERC20 and ERC721 token standards to create digital assets on the blockchain. These token standards define how users are able to transfer ownership of compliant digital assets. And because the standards are so widely adopted, we have witnessed the creation of powerful tools that are able to service these tokens. The common interface for transferring ownership of these digital assets is powerful. However, the inclusion of a few optional pieces of data has proven useful as well, namely, token name, symbol, and the number of decimals. Incorporating this extra information into the standard makes the aforementioned tools even more helpful and informative.

One popular protocol that takes advantage of the ERC20 token standard is the 0x protocol, a protocol to facilitate the decentralized exchange of tokenized assets on the Ethereum blockchain. This protocol allows users to atomically swap x number of W tokens for y number of Z tokens. The swap is executed by a smart contract immediately — there is no risk of one party transferring ownership of tokens while the other party does not reciprocate. This allows for trustless exchanges of tokenized assets. However, this type of exchange is not all-encompassing. From complex financial agreements like mortgages to simple transactions like purchasing coffee from Starbucks, there is a period of time when one party has yet to fulfill his/her side of the agreement; that party is in debt. It would be difficult to purchase a Starbucks coffee using the 0x protocol. Of course, the most obvious issue is that a Starbucks coffee does not exist on the blockchain, but let’s ignore that problem for now. We would still not be able to represent this transaction using the 0x protocol because the transaction is not an atomic swap of two assets. Instead of swapping $4 for a cup of coffee, the purchaser is swapping $4 for the promise of a coffee in a few minutes. Admittedly, just because the 0x protocol couldn't easily facilitate this transaction doesn’t mean we could not represent this transaction on the blockchain — Starbucks could develop their own smart contract to facilitate this transaction. However, we might also want to buy coffee from Dunkin Donuts and Saxbys, so they each could implement their own smart contracts as well. This works. I can now buy coffee from each of these stores using the Ethereum blockchain!

Unfortunately, these ad hoc implementations of similar transactions leads to siloed pools of debt that are not interoperable. Unlike ERC20 tokens, which all have the same methods for transferring ownership, these individual implementations of debt on the blockchain would not have a shared set of common features. As a result, we would not see the creation of protocols like 0x.

It might not be immediately obvious why we would need a protocol like 0x from the examples we have looked at. I am able to purchase a coffee and receive it a few minutes later. In the morning, being able to buy my coffee and get to class is all that I need. However, when we start considering more complex debts, take a home mortgage, for example, it becomes clear why this lack of interoperability might be a problem. In fact, there are many common secondary uses of debt that would become nearly impossible to recreate on the blockchain if there was not this interoperability.

• Debt factoring is the process of selling the right to receive payment for a debt in exchange for cash at a discounted rate. This is a common practice that businesses employ to improve cash flow.
• Credit default swaps help eliminate possible loss arising from default by acting as a sort of default insurance.
• Collateralized Debt Obligations (CDO’s) are financial instruments used by banks to package many individual debts into a product that is sold to investors on the secondary market.

Not only do these secondary processes require the knowledge of how to transfer ownership of a specific piece of debt (whether it be the debt of Starbucks, Dunkin Donuts, or Saxbys), but they also must have the ability to learn basic information about the debt, like how much it is for, when it is due, who owes it, etc.. The Ethereum community needs a standard for representing debt on the blockchain.

I am proposing a debt standard as an optional supplement to the ERC721 token standard just like the name, symbol and decimal are optional supplements to the ERC20 token standard. The Debt Standard defines a common interface that is to be implemented by all ERC721 token smart contracts deployed as a registry of debt. By providing this common debt standard, individuals and applications will be able to gain insight into the debt that each token represents in a systematic way. This will allow for the creation of financial management tools that can be used to manage all forms of debt across the Ethereum blockchain.

The existing ERC 721 token standard is inadequate for representing debt on the blockchain because, although it does provide a standard for transferring ownership of unique tokens, the standard does not include basic functionality that is common across all debts. Importantly, the ERC 721 token standard does not have a standard for associating a value of debt with each token, nor does it have the necessary functions to gain insight into what the token represents. Because all forms of debt have a value attached to it, it is beneficial to the Ethereum community to agree on a set of basic functions to interact with the value that each debt is worth.

The adoption of the debt standard will break down the walls of the silos that are currently under construction and allow for secondary markets to exist that are accessible to all debt on the Ethereum blockchain, regardless of what platform facilitated its creation.

The adoption of the debt standard is only possible through community collaboration. To join the conversation visit this discussion board.