Updated: RFC 0061 — Safe Network Token Distribution

How many tokens do you have? I will buy that all and please leave here. I dont like keyboard attacking. Send me DM.


You should hear the original by our own wee Scottish lad Eric Bogle. He wrote it. Check it out on the tube. Also waltzing matilda. Very much questioning war and it’s outcomes. Great stuff


But the proposed solution not only fails to address this problem, it makes it even worse.
The fact that it also concentrates all the loss on one particular group makes it, as I keep insisting, very dangerous.
The people of Maidsafe, the company and the two foundations (Swiss and Scottish) must be protected as much as the network itself.
The enemies of this project will not hesitate to attack any weak flank they can find, so it is imperative to leave none behind.

From Maidsafe.

These are the public terms of the Crowd Sale and, therefore, have a legal binding which, in case of non-compliance, could lead to a legal action.

That’s why I think it’s so important to keep the max supply at 2^32 at all costs.

The simplest is to reduce the Remaining Tokens, which would only drop by 0.54%. For practical purposes it would not affect anything.

The other solution, which would personally piss me off a lot, is to reduce the Extra Maids from the Network Royalties Pool.
If these Extra Maids were used for the development of the project, it makes sense to allocate them to this pool.
Legally, this seems to me, by far, the least problematic solution.

Of course the people at Maidsafe have put many hours of thought into the making of this RFC and will have considered these solutions as well as consulted with legal experts.

If they still believe that the original solution is the right one, despite the problems some of us have encountered, go ahead with it.

The worst that could happen is that the project could be delayed even further.

1 Like

Yes, true.

Yes, I see your point here and agree. I thought my original suggestion to have the foundation handle the overprint via an ad hoc payment would create the least disturbance and bring up the point that the core development team should still get 5% of max supply based on the whitepaper promises. But to be perfectly honest, you are completely correct here.

The overprint issue can/should be viewed as an advance on the 5% that was promised to the core team. I will revise RFC0061A to reflect this.

I don’t think it is ethically proper to break the 70/30 split between future contributors and past/present ones. I agree that @oetyng’s suggestion is the most proper.

I strongly disagree with the above statement when it comes to the day 1 injection of the Genesis Supply. The whitepaper was very clear how much was promised to core developers and that 5% should be honored in some fashion.

That’s a utilitarian perspective and may have little consequences, but it is not the correct choice here. @oetyng hit the nail on the head in his comment above with the correct course of action imo.

Yes, agreed.

I have no knowledge of Swiss procedure, but depending on how much detail has been submitted in the foundation paperwork, there may be no need to derail anything. Perhaps a few amendments may be all that are needed? Correcting something like the requested max token issue from 4525524120 in the application to 4294967296 in the network means a simple burn of the difference in terms of foundation bylaws, no?


What you described is what was proposed here.

1 Like

Not exactly. You add a payment of 100K. I don’t know why, which seems to me to be totally inadequate.
In fact it looks like a bribe that raises legal issues which is exactly what we want to avoid.

That’s actually in the original safecoin white paper, and we don’t agree it is right to keep it there, so that’s why it doesn’t feature in this RFC.

1 Like

Like Jim said, I only included it because it was promised in the whitepaper. If there is another way to pay the interested party and keep that promise to their liking, then it would make sense to eliminate it from an RFC.


Not really since the network doesn’t exist yet. The initial resource pool is for work done after the pool is created. The sale of the 23 million went to the initial development of the network to get it to launch.

This is also what the white paper was saying. There was the 100K$ repay the dev team for work done to get to launch. But as @JimCollinson said its not really fair and that would be because of the various funding sources has paid them already including the 23 million.

The resource pool though apart from the 100K$ was for work done after launch.

This is why developing the RFC is not quite as easy as it seems and trying to be dogmatic is showing up problems and the RFC0061A has the 100K$ in it so trying to say the 23 million sale was part of teh resource pool is a double error


So true.

Even the ‘simple’ solutions turn out to be very complicated and take a lot to work through. There are a lot of moving parts involved that often conflict. Nothing is simple with humans and money.


The team has taken on challenges that no one has succeeded in over the past decades, and the results are now visible now.

You should be ashamed to tackle something like this. What is important than this results. Be a man.


I absolutely will! :slight_smile:


Dunno if Eric Bogle is “ours” anymore, he’s been an Aussie icon since 1970ish. He’s retired now but me and Mrs Southside saw him a couple of times at Mayfest back last millenium . She has just about everything he ever recorded. Used to be easy to sort out her Xmas.
He can be bleak but very powerful. "Music to decisively slash your wrists to "

While exploring Eric Bogle in pre www days, I came across Redgum kinda similar in some ways

Having a Redgum tape in Turkey in the early 90s got us a 2 day cruise and a pal for life but thats another story…


Ok, the updates are in. Let’s get this thing to bed! :sweat_smile:

I’ve updated the OP at the top of the thread with the latest, or you can compare the changes directly on GitHub.


Here we go again :woozy_face::joy:


Good way to express the exchange amount (amount of MAID) and its exchange, no hiding, double dipping accounting or smoke and mirrors. :clap:

There seems to be a mistake in this
You have

  • initial allocation of 30.536806937% (1,311,545,871) Made up of
    • MAID emission of 10.536806937% (452,552,412)
    • Shareholders of 5% (214,748,465) and
    • Royalties of 14.463193063% (621,189,412)
  • remaining tokens 70% (3,006,477,107)

But 10.536806937% + 5% + 14.463193063% == 30% which is not what you said the Genesis supply would be

Also Genesis supply plus remaining supply is over 100% (100.536806937%)

I suspect that you meant to have the remaining tokens to be 69.463193063% (2,983,421,425) and of course the Royalties to be the full 15% (644,245,094)

10.536806937% + 5% + 15% = 30.536806937%
30.536806937% + 69.463193063% = 100%

This seems to be an excellent way to deal with the situation. Both this and the now alternative to me seemed good, but for all the complaints (possibly quite valid) this seems to solve the problem with the least issues long term.


Yes, sorry, my bad missing the changes on the genesis supply after a series of internal revisions.
Will correct.

Breakdown at the end details the current proposal vs the options correctly though.


I thought it was just an error being made in figures and understandable after a long day of revisions


@JimCollinson I think upping the Genesis supply is the fairest way.

The shareholders were only ever promised 5% of max supply (2^32) in the original paper and really they are still getting what the plan was originally, so they really are not missing out.

And the royalties should be 15% too to be fair to the foundation and the devs that will receive some of the 15%


If you could breakdown how this could be done without disadvantage, I’d be interested, otherwise I’d say this is the mythical cake-and-eat it beast.