The last several months the Master Protocol developers spent laying the technical foundations of the Master Protocol, we now begin to add more focus on the design of smart contracts and smart property types. With that we’re introducing an effort to create an open source business requirements document which will be used as the basis for further development of The Master Protocol specification. But first some background.
A great innovation like Bitcoin lays a technical and operational basis to spread out the costs of enforcement of sending cash-like money electronically, so that rather then using central or federated authentication authorities, everyone can play a role. However, there is a variety of economic activity far beyond one way transfers of valued money from one party to another.
Expansion of P2P Protocols
With the mass adoption of Internet technology as a means of information sharing and exchange, we are also faced with the growth of intangible, digital commodities and unique items. Note that in the first wave of p2p protocols there was no simple, p2p ledger system:
- p2p file sharing (the p2p progeny of Napster)
- p2p VOIP traffic routing (Skype)
- Generalized p2p Web traffic routing (TOR – thanks to the US Navy)
Bitcoin gives the first thrust for the next wave of decentralized applications. The Master Protocol, which uses Bitcoin’s protocol (and eschatocol), is a specification for the classification of and means of secure exchange of various contract types. Some of the first contract types and smart property types contained within the specification document can be enumerated as follows.
Current Master Protocol is comprised of the following components (this is not exhaustive for the sake of brevity):
0. Wallet Address
A. Default Address
By default Master Protocol wallet address (a Bitcoin address) functions the same was as any other BItcoin address, meaning that if one possess the private one has complete control over that wallet. The protocol is simple: show me the private key, and your wallet opens.
B. Guardian and Savings Addresses
Master Protocol however specifies another wallet address protocol, which contains several unique characteristics:
- Defines a Guardian Address which has the same functionality as a Default Address can do the following:
- Define a transaction reversibility period for a Savings Address.
- Mark a Savings Address as compromised.
- Receive funds in pending transactions and any remaining funds at the Savings Address.
- Define a rate limit for a Savings Address (for example, 1 Mastercoin per X blocks).
1. Electronic Cash and Credit Protocols
Protocols which essentially are a one way transfer. Potentially, one could make these pseudo-two-way by at least having the other party trade a receipt or invoice on the blockchain (see protocols for e-commerce in the spec).
A. One-way Ownership Transfer
Perhaps the simplest smart contract type and related to the type used in Bitcoin for sending the equivalent of electronic cash from one address to another. The nomenclature in the specification for this is Simple Send, and is useful for in-person transactions were one takes physical possession of a good or consumes a service.
B. Restricted One-way Ownership Transfer
Functions similar to a secured credit card in functionality (but without interest). Otherwise it is identical to 1.A. however the funds come from a “savings address” which has a rate limit and a transaction maturation time parameter. Transactions which have not matured can be reversed should the address become compromised.
C. Investment Send
A special send that locks funds and returns another smart property token after the end of the lock period. These are used only for variable quantity smart property creation, where quantity is some multiplier of total quantity of sends.
2. Trading Protocols
There are essentially two types: standard native trades, and trades involving bitcoins which require an extra funding.
A. Sell Offers and Buy Offers denominated in Bitcoin
The protocol for trading Mastercoin in exchange for Bitcoin. The process involves:
1. Sell Offers
Posts the terms of an offer to sell Mastercoins or Test Mastercoins for bitcoins.
2. Buy Offers
These entail a two-step process.
Step 1: The Matching MSC Sell Offer Submission and Acceptance
Posts acceptance of an offer to sell Mastercoins for bitcoins. All or some of the coins offered can be purchased with this transaction. Once enough confirmations occur for the matching Buy Offer to statistically ensure that no other submission has priority for matching should an orphan chain occur, there is a final BTC send transaction that needs to occur in order to fund the the matched transaction.
At this point the portion of the Sell Offer that is matched is in accepted status.
Step 2: Funding Event and Balance Adjustments
Send the appropriate amount of bitcoins before the time limit expires to complete the purchase. Mastercoin balances are updated to reflect the new balances for the two addresses involved in the transaction.
An offer to sell coins can be changed until either: there are valid corresponding purchase offers for the whole amount offered, or the sell offer is canceled.
Otherwise the change will apply to the balance that has not yet been accepted with a purchase offer.
A currency sell offer can be canceled until the offer has been fully accepted by valid purchase offers. When a sell offer is canceled, the associated coins are no longer reserved.
Trading between two native smart properties on the Master Protocol (for example, Mastercoins and Goldcoins) occurs in the same format as in Section 2.A however Step 2 of Section 2.A.2 no longer requires funding as the two tokens are matched and balances of the two accounts involved are adjusted to reflect the trade.
3. Smart Property Protocols
There are many use cases for this but perhaps the simplest is as a “User Currency” in Master Protocol parlance. Say that you are the Chairman of the central bank in a country that has a highly devalued currency that no one trusts, or maybe a game designer not wanting to worry about a hacked money problem (I’m looking at you Rockstar).
The supply of this token is a function of a multiplier of the amount of funds raiser coupled with a time dependent multiplier variable (i.e., bonus for early participation), some number of tokens set aside for the issuer. There is an end date to the offer.
The preceding taxonomy is not exhaustive and still in development.
If you would like to contribute head over to the Marketing & Product Requirements Document for Decentralized Trading Protocols and Smart Properties on GitHub to help with the requirements so that our specification team can evaluate various requirements for consideration to be added to the Master Protocol specification. As always with Mastercoin Foundation, your contributions in the form of qualified pull requests will be accounted for when we do our monthly bounty distribution.