RFC 0061 — Safe Network Token Distribution

This is a good RFC from the standpoint of making intentions clear. The foundation is the weakest part about it but at least you recognize that. Given the the DBC work that has been done, I don’t see any reason why an automated system couldn’t be devised where the network doles out the remaining 70% of rewards to farmers and 15% to devs over time. For that reason I’m currently not worried about the mention of the foundation middleman, because I seriously doubt it will be required by launch time.

Even so, here are a few comments on what needs to be eliminated, just in case:

This section needs to be eliminated. The foundation finances should not be tied to the network economics in any way shape or form. It should rely on donations from the community just like any other non-profit.

This should be eliminated.

This too should be eliminated.

This is not a good way to do it.

Repeat: eliminate any financial ties between the foundation and the network.


To my mind, a fair/good launch of a cryptocurrency/token is one that:

  1. Is announced well in advance as widely as possible so that all interested parties have a chance to get setup and participate from the moment of launch.
  2. is fully decentralized and automated.
  3. Is part of the regular working of the decentralized software. ie, block rewards or storage rewards would count, but an ico or airdrop would not.

I’m with @bogard in that I typically would not trust a “cryptocurrency” that distributes via a foundation rather than an automated system wherein the exact mechanism can be viewed and studied by all in an open manner.

I understand there is some history here, there was a prior ICO, etc, which complicate things a bit. For all remaining funds, I would urge project leaders to invest in devising an automated system that is available at launch, even if it means further delay.

ps, the word “governance” is anathema to me. Kind of a shorthand used by many projects for “our code/incentives don’t quite work so we’ll wing it with voting and politics”. I agree with @jlpell that section should be eliminated.



We’ve had 2^32 drilled into our heads for years. I consider the 4,525,524,120 to be a typo.

I’ll reply the same here as I did in the weekly update:

I can’t remember in which topic I’ve seen the discussion regarding total distribution but I believe there was a point where the total supply would be in circulation from the start of the network by having 1 MaidSafeCoin equal 10 SNT. Looking at the proposal now the 1:1 kinda surprises me, especially since the SNT will be so dividable.

Could you explain why the network would function better with say 4,525,524,120,000,000,000 available subunits than with 4,525,524,120.

Additionally, is there a reason we’re opting in for 10^9 instead of say 10^8 that most exchanges use? I think we should try to stay uniform with what’s common in crypto if we’d like to have a bridge from the network to external exchange accessibility.

2^32 was facet of the original design concept of Safecoin. It was a hard limit due to that design.

But as some of you may recall, due to some ‘fun times’ at the ICO thanks to a mastercoin bungle, there was an over issue of MaidSafeCoin which left us with a conundrum on how to deal with the additional supply and maintain a 1:1 redemption as promised.

Thankfully with the new token system design we no longer have any such restrictions on what the Total Supply can be and we can match the ICO amount, and maintain the same splits as per the original paper.

Hence the change to 111.5 SNT per share.

There are 2,029,332 shares. Any left over SNT will be melted down, forged into a medallion and presented to @Bogard at the Network launch ribbon cutting ceremony.


If we accept there will be a limit on the divisibility for us to work around due to technical and performance constraints then the rest of the decision is really about usability, perception, language and pragmatism.

We did consider some other options (which granted, I could have included in the RFC, but I’ll put them here now) which really come down to how many whole units we have, where decimal places go, and where the ‘whole token’ is placed in the spectrum.

I’ve done a comparison with Filecoin on price as a very very very rough guide to a (almost im)possible (to predict) dollar value that SNT might have in the medium term. This is only to give you some way to compare the different solutions between each other in terms of fiat conversions, and how people might manage that in their head. Please don’t take it as anything other than that. And it was also done before the start of winter.

(Note: some of these calcs for share price etc include the original 2^32 starting point, but you get the idea)

Proposal for Nice Numbers

Here’s an option. One where we deviate from the original supply, but use nice powers of 10 for symmetrical goodness. For this, we can still do typical English names for the biguns and then only need to go down the the micro for the sub-divisons. This is pleasing to me.

Total Supply of base/whole units: 1013 or 10,000,000,000,000 or 10 trillion
Number of sub-divisions: 106 or 1,000,000 micro tokens
Total number of available sub-units: 1019 or 10,000,000,000,000,000,000

Decimal Name
1 000 000 000 000 trillion
1 000 000 000 billion
1 000 000 million
1 000 thousand
1 token
0.01 cents
0.001 milli
0.000 001 micro

Let’s take a look at the implications for conversion from MAID and for shareholders too. It’s not of much consequence long term, but it will need to be explained as a deviation from the original promises. People might be wary and call a bait-and-switch late in the day. Incorrectly of course, but something we have to manage, and a drawback to be aware of:

Number of SNT per MAID 2,328.31
Number of SNT per Share 246,386.50

And then there’s the…

Comparison this with the Filecoin numbers
Implied SNT dollar price $0.0003
Est. SNT cost per TB 174.62

The Many Units Proposal

Here’s an exercise in looking at the proposal with the base unit being the smallest thing, and then working up from there

Total Supply of base/whole units: 1019 or 10,000,000,000,000,000,000 or 10 quintillion or 10 exa tokens

Decimal Name
1 000 000 000 000 000 000 exa (quintillion)
1 000 000 000 000 000 peta (quadrillion)
1 000 000 000 000 terra (trillion)
1 000 000 000 giga (billion)
1 000 000 mega (million)
1 000 kilo (thousand)
1 token
Number of SNT per MAID 2,328,306,437
Number of SNT per Share 246,386,495,655

And then there’s the…

Comparison this with the Filecoin numbers
Implied SNT dollar price $0.0000000003
Est. SNT cost per TB 174,617,085

In the end what we've pitched in the RFC what may not be perfect, but is a pragmatic solution, as it's still reasonably usable and is the closest to the original proposal i.e. giving MaidSafeCoin and share holders what they were promised:

Proposal sticking with original whole token supply

Total Supply of base/whole units: 4,525,524,120
Number of sub-divisions: 109 or 1,000,000,000 nano tokens
Total number of available sub-units: 4,525,524,120,000,000,000

Decimal Name
1 000 000 000 billion
1 000 000 million
1 000 thousand
1 token
0.01 cents
0.001 milli
0.000 001 micro
0.000 000 001 nano
Comparing this with the Filecoin numbers

Given the current Filecoin cap, and their stated storage cost (which is notoriously hard to interpret, but we try) multiples by a factor of 5 which gives a rough approximation of perpetual; storage costs we get:

Implied SNT dollar price $0.71
Est. SNT cost per TB 0.075

So to summarise, given our best guess at the likely performance limitations given the currently available information we have divisibility at 10^9, and for simplicity and pragmatism we stick as close to the original supply proposal.


@JimCollinson To allow for further division in the future when maybe real prices soar and SNT needs more division and/or hardware/networking allows it, is a real simple version number for amounts.

Then simply go from a 64 bit integer number to 128 (or 96) bit number and increase the version number.

Thus if Version 64bit DBC is presented then when spent it is changed to version 128 bit for the new DBCs

Simple as and how for decades we’ve been able to upgrade protocols while allowing old devices to continue working even though they use an old version

So no need to consider any more than the 9 decimal places (19 digits total) at this stage.


I’m not sure your reply answered this question. That could be my mistake though, some of this is going way over my head to be fair. Did I miss it?


There is a wide variety of divisibility across crypto currencies, and no standard to speak of. Ethereum for example, is 18 decimal places IIRC.

How cute. Just make sure it’s large enough otherwise it’ll be too small for my big head.


Fully agree.


A small portion given to the foundation at genesis on the scale of what the ETH foundation did could even be forgiven (say 5% of the combined ICO and Maidsafe portions). But the current proposal has the foundation taking 50% of the genesis (ignoring the 70%), which completely turns on its head the norm that such a non-profit/foundation should rely on the community.

Thanks for the clarification Jim. However, now you’ve created another unnecessary tragedy of a bungled conundrum. Your proposal violates the number one rule of crypto… don’t change the hard cap. This also damages the cultural aesthetic of the Safe Network from those who have been following the project for so long. It’s the equivalent of ripping the hood ornament off of a classic rolls royce and replacing it with a sausage. This is only the second time I’ve ever wanted to use profanity in a forum post. I find it insulting and have a hard time understanding how you could have possible thought this was a good idea. There was no hard limit “due to the design”. It was an immutable hard limit by decree, that supporters agreed to, and any proposal needs to honor that.

What you should have proposed on the back of a napkin:

  • The total supply of SNT is (2^32) = 4,294,967,295 and will be issued at genesis.
  • MaidSafeCoin holders will exchange for SNT at 1:1; which equates to 452,552,412 SNT.
  • The genesis allocation to MaidSafe shareholders is 226,276,206 SNT; to be divided proportional to outstanding shares of MaidSafe capital stock.
  • The remaining 3,616,138,677 SNT will be distributed throughout the Safe Network, to be paid out according to an automatic reward system to farmers, app devs, core devs, and/or other Network promoters (Pt*).
  • Data payment fees will be distributed such that 85% are give to node operators as Resource Supply Reward, and 15% to Network royalties (Pt*).
  • Each individual SNT will be divisible to no less than 2^32, with the possibility of having extreme divisibility in the future. A value of 10^21 is recommended (1 Sextillionth) for SI compatibility and decimal intuition.
  • The Bamboo Garden fund will serve as an endowment for the Safe Network Foundation, revenue generated from it and any other donations to it will cover activities of the Foundation. The Foundation will have no role in the decision making of the Network, nor financially benefit from any Network activity. Instead it will support scholarship, social good, marketing, IP protection, pursue litigation against Safe Network adversaries, guide global policy makers, and educate the public about the benefits of Safe Network technology or how it can improve online safety, data integrity/security, privacy and human rights.

For the record I support the proposal as set out in the RFC. I expect there will be changes but the wholesale rejection by some seems at best misguided and unnecessarily nasty in its tone in some cases. None of the explanations of why this is a terrible way to do things in this or that respect are convincing to me and much of the comment seems to me wrong, or ignores what has been explained.

It feels like a coordinated attack on MaidSafe and the project. I don’t think it is necessarily the case but by ignoring facts or stating things which aren’t true, suggesting naivity, ignorance, betrayal and so on are unjustified and hard to understand given the history of the project and those making these accusations.

It makes me sad to see this just as things are coming together. The timing :thinking:


Also is an open invitation for more KYC to an anonymous token which tbh, is a fumble at the starting line. Afterwards obviously gives people power still but I’d rather see decentralized and automated import of Bitcoin private key and bam into your anonymous wallet. :man_shrugging:t3:


Unless you’re intent on avoiding tax on gains, is KYC to secure your SNT an issue? Converting MSC to fiat will also require KYC, as would SNT to fiat so that’s presumably not the concern. So what does KYC do here other than encourage people to pay tax on gains?

The question then becomes what is the risk/benefit of an automated conversion assuming it could be implemented. Presumably it might put those implementing it and publishing the code at potential risk. In some jurisdictions such things could mean very long jail terms. Is anyone expected to take that risk for what seems little benefit?

Calling it a fumble ignores these questions which I suspect are relevant to the proposal.

1 Like

For me no. If I wanted fiat then like you suggest, pay your damn taxes (so KYC before or after conversion is fine) but if you want to live outside the system and solely in the Safe Network, which should be your right, then yes.

1 Like

i hear people say this often wrt various cryptocurrencies in a hand-wavy way. But I’ve yet to see anyone actually do it. It’s not actually that simple because by the time one reaches a point where it is needed there is a huge installed base of users, software (lots of different clients, etc), exchanges, financial news reporting, etc, etc, etc.


Then how is KYC when converting to SNT problematic?

“For, after all, how do we know that two and two make four? Or that the force of gravity works? Or that the past is unchangeable? If both the past and the external world exist only in the mind, and if the mind itself is controllable – what then?”

[Then any criticism of the RFC or incomplete trust in the Foundation/Maisafe is a direct, coordinated attack on the project.]

“How can I help it? How can I help but see what is in front of my eyes? Two and two are four.” [And this isn’t a direct attack on the project, and what is being stated isn’t false.]

“Sometimes, Winston. Sometimes they are five. Sometimes they are three. Sometimes they are all of them at once.” [And yes, all the arguments are false and unconvincing and you shall just trust the decree. Otherwise it’s a coordinated attack.] "You must try harder. It is not easy to become sane.”

I’d prefer if we could keep things focused on the specifics of the RFC