PIP-0011: 20% Developer Reward

PIP/PIP-0011.md

@@ -0,0 +1,74 @@
+<pre>
+  PIP: PIP-0011
+  Title: 20% Developer Reward
+  Type: Protocol
+  Impact: Hard-Fork
+  Author: Herman Schoenfeld <i>&lt;[email protected]&gt;</i>
+  Comments-URI: https://discord.gg/sJqcgtD  (channel #pip-0011)
+  Status: Proposed
+  Created: 2018-01-02
+</pre>
+
+## Summary
+
+It is proposed that 20% of the block-reward be portioned and allocated to the developers for the purposes of rapidly delivering the roadmap and supporting the project at large. The funding can be used for layer-1 protocol development, layer-2 development, anonymity R&D and implementation, marketing, infrastructure support and exchange listings. In practice, budgets will be proposed by and voted on by the community itself.
+
+## Motivation
+
+With the recent addition of well-funded ICOs into the cryptocurrency sector, it has become necessary to rely on commercial time and material in order to realistically compete for adoption. By introducing a developer reward, funds can be provisioned for all aspects of the PascalCoin project including much needed exchange listings. This concept has already been successfully pioneered by other cryptocurrencies such DASH and DCR and is expected to significantly boost the current PascalCoin ecosystem size and value. As a result, even though miners will earn 20% less, the capital gain of the remaining 80% is expected to exponentially exceed the value they would otherwise have, which is fair compensation. Another major benefit is the ability for the developers to dispense accounts to new users in order to facilitate smooth adoption.
+
+## Specification
+
+PascalCoin block rewards comprise of 5 new accounts awarded to the miner with the first containing the PASC reward. It is proposed that account 5 be instead awarded to the developers, and the PASC reward be split 80% - 20% respectively.
+
+### SafeBox transaction rule change
+
+In the current protocol, when PascalCoin encounters a valid block X, a corresponding Account Segment X is appended to the SafeBox structured as follows:
+
+**Account Segment X**
+```
+[Header]
+[Account No: X+0, Key: Block.MinerKey, Balance: BLOCKREWARD]
+[Account No: X+1, Key: Block.MinerKey, Balance: 0]
+[Account No: X+2, Key: Block.MinerKey, Balance: 0]
+[Account No: X+3, Key: Block.MinerKey, Balance: 0]
+[Account No: X+4, Key: Block.MinerKey, Balance: 0]
+```
+
+It is proposed that after activation, Account Segments be structured as follows:
+
+**Account Segment X**
+```
+[Header]
+[Account No: X+0, Key: Block.MinerKey, Balance: ROUND(BLOCKREWARD * 0.8, 4-decimal-places)]
+[Account No: X+1, Key: Block.MinerKey, Balance: 0]
+[Account No: X+2, Key: Block.MinerKey, Balance: 0]
+[Account No: X+3, Key: Block.MinerKey, Balance: 0]
+[Account No: X+4, Key: SafeBox.Account[0].Key, Balance: ROUND(BLOCKREWARD * 0.2, 4-decimal-places)]
+```
+
+**NOTE**: the developer key is simply attained by copying the key from account ```0-10```.
+
+No other changes are required. 
+
+## Social Contract
+
+As part of this proposal, the developers are committed to openness and engagement with the community with respect to allocation of these funds. During a financial quarter, the following work-flow will be executed:
+1. Developers (and community) propose budgets at any time during the quarter
+2. Users vote on budget proposals at any time during the quarter
+3. On first day of the next quarter, the current majority-voted budget is adopted for the quarter
+4. Goto 1
+
+Users will be able to vote on proposals by simply changing their Account.Type to the corresponding budget number. The total PASC and PASA will be tallied as follows:
+```
+1 PASC = 1 VOTE
+1 PASA = 5 VOTES
+```
+
+## Rationale
+
+Other developer reward approaches were considered but deemed undesirable since the proposed approach is the simplest and most elegant. For example, it is possible to hard-code the developer key instead of copying it from 0-10, but this introduces high-risk attack vectors. By copying the key, developers can ensure cold-wallet security at all times. Also, the reward mechanism could have been a new Operation type, but this would require much more development which adds hard-fork risk, for little gain. The current approach is easy and low-impact since it technically does not require new consensus rules. Consensus is achieved simply by the fact that if a node does not implement the above rule, it's subsequent SafeBox hash will be totally out-of-consensus with the majority network.
+
+## Backwards Compatibility
+
+This proposal is not backwards compatible and requires a hard-fork activation.

PIP/README.md

@@ -17,4 +17,5 @@ If they wish to continue, copy [this template](PIP-template.md) and ensure your
 | [8](PIP-0008.md)      | Hook(s) to start external programs       | Preben Björn Biermann Madsen   | Backend        | Draft    |
 | [9](PIP-0009.md)      | RandomHash: GPU & ASIC Resistant Hash Algorithm | Herman Schoenfeld       | Protocol       | Proposed |
 | [10](PIP-0010.md)     | 50% Inflation Reduction                  | Herman Schoenfeld              | Protocol       | Proposed |
+| [11](PIP-0011.md)     | 20% Developer Reward                     | Herman Schoenfeld              | Protocol       | Proposed |