Introduction & Features:

There are many ways to consider a new Ethereum-based protocol: the value it creates for a user, the value it creates for a developer, and the value it creates for the community. At Blockmason, we are dedicated not only to building useful, functional applications and protocols that solve real-world problems, but also to developing platforms that inspire adoption of the Ethereum network and expand global access to cryptocurrency.

That is why we are so excited to announce the development of our newest product: The Credit Protocol (CP).

Until now, it was only possible to move money on the blockchain in the form of cash. Bitcoin democratized the transfer and storage of money, and Ethereum democratized the creation and storage of monetary contracts. With the Credit Protocol, BlockMason has taken the next logical step in the decentralized economy: democratizing the creation of credit. Debt and credit are already extremely powerful financial tools, and now they will be strengthened by the security and flexibility of the blockchain. In fact, because an individual need not own ether in order to draw debt in ether, it is entirely possible to imagine a future in which debts and credits recorded on the Credit Protocol could exceed the total market capitalization of all cryptocurrencies combined, dramatically increasing the scale of the digital economy.

It is entirely possible to imagine a future in which debts and credits recorded on the Credit Protocol could exceed the total market capitalization of all cryptocurrencies combined, dramatically increasing the scale of the digital economy.

However, there is no better proof of a team’s vision and execution than its product. At Blockmason, we have never set much store by empty promises or flashy Whitepapers. Yes, we are extremely proud of the work our team has put forth to create this document, but we are even more proud of our developers, who have already deployed a fully-functional version of our newest application, Lndr, demonstrating the functionality of the Credit Protocol. This awesome, simple DApp is available right now. Go ahead, check it out at lndr.io, we’ll wait…

Oh, you’re back.

Well, before you read about our new protocol, how about one last thing:

When purchasing product-use tokens, it is important to not simply look at the product as is, but also consider the company’s ability to provide exemplary customer support for that product. That is why we will continue to update and improve CP in advance of and throughout the duration of the token. Unlike other sales, based on hope and potential, our work stands alone to demonstrate our company’s commitment to ongoing development, product maintenance, and creativity as we expand the possibilities of blockchain technology. Our passion for our product and desire to improve the Ethereum ecosystem is not dependent on funding, and we aim to prove that we love building useful, functional, life-changing DApps—no matter what.

The Credit Protocol

At its most basic level, the Credit Protocol is a system for recording debts and credit between entities on the Ethereum blockchain. One entity sends a debt or credit request to another, and that user then confirms the debt or credit, which is recorded and stored within the Credit Protocol’s smart contract.

This simple interaction between entities via the Credit Protocol enables a deceptively powerful and complex array of possible transactions when coupled with a Use Case Authority Contract (UCAC) built atop the protocol. Each UCAC has its own set of rules about what types of debts it will record, when it will record them, and from whom it will accept them. For example, a UCAC may permit transactions from only certain certified users, allowing organizations to build private debt recording contracts. These contracts could be used for anything from tracking accounts receivable to developing private organizational currency, as is used on many college campuses.

In many ways, this system is similar to a highway. Each debt or credit is akin to a car—there are different makes, models, features, and colors, but they all serve a fundamentally similar purpose. Once a car is allowed onto the highway, this debt, and all its particularities, is recorded. But, of course, you may desire some regulation to keep all that traffic running smoothly and going to the right place. Enterprising developers can construct their own tollbooths, or UCACs, at the entrance to the highway. Each tollbooth has complete control over what types of cars it allows on to its particular stretch of highway—sports cars or semi-trucks or huge vans filled with puppies—and when those cars may access the highway. Of course, operating a tollbooth requires resources. Users of the CP will have opportunity to purchase a Credit Protocol Token (BCPT), which funds the movement of cars through the tollbooth and onto the highway. Users may charge a fee to allow cars to travel the highway, or they may let the cars pass for free.

The amount of cars allowed through a tollbooth depends on two factors: how many BCPTs are funding the tollbooth’s operation, and how many transactions are permitted per BCPT. Blockmason will adjust the number of transactions permitted per one BCPT based on network traffic, meaning that transaction costs are dynamic and adjustable based on the needs of the network.

Through these BCPTs, a UCAC effectively buys debt recording capacity from the network. BCPTs are, in essence, a license to use the CP network, much as software is licensed to users. This license is granted in perpetuity to the holder of a BCPT for as long as he or she owns that token. The owner of a BCPT may choose to “sublicense” their allotted transactions to another user, whether for free or for compensation, while retaining their token and the rights granted therein.

Use Case Authority Contracts

Use Case Authority Contracts act as a pathway for inputting and settling debts. Because UCACs are user-created, the particular rules that govern recording debt through a UCAC may be optimized to best fit the need of the organization or user employing the Credit Protocol. Parameters for which a UCAC may be programmed include currency type, the size and frequency of allowable transactions, which users may create debt or be extended credit, limits of debt accrued, and much more. The possible iterations of effective, valuable UCACs is restricted only by the imagination of the designer, so long as its result is a debt transaction compatible with the Credit Protocol.

Each UCAC requires the operator to “stake” a minimum of one BCPT to write debt or credit through that UCAC to the Credit Protocol system. Each BCPT possessed by the operator permits the UCAC to process a specified number of transactions per day, a number determined by a variable set by Blockmason within the CP smart contract. Therefore, staking more BCPTs allows for greater transaction throughput within the UCAC. Depending on the intended debting system, a user or developer may need to own multiple BCPTs to optimally guarantee the UCAC throughput capacity. While users may own fractional tokens, these partial tokens cannot be used to generate transactions. The transactions generated by a single BCPT expire 24 hours after generation, at which point the BCPT will generate a new set of available transactions.

Bounty Program for UCACs

While we have spent significant time and energy conceptualizing useful UCACs that take advantage of the Credit Protocol to solve real world problems, we know that we cannot envision every application of the CP alone. Because there are infinite variations of Use Case Authority Contracts, as well as varying demand for the creation of such contracts, the Credit Protocol token sale set aside a portion of the BCPT sales revenue to fund a Bounty Program that incentivizes developers to write high-demand UCACs that can show the way for developers to build apps.

Free UCAC Depository

At Blockmason, we are dedicated to providing outstanding customer support for the Credit Protocol and its users. A vital step toward that goal is building a supportive community that believes in the Credit Protocol and further developing its unique ecosystem. In that spirit, we will create and maintain a depository of free UCACs for developers to leverage in building their own DApps on top of the Credit Protocol. This depository will include all winners of our Bounty Program, as well as generic templates of successful UCACs that may be customized for specific applications. This depository will not only encourage the growth of a strong CP community, but it will also promote the adoption of the CP protocol by prospective users who can browse a list of successful UCACs already being implemented throughout the world.

Enforcing Debt Repayment

While the CP provides a valuable, multipurpose tool for recording debts and credit, it is important to note that individual users must still agree upon how best to enforce repayment of those debts. This enforcement may take many forms, and could involve both on-chain and off-chain solutions, including: binding legal contracts, collateral in the form of physical / digital assets, or social mechanisms such as blockchain credit reporting or business reviews.

Ultimately, users should not lend to entities in whom they doubt the ability to repay their debt, nor should users lend more money than they are comfortable losing.

Through the customization and personalization of UCACs, however, it is possible to design debt contracts that perfectly match the needs and individual users and businesses, rendering the question of debt enforcement moot. While we outline several possible use cases of the Credit Protocol below, it is worth considering two common debting scenarios:

1. Jesse owes his friend, Tim, a beer.
2. Jesse’s business, Jesse Corp., issued his customer, Tim, a gift card.

In scenario one, social pressure is sufficient to enforce repayment of the debt once it has been recorded on the Credit Protocol through the UCAC—no one wants to be Jesse’s friend if he won’t get you back for that sweet, refreshing, cold-as-the-Rockies brew.

In scenario two, economic pressure is sufficient to enforce repayment of the debt once it has been recorded—no one will shop at Jesse Corp. if the business won’t honor its gift cards.

In both cases, the specific UCACs that control the types of debt being recorded have built-in mechanisms for debt enforcement. In general, this type of enforcement is particularly effective for debting scenarios in which a large company or institution owes a smaller beneficiary for prepaid goods or services.

Because legal and social mechanisms already exist for enforcing debt repayment, the true power of the Credit Protocol rests in its ability to reliably record debts through double confirmation. These eliminates the need for the ceremony or bureaucracy currently for parties to trust a debt. Recording debts on the blockchain allows individuals and entities to tap into existing mechanisms for debt transactions without the red tape of banks, lawyers, and other trust institutions.

• ← Prev Section
• Next Section →