The 2^32 being adhered to is more important than the 10% being adhered to because nobody who owns MAID loses out financially if the 10% of total supply becomes a bit more than 10%, but every MAID holder loses out long term if the total supply is increased by 5% above what was specified.
It seems to me that an easy solution would be to keep the max supply as it was from the start, and the over-mint error can be corrected by taking it from the amount allocated to recipients who as yet don’t exist (farmers), and therefore can’t feel cheated, even if only in a very small way.
This way, shareholders, ICO participants, other MAID holders aren’t diluted, and the total supply is as originally planned.
The error can’t be undone, but in my current thinking, it should be corrected in a way that doesn’t disadvantage, even slightly, anyone who has participated & supported so far if there are easy alternatives.
In the end it’s not likely to be a huge issue in terms of valuations, but in principle it seems wrong to compound the error rather than fix it.
Leave enough meat on the bone for the next people - the increase in the price of the token will come from new speculators (I know there is a hypothesis that it will come from users of the network, but FileCoin, Storj, Sia, Noia and all other crypto projects offering Web3 show that the interest is at best case minimal and at worst close to 0).
For new speculators, enough meat on the bone seems to be the amount of tokens in circulation - the fewer tokens that can be dumped on the market in the coming years, the better for the story, why the price of the token will go up.
Why do you think the 70% of max supply portion for future farmers aka node operators should fix it? In the commentary above, I propose that the foundation should fix the problem by way of it’s portion of the genesis supply. Isn’t this more fair?
Maybe I’m misinterpreting what you’ve written, so just to clarify the situation …
People that don’t hold tokens now will buy it at a price that already takes into account the greater number of tokens. The market cap is going to be whatever it will be but the market participants will take into account the total number of tokens when deciding what to pay for them.
This means that at 2^32 the price per token would be higher and at the new larger number the price per token will be lower (1. all else being equal - see below)
So people who buy tokens in the future will be buying them at a lower price and the total number they buy multiplied by the price will equal the same value no matter the total number decided today.
The current MAID holders (myself included) are the one’s losing out in this situation (again all else being equal) as we can expect a lower price and hence a reduced total value for the tokens we hold even though the percentages remain the same.
Is all else equal? For me I think this is more of a perception issue though and not purely a token number issue. If we change the percentages I expect that this will be used as FUD to say that Maidsafe is manipulating their original percentages plan in order to favor early investors. This in turn will keep a number of people away from the project for a longer period of time and there may also be legal issues here.
So the price per token may very well decrease in the short to medium term if the percentages are changed simply do to FUD.
Overall this is a complex issue. None of us can know the best choice.
Then they have the wrong perspective. Everything is absorbed and rolled up into the total genesis supply of 30%. The 2^32 hardcap can be maintained, and the 30/70 split is maintained. The only group responsible for fixing the overmint discrepancy is Maidsafe via the foundation from the foundation’s portion of the genesis supply. This is the simplest and fairest solution.
Every MAID holder loses every day the network is not up and running. I find this debate huge waste of time. If the network fails or is never launched, our holdings are going to be zero, ±10% is still zero. If the network works and is a success, than we will be looking at 1000x growth and more. Again 10% at the start of exponential curve means almost nothing.
± 10% is one good or bad day in crypto, nothing more. And every day the devs spent with this “injustice” or whatever people call it, is a day that pushes launch further away and we all lose.
Based on your comment it appears you missed the whole point of the discussion or didn’t read my review posted above. This debate isn’t so much about “injustice”, but in delivering on promises in a fair manner to ensure long term trust and ultimate success of the project.
I must say, this seems correct (i.e. the part where the overmint could be notarized with least change).
It’s not like the foundation is going to lack funds, and I don’t see any legal or perception issues here.
This is an aspect/alternative that I don’t think was deeply considered, not among the aspects I discussed and brought up anyway, when I was recently evaluating the pros and cons of these variants in internal discussions.
This would be maintaining all original values, proportions and numbers, except the foundation gets less, right?
The argument for current solution, afaik, is that some of the most important numbers are preserved. But not as many as this alternative would?
I can’t see why it would be preferable to choose an option where some numbers get changed, if there is one where they don’t.
How much the foundation gets is an arbitrary number anyway and is going to be huge regardless.
The perception issue is lower with that one I’d say.
I could be wrong of course, but that’s what it looks like to me.
Except… it’s not “the Foundation’s portion”. It’s rewards for people contributing the to the Network, such as app developers, content contributors, marketers, core developers etc. The Foundation is merely the distributor of those funds.
The perception issue would be smaller I think, that is the biggest question really. And simplicity.
We already got the extra 23m for core developers, due to to the overmint, but as an upfront payment. Seems fair and simple to consider it as such.
The absolute values to distribute are going to be huge anyway?
And, it can be notarized directly on the core developers share (which was before the change already very high at 5%, likely way too high, so it’s somewhat already accounted for.)
So no need to even communicate it as taken from app developers, content contributors, marketers etc.
I don’t think there’s going to be a lack of core developer funds the way it’s designed now.
Just wanted to acknowledge that specific part of your point @jlpell (not all of what you’ve written) it looks factually correct to me.
But (given that it really is a better solution) that
would probably take a bit of time to digest and updating the application, which in the end might not be considered worth it.
No, the intent is to give the maximum level of divisibility without imaging the performance of the Network.
It was deemed that, at this stage, that can be done at a maximum of ^9.
We’ve been over this in previous threads and announcements… but to re-state:
The royalties are now to be just one pool, to be allocated as appropriate for the needs of the Network, rather than a hard 5/10% split. 5% for core devs to begin with, is likely just way to much, and then to maintain that level of split going forward, where the balance of the work and rewards required as the Network matures, would likely be wildly inappropriate.
I thought of the node operators because 1) they won’t notice because they don’t exist yet & can’t feel to have missed out, and 2) because they have the largest slice, so the impact is the smallest.
But your suggestion of the foundation could also work, and maintain the 70/30 split if that is important (I like @oetyng’s comment on making the least changes being preferable).
Whether it’s the foundation or the node operators, it seems better to me that the over-mint error just means that those coins were accidentally released early, rather than it for some reason having to change the total coins to be issued & reduce ICO participants’ eventual total share.
My perception is that changing the total supply to be different from the white paper is likely to be a big issue for credibility etc in the eyes of some… not saying it’ll be a disaster, but best avoided if possible.
The original plan was for crowdsale participants to receive 10% of the total allocation.
The over-mint happened and was wisely used to keep development going when needed.
When this happened, in my view, there was the 10% of final distribution crowdsale participants’ MAID in circulation, plus some extra MAID that was accidentally minted.
It seems neater and fairer to take that extra MAID from another future allocation than changing the crowdsale participants’ share from 10% to 9.x% and raising the eventual total supply.
I’m arguing for keeping the 10% for ICO participants as originally planned. The current plan is what deviates from this - not my proposal.
The current plan reduces the ICO participants’ 10% and raises the total supply by ~5% from the whitepaper.
My proposal (and @jlpell’s) maintains the ICO participants’ 10% and the total supply from the whitepaper, which I expect would be far less likely to cause FUD than changing them.
That sounds like the right category to allocate the extra MAID to, given the funds were used for development by core developers, just brought forward in time due to a happy accident.
Feel free to ignore it. There’s an RFC about it, and people are commenting as requested. A decision needs to be made, and sharing thoughts to help find the best way forward is helpful, especially when a few people feel the presented plan could be improved.
We did try to make a decision. It’s inordinately difficult. I am not sure any RFC in this field will be 100% agreed, and I fear a constant battle between friends can happen.
I try and follow on but it’s really emotional for some who are super keen on making valid points and do so with such gusto.
Hard one, folks. How do we work with this? Whoever we agree with, then others will complain, then we try and sign off and then last-minute changes and on we go.
This is after a massively long process in our discourse going over a load of options on this one. It does seem to me that it’s not that important in many ways, but to others, it’s the whole project’s credibility at stake.
The whole Swiss foundation work will possibly be made much longer and trickier if we cannot get broad agreement somewhere, but then a poll means folk don’t read/research and vote with what they feel it might mean.
Happy Saturday afternoon in the depths of what is really being said by whom for what reasons.
If that’s the case, then what has been proposed to take the ~23M overprint from the 5% core dev (now part of the 15% for the foundation) is the simplest and least controversial path. It involves the least amount of changes and explanation. It damages no one so there’s no opportunity for FUD unlike the proposed option.
I’m not asking at all for the below changes to be made, just pointing out that:
My point further above about a perpetual royalty tax not being needed is further backed by the official recognition that the initial 5% from genesis could be too much
Lumping together 5% core dev and 10% app/grants/etc. can also go in the reverse direction from the ostensible reason for which it is being done
That the foundation would favor proposals that give it more token/control isn’t entirely surprising. A lot of deliberate and potentially painful efforts will have to be made to recognize that natural tendency and take steps against it from the very outset as it’ll be even harder later on and those who might say something would have either been driven away by then or be entirely exhausted of sounding like a broken record against a well-meaning tide that can’t get the point until too late. Don’t just think about the current crop of foundation administrators and whatever will pull on them, think even further to times after that when people you don’t know/like control the foundation whether due to time or by some decree.
Hard disagree from me here. Network royalties are for the ongoing sustainable funding of not just the core open source development of the Network, but also the app developers and the whole client ecosystem.
(And let’s not forget about schemes such as pay-the-producer etc.)
These are fundamental parts of the project as a whole, and I think you will have a tough job selling ripping that all up to the community.
Well quite. And that’s by design, because none of us can foresee the funding needs of the ecosystem ahead of time.
