RFC 0061 — Safe Network Token Distribution

Monero had a really shoddy initial distribution, doesnt seem to have done it any harm at all.

It seems my memory and a very
quick search failed me spectacularly here

Thank you for this comment, @oetyng. Super helpful. Still digesting it and will hopefully be able to make the time to circle back with a less nonchalant response to the RFC.

1 Like

Also there should be funds for marketing and I think @Sotros25 and others would agree.


This is the model (perhaps 1:1 model is a better name or 10^0 model) that most cleanly represents the actual workings of an integer based digital cash system. (as opposed to say a rational number based system).

If we use bitcoin as an example, the real fundamental unit is the “satoshi”. ie, the integer number 1. What we think of as “1 BTC” is actually 100 million of these. So the decimai place was arbitrarily moved 8 digits. In fact, the decimal place is purely a display mechanism because internally all (properly written) bitcoin software when performing mathematical operations will represent 1 BTC as integer value 100,000,000.

This translation represent a small but non-zero (and unnecessary) hurdle towards clear understanding and clear thinking with regards to “what is 1 BTC?”, “how is it divisible?”, etc. And the arbitrary nature of the decimal point placement is distasteful to anyone that likes things to be clear, logical, and have a solid rationale behind them.

The rationale for the 1:1 model is simple. One token, ie 1 SafeCoin, is represented by the number 1, which is the smallest integer possible. The human representation and the machine/software representation are the same, so understanding and calculations are simpler. No translation is necessary! KISS!!! Machines and humans can both use Si prefix names such as kilo, mega, giga, to abbreviate large numbers and move the decimal point in a familiar, standardized way, which is also used in many other contexts such as distances, hard drive size, weights, chemistry, etc.

So for example we could use the term “100 megasat”, or “100 mega” which would be equivalent to 1 BTC. As price discovery starts happening, humans would naturally tend toward using whichever SI prefix is most useful to use as a whole number given the pricing of the currency around common commodities such as eggs, milk, movie ticket, etc. Thus we hopefully avoid the strange situation of a carton of eggs that costs 0.00032 BTC.

Further, all software that deals with BTC presently must perform a translation from internal integer representation to decimal representation for displaying an amount, and likewise translate from decimal to integer when accepting input amounts. While not especially difficult, it does introduce/require code that is not technically necessary, and an additional surface area for bugs. And this is for every single piece of software, eg: wallet, exchange, library, accounting, financial, loan processing, banks, and on and on. Why require this rigamarole?

In closing I view arbitrary decimal placement as a barrier to understanding for newcomers to the currency. It is an attempt to somehow “simplify things” for people which in reality complicates intuitive and full understanding and adds unnecessary cognitive load on ongoing basis. It introduces possibility of calculation errors and disagreements because humans will calculate based on decimal floating point values displayed on-screen which are then prone to rounding errors and will not match results performed by software performing proper integer calcs.

or so it seems to me.

If the RFC is going to continue with the 10^9 decimal placement rather than 10^0, I would like to see it contain a full rationale for that decision, based on something more valid and logical than “other cryptos did it”.

a final closing thought: if Satoshi Nakamoto had chosen the 1:1 model for bitcoin, people would today just be using it without a second thought and we wouldn’t even be having this discussion. It is only because he chose the “arbitrary decimal point model” that the cryptocurrency industry has grown up around it and regard it as somehow “natural”. People are naturally inclined to do what they are familiar with, even without any logical basis for doing so. I challenge the author(s) of this RFC to do better and provide a thorough rationale for their chosen model, or else adopt the 1:1 model and its KISS rationale.

speaking of authors: I do not see any author(s) listed in the RFC document. Please add one. (git history shows Jim Collinson as the commiter.)

edit: one additional point. With BTC, one typically hears that there are 21 million BTC that could ever exist. Yet this is a kind of sleight-of-hand because in reality 21,000,000 * 100,000,000 satoshis could exist. People think: there are only 21 million btc and there are 7 billion people, wow. That’s a very different thought than: There are 2,100,000,000,000,000 BTC units and 7,000,000,000 people. This is an example of how playing with the decimal point can confuse and radically alter people’s thinking. Again, because we are obfuscating the system rather than representing the system as it actually is.

In this sense then, the decimal point placement (of existing cryptocurrencies) can be thought of as a type of deception and/or marketing propaganda to make the token seem more scarce than it actually is. I abhor deception and marketing propaganda.


@bones, I would request that you elaborate further (mainly out of curiosity as to your definition of “shoddy initial distribution” in the Monero case). But I’d like to keep this thread super focused on the RFC. So let’s take this one to direct message or to a separate thread if that works for you.

To be clear, I think your comment is relevant re:looking for precedents, but a more thorough look at a certain number of these is something that I hope I can put together and circle back with as part of a better response to the RFC.

1 Like

The 9 decimals comes from efficient use of u64 integer.

2^32 SNT is 10 digits. Nine decimals means then that is 19 digits.
A u64 has 19 1/2 digits (the 1/2 is part use of the 20th digit). So then using 9 decimals is maximising the use of the u64 variable.

u96 gives 28 1/2 digits which would allow 18 decimals.
u128 gives 38 1/2 digits which would allows 28 decimals

Granted that is correct, although Safe has the better chance since its all in the DBCs

If the version is built in up front then the installed software base can recognise the difference. It is not a reason to say we only keep the original.

Personally I would like to see u128 implemented from the start even though 28 decimals is too much for reasonable use for the forseeable future. But personally, and I argued this last time, 9 decimals is building in a limit that is short sighted. 18 decimals would be far better and 28 while not likely to be usefully for decades will not be an issue.

But I can see that to go above 9 decimals at this stage is to invite spamming using 1 x 10^-28 dust. But with all the work the client has to do to split a DBC and send it, may mitigate this issue where sending dust will cost the spammer more than actually spam.

One way to implement 9 decimals now and increase later is to use a u128, but the core code will not approve a DBC with more than 9 decimals. Then during an upgrade the node software can then increase the number of decimals to say 12, and next time to 15, etc. Since Nodes have to upgrade within a reasonable period (ie only be a couple of versions behind). And the enable point/trigger is worked into the upgrade which occurs after the time all nodes will have had to install to still be allowed on the network.

@JimCollinson I consider hard setting the decimals to 9 places will sorely limit usefulness of micro payments since the perception (& hope of many) that SNT will rise to 1000$ or more and thus 1x10^-9 is at the limit of a micro $ payment. Even 12 decimals will cover this even if/when SNT is worth a lot more in 20 years.

I suggest that DBCs use u128 (allows 28 decimals) even though we would not want 28 decimal places, but this would then provide a simple path, through code upgrades, to increase the allowed decimal places from the original 9 over time as its needed and/or compute power/net-speeds is higher.

Basically there is 28 decimals from the start but the last 19 places have to be zeros while decimals is limited to 9


In this case, airdrop is more of a regulator term of art, rather than mechanism/process.

I’m not quite sure I understand where your KYC worries come from? None of the proposed distribution of Remaining Tokens, or MaidSafeCoin funds etc should require that.

That is correct. Hence the increase to maintain a 1:1 conversion.


:wink: … not if we have a transaction fee.

Transaction fee of 1x10-9.
SNT at current sort of prices - choose high $1.00
1 SNT ==> 1,000,000,000 transactions.

Yea, transaction fees will not stop spamming billions of transactions.

Transaction fee at a very high value of 1x10-6

Yea for a mere 1000$ you get a billion transactions and destroy micro transactions in the process since half the micro transaction is in fees. Spend 2 x 10-6 to tip 1x10-6

Nope with nine places reasonable fees that allow micro transactions will not stop spamming.

This is one reason why the concept has always been for no fees, change the world, especially in places where 1 cents is worth something.

Thanks for all the discussion folks. There is a lot to respond to here, so I think I’ll start with making some observations on the larger themes, and then make some subsequent posts to cover more:

On Automation of Network Royalty Distribution…

First thing to note here is that the automation discussed isn’t “the automated distribution of Foundation funds” it’s the Network distributing them directly without them touching the Foundation at all.

We are specifically looking at ways we could make this kind of automated distribution of funds ready as part of the launch candidate. But at the same time please don’t underestimate the size and complexity of this work, particularly for App Developer Rewards.

If you are advocating that the launch of the Network should be delayed until this automation is in place, then you may have to accept the possibility of an indefinite delay; because like it or not, we have a finite runway.

But we are specifically providing for this kind of scenario in the RFC, which allows us to get the Network up on its feet, sustaining itself, and then continue to work on these key features. Note here, that this is also the scenario envisaged by the original project white paper, because it is a significant task, and therefore was originally slated as coming post-launch.

On Automated Distribution of the Remaining Tokens…

We also provide for the scenario where things like the automated distribution of the Remaining Tokens to users are subsequently deemed too technically challenging, or inadequately secure, with a backstop that would have them airdropped MaidSafeCoin holders and investors, in-line with what many are suggesting.

This outcome isn’t the first choice as it has it’s own significant drawbacks, and it doesn’t align with the original prospectus:

Namely, distributing the entire supply to a small group of people, maybe only a few thousand, is still a significant concentration of power in the hands of a few. Far better aim to distribute these funds among users of the Network, through the process of it being used. It’s far more inline with the ethos and aims of the project.

But… as a backstop, we’ve conceded, it’s a pragmatic solution, and limits the even higher concentration of resources at the Foundation, hence the reason we have provided for this backstop in the RFC.

On Core Developer Rewards…

Likewise, calling for things like core developer rewards—part of the original promise described in the Safecoin white paper—to be removed from this package is eliminating the proposed ongoing funding of the Network development which would include things like automated distribution of funds, etc.

So please think carefully before you dismiss the idea of Core Developer rewards, as it’s a tenet of the sustainable ongoing development of the Network, and one of the few areas where automated distribution of funds is likely to be unworkable, and thus will require oversight by the Foundation.


Not sure how technically feasible this idea is going to be but her goes. Is there any way to reward the first ‘x’ amount of safes started that have provided ‘x’ amount of resources for ‘x’ amount of days/weeks? Could work as a good marketing campaign and help with the distribution of the tokens.


We are looking at solutions where there is a curve to pay out at a higher rate in the early days of the Network, and then level out as it grows. And in particular rewarding those who are contributing to the Network in the form of storing data and/or contributing resources.

As you point out this could be both a good mechanism for equitable distribution of the remaining supply, and also serve the Network well in terms of early adoption.


I guess as usual I’m using Tezos foundation as precedent. No one had to KYC when participating in the crowd sale but the Swiss foundation upon network launch required it.


As far as we can tell at the moment, it shouldn’t be needed for MaidSafeCoin holders to get their SNT via the airdrop.


Early adoption could be a curse if cost of upload goes through the roof when subsidy really declines, people upload less, & network has to raise storage cost dramatically to keep farmers happy … all of which could trigger a spiraling collapse wherein price to upload keeps going higher and consequently fewer and fewer actually upload … death spiral.

This has happened many times now in crypto - it’s a financial reality.

SN needs to have a resilient economy and this is the opposite approach.

SN needs to be GREAT ENOUGH to attract people to use it WITHOUT initial subsidies.

SN is NOT Bitcoin and the same methodology for distribution is a fundamental error in thinking IMO.


It’s a blank slate at the moment, and I’m sure it will be subject to many discussions and options. Flat vs curve, various rates of release etc. Nothing is set in stone.

But it’s worth remembering that, as you point out, we are not primarily a crypto currency project, and resilience is the name of the game.


I think we need to talk about this kind of dichotomy in response to this RFC:


On the whole the RFC tends toward staying true to the original project white paper and what it proposed to investors, ICO participants, and MaidSafeCoin holders within the current context.

Whereas some of the alternative proposals in the thread really tear it all up; some to a lesser degree, some to a coach and horses degree.

Minor changes to my mind would be things like the decimal point placement as @danda is pushing for. It has little bearing on the functionality of things, so yeah, perhaps we should be open to that? But at the same time it might feel like a significant shift to MaidSafeCoin holders to move from the 1:1 redemption they’d been promised, to now it being a 1:2,328,306,437 swap. Perhaps it is worth the effort pain and time to explain, and walk people through all that, or maybe it’s an unnecessary distraction?

But then there are others that are really more significant indeed, such as the entire supply being airdropped to MAID/eMAID holders ahead of launch (which is a very dramatic shift indeed with significant consequences), or those that effectively end the possibility of core developer rewards etc.

These are dramatic shifts late in the game, what are supporters, and investors, and holders (and yes financial regulators too) to make of them?


I’m not certain of the various items here, but late in the game for whom? As I’ve already mentioned in this thread, many of these ideas have been debated here for years. That the team is only now paying attention to it … well what can I say really. Finger pointing isn’t going to help here, so IMO, break things down and tackle them one at a time as quickly as possible in new focus threads.

Otherwise, it’s again as I said earlier, what’s the point of this discussion if the team isn’t really open to hearing options and making changes. I’m certain we all have better things we can be doing if this discussion is just for show (which I really want to believe that it isn’t).

1 Like

I don’t think this, nor your other comment earlier, is particularly fair nor constructive.

There are many aspects that have been debated for 8 years. Thousands of threads, tens of thousands of discussion points, often with out any particular conclusion to hang a hat on, often circular and polarised. All of which are digested by the team.

The RFC process is an opportunity to actually dial in to a conclusion. If you’d like a specific aspect changed, then let’s discuss it.

It’s late in the game in that we are approaching a launch, and we now have to put plans before a regulator so we can actually be in a position to issue the token, let people have their return on investment, have the ability to access the services of the Network via MaidSafeCoin, and build a viable and resilient Network.

Now is the time to dial it in. I’m not sure how that is finger pointing.


And often too, just the opposite. There is more than one thread that has polls that lead to clear conclusions.

No point debating that though - you must be aware of it if:

I asked some questions in my first post in this thread which weren’t even answered. Kinda not very inspiring to go further for someone who wants to discuss it … is it?

I get that … and I don’t want to point fingers (I wasn’t accusing you or the team of pointing fingers - I was saying that I didn’t want to point them), but, since we are here I’ll just say it: The team could have been nailing all this down years ago … where was the leadership when the runway was long? Do you understand the frustration here or am I just not reaching you?