Clarifying safecoin distribution percentages

In working over some related data, I again ran into something that hasn’t made sense to me at times but which I’ve never sorted out till now.

I don’t remember where it’s originally laid out, but the distribution of safecoin is supposed to be according to the following percentages:

10% crowd sale
5% existing investors
5% core development
10% app devs
70% farmers

These add up to 100%, right? Well, yes and no.

Something about this never quite made sense. Here’s why, and what the actual scene is.

The 15% for crowd sale and investor pools are created from the total of possible safecoins. Most or all of these will likely, eventually be spent back into the network in exchange for network resources, and thus become available for farming, just as any other safecoins which come into circulation.

The remaining categories (farmer, app dev and core dev award coins) are very different when viewed from the perspective of percentages. These safecoins are generated on an ongoing basis as shares of successful farm attempts and divided according to a relative proportion. Of the 100% of safecoins which are farmed in any given time, 0% are allocated for crowd sale or investors, as those obligations are handled by the pre-farmed coins.

The awarded coins will be generated as parts of the 100% of safecoins farmed, rather than the 100% of safecoins possible. These are different percentage pools, but they are presented in the breakdown above as part of the same 100%, thus the confusion.

Mathematically, according to these ratios, out of the total of successful farm attempts, farmers get 14/17ths, app devs get 2/17ths and the core dev pool held by the Maidsafe Foundation gets 1/17th.

In percentages, according to the above relationships, the farmers are awarded 82.24% of successful farm attempts, the app devs 11.76, and core devs 6%.

I don’t really know exactly how important this is, but it has been snagging bits of my attention that I couldn’t identify till now. It is factual and the distinction doesn’t seem to have been appreciated.

I guess implementing the algorithm could be done in a 14/2/1 priority order.

As I say, I don’t know if it’s very important, but I’ve had my say.


Sorry I do repeat some of what you said and I am not disagreeing but approaching it from a slightly different angle to examine the 17ths figure you arrive at.

As was discussed later after we were given the %ages.

The farmers get 100% of the FR that a coin is available
The app devs get 10% of FR that a coin is available.

But the complexity is that this is ongoing. So after 10 years for example the farmers may have collectively received some 1000 times the coin max of 2^32

How, simple the recycling of he coin

So really we need to split the %age mentioned into 2 groups

First the 15% which is made up of the crowd sale and investors.

Second the ones that are ongoing. and that is the rest.

For the first they get that absolute number of coin (15% of 2^32) once only on day 1. Then they can hoard it and sell it off whenever they desire. BUT eventually they will be spent into the network so the amount held by these people (and who they sell them to) will reduce to near zero.

In other words the coin held from of the first group will reduce towards zero over the years.

The second group is simply a %age that is related to FR

  • Farmers 100% of FR (set in the RFC and proposed code.)
  • APP devs get 10% of the FR as stated
  • Core development is one I am not sure how the 5% is arrived at, but is also related to generated coin.

And the second group is there fore not a percentage of the total coin 2^32, but a percentage (at this time) tied to FR and can end up paying out 1000 x 2^32 over the years/decades.

I have repeated some of what you said, to show that the 17ths is incorrect. In fact they can get 1000 * 100% of coin supply over time. Time and operation is the key to how much farmers etc eventually get.

It is very important to understanding how farming rewards and any other rewards fit into the scheme of coin supply and recycling.

1 Like

That is my whole point.

All coins generated over time (aside from the one-time investment chunk) are generated as a result of farm requests. That is the only mechanism for bringing safecoin into existence on an ongoing basis.

Safecoins from successful farm requests are assigned according to a ratio, with the farmers getting the bulk, and the other categories getting smaller portions. This is a dynamic, ongoing ratio.

Whatever ratio is ultimately used, it’s a fixed ratio per unit time and needn’t be thought of in relationship to the 2^32 cap at all.

I arrived at the 17 scale by isolating the lowest common denominator from the ratios presented as follows:

core pool = 5
app devs = 10
farmers = 70

5 is the lowest common denominator. Divided out that makes:

core pool = 1
app devs = 2
farmers = 14

Total units to be broken up:

1+2+14 = 17


core pool = 1/17
app devs = 2/17
farmers = 14/17

It may be implemented differently, but that’s the proportions based on the data given.

The confusion is generated by putting the two different things in the same basket and saying they add up to the same 100%. One is a fixed percentage of the ultimate total. The other is a dynamic flow relationship. In order to think and talk clearly about the ratios, we need to differentiate the two.

[Looking at this post, I can’t help thinking it looks like @dyamanaka might have written it.:grin:]


Thanks @fergish, I never considered this, and @neo for clarifying. I think I get it now, but didn’t realise I hadn’t already :slight_smile:

If you guys could sum this up in one or more FAQ style entries, it would be a great thing to have in the wiki FAQ so we could answer this with just a link.

It is going to get asked about a lot of times I’m sure.

Anyone from the community by all means have a go. We need some really clear references that answer these questions.

@Erik_Aronesty I think your answer is above! :slight_smile:

1 Like

I’d be happy to do that in the near future. The only thing missing is a touch of feedback from @dirvine or someone else close enough to the center of how it will be coded.

1 Like

It is like that, a nice way of looking at it perhaps. In code it looks more like (IIRC)

Farming Rate = FR
Get request name = XXX [ a 512 bit hash ]

if XXX % FR == 0 then farming payment
if XXX % (FR * 10) == 0 then app dev payment (10 times less)
if XXX % (FR * 20) == 0 then core dev payment (20 times less)

Where % == modulo divide. So when it equates to zero it means no remainder.

Hope this helps, again sorry for speed, forgive mistakes :wink:


Thanks, David. I think that’s enough for me to work out a reasonable presentation.

1 Like

Thanks, Neo.
I didn’t really get this when you posted it, but after David’s post, see what you were saying.


/me as an app dev makes note to keep adding/altering insignificant bytes until my hash is a multiple of 10 to get more money :slight_smile: (I kid of course, just thinking out loud)

1 Like

Nice idea :smiley: however the hash is made up of nodes along the path and none of us can see those :wink: IT’s not the hash of your message, although that is involved.


One thing I have a question on here: in above when you say “farming payment” you actually mean “farming attempt” right? Then the attempt may or may not result in a safecoin actually farmed?


Yes all these payments should be attempts, good catch John, thanks for that.


One further question on this for the record: Do all Get Requests result in a farm attempt by one of the three categories, or does some predictable (or unpredictable) percentage of Get Request result in no farm attempt at all?

Only one in FD gets result in a farm attempt. FD = (1/FR). So no not all gets result in a farm attempt.

Each get is tested for a farm attempt and only if the modulus operation results in zero does a farm attempt occur.

FR is actually the FD = 1/FR

From the RFC

[code]If this result % farming divisor (modulo divides) yields zero then

  • This data is sent to the group who are closest to result
  • This request is a POST message as a safecoin request
  • If there is a safecoin available of the name result then
    • The safecoin is created and the owner set to the wallet address provided in the result packet
    • The safecoin close group then send a receipt message to the wallet address to inform the user of a new minted safecoin allocated to them.[/code]

And this test will occur if a dev get, and will occur for core dev test. And PtP if it ever is included

Thanks. That’s what I figured, but wanted to make sure so I can write it in descriptives accurately.

Also note the “If there is a safecoin available of the same result”

This means that if there is no safecoin at that safecoin address (worked out from the result) then one is generated, but if the coin already exists then the farming attempt will fail. So as the available coin drops (lots of coin issued) so more of the farming attempts fail.

Substitute PtD, Core_dev, PtP in place of farmer above, they use the same logic for coin issuance attempts, just different rates.


If I have made any mistakes then I am sure @dirvine will correct it as it is important that you have the most correct info to write about

1 Like

Pardon the stupid question, but, in this case, coins used to PUT data on the network will not go back to the farmable safecoin list ?

What becomes of them then; how can they reenter the network economy if they cannot be assigned to a new owner upon a GET request?

They are deleted, which creates the space for a new coin.


Ok, a lot of this still confuses me but let me start by asking in the area I can at least explain my confusion. When I read the safecoins get “recycled” I think they will be broken down to be reused again. So recycled means to me an unlimited supply of safecoins and not the 4.3 billion limit I thought I understood.

Then I read the coins will not be recycled but deleted which to me means they will be destroyed forever and the 4.3 billion could potentially all be deleted over time.

So will safecoins be recycled or deleted. Will it be an unlimited supply or limited? Thx