@oeytng Thank you for your articulate and insightful response. I’d like to offer a more detailed analysis than my “back of a napkin”/“back of the envelope” list quickly hashed out before.
The biggest issue I’ve had with this RFC is the seemingly haphazard way that the initial allocations were reformulated, the way “royalties” were described (horrible term) compared to “developer rewards” or “developer pool”, and what appears to be a vast increase in the role and power wielded by a foundation. I thought to myself, “Have a few years worth of forum discussions made me think that SAFE is something it was never intended to be?” In light of the current RFC I picked through the original whitepaper again to see if I had missed something before. There were a lot of good ideas in that original whitepaper! But there were also stipulations, uncertainties, and some vague aspects that were good to refresh myself with. Here are a few things I’d like to highlight from the original whitepaper:
" This project is simply the beginning of a new Internet, one that we all own and nobody controls, this is the “Internet sans frontieres!” The MaidSafe Foundation will be a key player in this proposal and exists to ensure fair distribution of wealth, while helping to foster education and innovation."
A new internet, hurrah - but the foundation role should be no surprise as a potential fly in the ointment if not given the proper role… It’s been part of the picture since day one. Thinking back, I suppose this was less of a concern the first time I read the whitepaper, thinking at the time that the charity/foundation’s role of was smaller, and seeing that it had rather noble intentions compared to other offerings in the crypto space. Recent discussions have somewhat indicated the opposite, increasing foundation roles/power in a way that weakens the network. So there was a disconnect here when considering RFC0061 that leaves a bad taste.
"This paper demonstrates the creation of a fixed number of coins over time 2^32 (~4 billion), which can be further subdivided to facilitate trading. "
“Safecoin issuance will be capped at 2^32 (4.3 billion)…”
“The data structure of such can be illustrated as … The fifth part indicates the level of subdivision of the original token, i.e. it contains the value of x. This format allows the tokens to be split into 2^248 parts if required.”
There it is, stated at least two times. The safe network will have a 2^32 hardcap, period, period. Some level of divisibility was intended up to a max of 2^248. There could be less tokens available due to burning or loss, but never more than 2^32. This is something that the current RFC has violated and should be corrected.
“The crowd sale will enable a direct purchase up to ten percent of MaidSafeCoin. These crowd sale participants will be buying MaidSafeCoin, an intermediary coin that will be swapped on a 1:1 ratio for safecoin once the full SAFE network is launched.”
Opps, technical error happened and a few more than 10% were sold. That’s not the fault of the participants. That also doesn’t mean you can change the hardcap willy nilly. The hardcap and the 1:1 exchange takes precedence, and the % is recalculated based on the amount sold relative to 2^32 total coins.
MaidSafe will allocate 30% of the tokens on day 1.
Up to 10% will be available for purchase via the crowd sale, 5% for the existing MaidSafe investors, 5% for the SAFE core development team and 10% for the general developer pool.
So here were the promised outlays. This equates to the following amounts:
- MaidSafe Shareholdings/Investors = 214,748,365
- Core Safe Network Development Team = 214,748,365
- MaidSafeCoin = 429,496,730
- Developer Pool = 429,496,730
- Total Remaining implicitly available for Resources Rewards = 3006477106
So now we deal with “the conundrum.” A technical error occurred during MaidSafe’s crowdsale and a total of supply of MaidSafeCoin is now 452,552,412. That is a difference of 23055682 tokens, which is only about 0.537% of the 2^32 hardcap. It really doesn’t make any sense to even consider changing the hardcap**, and the remaing ratios relative to the hardcap, or divisility etc., to adjust for the glitch in the manner that was proposed in this RFC0061! - full stop.
@JimCollinson, @dirvine - The simplest solution here is that instead of exactly 30% of the coins being allocated on day 1, there will actually be approximately 30.537% allocated. This does not change percentage of total token supply promised to core developers and non-core developers, nor does it change what was promised to MaidSafe investors. There was never a promise that ALL remaining tokens would be issued to farmers, just that there would be a hard cap of 2^32. KISS. Problem solved.
“15% of all safecoin earned will be allocated to the developer pool. This will ensure the developer community is highly motivated and rewarded for providing free-to-use applications”
“It is possible that 10% of these coins maybe recycled if a an idea of automated developer awards comes to fruition.”
“5% of the developer pool coins will be given to the core developement team.”
Here is a detail I overlooked before. The core development team will not get 5% of total earnings/farming rewards issued. Instead it’s 5% of the 15% set for the developer pool = 0.75%. If we review the math, that means there is a missing 4.75% of earnings in the developer pool are free to be used for something else. Is this where Pt* comes in? Is this just an administration or “governance” fee taken by the foundation? That’s a quite large administration fee, yikes! There is too much left to the imagination here, the vague wording needs to be corrected.
The MaidSafe Foundation will initially:
• Hold and distribute safecoin for developer pools
• Manage issuance of MaidSafeCoin to funders and existing investors
• Hold all patents and use safecoin to pay for the upkeep and further patents for all projects (until this sphere cannot be litigated against, the MaidSafe Foundation will act as the holder of defensive patents, of which there is already a considerable worldwide portfolio, to protect the decentralised Internet).
• House the MaidSafe team in an HQ and provide funding for independent development pods, worldwide
• Provide finances for the core team and development pods for a period of at least three years
No further actions can be taken by the Foundation, unless the authority is requested by the community to add additional objectives to this list
The original plan for the foundation specified interesting roles. Can the community ask that the foundation have certain objectives removed?
Presumably the MaidSafe Foundation roles will be dissolved or absorbed by the Safe Network Foundation. What’s not clear in the original proposal is how the foundation will be funded (by private donations or through implied administration fees taken in SNT). Up to now I had always presumed that the foundation finances would not be mingled with the developer pools in any way and it would be funded through donations just like any other foundation. That would be a preferred approach. Non-profit foundations usually rely on endowments, and donations. This is better than network “royalties”. The Bamboo Garden fund is a good example of how the foundation would likely receive large donations that could be made part of an endowment to fund operating costs.
This group will ensure the correctness of the coin issuance and also that every project that is applicable is included in the polling system for funding of that project. The board can put forward their suggestions and conclusions for any funding for projects. The assurance of developer rewards will also be continuously-monitored and managed. This mandate will be kept as minimal as possible to prevent unfair or ill considered decision making.
So yeah, perhaps willfull blindness on my part when I read this the first time. MaidSafe was transparent in their original intention to use a foundation and a board to manage the developer rewards. This is a very practical approach for just getting the network launched, but imo it is not ideal long term and adds a huge attack surface to the network. It would be better if that function could be eliminated. Imo instead of having only a goal of partial automated reward disbursal from the developer pool, all rewards would be automated. This may not be possible for core developer rewards, but the goal should be to minimize the role of the foundation in token distribution after the initial genesis supply is introduced. If there is also a way to eliminate the need for it to issue genesis tokens, all the better. This leaves the foundation to pursue other aims related to educational outreach, hackathons, developer outreach, marketing, patent and trademark protection, legal issues, fund lobbyists, normal non-profit corporate activities and all the “human” related aspirations, benevolence, malevolence, and deficiencies that go along with that, that are by design not directly tied to network functions in any way. This functional partition between in-network and out-of-network roles is important to long term success imo.