With the ICO chaos beginning to get itself resolved, the ecosystem is finding new direction with the rise of the security token. Startups are moving in that direction. Standards are underway, with some of them having direct focus on the regulatory component. Market factors are knocking out those who can’t adapt. When the smoke clears, there will be a much more tight-knit competitive landscape that bodes greater promise for regulators, investors, and users.
The juxtaposition of the space’s technoeconomic complexity and its “gold rush” zealotry has provided some interesting results with no clear-cut answer as to whether the first-mover or wait-and-see approach harbors a better go-to market model. Currently, a few major issues being worked out include the viability of the proof-of-work consensus mechanism (whether centralized or decentralized), the balanced incentivization of market participants, and the ability for tokenized debt arrangements. I believe that there may be solutions.
The Incentivized “Break-Even”
I feel that much of the cryptocommunity’s popular sentiment, to this day, has reflected on Bitcoin’s incentive program the wrong way. Whereas on face value both users and miners want the same thing — platform stability — there is fundamental asymmetry in the degree to which both groups of market actors want this.
Users — wanting to transact cheaply on a fast, reliable network — are incentivized to keep the network as stable as possible without exerting an inconvenient amount of work. Users are limited by what they can do on platform, but understand that working with a helpful system in the short-term benefits them in the long-run as well.
Miners, on the other hand, have different priorities in mind. Because the network has been set up in a competitive, capitalist fashion where the sky is the limit on monetary incentives, miners can often decide to act in ways that benefit themselves but do not benefit the rest of the network (eg only choosing certain blocks that maximize profits; artificially making “data-light” blocks that they can then validate). In contrast, the users using the platform are not driven in this fashion because they are just trying to use the platform for its efficiency, to mitigate risk, and to secure their funds.
And there we have it: mitigate risk. What if instead of trying to reward miners with Montezuma’s gold, we instead establish a system where the miners mine so that they can manage their own risk….or even debts.
Taking Debt Models in a Different Direction
Looking at the security token side of things, one of the biggest challenges for creating a debt token model is in the lack of assurance that a debt holder will pay back the debt issuer. While some of this challenge is rooted in the perception surrounding the ability for smart contracts to hold up in a court of law as legally-binding, more legal precedence is being determined by the day to establish the litigative legitimacy of smart contracts. I’d argue that the lack of ability in decentralized networks and the earliness of mature solutions in centralized networks, haven’t really presented a need for the conversation to include debt tokens. Now that systems and norms are evolving, the ecosystem may be ready to consider debt-based tokens as alternatives.
I think the general consensus is that certain components will be commonly found in implementations utilizing debt token models. These include collateral staked by the debt holder, KYC/AML assurance, and regulatory oversight. One of the pitfalls for debt tokens in these early days of mainstream adoption is that there are limited options in digital assets that can serve as collateral. The go-to forms of collateral are either cryptocurrency (which face volatile price fluctuations, and therefore aren’t ideal) or tokenized representations of high valued assets, like real estate for instance. While these can work in loan origination through institutions, it is not ideal in a decentralized system. Also presenting limitations, for those that don’t have the collateral to stake, there doesn’t seem to be a tenable debt arrangement.
Now suppose there was an alternative method where individuals (and companies semi-autonomously acting on their behalf) could issue and receive loans with a sort of “insurance policy” allotted for the loan originator party that doesn’t involve collateral from the counterparty?
Workflow
Suppose we take a second to change focus from how we can prevent bad actors from taking advantage of the system to providing a way for debt issuers to make back the money they lent out to the loan that currently stands in default. What if there were a lending schema in place that would allow the loan issuer to use their computational resources & time as a means of guaranteeing the money that they lent out for the loan. In this scenario, if the debt holder is unable or unwilling to pay their debt, the debt issuer has the option to temporarily sacrifice their time and computer’s internal memory, processors, and storage to perform proof-of-work algorithms for payment equivalent to the amount of debt issued. In effect, the loan issuer would break even by performing work. This would serve as the cost for the risk that they incur for giving out the loan.
The workflow would follow this fashion:
DebtIssuerA issues debt to DebtHolderB, via a smart contract, with a high interest rate because DebIssuerA didn’t necessarily trust DebtHolderA and because DebtHolderB had a poor credit score.
Because DebtIssuerA didn’t trust DebtHolderB, in addition to having a high interest rate for loan repayment, DebtIssuerA inserted a provision into the initial smart contract agreement that, in the event of default by DebtHolderB, would allow DebtIssuerA the opportunity to issue his computer’s resources for computing advanced proof-of-work algorithms to a 3rd party (ServiceProviderC). This provision was already solidified between DebtIssuerA and ServiceProviderC prior to the agreement being seen by DebtHolderB, as ServiceProviderC already signed off on it.
While ServiceProviderC, a SaaS service provider of large secure networks, represents a number of clients that require high amounts of computational resources (and distributed across many different computers), in this instance ServiceProviderC represents InstitutionD.
InstitutionD is a research facility doing rigorous, technical analysis of nuclear anatomy and require as much computing power as possible. Because InstitutionD is doing very mission-critical work which they are trying to keep clear from interference, they are mindful of having a lot of computational resources to reinforce the network, as well as have as many different nodes as possible to keep the network power distributed. Fortunately, ServiceProviderC provides this service by matching numerous contractors with clients to maintain and power the network.
Going back to DebtIssuerA and DebtHolderB, time elapses and sure enough DebtHolderB doesn’t repay the loan or interest. Because DebtIssuerA had the provision in the contract that involved ServiceProviderC, DebtIssuerA is able to be a contractor of ServiceProviderC on behalf of InstitutionD in order to repay the amount on the bad debt (but nothing more). DebtIssuerA then provides his desktop computer for the 8 hour time period required to recoup DebtHolderB’s bad debt loss to which he had lended.
As another example: suppose instead of DebtIssuerA being a free agent for the most part, imagine he is using a platform that autogenerates smart contracts with boilerplate text including the provision that DebtIssuerA included in the previous example. The only thing that DebtIssuerA has to decide for (ie negotiate with DebtHolderB) in this instance are the parameters. However, suppose that this platform that DebtIssuerA is using is run by a company (let’s call it Company1) which limits the range on the parameters but lets negotiating parties (like DebtIssuerA and DebtHolderB) decide their own terms within the parameter ranges and regardless of credit scores. However, what Company1 has provided for in the boilerplate text in the contract is that same contingency provision as seen in the previous example. However, in this example, it was a firm (Company1) speaking for the users of the platform (DebtIssuerA, DebtHolderB), that if DebtHolderB didn’t pay, then DebtIssuerA would have the option to provide computational resources to ServiceProviderC if DebtIssuerA wanted as much as to recoup his bad debt loss in the event that DebtHolderB didn’t pay.
TL;DR
An individual would have the ability to enter into a contract in which he could offer another money with the best case scenario being getting repaid in full (including interest) and the worst case scenario being that he is guaranteed but has to contract out his computing resources to receive the guarantee.
The same as above, but instead of an individual dictating all of the terms and individually tracking down the service provider, the company behind the platform acts on the users’ behalf whilst still allowing the users autonomy in negotiation and repayment stages.
Conclusion
As token debt increasingly becomes a hot topic within regtech circles of the distributed ledger community, we need outside of the box thinking to compensate for the “trustlessness” that blockchain purports. While I am very much of the belief that, as the ecosystem evolves, regulators will stick to conventional methods within the distributed ledger industry for the majority of tokenized debt use cases surrounding highly-valued assets, in situations involving smaller sums of money to be repaid this model may serve as a nimble alternative. It goes without saying that the viability of this idea would need to be explored at a finer grain, as one of my biggest considerations would be whether the price someone would pay for “secured computational power” would correspond with what someone would be willing to allocate their resources for in order to recoup a loss.
Supposing the financials and technological/regulatory capacity work out, we would need to see the rise of two entities in order for success of this model. The first would be institutions seeking large amounts of persistent, computational power. These institutions may need to solve rather computationally-intensive problems, run an incredible amount of processes concurrently, or want an extra backbone of security to their network. The second entity needed would be proof-of-work service providers. The role of these institutions would be to collect individuals willing to enlist their computational-resources-for-hire in the event of default on the loan held by the counterparty.
This idea is an incomplete one, and may be discussed further in future articles.
…
While this article is posted here, it’s posted elsewhere as well. In an effort to create a cross-platform discussion, I invite you to expand on any thoughts you have here in the comments as well as over on treadie, which is very much a microcommunity twitter. The reason I use treadie is because (1) it’s free, signup only with Facebook or Twitter; (2) you don’t get the walled garden of only one platform comment section, instead combining everyone for discussion. Link: https://powaaststtd.treadie.com/
