From 3388c7c93433137cf777402a32400c024e0e9504 Mon Sep 17 00:00:00 2001 From: Sean Gilligan Date: Thu, 24 Oct 2019 16:03:46 -0700 Subject: [PATCH 1/2] Rename all .md to .adoc EXCEPT spec/README --- AssetIssuanceStandard.md => AssetIssuanceStandard.adoc | 0 Process.md => Process.adoc | 0 RoleBasedBounties.md => RoleBasedBounties.adoc | 0 VotingRules.md => VotingRules.adoc | 0 WhyMastercoinsHaveValue.md => WhyMastercoinsHaveValue.adoc | 0 5 files changed, 0 insertions(+), 0 deletions(-) rename AssetIssuanceStandard.md => AssetIssuanceStandard.adoc (100%) rename Process.md => Process.adoc (100%) rename RoleBasedBounties.md => RoleBasedBounties.adoc (100%) rename VotingRules.md => VotingRules.adoc (100%) rename WhyMastercoinsHaveValue.md => WhyMastercoinsHaveValue.adoc (100%) diff --git a/AssetIssuanceStandard.md b/AssetIssuanceStandard.adoc similarity index 100% rename from AssetIssuanceStandard.md rename to AssetIssuanceStandard.adoc diff --git a/Process.md b/Process.adoc similarity index 100% rename from Process.md rename to Process.adoc diff --git a/RoleBasedBounties.md b/RoleBasedBounties.adoc similarity index 100% rename from RoleBasedBounties.md rename to RoleBasedBounties.adoc diff --git a/VotingRules.md b/VotingRules.adoc similarity index 100% rename from VotingRules.md rename to VotingRules.adoc diff --git a/WhyMastercoinsHaveValue.md b/WhyMastercoinsHaveValue.adoc similarity index 100% rename from WhyMastercoinsHaveValue.md rename to WhyMastercoinsHaveValue.adoc From d9f3b2b09a3d7def7b84a4fa4c8bc00cdde7e265 Mon Sep 17 00:00:00 2001 From: Sean Gilligan Date: Thu, 24 Oct 2019 16:04:45 -0700 Subject: [PATCH 2/2] Convert to adoc format --- AssetIssuanceStandard.adoc | 257 +++++++++++++++++++++-------------- Process.adoc | 27 +++- RoleBasedBounties.adoc | 176 ++++++++++++++++-------- VotingRules.adoc | 140 +++++++++++++------ WhyMastercoinsHaveValue.adoc | 115 ++++++++++------ 5 files changed, 466 insertions(+), 249 deletions(-) diff --git a/AssetIssuanceStandard.adoc b/AssetIssuanceStandard.adoc index 8d83d49..7e7fb29 100644 --- a/AssetIssuanceStandard.adoc +++ b/AssetIssuanceStandard.adoc @@ -1,92 +1,143 @@ -# Proposed Standard for Bitcoin Assets +== Proposed Standard for Bitcoin Assets -Original proposal by [Gideon Greenspan](http://www.gidgreen.com/) with input from [J.R. Willett](https://github.com/dacoinminster), [Ron Gross](https://github.com/ripper234) and [Flavien Charlon](https://github.com/Flavien). +Original proposal by http://www.gidgreen.com/[Gideon Greenspan] with +input from https://github.com/dacoinminster[J.R. Willett], +https://github.com/ripper234[Ron Gross] and +https://github.com/Flavien[Flavien Charlon]. -## Summary +=== Summary -This is a proposal under consideration for a standard format for representing assets which are issued over the bitcoin network. Reasons for developing such a standard: +This is a proposal under consideration for a standard format for +representing assets which are issued over the bitcoin network. Reasons +for developing such a standard: -* Make it easier for wallet and tool developers to support multiple "Bitcoin 2.0" protocols (such as MasterCoin or colored coins) which might issue and transact in these assets. +* Make it easier for wallet and tool developers to support multiple +"`Bitcoin 2.0`" protocols (such as MasterCoin or colored coins) which +might issue and transact in these assets. +* Make it easy for issuers to offer the same asset over multiple +protocols. +* Increase the liquidity of such assets by maintaining their legal and +financial equivalence between different protocols. -* Make it easy for issuers to offer the same asset over multiple protocols. +==== Overview and example -* Increase the liquidity of such assets by maintaining their legal and financial equivalence between different protocols. +Assets definitions use http://www.json.org[JSON] format with UTF-8 +encoding. Wallets must support JSONs up to 1 MB in size (they may also +accept larger JSONs if they wish). Below is an example - note that all +fields are optional: -### Overview and example - -Assets definitions use [JSON](http://www.json.org) format with UTF-8 encoding. Wallets must support JSONs up to 1 MB in size (they may also accept larger JSONs if they wish). Below is an example - note that all fields are optional: - -``` +.... { - "name": "Credit at John Doe's", - "name_short": "JD Credits", - "issuer": "John Doe's Restaurant Chain", - "type": "Credit", - "currency": "USD", - "description": "Can be used for any purchase at John Doe's, excluding breakfasts.", - - "interest_rate": 1, - "issue_date": "2014-03-01", - "expiry_date": "2024-02-29", - - "icon_url": "http://www.john-doe-dining.com/bitcoin-credits-icon.png", - "image_url": "http://www.john-doe-dining.com/bitcoin-credits-image.png", - "contract_url": "http://www.john-doe-dining.com/bitcoin-credits-contract.pdf", - "redemption_url": "http://www.john-doe-dining.com/bitcoin-credits-redeem.php", - "feed_url": "http://www.john-doe-dining.com/bitcoin-credits-feed.rss", - - "color": "#ffccaa", - "multiple": 0.01, - "format": "* dollars", - "format_1": "1 dollar", - - "mastercoin_id": "123456", - "coinprism_sources": ["2MyvmsxoCxsnzPapDnK7ZcMxWjU3hqLZkpX"], - "coincolors_id": "f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6" + "name": "Credit at John Doe's", + "name_short": "JD Credits", + "issuer": "John Doe's Restaurant Chain", + "type": "Credit", + "currency": "USD", + "description": "Can be used for any purchase at John Doe's, excluding breakfasts.", + + "interest_rate": 1, + "issue_date": "2014-03-01", + "expiry_date": "2024-02-29", + + "icon_url": "http://www.john-doe-dining.com/bitcoin-credits-icon.png", + "image_url": "http://www.john-doe-dining.com/bitcoin-credits-image.png", + "contract_url": "http://www.john-doe-dining.com/bitcoin-credits-contract.pdf", + "redemption_url": "http://www.john-doe-dining.com/bitcoin-credits-redeem.php", + "feed_url": "http://www.john-doe-dining.com/bitcoin-credits-feed.rss", + + "color": "#ffccaa", + "multiple": 0.01, + "format": "* dollars", + "format_1": "1 dollar", + + "mastercoin_id": "123456", + "coinprism_sources": ["2MyvmsxoCxsnzPapDnK7ZcMxWjU3hqLZkpX"], + "coincolors_id": "f5d8ee39a430901c91a5917b9f2dc19d6d1a0e9cea205b009ca73dd04470b9a6" } -``` - -### List of fields - -All fields are optional in this specification, though some may be required by certain protocols: - -* `name` = full name of the asset for display, up to 64 characters. -* `name_short` = short name of the asset for display, up to 16 characters. -* `issuer` = full legal name of the issuer for display. -* `type` = type of the asset, examples: `"Credit"`, `"Stock"`, `"Bond"`, `"Cash"`, `"Licence"`, `"Coupon"`, `"Property"`. -* `currency` = 3-character [ISO 4217](http://en.wikipedia.org/wiki/ISO_4217) currency code, if relevant. -* `description` = more information about the asset for display (up to a few sentences). -* `interest_rate` = annual interest rate percentage, negative for demurrage. -* `issue_date` = date/time when the asset was issued, formatted as [ISO 8601](http://en.wikipedia.org/wiki/ISO_8601). -* `expiry_date` = date/time when the asset will no longer be valid, formatted as ISO 8601. -* `icon_url` = absolute URL for square icon to show for the asset (PNG only), minimum 32x32 pjxels. [1 MB] -* `image_url` = absolute URL for larger image to show for the asset (PNG or JPEG), minimum 128x128 pjxels. [1 MB] -* `contract_url` = absolute URL of the contract underlying the asset. [16 MB] -* `redemption_url` = absolute URL of the web page where the asset can be redeemed. -* `work_url` = absolute URL of the content to which the asset grants a license. -* `feed_url` = absolute URL of an RSS 2.0 feed for the asset. [1 MB] -* `color` = HTML-style hexadecimal color for displaying the asset, with preceding `#`. -* `multiple` = number by which to multiply the asset quantity for display. -* `format` = how to display asset quantities (`*` is substituted for the display value), up to 20 characters. -* `format_1` = how to display the asset quantity if the display value is exactly 1, up to 20 characters. - -For `*_url` fields, sizes in [square brackets] indicate the size of the referenced asset that wallets must support. Wallets may support larger sizes if they wish. - -Additional user-defined fields are permitted. Fields which are specific to a protocol should be prefixed with that protocol's name, such as `mastercoin_id`, `coinprism_sources` and `coincolors_id` in the example above. - -### Notes - -* All references to external assets in the metadata should use absolute URLs, to avoid wallets having to resolve relative URLs. - -* Two relatively simple asset types can be defined in terms of (a) redemption (e.g. a bank promises one cent per asset unit), or (b) license (a website grants access to its content for asset holders). For these cases, there is a field linking to the redemption process (`redemption_url`) or the licensed work (`work_url`) respectively. - -* Linked contracts (`contract_url`) must be in a self-contained format such as PDF (without external references), UTF-8 encoded plain text, JPEG or PNG. The file type will be determined based on the MIME type returned by the web server in the HTTP headers. If the MIME type was incorrect, wallets may optionally use file inspection to determine the file's contents. Wallets must explicitly block contracts in HTML format, since HTML web pages can reference external assets such as images whose substitution can completely change their meaning. - -* The `format`, `format_1`, `color`, `icon_url` and `image_url` fields enable visual control over how asset quantities are displayed in wallets. Icons should be square PNGs (with transparency permitted) at least 32x32 pixels in size, which the wallet can scale as necessary. Images can be PNGs or JPEGs and should be at least 128x128 pixels in size, not necessarily square. - -* If present, the `multiple` and `interest_rate` fields modify the raw integer quantity of units, before it is displayed in a wallet. (The raw number of units held can only be changed by transactions on the blockchain.) The `interest_rate` field is treated as a percentage per annum, beginning from the `issue_date`, and may be negative to indicate demurrage. In quasi-code, the display amount would be calculated as: - -``` +.... + +==== List of fields + +All fields are optional in this specification, though some may be +required by certain protocols: + +* `+name+` = full name of the asset for display, up to 64 characters. +* `+name_short+` = short name of the asset for display, up to 16 +characters. +* `+issuer+` = full legal name of the issuer for display. +* `+type+` = type of the asset, examples: `+"Credit"+`, `+"Stock"+`, +`+"Bond"+`, `+"Cash"+`, `+"Licence"+`, `+"Coupon"+`, `+"Property"+`. +* `+currency+` = 3-character http://en.wikipedia.org/wiki/ISO_4217[ISO +4217] currency code, if relevant. +* `+description+` = more information about the asset for display (up to +a few sentences). +* `+interest_rate+` = annual interest rate percentage, negative for +demurrage. +* `+issue_date+` = date/time when the asset was issued, formatted as +http://en.wikipedia.org/wiki/ISO_8601[ISO 8601]. +* `+expiry_date+` = date/time when the asset will no longer be valid, +formatted as ISO 8601. +* `+icon_url+` = absolute URL for square icon to show for the asset (PNG +only), minimum 32x32 pjxels. [1 MB] +* `+image_url+` = absolute URL for larger image to show for the asset +(PNG or JPEG), minimum 128x128 pjxels. [1 MB] +* `+contract_url+` = absolute URL of the contract underlying the asset. +[16 MB] +* `+redemption_url+` = absolute URL of the web page where the asset can +be redeemed. +* `+work_url+` = absolute URL of the content to which the asset grants a +license. +* `+feed_url+` = absolute URL of an RSS 2.0 feed for the asset. [1 MB] +* `+color+` = HTML-style hexadecimal color for displaying the asset, +with preceding `+#+`. +* `+multiple+` = number by which to multiply the asset quantity for +display. +* `+format+` = how to display asset quantities (`+*+` is substituted for +the display value), up to 20 characters. +* `+format_1+` = how to display the asset quantity if the display value +is exactly 1, up to 20 characters. + +For `+*_url+` fields, sizes in [square brackets] indicate the size of +the referenced asset that wallets must support. Wallets may support +larger sizes if they wish. + +Additional user-defined fields are permitted. Fields which are specific +to a protocol should be prefixed with that protocol’s name, such as +`+mastercoin_id+`, `+coinprism_sources+` and `+coincolors_id+` in the +example above. + +==== Notes + +* All references to external assets in the metadata should use absolute +URLs, to avoid wallets having to resolve relative URLs. +* Two relatively simple asset types can be defined in terms of (a) +redemption (e.g. a bank promises one cent per asset unit), or (b) +license (a website grants access to its content for asset holders). For +these cases, there is a field linking to the redemption process +(`+redemption_url+`) or the licensed work (`+work_url+`) respectively. +* Linked contracts (`+contract_url+`) must be in a self-contained format +such as PDF (without external references), UTF-8 encoded plain text, +JPEG or PNG. The file type will be determined based on the MIME type +returned by the web server in the HTTP headers. If the MIME type was +incorrect, wallets may optionally use file inspection to determine the +file’s contents. Wallets must explicitly block contracts in HTML format, +since HTML web pages can reference external assets such as images whose +substitution can completely change their meaning. +* The `+format+`, `+format_1+`, `+color+`, `+icon_url+` and +`+image_url+` fields enable visual control over how asset quantities are +displayed in wallets. Icons should be square PNGs (with transparency +permitted) at least 32x32 pixels in size, which the wallet can scale as +necessary. Images can be PNGs or JPEGs and should be at least 128x128 +pixels in size, not necessarily square. +* If present, the `+multiple+` and `+interest_rate+` fields modify the +raw integer quantity of units, before it is displayed in a wallet. (The +raw number of units held can only be changed by transactions on the +blockchain.) The `+interest_rate+` field is treated as a percentage per +annum, beginning from the `+issue_date+`, and may be negative to +indicate demurrage. In quasi-code, the display amount would be +calculated as: + +.... display=raw_units_held; multiple=get_asset_definition_field('multiple'); @@ -96,31 +147,37 @@ format=get_asset_definition_field('format'); format_1=get_asset_definition_field('format_1'); if (is_valid_floating_point(interest_rate) && is_valid_iso_8601(issue_date)) { - seconds_elapsed=time_now_in_seconds()-iso_8601_to_seconds(issue_date); - years_elapsed=seconds_elapsed/31557600 // assume 365.25 days per year; - display*=power(1.0+interest_rate/100, years_elapsed); + seconds_elapsed=time_now_in_seconds()-iso_8601_to_seconds(issue_date); + years_elapsed=seconds_elapsed/31557600 // assume 365.25 days per year; + display*=power(1.0+interest_rate/100, years_elapsed); } if (is_valid_floating_point(multiple)) - display*=multiple; - + display*=multiple; + if ((display==1.0) && is_not_empty(format_1)) - display=format_1; - + display=format_1; + else if (is_not_empty(format) && string_contains(format, '*')) - display=string_replace(format, '*', display); - -``` - -* The `expiry_date` field indicates when the asset will no longer be redeemable, or no longer grant access to the licensed content. Wallets should display an appropriate warning as this expiry date approaches, in order to remind users to redeem their asset or renew their subscription. - -* The `feed_url` field enables notifications to be issued to asset holders via RSS 2.0, for inclusion in a wallet news feed. - -* An asset definition JSON can be embedded inside a web page by `\uXXXX`-escaping the characters `(` `)` `<` `>` inside the JSON, and inserting it into the code below. Using this encoding, the JSON can be easily extracted from the raw HTML using a regular expression (no DOM parsing) and will also be accessible to Javascript on the page. - -``` + display=string_replace(format, '*', display); +.... + +* The `+expiry_date+` field indicates when the asset will no longer be +redeemable, or no longer grant access to the licensed content. Wallets +should display an appropriate warning as this expiry date approaches, in +order to remind users to redeem their asset or renew their subscription. +* The `+feed_url+` field enables notifications to be issued to asset +holders via RSS 2.0, for inclusion in a wallet news feed. +* An asset definition JSON can be embedded inside a web page by +`+\uXXXX+`-escaping the characters `+(+` `+)+` `+<+` `+>+` inside the +JSON, and inserting it into the code below. Using this encoding, the +JSON can be easily extracted from the raw HTML using a regular +expression (no DOM parsing) and will also be accessible to Javascript on +the page. + +.... -``` \ No newline at end of file +.... diff --git a/Process.adoc b/Process.adoc index 709f8b8..897b6ed 100644 --- a/Process.adoc +++ b/Process.adoc @@ -1,9 +1,22 @@ -This document describes the process of making changes to the Mastercoin spec. This process is it's very early stages, and is expected to change rapidly in the future (e.g. to include [Voting](https://bitcointalk.org/index.php?topic=309729.0)). The current Protocol Owner is J.R Willett. +This document describes the process of making changes to the Mastercoin +spec. This process is it’s very early stages, and is expected to change +rapidly in the future (e.g. to include +https://bitcointalk.org/index.php?topic=309729.0[Voting]). The current +Protocol Owner is J.R Willett. -Right now, there are two possible change mechanisms to the spec document: +Right now, there are two possible change mechanisms to the spec +document: -1. Developers can fork the repository, work on their own copy, push their proposed changes, and send a pull request accompanied with a post to bitcointalk. The Protocol Owner and the community reviews the changes, and when enough consensus has been generated, The Protocol Owner merges the changes back to the [parent repository on mastercoin-MSC](https://github.com/mastercoin-MSC/spec). - -2. Minor and/or non-breaking changes can be made directly on top of the mastercoin-MSC parent repository, by people who have push right to this repository. If you want to be included in this group, ask Willett. - -3. For sake of convenience, people who already have push access to the parent repository can work on branches instead of forks. This achieves the same purpose as option 1 above, in a manner that might be more convenient to some developers. +. Developers can fork the repository, work on their own copy, push their +proposed changes, and send a pull request accompanied with a post to +bitcointalk. The Protocol Owner and the community reviews the changes, +and when enough consensus has been generated, The Protocol Owner merges +the changes back to the https://github.com/mastercoin-MSC/spec[parent +repository on mastercoin-MSC]. +. Minor and/or non-breaking changes can be made directly on top of the +mastercoin-MSC parent repository, by people who have push right to this +repository. If you want to be included in this group, ask Willett. +. For sake of convenience, people who already have push access to the +parent repository can work on branches instead of forks. This achieves +the same purpose as option 1 above, in a manner that might be more +convenient to some developers. diff --git a/RoleBasedBounties.adoc b/RoleBasedBounties.adoc index b117286..eb43fe5 100644 --- a/RoleBasedBounties.adoc +++ b/RoleBasedBounties.adoc @@ -1,69 +1,129 @@ -Role Based Bounties -=================== +== Role Based Bounties -**Document Version: 0.6** +*Document Version: 0.6* -**Please update the version number whenever you update this document.** +*Please update the version number whenever you update this document.* -A role based bounty or RBB is the term we use for someone who receives an ongoing bounty for filling some role for the project. +A role based bounty or RBB is the term we use for someone who receives +an ongoing bounty for filling some role for the project. -This is the [DA](http://wiki.mastercoin.org/index.php/Decentralized_Application) equivalent of an employee in traditional companies. +This is the +http://wiki.mastercoin.org/index.php/Decentralized_Application[DA] +equivalent of an employee in traditional companies. -Right now the Mastercoin Foundation is managing RBBs, but management of RBBs will move over to the protocol Proof of Stake voting as soon as that's implemented. +Right now the Mastercoin Foundation is managing RBBs, but management of +RBBs will move over to the protocol Proof of Stake voting as soon as +that’s implemented. -The reason an RBB exists is to complement the traditional bounty system. We want to encourage people to work on the project full time, and even quit their day jobs, and for this they require some stability and predictability which the one-time bounty system doesn't really offer. +The reason an RBB exists is to complement the traditional bounty system. +We want to encourage people to work on the project full time, and even +quit their day jobs, and for this they require some stability and +predictability which the one-time bounty system doesn’t really offer. -# How it works right now +== How it works right now -* The Foundation decides to allocate a new Role Based Bounty, and they choose a person to fulfill that role. -* [The specific terms are on this Google Spreadsheet](https://docs.google.com/spreadsheet/ccc?key=0AosWigpBxkwZdHhBaUtTZV9MWUpMVWV6U3VJV1RPbmc&usp=sharing#gid=0). The current terms are all identical and include 6000 monthly USD (paid usually in bitcoin), and some number of Dev MSC depending on the relative amount of MSC distributed that month. This will change for future hires that come into the project at a later phase. +* The Foundation decides to allocate a new Role Based Bounty, and they +choose a person to fulfill that role. +* https://docs.google.com/spreadsheet/ccc?key=0AosWigpBxkwZdHhBaUtTZV9MWUpMVWV6U3VJV1RPbmc&usp=sharing#gid=0[The +specific terms are on this Google Spreadsheet]. The current terms are +all identical and include 6000 monthly USD (paid usually in bitcoin), +and some number of Dev MSC depending on the relative amount of MSC +distributed that month. This will change for future hires that come into +the project at a later phase. The following standard conditions apply to all RBBs: -* In addition to USD or BTC, each RBB also wins a proportional amount of the Dev MSCs. The amount they receive is proportional to the relative share of their USD or BTC allocation, out of all the Bounty BTC awarded that month. Dev MSC is released on a vesting schedule, currently described here: https://docs.google.com/document/d/1q6vuIPC7JSCiFKFTsXx24BvGhaXPKpNy2574XeqmAos/edit (should probably be moved to github) -* The payment schedule is monthly, usually via bitcoins (but we can pay via other means if needed e.g. wire transfer). -* The position is "at will", meaning both the Foundation and the RBB can terminate the RBB position without any reason. -* We do set a mutual 30 days notice period. Both the Foundation and the RBB are obligated not to terminate this RBB position without giving a 30 days notice. -* We generally intend to keep RBBs on for a long time, typically a year or more. However note that just like most jobs, this is not a contractual obligation given the items above. -* RBBs qualify to receive other outstanding bounties, however the amount awarded to them via the RBB position in a given month will be deducted from the total value of other bounties received that month. i.e. if a core developer contributes above and beyond and wins 10000 USD worth of bounties in a month, the 6000 USD from their RBB would subtracted from the award giving them 4000 USD in bounties and 6000 USD for the RBB for a total of 10000 USD. -* RBBs may manage teams, and the team may qualify for outstanding bounties. Each team's budget should be managed independently of the team lead's personal funds. - -# Signup bonus for C-Level positions -Any C-level hire (e.g. CEO/CTO/CMO) is entitled to a signup bonus. The purpose of the bonus is to properly reward such key members of the organization, and make sure they have an extra incentive to promote The Master Protocol. The bonus works as follows: - -1. In addition to the Role Based Bounties above, a C-Level position is entitled to $60,000 ($30,000 worth of BTC and $30,000 worth of MSC). -2. These amounts will be vested over a period of 12 months, via a quarterly vesting / pricing schedule, and a 6 month cliff. -3. At the 3 month mark, - a. $7,500 will be calculated in BTC and allocated to the RBB. - b. $7,500 will be calculated in MSC and allocated to the RBB. -4. At the 6 month mark, - a. $7,500 will be calculated in BTC and allocated to the RBB. - b. $7,500 will be calculated in MSC and allocated to the RBB. - c. All allocated BTC will be paid to RBB. -5. At the 9 month mark, - a. $7,500 will be calculated in BTC and allocated to the RBB. - b. $7,500 will be calculated in MSC and allocated to the RBB. - c. All allocated BTC will be paid to RBB. -6. Finally, at the 12 months mark, - a. an additional $15,000 will be allocated, and the entire bonus MSC pool and BTC pool will be transferred to the RBB. -7. We want to encourage key members of the Foundation to keep these MSC long term. For this purpose, The Mastercoin Foundation will keep these bonus MSC, and will send them to the RBB after the sooner of these two events: - 1. A year passes from their signup date, or - 2. The RBB quits or is let go. In this case, only the vested portion of their bonus will be sent, and the rest will be returned to the Mastercoin Foundation's budget. - -# Converting USD to MSC -For the purpose of this contract, sometime a dollar amount is payable via MSC (e.g. the Bonus for C-Level positions). - -Such calculations are made by using the spot price (best available data) on the day of allocation (The best price source is used - either a centralized exchange, the price on a decentralized exchange, or a combination of these, by our consideration.) - -# Hourly Bounties - -Some tasks are more suitable to be carried out by hourly "employees", rather than a full fledged Role Based Bounty. We term these Hourly Bounties. The way it works is: - -1. We approve a budget for the Hourly Bounty in the usual process (see the Voting Rules). A standard budget size can be 1,000-2,500 USD, but it can vary by task. -2. We use a standard uniform rate of 40 USD per hour. -3. The Hourly Bounty is expected to manage and report his budget and hours. If the hours run out before the task is completed, or it is an ongoing task, the Hourly Bounty is expected to ask the Foundation for an refill of his budget. -4. Like other bounties, the Hourly Bounty is entitled to Dev MSC, in accordance with the [Dev MSC distribution algorithm](https://github.com/mastercoin-MSC/spec#development-mastercoins-dev-msc-previously-reward-mastercoins) - -# The Future - -Like everything else, we will decentralize any central control to the RBB protocol. All of the above will be codified in a Proof of Stake voting system, and it will become part of the official Mastercoin spec. +* In addition to USD or BTC, each RBB also wins a proportional amount of +the Dev MSCs. The amount they receive is proportional to the relative +share of their USD or BTC allocation, out of all the Bounty BTC awarded +that month. Dev MSC is released on a vesting schedule, currently +described here: +https://docs.google.com/document/d/1q6vuIPC7JSCiFKFTsXx24BvGhaXPKpNy2574XeqmAos/edit +(should probably be moved to github) +* The payment schedule is monthly, usually via bitcoins (but we can pay +via other means if needed e.g. wire transfer). +* The position is "`at will`", meaning both the Foundation and the RBB +can terminate the RBB position without any reason. +* We do set a mutual 30 days notice period. Both the Foundation and the +RBB are obligated not to terminate this RBB position without giving a 30 +days notice. +* We generally intend to keep RBBs on for a long time, typically a year +or more. However note that just like most jobs, this is not a +contractual obligation given the items above. +* RBBs qualify to receive other outstanding bounties, however the amount +awarded to them via the RBB position in a given month will be deducted +from the total value of other bounties received that month. i.e. if a +core developer contributes above and beyond and wins 10000 USD worth of +bounties in a month, the 6000 USD from their RBB would subtracted from +the award giving them 4000 USD in bounties and 6000 USD for the RBB for +a total of 10000 USD. +* RBBs may manage teams, and the team may qualify for outstanding +bounties. Each team’s budget should be managed independently of the team +lead’s personal funds. + +== Signup bonus for C-Level positions + +Any C-level hire (e.g. CEO/CTO/CMO) is entitled to a signup bonus. The +purpose of the bonus is to properly reward such key members of the +organization, and make sure they have an extra incentive to promote The +Master Protocol. The bonus works as follows: + +. In addition to the Role Based Bounties above, a C-Level position is +entitled to $60,000 ($30,000 worth of BTC and $30,000 worth of MSC). +. These amounts will be vested over a period of 12 months, via a +quarterly vesting / pricing schedule, and a 6 month cliff. +. At the 3 month mark, a. $7,500 will be calculated in BTC and allocated +to the RBB. b. $7,500 will be calculated in MSC and allocated to the +RBB. +. At the 6 month mark, a. $7,500 will be calculated in BTC and allocated +to the RBB. b. $7,500 will be calculated in MSC and allocated to the +RBB. c. All allocated BTC will be paid to RBB. +. At the 9 month mark, a. $7,500 will be calculated in BTC and allocated +to the RBB. b. $7,500 will be calculated in MSC and allocated to the +RBB. c. All allocated BTC will be paid to RBB. +. Finally, at the 12 months mark, a. an additional $15,000 will be +allocated, and the entire bonus MSC pool and BTC pool will be +transferred to the RBB. +. We want to encourage key members of the Foundation to keep these MSC +long term. For this purpose, The Mastercoin Foundation will keep these +bonus MSC, and will send them to the RBB after the sooner of these two +events: +.. A year passes from their signup date, or +.. The RBB quits or is let go. In this case, only the vested portion of +their bonus will be sent, and the rest will be returned to the +Mastercoin Foundation’s budget. + +== Converting USD to MSC + +For the purpose of this contract, sometime a dollar amount is payable +via MSC (e.g. the Bonus for C-Level positions). + +Such calculations are made by using the spot price (best available data) +on the day of allocation (The best price source is used - either a +centralized exchange, the price on a decentralized exchange, or a +combination of these, by our consideration.) + +== Hourly Bounties + +Some tasks are more suitable to be carried out by hourly "`employees`", +rather than a full fledged Role Based Bounty. We term these Hourly +Bounties. The way it works is: + +. We approve a budget for the Hourly Bounty in the usual process (see +the Voting Rules). A standard budget size can be 1,000-2,500 USD, but it +can vary by task. +. We use a standard uniform rate of 40 USD per hour. +. The Hourly Bounty is expected to manage and report his budget and +hours. If the hours run out before the task is completed, or it is an +ongoing task, the Hourly Bounty is expected to ask the Foundation for an +refill of his budget. +. Like other bounties, the Hourly Bounty is entitled to Dev MSC, in +accordance with the +https://github.com/mastercoin-MSC/spec#development-mastercoins-dev-msc-previously-reward-mastercoins[Dev +MSC distribution algorithm] + +== The Future + +Like everything else, we will decentralize any central control to the +RBB protocol. All of the above will be codified in a Proof of Stake +voting system, and it will become part of the official Mastercoin spec. diff --git a/VotingRules.adoc b/VotingRules.adoc index 62758c8..f2f10b5 100644 --- a/VotingRules.adoc +++ b/VotingRules.adoc @@ -1,55 +1,111 @@ -## One time expenses ## -1. 1 Board member may spend up to $500 without consulting anybody -2. 2 Board members may agree to spend up to $1000, as long as there are no objections raised -3. 3 Board members may agree to spend up to $2500, as long as there are no objections raised -4. 4 Board members may agree to spend up to $5000, as long as there are no objections raised -5. 5 Board members may agree to spend up to $10000, as long as there are no objections raised -6. 6 Board members may agree to spend up to $25000, as long as there are no objections raised -7. The board must vote unanimously to spend more than $25000 +== One time expenses -## One time bounties ## -Bounties are treated like expenses, with 1 board member “discount”: +. 1 Board member may spend up to $500 without consulting anybody +. 2 Board members may agree to spend up to $1000, as long as there are +no objections raised +. 3 Board members may agree to spend up to $2500, as long as there are +no objections raised +. 4 Board members may agree to spend up to $5000, as long as there are +no objections raised +. 5 Board members may agree to spend up to $10000, as long as there are +no objections raised +. 6 Board members may agree to spend up to $25000, as long as there are +no objections raised +. The board must vote unanimously to spend more than $25000 -1. 1 board member can put a bounty of up to $500 -2. 2 board members can put a bounty of up to $1000, as long as no objections are raised -3. 3 board members can put a bounty of up to $2000, as long as no objections are raised -4. And so forth… +== One time bounties -(Note that this is just a copy-paste of the normal Voting Rules tab, with 1 less board member per line). +Bounties are treated like expenses, with 1 board member "`discount`": -The Executive Director has the voting power of 2 board members for the purpose of approving one time bounties. +. 1 board member can put a bounty of up to $500 +. 2 board members can put a bounty of up to $1000, as long as no +objections are raised +. 3 board members can put a bounty of up to $2000, as long as no +objections are raised +. And so forth… -## Hire process for Role Based Bounties ## -1. Any board member can nominate an RBB -2. If 3 other board members support this nomination AND no board member formally objects AND 48 hours from the moment the RBB was nominated, the RBB is hired. -3. If anyone objects OR we fail to reach a total of 4 supporting board members, the discussion continues until the objections are met. +(Note that this is just a copy-paste of the normal Voting Rules tab, +with 1 less board member per line). -## Monthly Budget ## -At any one time, the monthly expenses that the Foundation is committed to AKA "burn rate" will not go over 75,000 USD (see our [actual burn rate](https://docs.google.com/spreadsheet/ccc?key=0AtCyUJvk_IyNdGpVcnpBN2tOczFmbVRnck5TWjZuRFE&usp=sharing#gid=8) and [proposed budget](https://docs.google.com/spreadsheet/ccc?key=0AtCyUJvk_IyNdGpVcnpBN2tOczFmbVRnck5TWjZuRFE&usp=sharing#gid=3)). +The Executive Director has the voting power of 2 board members for the +purpose of approving one time bounties. -## Recurring expenses ## -1. If the total sum of the recurrences fits under a specific voting rule for one-time expenses, then this number of board members can approve it. E.g. 3 board members can approve a monthly recurring $150 expense for 6 months. -2. It takes one more board member than usual to approve a recurring monthly expense. E.g. 6 members members can approve a monthly expense of up to $5000 (it takes 5 board members to approve a one time expense of up to $5000). +== Hire process for Role Based Bounties -## Discretionary Funds ## -The board may approve a member (such as the Executive Director) to have a larger pool of discretionary funds by unanimous vote +. Any board member can nominate an RBB +. If 3 other board members support this nomination AND no board member +formally objects AND 48 hours from the moment the RBB was nominated, the +RBB is hired. +. If anyone objects OR we fail to reach a total of 4 supporting board +members, the discussion continues until the objections are met. -## Executive Director Spending ## -1. The Executive Director is allowed to make any single expense of up to $15,000. This includes actual expenses, one time bounties, limited hourly bounties and time-limited role-based bounties or recurring expenses (e.g. $3,000 per month for 3 months). -2. The Executive Director is entitled to approve any number of unrelated expenses, each up to $10,000. -3. Direct expenses made by the Executive Director will be reported via the Executive Director ledger. Expenses will be reported to expenses@mastercoin.org. -4. Bounties and other delayed expenses may be paid by the Executive Director directly, or by the treasurers. Normal reporting rules apply (each person reports his direct expenses). -5. For large expenses, the Executive Director is expected to consult with the board and give some time for consideration. This is not a strict requirement, depending on the expense size, urgency, and availability of board members. +== Monthly Budget -## Objections ## -If an objection is raised, time must be allowed for discussion, and all members must vote if there is still disagreement after discussion. Under no conditions will more than $20k be spent over the objection of any board member. +At any one time, the monthly expenses that the Foundation is committed +to AKA "`burn rate`" will not go over 75,000 USD (see our +https://docs.google.com/spreadsheet/ccc?key=0AtCyUJvk_IyNdGpVcnpBN2tOczFmbVRnck5TWjZuRFE&usp=sharing#gid=8[actual +burn rate] and +https://docs.google.com/spreadsheet/ccc?key=0AtCyUJvk_IyNdGpVcnpBN2tOczFmbVRnck5TWjZuRFE&usp=sharing#gid=3[proposed +budget]). -## Change of these rules and composition of the board ## -1. A unanimous vote is required to change these rules, or to change the composition of the board +== Recurring expenses -## Quorum -1. A Quorum is defined as 2/3 of the board members, rounded up. E.g. with 7 board members, a Quorum is any 5 board members. -2. During a board meeting that has been announced with ample notification of at least 10 days, a Quorum of board members with no objections is sufficient to make any decisions, including ones that normally require all board members. If there are any objections, they must be resolved for the Quorum to be in effect. +. If the total sum of the recurrences fits under a specific voting rule +for one-time expenses, then this number of board members can approve it. +E.g. 3 board members can approve a monthly recurring $150 expense for 6 +months. +. It takes one more board member than usual to approve a recurring +monthly expense. E.g. 6 members members can approve a monthly expense of +up to $5000 (it takes 5 board members to approve a one time expense of +up to $5000). -## Documentation of expenses ## -ALL expenditures must be itemized in our public-facing budget spreadsheet (or equivalent) \ No newline at end of file +== Discretionary Funds + +The board may approve a member (such as the Executive Director) to have +a larger pool of discretionary funds by unanimous vote + +== Executive Director Spending + +. The Executive Director is allowed to make any single expense of up to +$15,000. This includes actual expenses, one time bounties, limited +hourly bounties and time-limited role-based bounties or recurring +expenses (e.g. $3,000 per month for 3 months). +. The Executive Director is entitled to approve any number of unrelated +expenses, each up to $10,000. +. Direct expenses made by the Executive Director will be reported via +the Executive Director ledger. Expenses will be reported to +expenses@mastercoin.org. +. Bounties and other delayed expenses may be paid by the Executive +Director directly, or by the treasurers. Normal reporting rules apply +(each person reports his direct expenses). +. For large expenses, the Executive Director is expected to consult with +the board and give some time for consideration. This is not a strict +requirement, depending on the expense size, urgency, and availability of +board members. + +== Objections + +If an objection is raised, time must be allowed for discussion, and all +members must vote if there is still disagreement after discussion. Under +no conditions will more than $20k be spent over the objection of any +board member. + +== Change of these rules and composition of the board + +. A unanimous vote is required to change these rules, or to change the +composition of the board + +== Quorum + +. A Quorum is defined as 2/3 of the board members, rounded up. E.g. with +7 board members, a Quorum is any 5 board members. +. During a board meeting that has been announced with ample notification +of at least 10 days, a Quorum of board members with no objections is +sufficient to make any decisions, including ones that normally require +all board members. If there are any objections, they must be resolved +for the Quorum to be in effect. + +== Documentation of expenses + +ALL expenditures must be itemized in our public-facing budget +spreadsheet (or equivalent) diff --git a/WhyMastercoinsHaveValue.adoc b/WhyMastercoinsHaveValue.adoc index 5000f54..b53096b 100644 --- a/WhyMastercoinsHaveValue.adoc +++ b/WhyMastercoinsHaveValue.adoc @@ -1,53 +1,84 @@ This document is collaboratively edited. Pull requests welcome. -Why Mastercoins Have Value -============ - -It’s worth addressing the specific use case which is the poster-child for App Coins, Mastercoin. It’s the first major project to use this model, and arguably the most well-known. - -From the very beginning, the Mastercoin model hasou always been “build useful features on top of Bitcoin, and make each feature use mastercoins in some way”. For mastercoins to have value, the following two conditions must be true: - -1. The Master Protocol must be used. -2. The features that make Master Protocol useful are enabled by Mastercoin. - -If people need mastercoins, they will have value. The value of mastercoins is therefore expected to have a direct correlation to how useful the Master Protocol is, and also to how well each feature fulfills the promise of using mastercoins. - -Following is a high level overview of each Master Protocol feature in [our spec](https://github.com/mastercoin-MSC/spec/blob/master/README.md), and how each feature uses mastercoins (some features described below are not implemented yet): - -1. User-created coins/tokens and distributed exchange -..1. Can optionally use mastercoins for fundraising -..2. Every user coin trades against Mastercoin on the distributed exchange* -..3. Mastercoin is the only exit to bitcoin using the distributed exchange. This means if you have a user coin and want Bitcoin, you must either get a centralized exchange to list your coin, or use Mastercoin -..4. Properties may be promoted (get preferential placement) in Mastercoin client default listings by burning Mastercoins -2. Betting and data-feeds (uncensorable betting on anything imaginable) -..1. Mastercoin, as the “currency of the realm” is the currency for placing bets* -3. Distributed e-commerce (decentralized eBay) -..1. Mastercoin, as the “currency of the realm” is the currency for buying and selling physical goods* -..2. Certain amounts of Mastercoin are burned by the reputation/feedback system -4. Security features (savings addresses, rate limited addresses) -..1. Apply to all Mastercoin-derived currency and not just Mastercoin, but contribute to the overall utility of the ecosystem -5. Pegged currencies (coins which maintain stable values due to a protocol-managed escrow fund) -..1. Holding mastercoins in escrow to back pegged currencies will have the effect of removing certain amounts of MSC from circulation, thus increasing the competition for the remaining MSC which is in active circulation for other features. - -*To the extent other currencies are allowed in these roles, there may be a small fee, burning a small amount of Mastercoin. +== Why Mastercoins Have Value + +It’s worth addressing the specific use case which is the poster-child +for App Coins, Mastercoin. It’s the first major project to use this +model, and arguably the most well-known. + +From the very beginning, the Mastercoin model hasou always been "`build +useful features on top of Bitcoin, and make each feature use mastercoins +in some way`". For mastercoins to have value, the following two +conditions must be true: + +. The Master Protocol must be used. +. The features that make Master Protocol useful are enabled by +Mastercoin. + +If people need mastercoins, they will have value. The value of +mastercoins is therefore expected to have a direct correlation to how +useful the Master Protocol is, and also to how well each feature +fulfills the promise of using mastercoins. + +Following is a high level overview of each Master Protocol feature in +https://github.com/mastercoin-MSC/spec/blob/master/README.md[our spec], +and how each feature uses mastercoins (some features described below are +not implemented yet): + +. User-created coins/tokens and distributed exchange ..1. Can optionally +use mastercoins for fundraising ..2. Every user coin trades against +Mastercoin on the distributed exchange* ..3. Mastercoin is the only exit +to bitcoin using the distributed exchange. This means if you have a user +coin and want Bitcoin, you must either get a centralized exchange to +list your coin, or use Mastercoin ..4. Properties may be promoted (get +preferential placement) in Mastercoin client default listings by burning +Mastercoins +. Betting and data-feeds (uncensorable betting on anything imaginable) +..1. Mastercoin, as the "`currency of the realm`" is the currency for +placing bets* +. Distributed e-commerce (decentralized eBay) ..1. Mastercoin, as the +"`currency of the realm`" is the currency for buying and selling +physical goods* ..2. Certain amounts of Mastercoin are burned by the +reputation/feedback system +. Security features (savings addresses, rate limited addresses) ..1. +Apply to all Mastercoin-derived currency and not just Mastercoin, but +contribute to the overall utility of the ecosystem +. Pegged currencies (coins which maintain stable values due to a +protocol-managed escrow fund) ..1. Holding mastercoins in escrow to back +pegged currencies will have the effect of removing certain amounts of +MSC from circulation, thus increasing the competition for the remaining +MSC which is in active circulation for other features. + +*To the extent other currencies are allowed in these roles, there may be +a small fee, burning a small amount of Mastercoin. Why Mastercoin Will Have Value -Let’s focus mainly on how mastercoins are needed because Mastercoin is implementing features that Bitcoin just doesn't have, and to implement those features you *must* have a unit of account available. - -** Properties may be promoted (get preferential placement) in Mastercoin client default listings by burning Mastercoins +Let’s focus mainly on how mastercoins are needed because Mastercoin is +implementing features that Bitcoin just doesn’t have, and to implement +those features you _must_ have a unit of account available. -This sounds like the Twister (3) proof-of-work incentive - promoted tweets - and again I see no reason why we wouldn't see clients just turn the promotions off for being spam. +** Properties may be promoted (get preferential placement) in Mastercoin +client default listings by burning Mastercoins -** Distributed e-commerce (uncensorable e-bay) -I'd take this out; I can't see any reason why OpenBazaar won't do this better than Master coin using just direct person-to-person Bitcoin payments. +This sounds like the Twister (3) proof-of-work incentive - promoted +tweets - and again I see no reason why we wouldn’t see clients just turn +the promotions off for being spam. -** Datastreams -It's worth pointing out that because the Mastercoin decentralized exchange is public the exchange itself can be an honest and accurate source of pricing information.(4) Unlike Colored Coins this exchange can be automatically acted upon by Mastercoin transactions. (though equally hybrid systems can do this in an auditable way, see below) +** Distributed e-commerce (uncensorable e-bay) I’d take this out; I +can’t see any reason why OpenBazaar won’t do this better than Master +coin using just direct person-to-person Bitcoin payments. +** Datastreams It’s worth pointing out that because the Mastercoin +decentralized exchange is public the exchange itself can be an honest +and accurate source of pricing information.(4) Unlike Colored Coins this +exchange can be automatically acted upon by Mastercoin transactions. +(though equally hybrid systems can do this in an auditable way, see +below) -See also -======== +== See also -1. [Why Appcoins Have Value](https://github.com/DavidJohnstonCEO/TheValueofAppCoins) -2. [Mastercoin is for Burning](http://blog.mastercoin.org/2014/06/11/mastercoin-is-for-burning/) +. https://github.com/DavidJohnstonCEO/TheValueofAppCoins[Why Appcoins +Have Value] +. http://blog.mastercoin.org/2014/06/11/mastercoin-is-for-burning/[Mastercoin +is for Burning]