RFC 57: Safecoin Revised - Specific Question concerning Safecoin size and Number + Polls

I have started this topic to try and gather from the community, reasoning, opinion, ideas and input to some aspects of the coin itself for the benefit of the Dev team and planning purposes. Since the coin is to be in a u64 variable in the back end and represented as a 9 decimal place Fixed Point there are a few options available for consideration.

The next post in this topic will lay some of the relevant posts from the main RFC topic for the revised safecoin RFC. And the third Post will be some polls to help gauge people’s opinions and desires for safecoin

I am doing this now because these should be easy to implement now compared to what is to be implemented as it relates to the u64/u128 and exposing micro now and nano later or nano now.

And finally this topic is purely for the discussions of the number of decimal places 9 (u64) or 28 (u128) and whether its considered necessary to expose nano safecoin now (or 28 places if u128) as well as micro and milli. Please consider your uses and future IoT needs.

Now the APPs will control how you view your safecoin balance/transaction amount and is not dependent on the API or backend, except if only micro exposed then the APP is limited to micro (0.000001)

Please vote as it was requested to gauge community position on whether the nano safecoin should be exposed in the API now or not.

The other two polls are related.


Here are the relevant posts from the main RFC topic and ones that I considered best representative of the subject at hand. You can add more to the discussions by replying


The first poll is about whether we keep to 2^32 SAFEcoins or expand the number to fill the 2^64 while keeping 9 decimal places (or 28 places if we got with u128). This would mean that the exchange from MAID to safecoin would be 1 MAID = 4,294,967,296 nano (Approx 4.3 coins/MAID). If u128 is used then it would be similar except 28 decimal places.

There is no fear of inflation as each MAID keeps its value. All MAID is still the approx 10% of total supply of safecoin when exchanged. Only perception is affected.

@Fraser , you might find this helps to use all bits

  • Keep to 2^32 coins for SAFE coin 1 MAID => 1 Safecoin
  • Use max allowed variable for safecoin 1MAID => 4.294967296 safecoin (~4.3 safecoin/MAID)
  • Give me Candy - ( No Opinion either way )

0 voters

Second poll is for consideration of IoT and if anyone feels it is necessary for IoT to be able to transact smaller amounts than 1 nano safecoin. when price of safecoin goes high, for instance over 100$ or maybe 1000$

OR do you feel that nano is not small enough for such a innovative coin such as safecoin and the SAFE network.

EDIT: Please Note that the 28 decimal places option (u128) does not mean that the network (back end) needs to work down to the 28th place. It could work with say 12 places on launch and change its lower limit later on to say 15 or 18 places with an upgrade changing the one lower limit value. Good Front end APPs would work with the whole 28 places anyhow so they don’t need changing and the Front end APPs only show what you want to see.

  • Use current proposal of u64 giving 9 decimal places (nano)
  • Use a u128 variable that provides for 28 decimal places (this represents more atoms in the universe and is practical infinite division)
  • Give me Candy - ( No Opinion either way )

0 voters

Third Poll is for whether you would want the exposure of nano safecoin immediately or wait for the eventual exposure of nano and only have micro safecoin allowed till its upgraded sometime later which maybe during beat but more likely after release.

  • Expose nano now so it can be used and tested
  • Expose only down to micro now and wait for nano to be exposed.
  • Give me Candy - ( No Opinion either way )

0 voters


My opinion based on experience is that if nano exposed at the API is delayed now there is a reasonable chance that other priorities will see the nano exposure and testing pushed back past release


I just want to say, that first option converting 1MAID to 4.3 Safe coin does not solve anything and the reason is simply technical to use all available bits. But on the other hand, this will be complete mess on exchanges. Imagine the day you are waiting for many years and on that day all exchanges will have problem with swapping MAID to SAFE. If it is not 1:1 than they have to create new market for it or the worse scenario there will be sudden drop on the graph to 1/4.3 value. Imagine the reputation of this coin between traders who does not understand details and spread news based on graphs. It will look like huge failure. The amount of confusion this will bring is not worth it just to satisfy such a weak technical argument. Any conversion different than 1:1 will bring lot of confusion and should be avoided like a plague untill it is not really necessary for many good reasons.


Good point.

But all it would mean is that they close the MAID market and open the SAFE market with your converted coin.

Or if the exchange does not do the conversion then they will have 2 markets. And likely close the MAID market at a certain date.

They can do this easy enough since MAID is on the omni protocol and SAFE is on the SAFE network.


This will mean lost history of trading. Lot of confusion to old users. Don’t forget that vast mojority of people holding MAID is not following this forum. Not talking about all the lurkers who knows about the project and would like to jump in once it ready. How would they act if they see price of new coin traded with much lower value than it was before? Of course we can discuss all possible scenarios but all this is discussion about how bad it is. There is not a single argument from user perspective for this mess. It is just about counting damage this will bring. So there has to be really good reason to risk it. And saving 2 bits or so seem like very weak argument.


Are there any downsides to 128 bit? Would performance suffer much on low power devices? Are the plenty of languages or libraries that support 128 bit?


Not really. The Api would have to only go down to a certain amount to keep it sensible. Say 12 places until the SAFEcoin $$ value increases by doing a update on the code.

Also Dust transactions may also be a problem too


I’m in for infinite divisibility.

How many user accounts are possible on the safenet?

1 Like

Depends on number of vaults and amount of storage. approx 2^128 if it were possible to store that amount. Quite impossible since there are not enough atoms let alone bytes


More than one account for every atom in the universe. Can’t get much more democratic than that :grinning: .


I haven’t been following these threads closely enough to understand the arguments either way so I haven’t voted as it would really just be a dart throw. Could someone layout the tradeoffs inherent in the various options? A simple list of pros and cons of each would be helpful to a lot of us here I’m sure.


That is why I gave the “Give me Candy” option so you can tell us that you don’t know or don’t have a preference either way. Its important for gauging how the community feel. For instance if more people don’t care then the other options have less significance.

So with u64 and proposal to pad it out ~4.3x maid token. what is the total proposed nano-safecoins?

my number is: 1945975371600000000

but that seems too small … I was only counting the maid tokens which are ten percent of the total safecoin that were to exist in the original design.

so: 452552412×4.3 = 1945975371.6
then: 1945975371.6×10^9 = 1945975371600000000

but is that right?

Its 18,446,744,073,709,551,616 nanos - 2^32 * 2^32. If you notice the 4.294967296 is 2^32 nanos

4,294,967,296 MAID * 4.294967296 = 18,446,744,073.709551616

So a wee bit over 18,446,744,073 coins

One advantage I see is that this gives us 4 times the max coins allowed and utilises the whole u64 word which @Fraser was desirous of. It means also that nano is slightly smaller in value than if 1:1 exchange

I must admit I am also one who likes to see no bit lost. Every bit is precious (sung to Monty Python’s famous tune from the movie). In saying that though I am also aware that sometimes for practicality wasting a bit or two is the better option saving on either program space or following best practices or making it clear to the next programmer. I once put a timeshare tasking scheduler and ran tasks in a D2 6800 kit that had 256 bytes of memory. That is squeezing a lot out of little memory


“Don’t care” and “Don’t know” are very different things though.


@JPL Yea, I know but please conflate the two so you can be counted. I am not assuming the “give me candy” means any more than you are not choosing at this time.

1 Like

Considering changing my vote. Since the PUT layer is being removed, more granularity in Safecoin could be needed.

Still, 28 decimal places is a bit much. So the 4x option (i.e., full use of u64) may be an okay compromise.

For now, not necessarily forever though. We need to test it.