Updated: RFC 0061 — Safe Network Token Distribution

The overprint should never have happened.
The overprint should never have entered circulation.

People will look back at the history of this project. The initial mistake being carried forward means people will need to know about the above two historical events.

If you correct it now, the past is irrelevant.

2 Likes

Most of them won’t, they will care about “now” and future.

Why? People will come a use SNT/network according current rules, same as you come and start using Bitcoin without knowing about all past forks for example.

7 Likes

Continue the mistake and be forever judged on your actions. Correct it now, and nobody cares.

It can’t be erased, it’s there and the only thing MaidSafe will be judged on is how they handled it then and following on until launch.

It can’t be “corrected” because there is disagreement about what that means.

Those who object to this option seem to keep keep saying how terrible it is - in their opinion - and failing to convince those who take other views to change their minds.

All that does is re-enforce that MaidSafe are not wrong.

I think you have run out of arguments and refuse to accept that you can’t make a good enough case for what you believe to convince others.

I’m still open to be convinced. I’ve explained how I see it (see cross post above).

You have the opportunity to explain why you disagree with that and show me my error.

8 Likes

Basically it boils down to weighting up the problems caused whichever path is taken.

There is (perceived/real ??) problems no matter which path is taken.

Personally the acceptance of the error in the original minting of MAID and dealing with it by doing the spirit of the white paper rather than the “law” of the white paper is a much better path to take.

The people who had their MAID diluted by a very small %age back then have lived with the dilution, the markets have dealt with the dilution and moved on, the current pricing on MAID includes the effects of the dilution. In my opinion the option that deals with the dilution and incorporates the effects of it is the more honest way to go.

And keeping to the spirit of the paper and that 10% was minted resulting in a slightly higher total supply is not a bad solution. The markets already dealt with it, much of the original ICO MAID has changed hands with it being slightly diluted from original intentions.

tl;dr There are issues whichever path is taken, markets have dealt with it and moved on for years, many people have accepted it and perhaps even sold their original ICO holdings.

9 Likes

The overmint was a mistake, it could have ended at that point by burning them.

Spending the overmint was a choice, which should be repaid. In a sense a form of overdraft.

The initial white paper should remain true at all costs. It’s going to potentially be referenced alot.

Answer these questions for me and change my mind

who benefits by increasing the supply to perpetuate the overmint mistake?

who benefits from buying back and burning the overmint mistake?

Will maidsafe get to spend the overmint 9 more times?

1 Like

What is overmint ? I dont understand your points.

A mistake was made when creating the amount of MAID for the crowdsale meaning that instead of 2^32 tokens being created, about 10% more were created. That amount was kept aside by MaidSafe (or the Foundation?) at the time, and when funds ran short MaidSafe we able to use them to keep the project going.

The only thing that really matters to me here is that we give MaidSafe the best chance possible of delivering the network.

I think some lose sight of that or are less interested in it than I am.

4 Likes

I have no problems that they used the extra tokens to keep the project going. My point is the “overprint” and the choice to use them tokens are two distinct events.

I feel the choice makes it something maidsafe shoul repay from their portion of network royalties. I mean that’s exactly what the royalties are for!

Late here and I probably shouldn’t be posting when I’m half asleep …

@jlpell Could you link to your original arguments here that you’ve mentioned? I will look for them tomorrow otherwise.

It’s obvious that you’re upset with the distribution and I’d like to have a fuller understanding of your thinking.

My perspective so far is that at least in regards to the dilution, this doesn’t seem to be very significant – especially as most of the tokens that MAY ever exist will be minted over many years - possibly decades. But you’ve said that was just one of the issues … so I’d like to get a bigger picture here.

Cheers.

2 Likes

I sympathize with people who are voicing discomfort with the change in max supply. It’s a small change, but sets precedent (the mere proposal of it has already set the precedent so going ahead with it or not is moot imo).

With that in mind, I suggest that the 10% of the max supply for dev rewards (outside of the 5% for core devs) not be issued at genesis and instead should also be implemented via a future network update as proposed for the 70% remaining of max supply.

Separately, I also suggest that the 5% perpetual core dev tax/royalty on every future payment should either be removed or a sunset provision should be added so that it’s removed after a period of time (e.g., 10 years). This is partly because it would open up the network to serious risk from forks and the committee managing that perpetual royalty tax to liability. Also, the developers of the current internet didn’t implement a perpetual 5% tax on it, did they? Bitcoin also doesn’t have a perpetual tax/royalty to be paid to its core devs. Truly open protocols don’t need that. Better to take the initial cut from genesis (which isn’t unsubstantial) and husband it well.

Edit/addition for clarity:

  1. The liabilities I allude to are both moral and legal.
  2. Just as the initial technical design specification advanced in the original white paper has changed considerably for the better, allowance should be made to update the initial economics of the network for the better and to take into account the progress that’s happened in the crypto space in the decade since.

The issue with this in my opinion is that the 5% is to fund ongoing development. To close it after a period is to set a sunset clause on (paid) development of the core systems of the network.

Well its even less at 5.36% and the markets have already adjusted to this years ago. Even with the sale of those extra the markets have adjusted and work with the new figure.

3 Likes

Bitcoin and Ethereum continue to get developed year after year without a royalty tax.

And so does a lot of other open sourced stuff. But does that mean there isn’t good alternatives?

As to those 2, I often wonder how much holdings these people have and is that an incentive. Safe is likely to not have the same dynamics with devs (or anyone really) having large holdings. Maybe a few investors will accumulate large holding to speculate on tokens, but SNT is more a utility token than speculative like BTC and ETH

You maybe right that any core dev payments is not needed after the network is matured. I’d hate to see development slow to a crawl too soon after launch due to devs needing to live. Yes I know you suggested maybe even 10 years which would help a lot there.

6 Likes

Development though is slow and ponderous - especially for bitcoin. Buterin has a lot of capital as he owns a lot of Eth so can continue to fund things as he likes. Plus there aren’t nearly so many developers for small projects and SAFE will be small for some time to come yet as many in crypto have become averse to alts.

further it would be a real shame to lose the developer base for such a complex project as SAFE and then to depend on random devs to try to comprehend it and code for it, just seems impossible to my mind. The team needs ongoing funding post-beta as there are going to be many bits and pieces that need to be added as well as fixes that will need to be done by those who solidly grasp the project.

All that aside, I suspect that this topic is really not up for radical change at this stage. The devs have too many other important things to work on and this topic is a big distraction.

So unless there are real technical or legal issues, then IMO, we should move on.

10 Likes

Worth repeating.

A mistake was forced on us a long time ago. The market has long since adapted to that. Lets move on unless you can directly point at someone who has suffered real loss as a result.

10 Likes

Just sticking to the original points and it seems like an optic and moral view and definitely valid and though I acknowledge and respect that perspective and the people voicing them, I just don’t think it matters as much as it once would have.

Even most long time ago investors are surprised it’s still being developed if you bring this project up. Noobs to crypto don’t know or care about history just the flavor of the week or what’s shiny. So much time has passed. Most in the space don’t even share the same ideals as us real early folk.

Pre mines etc are nothing compared to other scams and crimes in the space and this. It was an honest mistake not even made by Maidsafe that has been thoroughly considered by a responsible team that without this mishap may not have weathered till now to deliver the world the gift we’re all here to support, so it’s just peanuts to me.

Maidsafe already owes a shit ton too. To pre crowdsale investors, to bank2the future investors, to community members that lent MAID. Shit happened and not all of it looks perfect but if it gets us where we need to be, that is real.

13 Likes

Your thinking is in error here. If I’m not mistaken this statement is completely false and inaccurate.

I’m mobile now and need a few days when I can get back to a keyboard and compose my thoughts or offer an alternative/revised RFC 0061A on this matter that actually makes sense from both a technical and ethical perspective.

3 Likes

Thanks for replying but again you’ve just repeated that I’m wrong (both here and in the dev update topic) and not said what is wrong in your view. Just saying, because there’s nothing new I need to respond to.

1 Like

Just to point out again, that there is not a hard 5%/10% split for core and app dev royalties anymore, as per the original safecoin paper. It’s 15% that can then be appropriately distributed over time as the needs of the Network and the ecosystem change.

Initially, 5% for might seem appropriate at Network launch, but years down the line, it would be wildly too much. So we’ve removed such hard ringfences, and it will be up to the Foundation to decide the allocations appropriately.

But I’d also like to point out that this 15% also includes things such as the notion of app rewards paid directly and autonomously by the Network in future, and also Pay-the-Producer (type) schemes, where the Network can automatically reward content creators/uploader.

But it’s also worth noting that the web as it is currently constituted is built upon privacy invading, data harvesting, ad-based business models, and that most opensource projects that hold the whole thing together are woefully and precariously underfunded.

We are not aiming to replicate that.

9 Likes