Cashflow on the Blockchain Part II: A Protocol for Tokenized Debt

This is the second part of a series exploring the potential of security tokens based on debt assets. In the first part,In the first part, we explored the potential of tokenized debt as one products that can unlock the potential of security tokens in the short terms. Today, I would like to deep dive into the building blocks of debt-based security tokens and explore the dynamics of a protocol for this type of crypto-security.

The main roadblock for the proliferation of debt-based security tokens is the absence of a native on-chain protocol that abstracts the lifecycle of a debt vehicle. While equity-based security tokens behave like semi-static representations of a share, debt-based crypto securities exhibit more dynamic behaviors such as dividend payments or defaults during its lifecycle. From that perspective, it is pretty obvious that debt-based security tokens are going to require new protocols that abstract those characteristics in the form of blockchain tokens. As explored in the first part of this article, protocols like Dharma can serve as a powerful inspiration but they are designed for a different use case than crypto-securities. The role of a protocol for crypto-securities debt will be to enable programmable interactions between participants in a debt vehicle on the form of on-chain smart contracts. To create such protocol, we need to start by understanding the different types of debt security tokens and its corresponding participants.

Forms of Debt Security Tokens

The lifecycle of a debt vehicle can be abstracted by the interactions between three main roles:

In the context of security tokens, debt vehicles can materialize in two main forms depending on whether the underwriting process happens on-chain or off-chain:

· Tokenized Off-Chain Debt: Issuing on-chain tokens that represent off-chain debt vehicles such as bonds or real estate leases.

· Native On-Chain Debt: Debt tokens whose entire lifecycle from underwriting to maturity takes place on-chain.

For obvious reasons we should expect the first wave of debt security tokens to be tokenized representations of off-chain debt products and gradually the protocols should evolve to support the creation of 100% on-chain debt.

Whether we are tokenizing off-chain debt vehicles or creating an on-chain infrastructure for issuing debt, we need a protocol that encapsulates the main components of debt interactions.

Architecting a Protocol for Debt Security Tokens

In its simplest form, a protocol for debt security tokens needs to incorporate the elements that regulate the lifecycle of a debt vehicle. Borrowing a few concepts from bond theory, we can architect a debt-based security token using the following elements:

· Maturity Date: Every debt-based security token should have a maturity date that determines the date on which the underlying debt will mature and the debt token issuer will pay the debt token holder the face value of the token.

· Face Value: The face value of a debt-based security token is the value of the underlying debt at maturity. Each debt token holder will receive a fraction of the face value proportional to its holdings at maturity date.

· Interest Rate: The interest rate is a nominal amount that debt token issuers will pay debt token holders during the lifecycle of the token. Interest rates can be adjusted based on inflation levels.

· Frequency: Interest rate payments need to be issued regularly based on a specific frequency.

· Rating: A debt token rating is a value that describes the quality or risk of the debt token. Typically, the higher the rating the lower the interest rate.

· Yield: This is the total return that a debt token holder can expect to receive at maturity date.

Putting the previous components together in the context of security tokens, we can come up with a relatively simple structure for a debt-based crypto-security.

A protocol for debt security tokens needs to go beyond the token structure itself and model the interactions between the different participants in a debt vehicle. At a high level, the following roles should be present in that type of protocol:

· Debt Token Issuers: Entities that create the tokenized debt vehicle.

· Debt Token Holders: Entities that own the debt tokens.

· Payment Distributors: Entities that distribute the interest rate and yield payments for the debt token holders.

· Raters: Entities that issue a quality or risk rating associated with a specific debt security token.

· Arbiters: Entities responsible for solving disputes between debt token issuers and holders in the case of a default.

Let’s see this components in action in the context of an example. Assume that a hard cash money lending company called IssuerA tokenizes a loan with a face value of $1000 and a 10% quarterly interest payment and a maturity date of 5 years. A Rater representing a credit agency grades the loan with a AAA rating indicating the high quality of the underlying assets. IssuerA will distribute 10,000 tokens value at $1 each representing 10 underlying loans. Two people HolderA and HolderB both buy a to 1000 tokens each. At the end of the first quarter, the protocol will use a Payment Distributor to pay $100 to both HolderA and HolderB. If IssuerA misses subsequent payments, the debt contracts are locked and send to an Arbitrer for resolution.

I know the example is overly simplistic but hopefully communicates some of the main ideas behind a debt protocol for security tokens.

The first forms of tokenized debt in security tokens are likely to be very simple and constrained in order to avoid bad behaviors and test the fundamentals of the concept. As the space evolves, we are likely to see new forms of debt security tokens that model debt vehicles that are impossible to create today. That will be the subject of a future post.