This is not what you are doing, the current Network economy consists of shareholders and MAID holders. Selling the extra slice diluted these two groups.
Nobody paid for the extra funding apart from shareholders and MAID holders.
The cost of continuing to make the network, fell onto shareholders and MAID holders. Without those two groups Royalty Pool and Nodes would have nothing.
So why are you giving extra to Royalty Pool and Nodes when they did not pay for the additional funding?
By rewarding the two groups that paid to continue the development of this network. Not diluting them by an additional 8 times the “additional fundraiser”!
but those that paid for the extra funding were compensated with extra tokens … so what have we lost? I feel like I’m missing something here.
It appears to me that under the 2^32 we stakeholders would have gained more than we were promised (concentrated not diluted), and now this change to total supply brings us back to the original promised percentages.
Certainly would be nice to have more, but I’d rather not have people watching the project say, “well there ya go, maidsafe is rigging the percentages to favor their stakeholders - just like so many other shitcoins have done” … readjusting total supply seems to be a way to keep things inline with original promised percentages.
So if MAID should be 10% and they sold and extra 0.36% then the shareholders (which is half the size of MAID) should be compensated 0.18% for the additional sale.
Why in this transaction do we need to create 9.5 more copies of the “additional funding”. The funds where already raised on the sale. The additional 9.5 copies is just inflation that hurts the people that bought into the shares, crowdsale, and additional funding.
When they multiply by 10, its money printing.
The other groups Royalty Pool and Nodes, pay by the fact their pool is smaller, they should not be rewarded because additional funding was required.
I am unaware of any legal need, but I’ve made a couple of points on why it’s maybe good.
Total marketcap is going to be whatever it’s going to be … but anything that may cause damage to the reputation of the project may reduce marketcap. So even if we stakeholders are getting less a percentage in this deal, we may end up with more value if the project’s reputation is clean looking. After all this adjustment appears to benefit future users not stakeholders and that’s good for our reputation longer term.
edit: also just to remind, most of all of these tokens aren’t even going to be minted for years and possibly decades to come. So this also makes this whole debate rather nebulous to my mind.
How much are we really losing in the short run or the long run … seems both complicated ( and too trivial in value ) to ponder.
As a long time maid holder, I don’t feel that I’m being punished at all. As an investor in general, when I buy into a high risk startup I expect there is a very high chance that I’ll lose it all - and even then I wouldn’t think I’d been punished. It’s all a gamble. I kicked the tires well, made my bet and rolled the dice - I wasn’t forced into it.
I expected to get a certain percentage and I am. What value I get out of it in return in the end though is still a mystery.
I know I’m not answering your point of fairness. Just to say that fairness, like everything else, is subjective.
I did buy in shortly after the crowd sale and not during it though … so I knew about the extra bit sold and hence I knew that such might change things down the track - part of kicking the tires before buying. But for someone who did buy in the crowd sale I suppose that might feel a bit unfair … but only a bit IMO and who knows how this cake will turn out when fully baked anyway. This one change to the total supply could end up being a good thing for the project for one reason or another.
I’m with the bakery on this one let the tin be a touch larger and be greatful that there was a little slice to sell when the bakery needed to keep the lights on.
I’m with the bakery on this one let the tin be a touch larger and be greatful that there was a little slice to sell when the bakery needed to keep the lights on.
Man, I am always sad when I see folk slevering over what might be a few bits of silver, or perhaps only tin.
You are saying maidsafe shareholders are damaged, but maidsafe took something. But maidsafe is the shareholders.
Then you say maidsafe have printed coins or something as though maidsafe is this other kinda large entity.
So to be clear, maidsafe that we all know here, are a bunch of developers and helpers who are trying to launch this network. They don’t get coins, they get paid a salary or volunteer, either way, none of that group are chasing big wages. Some have and they are gone.
So this maidsafe you are stamping as some kind of evil is misleading. So let’s say you mean us, the group of folk that are employed by maidsafe, not owners or controllers, but employees. As employees they stand ot benefit a sum total of £0 from however many coins go to whoever many groups as none go to the employees.
Caviat that a little as I gave up my shares to the employees so they will get a share of the shareholder payments as they are shareholders in that sense, albeit small.
So the group of maidsafe staff have no “skin in the game” in terms of employees getting coins at all, regardless how the cake is split up.
**
Sorry for long ramble, but somebody seems to be accusing somebody else of some kind of trickery and it’s unclear
who is being accused
What would they gain
So perhaps if you can outline that it would help?
If it’s something else then please outline that in simple terms,
I try not to look at the cash side too much, as you all know, but I do realise its importance, just like I don’t think too much about the constituent components of air. It does not mean I don’t wish to breath, just like it does not mean I don’t want a strong economic story for Safe. i.e. those on cash-high horses need not lecture me on the importance of the economy
I don’t think anyone was being accused of trickery. I suspect some had certain ideals in their mind and when that didn’t come to pass they were frustrated with the decision that’s being made and just wanted to talk it out.
We’ve been doing that and hopefully things are working themselves out.
I don’t think this is fair to the builders of the network (so called “employees”). The people who worked nights, long hours, devised clever solutions, etc. should be rewarded beyond mere salaries.
It’s kind of ironic to talk about setting aside a large portion (same as maid and investors put together from genesis and then a perpetual royalty tax) for the purpose of paying for the network’s upkeep in part, and yet those who actually made the original network feasible don’t get much? Very strange.
And a bit (lot?) of damned if you do and damned if you don’t
It does mean that the developers are not developing for token profits but for the network itself and getting paid for their time. Long term this seems to provide a more demonstrated ethical development so that decisions are not made for individual profits/benefits.
The workers/developers are still at liberty to privately purchase MAID like anyone else.
The following is a more detailed review of the updated RFC 0061 that further explains prior criticisms offered in this thread and others. Rather than provide a complete and formal RFC 0061A at the start, I thought it would be more effective to highlight differences in logic or opinion first. After going through this process, my plan was to create another thread that contains a complete RFC 0061A revision candidate for consideration. My expectation is that before posting any comments, other people will read through this review with as much a critical eye as I had when reviewing RFC 0061 itself.
This statement is completely untenable. It is at direct odds with the core token system proposed in the original Project Safe whitepaper. The founding public document proposed a “token-based scheme” which would ensure that Safe Network computational resources were efficiently utilized in an autonomous manner while also ensuring all stakeholder groups contributing resources were compensated in a manner that was fair and equitable. The proposal stated that the network token (called “safecoin” at the time, later renamed to SNT due to lack of adequate trademark protection or other reasons) " will have a predictable cap (2^32)."
A rose by any other name is still a rose, but numbers are more important than names in this scenario. So yes @JimCollinson , you did break “the first law of crypto” here. After so many years of 2^32 mantra it’s part of the project’s DNA. There is a logical inconsistency here when one thinks that a promised and long considered hardcap can be so trivially changed. Some other points to consider:
If this is the outcome it means that there was never a hardcap to begin with, and the original statement was a lie. This is a problem and leads to a scenario where trust is broken. One can’t expect to change the project’s hardcap and not expect harsh criticism far into the future. What other core network principles will change?
The history of the project needs to demonstrate evidence that promises made were promises kept.
While it is expected that some implementation details may vary over time as required for the success of the project vision, the one thing that cannot change is the the total token cap. Since it is an a priori logical constraint by definition, and it was what everyone signed up for.
Changing the hardcap also means that the promise of 1:1 exchange equivalent value between MAID and SNT is broken. This RFC Based on publications to date the minimum possible exchange rate was 1 MAID = 1/(2^32) of total SNT supply. This RFC changes that to 1 MAID = 1/(4,525,524,120). This is not as a trivial change and one can’t just ignore the difference.
Minor suggestion here, but also important to consider imo. The level of divisibility first described to in the whitepaper was 2^248. Other discussions on the forum have ranged all over the map. I understand the intent here was to offer some reasonable level of divisibility that is easy to grok for a general layperson without making it too difficult to implement. That being said, my view is that this number should be increased to a trillion (1e12). This should be done for three reasons:
This increased level of difficulty is the largest number that a layperson can grok. (ie. “layperson: I can break these into a trilion!”, “sciencey crypto geek: each subunit represents a picoSNT”).
The extra three orders of magnitude offers enough extra headroom for micro transactions or other uses that will push any need to offer additional divisibility much farther into the future, if ever. From an economic perspective, all but catastrophic change to the total global money over the next 100 years under a highly inflationary (but not super-hyperinflationary) world economy for fiat can more easily be accommodated.
The change from 1E9 subunits to 1E12 subuinits appears trivial from a code perspective.
This is where the problem I’ve raised about the hardcap is most easily solved. Here, “fullfil its objectives” should include fixing the original discrepency between the intended amount of MAID originally created (10% of 2^32) vs. the actual amount of MAID obligation created (4,525,524,120). This means that the foundation should/shall/will pay the difference out of it’s share of the genesis supply.
The 30% of maximum supply matches the original whitepaper. But the genesis allocation should be 30% of 2^32 so that the hardcap stated in the whitepaper remains unchanged. Rounding down this equates to 1288490188 whole tokens.
Again, the details and wording are important here. The perspective should be that by keeping the hardcap at 2^32, the original intent of swapping MAID for SNT at 1:1 is fullfilled at the same relative network value. Rounding down this equates to 429,496,729 SNT. The difference between total MAID+eMAID obligation and this number (452,552,412 - 429,496,729 = 23,055,683) should be taken from the foundation’s Network Royalties Pool to correct the technical error which occurred in 2014 that caused a slightly greater obligation than originally intended.
Again, keeping the hardcap at 2^32, 5% of total supply equates to 214,748,364 whole SNT. I believe this works out to each company share representing roughly 105.822193707 SNT (2029332 shares divided into 214,748,364 whole SNT). Simple math here.
There are three main issues I see in this section:
Again, you should maintain the hardcap at 2^32, and take the 15% of maximum supply (rounding down) to yield 644,245,094 whole SNT dedicated to the pool. Again, out of this initial allocation the foundation will make an “ad hoc” payment to cover and correct the difference between total MAID+eMAID obligation and the originally intended total MAID obligation. This ad hoc correction equates to 23,055,683 SNT relative to a maximum possible hardcap of 2^32 = 4,294,967,296.
There is a problem with the way you have eliminated the distinction between core development and general development. Section 10 of the original whitepaper describes the Day 1 Injection very clearly. Out of the 15% of maximum network supply allocated to development (aka the current Network Royalties Pool), 5% of network supply was supposed to go to the core development team, and 10% was to go to the pool for general development. To keep these promises, 5% of total network supply should still go to the core development team, leaving only 10% of maximum supply for the foundation to meet the various obligations outlined in RFC 0061.
The original whitepaper unclearly stated that “15% of all safecoin earned will be allocated to the developer pool.” And that “5% of the developer pool coins will be given to the core developement team”. The promise to the core developers pool should be maintained. Based on the surrounding text and context given in the whitepaper for day 1 injection vs. ongoing royalties this means 5% of 15% = 0.75% of network earnings should be given to the core developers in perpetuity. The alternative view is that 1/3 of the total network royalty should be allocated to core development of the network (5% of total earned) vs. 10% of total allocated for general app development. This second interpretation does not seem accurate given what was outlined in the whitepaper. Instead, the 5% of 15% for core development and 10% of 15% for automated rewards appears to most accurately adhere to what was proposed in the whitepaper. This leaves a maximum of 85% of the 15% ( 12.75% of “earned” SNT) allocated for royalties to be administered by the foundation.
What if people see the 10% of max supply from the white paper as important if not more important than the 2^32 data objects representing 2^32 tokens?
We already lost the tokens being data objects as specified in the white paper. So then the 2^32 tokens represented by 2^32 data objects is lost.
My point is not to be taking any sides but to point out that due to various reasons the original constraint on 2^32 data objects representing 2^32 tokens is gone. What we still can do is to keep MAID represents 10% of the total.
As I said before there is a problem whether you attempt to reinstate the 2^32 tokens but without the promised backed by actual data objects OR keep to the MAID is 10% of total supply.
Either way represents a difference in perceived/theoretical MAID value compared to the other way. The paying back doesn’t fix it either just adds another complexity to the perceived/theoretical MAID value.
Its a damned if you do and damned if you don’t situation. I favour the one that the markets have already adjusted to years ago rather than trying to reinstate an already lost token backed by data objects to give 2^32 tokens from the white paper. Just using the 2^32 is another bastardisation of the original concept.
